Pulls and drive strengths in the pinctrl world

[Tomasz Figa]

On Wednesday 15 of May 2013 14:19:18 Doug Anderson wrote:
> Tomasz,
> 
> Thanks for your comments.  I'm glad I'm not totally off-track.  I'll
> respond to most things in reply to Linus' email, but a few here:
> 
> On Wed, May 15, 2013 at 10:26 AM, Tomasz Figa <tomasz.figa at gmail.com> 
wrote:
> >>   pinctrl at 11400000 {
> >>   
> >>     cyapa_irq: cyapa-irq {
> >>     
> >>       samsung,pins = "gpx1-2";
> >>       samsung,pin-function = <0xf>;
> > 
> > You can omit samsung,pin-function here.
> 
> One potential reason for leaving them is the hopes that it might cause
> a little less line glitching, especially in the case of outputs.
> There is some delay between the pinmux being configured at the start
> of device probe and the device actually claiming the GPIO.  Things
> might be worse in the case of deferred probe (?).  Can you think of
> any reason to remove (other than yet more lines of device tree to deal
> with)?

Well, actually in case of interrupts the function should not be configured 
manually, because it is likely to cause a false interrupt to be caught, 
before appropriate interrupt trigger type is configured. The correct way 
is to leave setting pin function to EINT to the pin control driver once 
the trigger gets configured (the pin control driver configures pin 
function from set_irq_type callback).

> >>       samsung,pin-pud = <0>;
> >>       samsung,pin-drv = <0>;
> > 
> > For inputs I guess you can omit samsung,pin-drv as well.
> 
> I will probably leave them even for inputs.  They shouldn't matter but
> I like the idea of initting things to a known state...

Well, the binding you proposed for interrupts doesn't initialize it. This 
is why I pointed that it can be omitted using current way as well.

Best regards,
Tomasz