Linus Walleij wrote at Thursday, October 20, 2011 4:25 AM:
On Thu, Oct 20, 2011 at 1:04 AM, Stephen Warren swarren@nvidia.com 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.