Re: gpio-generic DT bindings?

[Tom Rini <trini-l0cyMroinI0@public.gmane.org>]

On 11/20/2013 11:15 AM, Stephen Warren wrote:
> On 11/20/2013 08:44 AM, Tom Rini wrote:
>> On Tue, Nov 19, 2013 at 03:38:20PM -0700, Stephen Warren wrote:
>>> On 11/19/2013 03:17 PM, Geert Uytterhoeven wrote:
>>>> On Tue, Nov 19, 2013 at 10:59 PM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
>>>>> On 11/19/2013 02:45 PM, Geert Uytterhoeven wrote:
>>>>>> This topic seems to come up from time to time.
>>>>>> Unfortunately the last time it coincided with the move of the mailing list
>>>>>> from ozlabs to vger, causing the mailing list archives not to have captured
>>>>>> the full discussion.
>>>>>>
>>>>>> Is there anything definitive/usable out there?
>>>>>
>>>>> What do you mean by "gpio-generic DT bindings"? A generic binding for a
>>>>> controller, or something else? I think it's best to have a specific
>>>>> binding for each individual controller, so it's always possible to know
>>>>> exactly which controller is present. Now, all the binding definitions
>>>>> should all look the same or as similar as possible for consistency...
>>>>
>>>> I mean DT bindings and DT support for drivers/gpio/gpio-generic.c.
>>>
>>> We should have DT bindings for particular HW, not for a driver. After
>>> all, DT describes HW, not a particular OS's driver.
>>>
>>> The path to adding DT support to gpio-generic.c is to define a binding
>>> for the particular HW you're interested in (which would quite likely
>>> only contain compatible, reg, and perhaps some other standard properties
>>> like interrupts, clocks, power domains, etc.). There would be one
>>> binding and compatible value for each different HW block you want to
>>> support, although they could all share the same schema and definition.
>>> Then update gpio-generic.c to bind to that (those) compatible value(s),
>>> and have some kind of table that maps from compatible value to whatever
>>> configuration structure gpio-generic.c uses internally.
>>
>> This I think is the rub that Geert is getting at.  The driver is
>> generic.
> 
> That's an OS-specific implementation detail that doesn't affect DT.

I got an off-list poke that this is being worked on, so I don't want to
inflame things.  But it's not really.  The hardware is presenting a
generic bit of functionality.  The only thing missing here is a
standards body declaring this a Whatever 1.0 compliant Doodad(tm).

>> You feed it a little info and it Just Works.
> 
> But, this information historically is a platform data structure in a
> board file, right? That means that historically for every new board
> using the driver, you needed to edit kernel code (the board file) to
> provide that platform data. If with DT you still need to edit kernel
> code (the driver) to add support for the HW. So, the situation with DT
> is no worse that the situation with board files.
> 
>> Having to patch
>> the generic driver N times for vendor,foo-gpio would be a step
>> backwards.
> 
> In fact, with DT you now edit the driver once per SoC/chip that embeds a
> particular GPIO controller IP block, rather than once per board that
> uses the IP block. That's likely a lower number of code edits, so you
> have gained something already.
> 
>> How do we have a binding here that lets us be as flexible as
>> we are today?
> 
> I think we already have that - something better in fact.

Putting on my old arch/ppc guy hat, "look we moved the editing/conflict
mess to another place, and it's a less messy now" never bought me much
with Paul/Ben other than "but it shows we can do better, everything is
so close".

So, I hope there's some way we can get to the high level point where
there's some way to say "I have a simple $foo as described &here" and
all of the various blocks that every vendor does themselves, but doesn't
require a per vendor driver Just Work without editing files.

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html