On Mar 2, 2014, at 2:48 PM, Olof Johansson <olof@xxxxxxxxx> 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@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. :) 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 -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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
