Re: [PATCH] pinctrl: establish pull-up/pull-down terminology

From: Laurent Pinchart
Date: Fri Jun 21 2013 - 19:30:08 EST


Hi Stephen,

On Friday 21 June 2013 13:06:47 Stephen Warren wrote:
> On 06/20/2013 06:38 AM, James Hogan wrote:
> > On 19/06/13 23:03, Stephen Warren wrote:
> >> On 06/16/2013 04:45 AM, Linus Walleij wrote:
> >>> From: Linus Walleij <linus.walleij@xxxxxxxxxx>
> >>>
> >>> It is counter-intuitive to have "0" mean disable in a boolean
> >>> manner for electronic properties of pins such as pull-up and
> >>> pull-down. Therefore, define that a pull-up/pull-down argument
> >>> of 0 to such a generic option means that the pin is
> >>> short-circuited to VDD or GROUND. Pull disablement shall be
> >>> done using PIN_CONFIG_BIAS_DISABLE.
> >>>
> >>> Cc: Heiko Stïbner <heiko@xxxxxxxxx>
> >>> Cc: James Hogan <james.hogan@xxxxxxxxxx>
> >>> Cc: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
> >>> Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx>
> >>> ---
> >>>
> >>> include/linux/pinctrl/pinconf-generic.h | 13 +++++++------
> >>> 1 file changed, 7 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/include/linux/pinctrl/pinconf-generic.h
> >>> b/include/linux/pinctrl/pinconf-generic.h index d414a77..67780f5 100644
> >>> --- a/include/linux/pinctrl/pinconf-generic.h
> >>> +++ b/include/linux/pinctrl/pinconf-generic.h
> >>> @@ -36,14 +36,15 @@
> >>>
> >>> * tristate. The argument is ignored.
> >>> * @PIN_CONFIG_BIAS_PULL_UP: the pin will be pulled up (usually with
> >>> high
> >>> * impedance to VDD). If the argument is != 0 pull-up is enabled,
> >>>
> >>> - * if it is 0, pull-up is disabled.
> >>> + * if it is 0, pull-up it total, i.e. the pin is connected to VDD.
> >>>
> >>> * @PIN_CONFIG_BIAS_PULL_DOWN: the pin will be pulled down (usually
> >>> with high * impedance to GROUND). If the argument is != 0 pull-down
> >>> is enabled,>>>
> >>> - * if it is 0, pull-down is disabled.
> >>> + * if it is 0, pull-down is total, i.e. the pin is connected to GROUND.
> >>>
> >>> * @PIN_CONFIG_BIAS_PULL_PIN_DEFAULT: the pin will be pulled up or down
> >>> based * on embedded knowledge of the controller, like current mux
> >>> function.>>>
> >>> - * If the argument is != 0 pull up/down is enabled, if it is 0,
> >>> - * the pull is disabled.
> >>> + * If the argument is != 0 pull up/down is enabled, if it is 0, the
> >>> + * configuration is ignored. The proper way to disable it is to use
> >>> + * @PIN_CONFIG_BIAS_DISABLE.
> >>
> >> Why treat PULL_UP/PULL_DOWN differently from PULL_PIN_DEFAULT?
> >> PULL_PIN_DEFAULT is logically simply a macro that selects PULL_UP/DOWN
> >> based on what's "normal" for the pin's expected usage, so surely the
> >> value associated with that option should behave identically?
> >
> > I'm not familiar with hardware that does this so I could be way wrong
> > here, but presumably if there's a default up/down, there's probably a
> > default resistance too. Does it really make sense to say
> > "pull up or down depending on whatever the pin is intended for... but
> > whichever it is must be XXX Ohm"?
> > If you know the resistance you want, you surely already know whether you
> > want it pull up or down with that resistence.
>
> IIRC the idea of the PULL_PIN_DEFAULT was to avoid having to specify
> UP/DOWN for each pin/group, but could just say "default", which would
> then reduce the number of pinctrl mapping table entries or pinctrl DT
> property entries.

I may be mistaken, but I've understood the PULL_PIN_DEFAULT option as a way to
select the default bias configuration when the default value is hardware-
controlled, not as a pure software option.

> I don't think this would have any interaction with setting the resistance;
> it's entirely plausible that you'd want the same explicit, or same default,
> resistance, for all pins, irrespective of pull-up vs. down.

--
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/