gpio-generic DT bindings?

gpio-generic DT bindings?

[Geert Uytterhoeven]

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?

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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

Re: gpio-generic DT bindings?

[Stephen Warren]

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...
--
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

Re: gpio-generic DT bindings?

[Geert Uytterhoeven]

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.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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

Re: gpio-generic DT bindings?

[Stephen Warren]

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.
--
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

Re: gpio-generic DT bindings?

[Tom Rini]

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.  You feed it a little info and it Just Works.  Having to patch
the generic driver N times for vendor,foo-gpio would be a step
backwards.  How do we have a binding here that lets us be as flexible as
we are today?

-- 
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

Re: gpio-generic DT bindings?

[Stephen Warren]

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.

> 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.
--
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

Re: gpio-generic DT bindings?

[Tom Rini]

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

Re: gpio-generic DT bindings?

[Geert Uytterhoeven]

On Wed, Nov 20, 2013 at 4:44 PM, Tom Rini <trini-l0cyMroinI0@public.gmane.org> 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.  You feed it a little info and it Just Works.  Having to patch
> the generic driver N times for vendor,foo-gpio would be a step
> backwards.  How do we have a binding here that lets us be as flexible as
> we are today?

Indeed. Is there really a need to name all simple GPIO drivers that provide
two register banks ("data" and "data direction") differently using a
"vendor,ipblock" tuple? What about something like "linux,gpio-generic"?

In particular, I want to use it for openrisc GPIO. Currently it uses its own
very simple driver
(http://git.openrisc.net/cgit.cgi/jonas/linux/tree/drivers/gpio/jbtrivial.c),
while there already exists a simple driver called gpio-generic
in mainline. But gpio-generic doesn't have DT support yet.

People tried adding DT support before:
  - https://lkml.org/lkml/2013/2/26/70, which was shot down last year.
  - http://www.spinics.net/lists/devicetree/msg00696.html, which also refers
    to simple-gpio, but unfortunately I can't read the whole thread as most of
    it happened during the ozlabs->vger transition of the mailing list.

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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