Hi David, On Thu, Sep 8, 2011 at 6:35 PM, David Gibson <[email protected]> wrote: [snip] >> [in a separate email since I don't want to pollute my comments on >> Stephen's nice patch with separate ravings] >> >> Thinking of bitfields, we already have a problem with the way GPIOs >> are specified. Typically we do something like: >> >> something = <&gpio 46 5> >> >> and define the third parameter to be three bits (direction, initial >> value, polarity). It would be nice to be able to do something like: >> >> something = <&gpio 46 INPUT,ACTIVE_LOW> >> something-else = <&gpio 46 OUTPUT,HIGH> >> >> instead. That would avoid having to explicitly have expressions >> containing | or define all combinations like this: > > I really don't like the idea of adding an extra explicit syntax for > bitfields. I much prefer just implementing integer expressions, which > would allow the same thing through |.
Well that's fine as well. In fact much better since that's on my wish list too. It will be interesting to try out these new toys and see how if affects some of the problems we have had with fdt on our platforms. My justification for explicit bitfield support is that they are essentially flags which could just occupy a whole cell each, but for space/efficiency reasons we decide they should be packed together into a single cell. So the syntax between these two options should perhaps be similar. With integer expressions, this works, since we convert <&gpio 147 1 2 4> to <<&gpio 147 1 | 2 | 4> if you see what I mean. It is the <&gpio 147 7> that I don't like. With Stephen's /define/ patch we should be able to do things like <&gpio 147 INPUT | ACTIVE_LOW>. Regards, Simon > > -- > David Gibson | I'll have my music baroque, and my code > david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ > | _way_ _around_! > http://www.ozlabs.org/~dgibson > _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
