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

[Koen Kooi]

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.

regards,

Koen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20111123/681a7073/attachment-0001.pgp>