Pinmux with device tree

Pinmux with device tree

[Simon Glass]

Hi,

I see a new pinmux system in the LKML. Has anyone looked at how to
represent pinmux settings in the device tree?

On a related topic, the examples that are used for GPIOs assume a
flags word which describes things like pull-ups, direction, etc. This
seems pretty cumbersome and gets worse with pinmuxes. People editing
the device trees want to see symbolic information rather than a coded
number, a bit like a #define. I can see this can be done with strings
but this is inefficient in time and space, and is error-prone.  Is
there support for this in device trees that I have missed?

Regards,
Simon

Re: Pinmux with device tree

[Mitch Bradley]

On 5/18/2011 6:34 AM, Simon Glass wrote:
> Hi,
>
> I see a new pinmux system in the LKML. Has anyone looked at how to
> represent pinmux settings in the device tree?
>
> On a related topic, the examples that are used for GPIOs assume a
> flags word which describes things like pull-ups, direction, etc. This
> seems pretty cumbersome and gets worse with pinmuxes. People editing
> the device trees want to see symbolic information rather than a coded
> number, a bit like a #define. I can see this can be done with strings
> but this is inefficient in time and space, and is error-prone.  Is
> there support for this in device trees that I have missed?

Open Firmware deals with this by defining both a numerical 
representation and a text representation.  The numerical representation 
appears in memory in device tree property values, and the corresponding 
text representation is for display and human input.

It primarily applies to unit addresses, i.e. the "reg" property value, 
but the idea generalizes.  The device tree compiler could accept the 
symbolic names, converting them into well-defined bitfield values which 
would be stored in integer cells within property values.



>
> Regards,
> Simon
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>

Re: Pinmux with device tree

[Haojian Zhuang]

On Thu, May 19, 2011 at 3:33 AM, Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> wrote:
> On 5/18/2011 6:34 AM, Simon Glass wrote:
>>
>> Hi,
>>
>> I see a new pinmux system in the LKML. Has anyone looked at how to
>> represent pinmux settings in the device tree?
>>
>> On a related topic, the examples that are used for GPIOs assume a
>> flags word which describes things like pull-ups, direction, etc. This
>> seems pretty cumbersome and gets worse with pinmuxes. People editing
>> the device trees want to see symbolic information rather than a coded
>> number, a bit like a #define. I can see this can be done with strings
>> but this is inefficient in time and space, and is error-prone.  Is
>> there support for this in device trees that I have missed?
>
> Open Firmware deals with this by defining both a numerical representation
> and a text representation.  The numerical representation appears in memory
> in device tree property values, and the corresponding text representation is
> for display and human input.
>
Could it be supported by flattened device tree? It seems that open firmware
isn't popular in ARM system.

> It primarily applies to unit addresses, i.e. the "reg" property value, but
> the idea generalizes.  The device tree compiler could accept the symbolic
> names, converting them into well-defined bitfield values which would be
> stored in integer cells within property values.
>
>
>

Re: Pinmux with device tree

[Grant Likely]

On Thu, May 19, 2011 at 07:30:52PM +0800, Haojian Zhuang wrote:
> On Thu, May 19, 2011 at 3:33 AM, Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> wrote:
> > On 5/18/2011 6:34 AM, Simon Glass wrote:
> >>
> >> Hi,
> >>
> >> I see a new pinmux system in the LKML. Has anyone looked at how to
> >> represent pinmux settings in the device tree?
> >>
> >> On a related topic, the examples that are used for GPIOs assume a
> >> flags word which describes things like pull-ups, direction, etc. This
> >> seems pretty cumbersome and gets worse with pinmuxes. People editing
> >> the device trees want to see symbolic information rather than a coded
> >> number, a bit like a #define. I can see this can be done with strings
> >> but this is inefficient in time and space, and is error-prone.  Is
> >> there support for this in device trees that I have missed?

Why is it error prone?  It is probably less error prone than using
magic integer values.  :-)  As for time and space inefficiencies,
we're talking about tiny amounts of data and processors now in the GHz
range with GBs of memory.  The time and space required is pretty much
in the noise.

A bigger issue is the fact that a GPIO binding has already been
established using integers.  To change it to something else must be
done in such a way as to not break existing users.

However, pinmux description is entirely orthogonal to GPIO
controllers.  The gpio binding is about matching gpio consumers to
gpio providers.  It says nothing about how the gpios are actually
routed on the chip.

A pinmux binding is more about the specific configuration of the
chip, and is very likely going to be something chip specific,
although there may be some common infrastructure and patterns for
describing the functionality.  I have no problem with defining a new
binding for describing pinmux.

I'll be very nervous if I see any implementation that tries to encode
pinmux information into the gpio binding.

> >
> > Open Firmware deals with this by defining both a numerical representation
> > and a text representation.  The numerical representation appears in memory
> > in device tree property values, and the corresponding text representation is
> > for display and human input.
> >
> Could it be supported by flattened device tree? It seems that open firmware
> isn't popular in ARM system.

The flat tree is directly derived from the Open Firmware design.  Yes,
this could be expressed by device tree, however we don't have any
syntax for the dt compiler right now to support the use case.  Plus,
I want to tread carefully here since it may also be possible that
firmware will want to modify the data, and it becomes a lot more
complex if it needs to keep two separate representations within the
same tree in sync.

One option would be to allow interrupt controllers to have a static
lookup property which matches bitfields in the interrupt specifier
with human readable names.

g.

RE: Pinmux with device tree

[Stephen Warren]

Grant Likely wrote at Thursday, May 19, 2011 11:10 AM
> On Thu, May 19, 2011 at 07:30:52PM +0800, Haojian Zhuang wrote:
> > On Thu, May 19, 2011 at 3:33 AM, Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> wrote:
> > > On 5/18/2011 6:34 AM, Simon Glass wrote:
> > >>
> > >> Hi,
> > >>
> > >> I see a new pinmux system in the LKML. Has anyone looked at how to
> > >> represent pinmux settings in the device tree?
> > >>
> > >> On a related topic, the examples that are used for GPIOs assume a
> > >> flags word which describes things like pull-ups, direction, etc. This
> > >> seems pretty cumbersome and gets worse with pinmuxes. People editing
> > >> the device trees want to see symbolic information rather than a coded
> > >> number, a bit like a #define. I can see this can be done with strings
> > >> but this is inefficient in time and space, and is error-prone.  Is
> > >> there support for this in device trees that I have missed?
> 
> Why is it error prone?  It is probably less error prone than using
> magic integer values.  :-)

I think that comment was saying that if the FDT itself contains the strings,
if there were a typo, it'd only be detected at run-time (well, admittedly
just like a typo in a number).

However, if the DT compiler implemented something like the pre-processor,
any typos in define usage would be detected at compile time due to referencing
a non-existing define/variable, which is less error-prone.

I must admit, when I first saw DT source files, my first though was to run
CPP on them (or similar token->integer replacement utility, which also
supported bitwise math e.g. for the GPIO flags stuff), and then pass the
result to dtc, so that I could work with names instead of numbers.

--
nvpublic

Re: Pinmux with device tree

[Grant Likely]

On Thu, May 19, 2011 at 11:24 AM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> Grant Likely wrote at Thursday, May 19, 2011 11:10 AM
>> On Thu, May 19, 2011 at 07:30:52PM +0800, Haojian Zhuang wrote:
>> > On Thu, May 19, 2011 at 3:33 AM, Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> wrote:
>> > > On 5/18/2011 6:34 AM, Simon Glass wrote:
>> > >>
>> > >> Hi,
>> > >>
>> > >> I see a new pinmux system in the LKML. Has anyone looked at how to
>> > >> represent pinmux settings in the device tree?
>> > >>
>> > >> On a related topic, the examples that are used for GPIOs assume a
>> > >> flags word which describes things like pull-ups, direction, etc. This
>> > >> seems pretty cumbersome and gets worse with pinmuxes. People editing
>> > >> the device trees want to see symbolic information rather than a coded
>> > >> number, a bit like a #define. I can see this can be done with strings
>> > >> but this is inefficient in time and space, and is error-prone.  Is
>> > >> there support for this in device trees that I have missed?
>>
>> Why is it error prone?  It is probably less error prone than using
>> magic integer values.  :-)
>
> I think that comment was saying that if the FDT itself contains the strings,
> if there were a typo, it'd only be detected at run-time (well, admittedly
> just like a typo in a number).

We can (and do) implement semantic checks in dtc.

>
> However, if the DT compiler implemented something like the pre-processor,
> any typos in define usage would be detected at compile time due to referencing
> a non-existing define/variable, which is less error-prone.
>
> I must admit, when I first saw DT source files, my first though was to run
> CPP on them (or similar token->integer replacement utility, which also
> supported bitwise math e.g. for the GPIO flags stuff), and then pass the
> result to dtc, so that I could work with names instead of numbers.

There has been much talk over the years about how to make dtc better.
I did try at one point to use CPP, but unfortunately there were too
many C assumption in CPP that made the result... yucky.

g.

Re: Pinmux with device tree

[Mitch Bradley]

On 5/19/2011 7:10 AM, Grant Likely wrote:
> On Thu, May 19, 2011 at 07:30:52PM +0800, Haojian Zhuang wrote:
>> On Thu, May 19, 2011 at 3:33 AM, Mitch Bradley<wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>  wrote:
>>> On 5/18/2011 6:34 AM, Simon Glass wrote:
>>>>
>>>> Hi,
>>>>
>>>> I see a new pinmux system in the LKML. Has anyone looked at how to
>>>> represent pinmux settings in the device tree?
>>>>
>>>> On a related topic, the examples that are used for GPIOs assume a
>>>> flags word which describes things like pull-ups, direction, etc. This
>>>> seems pretty cumbersome and gets worse with pinmuxes. People editing
>>>> the device trees want to see symbolic information rather than a coded
>>>> number, a bit like a #define. I can see this can be done with strings
>>>> but this is inefficient in time and space, and is error-prone.  Is
>>>> there support for this in device trees that I have missed?
>
> Why is it error prone?  It is probably less error prone than using
> magic integer values.  :-)  As for time and space inefficiencies,
> we're talking about tiny amounts of data and processors now in the GHz
> range with GBs of memory.  The time and space required is pretty much
> in the noise.


Ideally, the device tree is exported by the firmware, whose storage 
device is often much much smaller than the RAM size.  Since I began 
doing firmware, average RAM sizes have increased by a factor of 4000 and 
RAM speed has increased by a factor of about 1000.  In that time, boot 
ROM size has increased by a factor of about 8 and the speed, in some 
cases, has decreased.

During a substantial portion of the firmware startup sequence, the CPU 
may be executing in a crippled mode, with caches unavailable.

On my current project, I have to fit everything in 1 MiB of slow SPI 
FLASH.  "Everything" includes microcode wads for things like the 
wireless module, extensive manufacturing and field diagnostics for every 
hardware device, crypto code and keys for boot security, drivers for 
on-board devices and a myriad of USB devices, sound clips for a startup 
jingle, graphics images for "pretty boot" and for language-neutral 
reporting of diagnostic results, unit-specific manufacturing info, 
filesystem and network protocol code, and a wireless multicast facility 
for mass updating of the OS onto an arbitrary number of units.

So, in my world, space is always an issue.


>
> A bigger issue is the fact that a GPIO binding has already been
> established using integers.  To change it to something else must be
> done in such a way as to not break existing users.
>
> However, pinmux description is entirely orthogonal to GPIO
> controllers.  The gpio binding is about matching gpio consumers to
> gpio providers.  It says nothing about how the gpios are actually
> routed on the chip.
>
> A pinmux binding is more about the specific configuration of the
> chip, and is very likely going to be something chip specific,
> although there may be some common infrastructure and patterns for
> describing the functionality.  I have no problem with defining a new
> binding for describing pinmux.
>
> I'll be very nervous if I see any implementation that tries to encode
> pinmux information into the gpio binding.
>
>>>
>>> Open Firmware deals with this by defining both a numerical representation
>>> and a text representation.  The numerical representation appears in memory
>>> in device tree property values, and the corresponding text representation is
>>> for display and human input.
>>>
>> Could it be supported by flattened device tree? It seems that open firmware
>> isn't popular in ARM system.
>
> The flat tree is directly derived from the Open Firmware design.  Yes,
> this could be expressed by device tree, however we don't have any
> syntax for the dt compiler right now to support the use case.  Plus,
> I want to tread carefully here since it may also be possible that
> firmware will want to modify the data, and it becomes a lot more
> complex if it needs to keep two separate representations within the
> same tree in sync.
>
> One option would be to allow interrupt controllers to have a static
> lookup property which matches bitfields in the interrupt specifier
> with human readable names.
>
> g.
>

Re: Pinmux with device tree

[Nicolas Pitre]

On Thu, 19 May 2011, Mitch Bradley wrote:

> On 5/19/2011 7:10 AM, Grant Likely wrote:
> > Why is it error prone?  It is probably less error prone than using
> > magic integer values.  :-)  As for time and space inefficiencies,
> > we're talking about tiny amounts of data and processors now in the GHz
> > range with GBs of memory.  The time and space required is pretty much
> > in the noise.
> 
> Ideally, the device tree is exported by the firmware, whose storage device is
> often much much smaller than the RAM size.  Since I began doing firmware,
> average RAM sizes have increased by a factor of 4000 and RAM speed has
> increased by a factor of about 1000.  In that time, boot ROM size has
> increased by a factor of about 8 and the speed, in some cases, has decreased.
> 
> During a substantial portion of the firmware startup sequence, the CPU may be
> executing in a crippled mode, with caches unavailable.
> 
> On my current project, I have to fit everything in 1 MiB of slow SPI FLASH.
> "Everything" includes microcode wads for things like the wireless module,
> extensive manufacturing and field diagnostics for every hardware device,
> crypto code and keys for boot security, drivers for on-board devices and a
> myriad of USB devices, sound clips for a startup jingle, graphics images for
> "pretty boot" and for language-neutral reporting of diagnostic results,
> unit-specific manufacturing info, filesystem and network protocol code, and a
> wireless multicast facility for mass updating of the OS onto an arbitrary
> number of units.
> 
> So, in my world, space is always an issue.

I'm guessing that in such a scenario you have the kernel stored 
somewhere else, right?  You therefore simply have to store the FDT data 
along with the kernel in that other location, and have your boot 
firmware load an additional and relatively small file.

It is very important that the DT data be updateable independently from 
the firmware, just like the kernel is.  Ideally, the DT would indeed be 
exported by the firmware, but that works only in theory.  In practice it 
_will_ contain bugs that might be visible only after kernel development 
has progressed, and therefore it is primordial to be able to update it 
easily.  Hence in practice it is best if it is not exported/generated by 
the firmware directly.


Nicolas

Re: Pinmux with device tree

[Mitch Bradley]

On 5/19/2011 10:36 AM, Nicolas Pitre wrote:
> On Thu, 19 May 2011, Mitch Bradley wrote:
>
>> On 5/19/2011 7:10 AM, Grant Likely wrote:
>>> Why is it error prone?  It is probably less error prone than using
>>> magic integer values.  :-)  As for time and space inefficiencies,
>>> we're talking about tiny amounts of data and processors now in the GHz
>>> range with GBs of memory.  The time and space required is pretty much
>>> in the noise.
>>
>> Ideally, the device tree is exported by the firmware, whose storage device is
>> often much much smaller than the RAM size.  Since I began doing firmware,
>> average RAM sizes have increased by a factor of 4000 and RAM speed has
>> increased by a factor of about 1000.  In that time, boot ROM size has
>> increased by a factor of about 8 and the speed, in some cases, has decreased.
>>
>> During a substantial portion of the firmware startup sequence, the CPU may be
>> executing in a crippled mode, with caches unavailable.
>>
>> On my current project, I have to fit everything in 1 MiB of slow SPI FLASH.
>> "Everything" includes microcode wads for things like the wireless module,
>> extensive manufacturing and field diagnostics for every hardware device,
>> crypto code and keys for boot security, drivers for on-board devices and a
>> myriad of USB devices, sound clips for a startup jingle, graphics images for
>> "pretty boot" and for language-neutral reporting of diagnostic results,
>> unit-specific manufacturing info, filesystem and network protocol code, and a
>> wireless multicast facility for mass updating of the OS onto an arbitrary
>> number of units.
>>
>> So, in my world, space is always an issue.
>
> I'm guessing that in such a scenario you have the kernel stored
> somewhere else, right?  You therefore simply have to store the FDT data
> along with the kernel in that other location, and have your boot
> firmware load an additional and relatively small file.

There is no stored FDT.  The firmware generates the device tree 
dynamically from a combination of static information and dynamic probing.

>
> It is very important that the DT data be updateable independently from
> the firmware, just like the kernel is.  Ideally, the DT would indeed be
> exported by the firmware, but that works only in theory.  In practice it
> _will_ contain bugs that might be visible only after kernel development
> has progressed, and therefore it is primordial to be able to update it
> easily.  Hence in practice it is best if it is not exported/generated by
> the firmware directly.


In our world it works in practice.  We control the hardware, firmware, 
and OS releases.  In many cases, a firmware update is less expensive 
than an OS release by several orders of magnitude.


>
>
> Nicolas
>

Re: Pinmux with device tree

[Nicolas Pitre]

On Thu, 19 May 2011, Mitch Bradley wrote:

> On 5/19/2011 10:36 AM, Nicolas Pitre wrote:
> > On Thu, 19 May 2011, Mitch Bradley wrote:
> > 
> > > So, in my world, space is always an issue.
> > 
> > I'm guessing that in such a scenario you have the kernel stored
> > somewhere else, right?  You therefore simply have to store the FDT data
> > along with the kernel in that other location, and have your boot
> > firmware load an additional and relatively small file.
> 
> There is no stored FDT.  The firmware generates the device tree dynamically
> from a combination of static information and dynamic probing.
> 
> > 
> > It is very important that the DT data be updateable independently from
> > the firmware, just like the kernel is.  Ideally, the DT would indeed be
> > exported by the firmware, but that works only in theory.  In practice it
> > _will_ contain bugs that might be visible only after kernel development
> > has progressed, and therefore it is primordial to be able to update it
> > easily.  Hence in practice it is best if it is not exported/generated by
> > the firmware directly.
> 
> 
> In our world it works in practice.  We control the hardware, firmware, and OS
> releases.  In many cases, a firmware update is less expensive than an OS
> release by several orders of magnitude.

I don't think this can be said for ARM in general though.
This is where all the recent surge of activity around DT comes from.


Nicolas

Re: Pinmux with device tree

[Mitch Bradley]

On 5/19/2011 4:23 PM, Nicolas Pitre wrote:
> On Thu, 19 May 2011, Mitch Bradley wrote:
>
>> On 5/19/2011 10:36 AM, Nicolas Pitre wrote:
>>> On Thu, 19 May 2011, Mitch Bradley wrote:
>>>
>>>> So, in my world, space is always an issue.
>>>
>>> I'm guessing that in such a scenario you have the kernel stored
>>> somewhere else, right?  You therefore simply have to store the FDT data
>>> along with the kernel in that other location, and have your boot
>>> firmware load an additional and relatively small file.
>>
>> There is no stored FDT.  The firmware generates the device tree dynamically
>> from a combination of static information and dynamic probing.
>>
>>>
>>> It is very important that the DT data be updateable independently from
>>> the firmware, just like the kernel is.  Ideally, the DT would indeed be
>>> exported by the firmware, but that works only in theory.  In practice it
>>> _will_ contain bugs that might be visible only after kernel development
>>> has progressed, and therefore it is primordial to be able to update it
>>> easily.  Hence in practice it is best if it is not exported/generated by
>>> the firmware directly.
>>
>>
>> In our world it works in practice.  We control the hardware, firmware, and OS
>> releases.  In many cases, a firmware update is less expensive than an OS
>> release by several orders of magnitude.
>
> I don't think this can be said for ARM in general though.
> This is where all the recent surge of activity around DT comes from.


Agreed, but I was pointing out that not everybody has space to burn, so 
I hope that the ultimate solution doesn't treat space as free.

>
>
> Nicolas
>

Re: Pinmux with device tree

[Simon Glass]

On Thu, May 19, 2011 at 10:10 AM, Grant Likely
<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
> On Thu, May 19, 2011 at 07:30:52PM +0800, Haojian Zhuang wrote:
>> On Thu, May 19, 2011 at 3:33 AM, Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> wrote:
>> > On 5/18/2011 6:34 AM, Simon Glass wrote:
>> >>
>> >> Hi,
>> >>
>> >> I see a new pinmux system in the LKML. Has anyone looked at how to
>> >> represent pinmux settings in the device tree?
>> >>
>> >> On a related topic, the examples that are used for GPIOs assume a
>> >> flags word which describes things like pull-ups, direction, etc. This
>> >> seems pretty cumbersome and gets worse with pinmuxes. People editing
>> >> the device trees want to see symbolic information rather than a coded
>> >> number, a bit like a #define. I can see this can be done with strings
>> >> but this is inefficient in time and space, and is error-prone.  Is
>> >> there support for this in device trees that I have missed?
>
> Why is it error prone?  It is probably less error prone than using
> magic integer values.  :-)  As for time and space inefficiencies,
> we're talking about tiny amounts of data and processors now in the GHz
> range with GBs of memory.  The time and space required is pretty much
> in the noise.

It strikes me that for a pinmux I want to say:

<&pingroup_gaa spi2 pullup normal>
<&pingroup_gab spi2 pullup tristatel>

or similar, with some definitions something like:

spi2: #4
pullup: #1
normal: #0
tristate: #0

The same for GPIOs since specifying an integer with bitflags is not
great for humans.

>
> A bigger issue is the fact that a GPIO binding has already been
> established using integers.  To change it to something else must be
> done in such a way as to not break existing users.

Well we could support bitfields:

bitfield gpio 0:0 {input, output}
bitfield pull 2:1 {normal, reserved, pulldown, pullup}
bitfield tristate 3:3 {tristate, normal}

then some magic could piece it together into a cell:

<&gpio32> <gpio:input, pulldown, tristate>

if you really want to go that far!

>
> However, pinmux description is entirely orthogonal to GPIO
> controllers.  The gpio binding is about matching gpio consumers to
> gpio providers.  It says nothing about how the gpios are actually
> routed on the chip.
>
> A pinmux binding is more about the specific configuration of the
> chip, and is very likely going to be something chip specific,
> although there may be some common infrastructure and patterns for
> describing the functionality.  I have no problem with defining a new
> binding for describing pinmux.
>
> I'll be very nervous if I see any implementation that tries to encode
> pinmux information into the gpio binding.

Yes they are completely separate. I feel that numbers are almost good
enough for GPIOs but are a bit of a stretch for pinmuxes. What sort of
symbolic support is actually available in FDT?

>
>> >
>> > Open Firmware deals with this by defining both a numerical representation
>> > and a text representation.  The numerical representation appears in memory
>> > in device tree property values, and the corresponding text representation is
>> > for display and human input.
>> >
>> Could it be supported by flattened device tree? It seems that open firmware
>> isn't popular in ARM system.
>
> The flat tree is directly derived from the Open Firmware design.  Yes,
> this could be expressed by device tree, however we don't have any
> syntax for the dt compiler right now to support the use case.  Plus,
> I want to tread carefully here since it may also be possible that
> firmware will want to modify the data, and it becomes a lot more
> complex if it needs to keep two separate representations within the
> same tree in sync.
>
> One option would be to allow interrupt controllers to have a static
> lookup property which matches bitfields in the interrupt specifier
> with human readable names.
>
> g.
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>