Op 22 nov. 2011, om 18:54 heeft Tony Lindgren het volgende geschreven:
- Linus Walleij linus.walleij@linaro.org [111122 03:30]:
On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham thomas.abraham@linaro.org wrote:
On 17 November 2011 19:27, Linus Walleij linus.walleij@linaro.org 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.
Yes the driver nodes should describe in DT which pins to use:
serial@12340000 { compatible = "8250"; reg = <0x12340000 0x40>; reg-shift = <2>; interrupts = < 10 >; pins = "uart1_rx", "uart1_tx"; };Note that we should use the actual signal names, not package specific pad names. This way they have a high likelyhood to work for new packages too by just mapping the signals to the new package.
How would this handle the situation where you can mux a signal to multiple pins? IIRC omap3 and am335x can do funny stuff with the display pins like being able to map the blue bits to different pinblocks.
regards,
Koen