Re: Pulls and drive strengths in the pinctrl world

[Tomasz Figa <tomasz.figa@gmail.com>]

On Wednesday 15 of May 2013 23:41:54 Tomasz Figa wrote:
> 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@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/msg3
> > > 21
> > > 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@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.

Ahh, not even saying that a single interrupt signal is not really an 
interrupt controller, which would make device tree diverge from real 
hardware description.

Best regards,
Tomasz