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.
regards,
KoenAttachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
