Pulls and drive strengths in the pinctrl world

Tomasz Figa tomasz.figa at gmail.com
Thu May 16 07:41:54 EST 2013


On Wednesday 15 of May 2013 14:31:20 Doug Anderson wrote:
> Linus,
> 
> Thank you for your comments.  See below...
> 
> Stephen: sorry for missing you earlier!  :(
> 
> On Wed, May 15, 2013 at 11:29 AM, Linus Walleij
> 
> <linus.walleij at linaro.org> wrote:
> > But please use the preprocessor to provide symbolic names for
> > the configurations. See for example these two patches from
> > J-C:
> > http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg321
> > 64.html
> Ah, that does look nice!  This probably needs to be addressed in a
> separate patch to cleanup all of the samsung pinctrl devicetrees.
> 
> > I don't think the idea with device tree is to write as compact trees
> > as possible, but as expressive and exact yet abstract trees as
> > possible for OS independence.
> 
> The compactness was one benefit, but also it was about trying to avoid
> excessive duplication of information.  I found it awkward that I
> needed to list that my interrupt was "gpx1-2" in two different ways.
> 
> I would find it just as good if I could express things like this (for
> interrupts):
> 
>   pinctrl at 11400000 {
>     cyapa_irq: cyapa-irq {
>       samsung,pins = "gpx1-2";
>       samsung,pin-function = <0xf>;
>       samsung,pin-pud = <0>;
>       samsung,pin-drv = <0>;
> 
>       interrupt-controller;
>       #interrupt-cells = <1>;
>     };
>   };
> 
>   trackpad {
>     reg = <0x67>;
>     compatible = "cypress,cyapa";
>     interrupt-parent = <&cyapa_irq>;
>     interrupts = <0>;
>     wakeup-source;
>   };
> 
> In this case I'm not saying that my interrupt parent is "gpx1-2" in
> two separate places that could diverge.

This will be hard, since the phandle in interrupt-parent is represented by 
an IRQ domain in kernel code. One-interrupt IRQ domains seem a bit awkward 
to me.

Since we are already going to modify the binding, let's think a bit more 
about this problem and try to figure out a solution that doesn't add any 
disadvantages (at least any significant) to avoid such situation in future 
again.

Best regards,
Tomasz



More information about the devicetree-discuss mailing list