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...
--
nvpublic
--
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
