Re: [PATCH 1/3] soc: Introduce drivers/soc place-holder for SOC specific drivers

[Kumar Gala <galak@codeaurora.org>]

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

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation