On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
<thomas.abraham@xxxxxxxxxx> wrote:
> On 17 November 2011 19:27, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>>
>> Maybe I'm mistaken about the device tree ambitions, but
>> I was sort of hoping that it would not contain too much
>> custom magic numbers that need to be cross-referenced
>> elsewhere ... or rather - the more understandable the device
>> tree is, the more we win.
>
> Device tree is expected to describe the hardware. So to
> cross-reference the hardware manual to understand device tree should
> be fine I guess. For instance, GPIO numbers in dts would be written as
> a numeric number and not a enum or other format. And by looking up the
> manual, we understand the actual details of the GPIO pin.
>
> If dt-compiler had a option to support #define like in C, the numbers
> could have been made more easier to understand. Like, 3 to mean
> GPIO_PULL_UP in Exynos dts file.
OK I think I get it now, so DT bindings shall really NOT be read
by any of the pinctrl core, it is *supposed* to be all driver-specific.
Then it makes perfect sense to have it as it is.
So for example in the pinctrl-coh901xxx.c example driver I have
locally defined registers presets like:
#define U300_FLOATING_INPUT { \
.bias_mode = PIN_CONFIG_BIAS_HIGH_IMPEDANCE, \
.output = false, \
}
#define U300_PULL_UP_INPUT { \
.bias_mode = PIN_CONFIG_BIAS_PULL_UP, \
.output = false, \
}
Then this type of stuff shall keep its custom format in the device
tree, and the driver for coh901xxx reads that out.
Thanks for helping me understand this crucial assumption of how
it works...
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
