[Letux-kernel] GPIOs and driver removal

H. Nikolaus Schaller hns at goldelico.com
Tue Nov 20 09:56:46 CET 2018


Hi,

> Am 20.11.2018 um 07:34 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> Hi,
> 
> On Mon, 19 Nov 2018 09:16:44 +0100
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> 
>> Hi,
>> 
>>> Am 19.11.2018 um 07:04 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>> 
>>> Hi,
>>> 
>>> I found out something interesting about GPIOs and driver removal.
>>> If I rmmod the gps driver, then exporting gpio145 (on/off), it shows up as an
>>> *input*. The value is read as 1. That causes an interesting behavior of the gps
>>> module.
>>> Enabling pulldown via pinctrl (for testing via devmem2) seems to solve that
>>> problem. GPS stays off after rmmod.
>>> A similiar behavior I have seen for the reset gpio of the usb3322 phy.  
>> 
>>> Unbinding the driver seems to enable that phy. manually setting the pin
>>> to low via OFFENABLE setting in padconf via devmem2 then disables it again.  
>> 
>> Well, it may be that these chips have an internal weak pull-up (e.g. 1 MOhm)
>> on their enable-input so that they are enabled by default if the pin is not
>> connected.
>> 
>> Using the gpio in input mode reads this as "1".
>> 
>> Activating pull-down (e.g. 50 kOhm) makes it read as "0" on both ends.
>> 
>>> 
>>> So that are things we should have in mind when rmmod something causes
>>> unexpected behavior in current consumption. Remember, I had that drop in
>>> suspend current on the a5 when I did rmmod hci_uart.
>>> 
>>> I was not aware of this.  
>> 
>> I wasn't as well...
>> 
>> IMHO there are (were) different pinmux settings for all gpios in suspend?
>> Those should probably applied on rmmod...
> 
> To me it is not clear at all how things should behave here. Should the
> driver somehow declare that the gpio should not be released?
> We can add the pulldown via pinmux to keep the gpio at inactive level.

This is IMHO the cleanest way.

> Is the gpio behavior really sane? Shouldn't gpios generally be declared as
> input, output or both (and not only the inputenable in the pinmux).
> Lots of strange things.

This is special for omap. Usually one would expect that a gpio is always
input and you declare it to be an output.

But on OMAP you can only enable the input by pinmux.

The reason seems to be that pinmux and gpio-controller are quite independent
functions.

And if a pin is really activated as output is defined by the controller. For e.g. i2c
the controller automatically switches on/off the output function. And "input"
must be defined so that it can receive something. Or if you define a gpio as
output, this does not change pinmux.

So a pinmux INPUT can be better interpreted as a "do not disable signals from
the pin to the controller". This may have an electrical reason (capacity, floating
inputs, feedback loop etc.).

The concept could well go back to OMAP1 and have been defined in the 1990ies and was
never changed by reuse of VHDL building blocks to keep software compatibility...

But that is speculation.

> Note: AFAIK only gpio stuff is affected here, not port pins at driver removal.
> For gpio-controlled regulators this is also not an issue.
> 
> There are separate pinmux settings for suspend, but I think that is really
> system suspend and not runtime suspend. Then some drivers have support for
> an idle state in their driver code.

Ok.

> Maybe it is a good idea to touch pinmux as little as possible in uboot, so
> most things stay in mode 7.
> At least we can then ensure that the kernel dtb is pinmux-complete.
> For several things, it still depends now on initialisation by uboot.

What is missing? IMHO it is no problem to augment the DTS to define the
same thing as u-boot already does. Just to be sure and safe.

ARAIK, u-boot only sets those pins it needs for its operation and to
protect hardware from wrong and power consuming states before the kernel
overwrites it for its own purposes.

> With Mode 7 we could ensure that everything is inactive before driver load
> besides our mad on/off-pulse chips.

IMHO this is already the case or do you have a specific example where it
isn't?

> The only (and quite hard) limitiation I see is that we would loose
> compatibility for old kernels.
> But maybe that is a step to go for pm debugging rather than for
> an official letux uboot release.

BR,
Nikolaus



More information about the Letux-kernel mailing list