[RFC 1/3] pinctrl: add a driver for the OMAP pinmux

[Hiremath, Vaibhav]

> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] 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 at vger.kernel.org; linaro-dev at lists.linaro.org;
> linus.walleij at stericsson.com; linux-samsung-soc; devicetree-
> discuss at lists.ozlabs.org
> 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 at linaro.org> [111122 03:30]:
> >> On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
> >> <thomas.abraham at linaro.org> wrote:
> >>> On 17 November 2011 19:27, Linus Walleij <linus.walleij at 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 at 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