Linus Walleij wrote at Thursday, October 20, 2011 4:25 AM: > On Thu, Oct 20, 2011 at 1:04 AM, Stephen Warren <swar...@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. -- nvpublic _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
