Tony Lindgren wrote at Tuesday, November 22, 2011 10:54 AM:
- 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"; };
Sorry to jump in late here, but I wasn't aware of this thread.
I don't necessarily agree with that. Describing the HW doesn't necessarily mean that each device needs to describe what pinmux pins it uses; one could quite easily have the pinmux describe what settings the various pins should have and which drivers will use those pins. That would map very well to the pinctrl subsystem's mapping table, and at least Tegra's existing pinmux tables, which are both just a big array of settings which end up getting provided to drivers.
I'll try and track down the rest of this thread and catch up though...