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