On 16:28 Tue 22 Nov , Stephen Warren wrote: > Tony Lindgren wrote at Tuesday, November 22, 2011 10:54 AM: > > * Linus Walleij <linus.walleij@xxxxxxxxxx> [111122 03:30]: > > > 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. > > > > 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... I agreee here as example on at91 I try to found a good way to let the macb driver to ask the pin configuration so in my mind i do not need put all pins in each board but in the dtsi and then in the drivers just said pins = "mii"; or pins = "rmii"; or if I want to use the alternative config pins = "mii_alt"; or pins = "rmii_alt"; and then in the dtsi I describe the pin used for those configs which is soc specifific not board Best Regards, J. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html