Pinmux with device tree

[Grant Likely]

On Thu, May 19, 2011 at 11:24 AM, Stephen Warren <swarren at nvidia.com> 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 at firmworks.com> 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.