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@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
