configuration for nc pins without pull

configuration for nc pins without pull

[Uwe Kleine-König]

Hello,

for a machine I want to configure a pin that is actually not connected
to minimize floating. (I think this is sensible, isn't it?)

For the pinctrl I can use a hog group of the pinctrl device. At least
one of the pins doesn't have a pullup/pulldown configuration though, so
I want to mux it to its gpio function and set the gpio to output and the
desired value.

Is there something nicer than defining an always-on regulator with gpios
= <&gpio4 3 0> to accomplish that without additional code?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: configuration for nc pins without pull

[Russell King - ARM Linux]

On Sun, Mar 22, 2015 at 11:00:59AM +0100, Uwe Kleine-König wrote:
> Hello,
> 
> for a machine I want to configure a pin that is actually not connected
> to minimize floating. (I think this is sensible, isn't it?)

Definitely.  It's a design error to leave a pin floating, especially
if they're MOS inputs (which most are).  The reason is that many
MOS inputs are a pair of MOS transistors - one from +V to their output
(into the device) the other between their output and ground.

If the input floats, then both transistors are partially turned on,
which gives a wasteful flow of current between +V and ground - hence
this increases the current draw and dissipation of the device - and
is a total waste of energy.

Generally, when designing MOS circuitry using standard gates, it is
very much a design error to leave any unused gate inputs unconnected
for this very reason - not only that, but the input is also sensitive
to static electricity.  A floating input has a very high input
resistance, and a static discharge into it can destroy those input
transistors I've mentioned above - turning *both* hard on, which
gives you a dead short between +V and ground.

That can result in the device effectively being fried, even if the
fried input is not being used (because it drags the supply down.)

Floating inputs are *always* bad.

(Just make sure that the designer hasn't already thought of this and
tied the inputs high or low, possibly through a resistor.  Even so,
I'd say that it's good practice if the chip has biasing to bias them
accordingly, so that should there be a bad joint on the board, it
doesn't allow the pin to start floating.  Bad joints happen, and
sometimes show after a few months of otherwise good operation...)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: configuration for nc pins without pull

[Linus Walleij]

On Sun, Mar 22, 2015 at 11:00 AM, Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:

> for a machine I want to configure a pin that is actually not connected
> to minimize floating. (I think this is sensible, isn't it?)

Yup, and Russell gave an excellent summary of why.

> For the pinctrl I can use a hog group of the pinctrl device. At least
> one of the pins doesn't have a pullup/pulldown configuration though, so
> I want to mux it to its gpio function and set the gpio to output and the
> desired value.
>
> Is there something nicer than defining an always-on regulator with gpios
> = <&gpio4 3 0> to accomplish that without additional code?

As explained in
Documentation/pinctrl.txt, section "GPIO mode pitfalls" like 788
this is not really "GPIO", it is a way of controlling the electric state
of the pin using software, it's just the hardware designers idea of the
use case that it is "GPIO", it is not what a software engineer would call
GPIO.

If the controller support GENERIC_PINCONF I suggest implementing
PIN_CONFIG_OUTPUT from include/linux/pinctrl/pinconf-generic.h
which is more or less for exactly this purpose.

It will bring the pin into "GPIO mode" by poking the right registers but
what is really happening is a non-GPIO usecase on the pin control
side of things.

This should be done using a hog on the device tree and
output-low; or output-high; using the generic pinctrl bindings.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: configuration for nc pins without pull

[Uwe Kleine-König]

On Sun, Mar 22, 2015 at 11:00:59AM +0100, Uwe Kleine-König wrote:
> Hello,
> 
> for a machine I want to configure a pin that is actually not connected
> to minimize floating. (I think this is sensible, isn't it?)
> 
> For the pinctrl I can use a hog group of the pinctrl device. At least
> one of the pins doesn't have a pullup/pulldown configuration though, so
> I want to mux it to its gpio function and set the gpio to output and the
> desired value.
> 
> Is there something nicer than defining an always-on regulator with gpios
> = <&gpio4 3 0> to accomplish that without additional code?
For the archive: Yes, there is something nicer in the meantime:

Since commit f625d4601759 (gpio: add GPIO hogging mechanism) which is
included in v4.1-rc1 you can do something like

&gpio3 {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_gpio3hog>;

        ext-armclk {
                gpio-hog;
                gpios = <15 0>;
                output-low;
        };
};

in the devicetree (here for an i.MX25).

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html