[Letux-kernel] GPIOs and driver removal

Andreas Kemnade andreas at kemnade.info
Tue Nov 20 07:34:55 CET 2018


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20181120/8b1c2f32/attachment.asc>

More information about the Letux-kernel mailing list