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
