| Message ID | 1393629520-12713-2-git-send-email-santosh.shilimkar@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, 28 Feb 2014 18:18:38 -0500 Santosh Shilimkar <santosh.shilimkar@ti.com> wrote: > Based on earlier thread "https://lkml.org/lkml/2013/10/7/662" and > further discussion at Kernel Summit'2013, it was agreed to create > 'driver/soc' for drivers which are quite SOC specific. > > Lets take the discussion forward with this patch. So what happens if you put something in say soc/banana and 3 months later the same IP block shows up in two other devices both of which have their own soc/ directory already ? What happens when the same blocks shows up on both a SoC and later externally ? Where does a soc specifc gpio driver go ? It seems to me we've got a lot of confusion here because drivers/ is split by type, and we've also got arch/* machine specific drivers and we've got drivers/platform which is intended as far as I can see for everything you'd put in drivers/soc except for that which goes in arch/* anyway. If QMSS is arm specific why isn't it in arch/arm, if it's not why isn't it in drivers/platform ? Just trying to understand the point of drivers/soc. Alan
On Sun, Mar 02, 2014 at 05:12:06PM +0000, One Thousand Gnomes wrote: > On Fri, 28 Feb 2014 18:18:38 -0500 > Santosh Shilimkar <santosh.shilimkar@ti.com> wrote: > > > Based on earlier thread "https://lkml.org/lkml/2013/10/7/662" and > > further discussion at Kernel Summit'2013, it was agreed to create > > 'driver/soc' for drivers which are quite SOC specific. > > > > Lets take the discussion forward with this patch. > > So what happens if you put something in say soc/banana and 3 months later > the same IP block shows up in two other devices both of which have their > own soc/ directory already ? This isn't so much about IP blocks as about all the other glue logic and management functions that vendors so far seem to implement in their own ways. I don't remember the name we agreed on, I don't think it was drivers/soc -- partly because naming it that brings up the kinds of questions you have. Paul took it upon himself to start sorting this out (and merge through us on arm-soc), so he hopefully remembers better than me. :) > What happens when the same blocks shows up on both a SoC and > later externally ? > > Where does a soc specifc gpio driver go ? drivers/gpio, of course. This isn't changing that. > It seems to me we've got a lot of confusion here because drivers/ is > split by type, and we've also got arch/* machine specific drivers and > we've got drivers/platform which is intended as far as I can see for > everything you'd put in drivers/soc except for that which goes in arch/* > anyway. > > If QMSS is arm specific why isn't it in arch/arm, if it's not why isn't > it in drivers/platform ? drivers/platform are for specific vendor platforms. I.e. various laptop vendors, a few server vendors, etc. Code for a whole silicon vendor's driver does not belong there. > > Just trying to understand the point of drivers/soc. Shortcutting most of the discussion by focusing on this question. ;) We've been struggling to find a home for some of the code that we want to keep in the kernel tree, and we sat down to talk with (among others) Greg at KS to try to figure out how to move forward. The code isn't the pure drivers. Those we find homes for. GPIO, for example, is a clear choice: they go under drivers/gpio. IRQ controllers under drivers/irqchip, etc. We've been good at finding the places for these, including making new homes for them where none was before (pinctrl and clk subsystems come to mind). The type of code we were still looking for a home for is the glue code that tends to be shared between drivers. For example, on a communication chip it might be queue managers that are shared between SATA, DMA engine, Ethernet controllers, crypto engines, etc. There's no obvious place for us to locate that today. Most of this code is handled like a library with the drivers calling into it. So, again, it's not for drivers as much as for shared management code. It will not be used for drivers (the Keystone patch adds an actual driver, so we need to talk about that as well :). And as with all other code in the kernel: If we find that more than one vendor has something compatible, we make them refactor and share the code when we discover it. It's a method we use now and it's working pretty well. Finally, your question on why we're not locating this under arch/*? It's not architecture-dependent code, some vendors have several SoCs that are very similar but with different cores of different architectures (MIPS, ARM, PowerPC, ARM64, etc). So a location outside of arch/ is needed. -Olof
On Mar 2, 2014, at 2:48 PM, Olof Johansson <olof@lixom.net> wrote: > On Sun, Mar 02, 2014 at 05:12:06PM +0000, One Thousand Gnomes wrote: >> On Fri, 28 Feb 2014 18:18:38 -0500 >> Santosh Shilimkar <santosh.shilimkar@ti.com> wrote: >> >>> Based on earlier thread "https://lkml.org/lkml/2013/10/7/662" and >>> further discussion at Kernel Summit'2013, it was agreed to create >>> 'driver/soc' for drivers which are quite SOC specific. >>> >>> Lets take the discussion forward with this patch. >> >> So what happens if you put something in say soc/banana and 3 months later >> the same IP block shows up in two other devices both of which have their >> own soc/ directory already ? > > This isn't so much about IP blocks as about all the other glue logic and > management functions that vendors so far seem to implement in their own ways. > > I don't remember the name we agreed on, I don't think it was drivers/soc -- > partly because naming it that brings up the kinds of questions you have. > Paul took it upon himself to start sorting this out (and merge through us on > arm-soc), so he hopefully remembers better than me. :) I think it was drivers/soc for the case that Paul was going to look at. I’d expect we’d go with drivers/soc/<VENDOR> to reduce churn between newer SoC families from a company sharing something with an older one, etc. > >> What happens when the same blocks shows up on both a SoC and >> later externally ? >> >> Where does a soc specifc gpio driver go ? > > drivers/gpio, of course. This isn't changing that. > >> It seems to me we've got a lot of confusion here because drivers/ is >> split by type, and we've also got arch/* machine specific drivers and >> we've got drivers/platform which is intended as far as I can see for >> everything you'd put in drivers/soc except for that which goes in arch/* >> anyway. >> >> If QMSS is arm specific why isn't it in arch/arm, if it's not why isn't >> it in drivers/platform ? > > drivers/platform are for specific vendor platforms. I.e. various laptop > vendors, a few server vendors, etc. Code for a whole silicon vendor's driver > does not belong there. >> >> Just trying to understand the point of drivers/soc. > > Shortcutting most of the discussion by focusing on this question. ;) > > We've been struggling to find a home for some of the code that we want to keep > in the kernel tree, and we sat down to talk with (among others) Greg at KS to > try to figure out how to move forward. We talked about drivers/lib and drivers/soc back at KS. Greg was going to start of drivers/lib and Paul was going to look at drivers/soc. > The code isn't the pure drivers. Those we find homes for. GPIO, for example, is > a clear choice: they go under drivers/gpio. IRQ controllers under > drivers/irqchip, etc. We've been good at finding the places for these, > including making new homes for them where none was before (pinctrl and clk > subsystems come to mind). > > The type of code we were still looking for a home for is the glue code that > tends to be shared between drivers. For example, on a communication chip it > might be queue managers that are shared between SATA, DMA engine, Ethernet > controllers, crypto engines, etc. There's no obvious place for us to locate > that today. Most of this code is handled like a library with the drivers > calling into it. > > So, again, it's not for drivers as much as for shared management code. It will > not be used for drivers (the Keystone patch adds an actual driver, so we need > to talk about that as well :). > > And as with all other code in the kernel: If we find that more than one > vendor has something compatible, we make them refactor and share the > code when we discover it. It's a method we use now and it's working pretty > well. > > Finally, your question on why we're not locating this under arch/*? It's not > architecture-dependent code, some vendors have several SoCs that are very > similar but with different cores of different architectures (MIPS, ARM, > PowerPC, ARM64, etc). So a location outside of arch/ is needed. > > > -Olof - k
On Feb 28, 2014, at 5:18 PM, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote: > Based on earlier thread "https://lkml.org/lkml/2013/10/7/662" and > further discussion at Kernel Summit'2013, it was agreed to create > 'driver/soc' for drivers which are quite SOC specific. > > Lets take the discussion forward with this patch. > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Kumar Gala <galak@codeaurora.org> > Cc: Paul Walmsley <paul@pwsan.com> > Cc: Olof Johansson <olof@lixom.net> > Cc: Arnd Bergmann <arnd@arndb.de> > Signed-off-by: Sandeep Nair <sandeep_n@ti.com> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> > --- > drivers/Kconfig | 2 ++ > drivers/Makefile | 4 ++++ > drivers/soc/Kconfig | 3 +++ > 3 files changed, 9 insertions(+) > create mode 100644 drivers/soc/Kconfig > > diff --git a/drivers/Kconfig b/drivers/Kconfig > index b3138fb..37f955f 100644 > --- a/drivers/Kconfig > +++ b/drivers/Kconfig > @@ -130,6 +130,8 @@ source "drivers/staging/Kconfig" > > source "drivers/platform/Kconfig" > > +source "drivers/soc/Kconfig" > + > source "drivers/clk/Kconfig" > > source "drivers/hwspinlock/Kconfig" > diff --git a/drivers/Makefile b/drivers/Makefile > index 8e3b8b0..0d8e2a4 100644 > --- a/drivers/Makefile > +++ b/drivers/Makefile > @@ -132,6 +132,10 @@ obj-$(CONFIG_VHOST_RING) += vhost/ > obj-$(CONFIG_VLYNQ) += vlynq/ > obj-$(CONFIG_STAGING) += staging/ > obj-y += platform/ > + > +# SOC specific drivers > +obj-y += soc/ > + > #common clk code > obj-y += clk/ > > diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig > new file mode 100644 > index 0000000..2f9d7d0 > --- /dev/null > +++ b/drivers/soc/Kconfig > @@ -0,0 +1,3 @@ > +menu "SOC specific Drivers" > + > +endmenu > -- > 1.7.9.5 Is there a follow up patch that populates this with something real? - k
On Mon, Mar 03, 2014 at 10:13:57AM -0600, Kumar Gala wrote: > > On Mar 2, 2014, at 2:48 PM, Olof Johansson <olof@lixom.net> wrote: > > > On Sun, Mar 02, 2014 at 05:12:06PM +0000, One Thousand Gnomes wrote: > >> On Fri, 28 Feb 2014 18:18:38 -0500 > >> Santosh Shilimkar <santosh.shilimkar@ti.com> wrote: > >> > >>> Based on earlier thread "https://lkml.org/lkml/2013/10/7/662" and > >>> further discussion at Kernel Summit'2013, it was agreed to create > >>> 'driver/soc' for drivers which are quite SOC specific. > >>> > >>> Lets take the discussion forward with this patch. > >> > >> So what happens if you put something in say soc/banana and 3 months later > >> the same IP block shows up in two other devices both of which have their > >> own soc/ directory already ? > > > > This isn't so much about IP blocks as about all the other glue logic and > > management functions that vendors so far seem to implement in their own ways. > > > > I don't remember the name we agreed on, I don't think it was drivers/soc -- > > partly because naming it that brings up the kinds of questions you have. > > Paul took it upon himself to start sorting this out (and merge through us on > > arm-soc), so he hopefully remembers better than me. :) > > I think it was drivers/soc for the case that Paul was going to look at. I’d expect we’d go with drivers/soc/<VENDOR> to reduce churn between newer SoC families from a company sharing something with an older one, etc. > > > > >> What happens when the same blocks shows up on both a SoC and > >> later externally ? > >> > >> Where does a soc specifc gpio driver go ? > > > > drivers/gpio, of course. This isn't changing that. > > > >> It seems to me we've got a lot of confusion here because drivers/ is > >> split by type, and we've also got arch/* machine specific drivers and > >> we've got drivers/platform which is intended as far as I can see for > >> everything you'd put in drivers/soc except for that which goes in arch/* > >> anyway. > >> > >> If QMSS is arm specific why isn't it in arch/arm, if it's not why isn't > >> it in drivers/platform ? > > > > drivers/platform are for specific vendor platforms. I.e. various laptop > > vendors, a few server vendors, etc. Code for a whole silicon vendor's driver > > does not belong there. > >> > >> Just trying to understand the point of drivers/soc. > > > > Shortcutting most of the discussion by focusing on this question. ;) > > > > We've been struggling to find a home for some of the code that we want to keep > > in the kernel tree, and we sat down to talk with (among others) Greg at KS to > > try to figure out how to move forward. > > We talked about drivers/lib and drivers/soc back at KS. Greg was > going to start of drivers/lib and Paul was going to look at > drivers/soc. Yes, drivers/lib/ is still on my TODO list, unfortunatly way down it... I'll get to it "soon" with some variation of "soon" :( greg "my inbox is full" k-h
diff --git a/drivers/Kconfig b/drivers/Kconfig index b3138fb..37f955f 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -130,6 +130,8 @@ source "drivers/staging/Kconfig" source "drivers/platform/Kconfig" +source "drivers/soc/Kconfig" + source "drivers/clk/Kconfig" source "drivers/hwspinlock/Kconfig" diff --git a/drivers/Makefile b/drivers/Makefile index 8e3b8b0..0d8e2a4 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -132,6 +132,10 @@ obj-$(CONFIG_VHOST_RING) += vhost/ obj-$(CONFIG_VLYNQ) += vlynq/ obj-$(CONFIG_STAGING) += staging/ obj-y += platform/ + +# SOC specific drivers +obj-y += soc/ + #common clk code obj-y += clk/ diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig new file mode 100644 index 0000000..2f9d7d0 --- /dev/null +++ b/drivers/soc/Kconfig @@ -0,0 +1,3 @@ +menu "SOC specific Drivers" + +endmenu