Re: Pinmux with device tree

[Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>]

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.