[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <74CDBE0F657A3D45AFBB94109FB122FF173D51C23C@HQMAIL01.nvidia.com>
Date: Thu, 20 Oct 2011 11:46:19 -0700
From: Stephen Warren <swarren@...dia.com>
To: Linus Walleij <linus.walleij@...aro.org>
CC: Linus Walleij <linus.walleij@...ricsson.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Barry Song <21cnbao@...il.com>,
Shawn Guo <shawn.guo@...escale.com>,
Linaro Dev <linaro-dev@...ts.linaro.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
David Brown <davidb@...eaurora.org>,
Grant Likely <grant.likely@...retlab.ca>
Subject: RE: [PATCH 2/2] pinctrl: add a generic control interface
Linus Walleij wrote at Thursday, October 20, 2011 4:25 AM:
> On Thu, Oct 20, 2011 at 1:04 AM, Stephen Warren <swarren@...dia.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists