> -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > owner@xxxxxxxxxxxxxxx] On Behalf Of Koen Kooi > Sent: Wednesday, November 23, 2011 8:51 PM > To: Tony Lindgren > Cc: Linus Walleij; Thomas Abraham; Nayak, Rajendra; linux- > omap@xxxxxxxxxxxxxxx; linaro-dev@xxxxxxxxxxxxxxxx; > linus.walleij@xxxxxxxxxxxxxx; linux-samsung-soc; devicetree- > discuss@xxxxxxxxxxxxxxxx > Subject: Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux > > > Op 22 nov. 2011, om 18:54 heeft Tony Lindgren het volgende geschreven: > > > * 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"; > > }; > > > > 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. > That's quite not true, in case of omap3 pins are labeled as R0-R7, B0-B7 and G0-G7; what changes is pixel format. AM335x LCDC is completely different IP altogether and spec doesn't map Colors to pins. It barely maps bit0 from memory to pinX. Now you call it as a standard or legacy or may be due to SGX software, the pixel format we use is BGR (as in memory). It is completely depends on how you interface the pins to LCD (considering) Software support/requirement. Thanks, Vaibhav > regards, > > Koen -- 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
