RE: [PATCH 2/2] pinctrl: add a generic control interface

[Stephen Warren]

Linus Walleij wrote at Thursday, October 20, 2011 4:25 AM:
> On Thu, Oct 20, 2011 at 1:04 AM, Stephen Warren <swarren@xxxxxxxxxx> wrote:
...
> >> + * @PIN_CONFIG_BIAS_HIGH_IMPEDANCE: the pin will be set to a high impedance
> >> + *   mode, also know as "third-state" (tristate) or "high-Z" or "floating".
> >> + *   On output pins this effectively disconnects the pin, which is useful
> >> + *   if for example some other pin is going to drive the signal connected
> >> + *   to it for a while. Pins used for input are usually always high
> >> + *   impedance.
> >> + * @PIN_CONFIG_BIAS_PULL_UP: the pin will be pulled up (usually with high
> >> + *   impedance to VDD), if the controller supports specifying a certain
> >> + *   pull-up resistance, this is given as an argument (in Ohms) when
> >> + *   setting this parameter
> >
> > What value should be used to disable a pull-up; 0?
> 
> A semantic question would also be if pull up is implicitly disabled
> if you issue PIN_CONFIG_BIAS_PULL_DOWN when you are
> in PULL_UP state.
> 
> I added PIN_CONFIG_BIAS_DISABLED  to
> set_pin_config(pin, PIN_CONFIG_BIAS_DISABLED);
> 
> So we can transition to a state of totally disabled pin bias.

I'm not too sure I like that; the core's definition of PIN_CONFIG_BIAS_*
is then imposing semantics that the HW might not have.

So, Tegra's pull configuration is up/down/none, as a register field with
3 values.

Another chip could easily have 1 bit to pull-up-enable and a separate
bit for pull-down-enable. It might be silly to set them both, but the HW
could quite easily be designed such that it'd work as one would exect
electrically.

I'm not convinced that the PIN_CONFIG_BIAS_* definitions should be defined
to force one model over the other. With SoC-defined param names, the
pinctrl driver can expose exactly what the HW supports without abstraction.

And how to hide the abstraction from drivers? Some kind of mapping table
or API; see my other email for details.

-- 
nvpublic

--
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/