[Letux-kernel] GPIOs and driver removal

Andreas Kemnade andreas at kemnade.info
Tue Nov 20 17:14:10 CET 2018


Hi,

On Tue, 20 Nov 2018 09:56:46 +0100
"H. Nikolaus Schaller" <hns at goldelico.com> wrote:

> 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.
> 
At least the easiest 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.
> 
Yes, and here I am talking about gpio-controller function only and how it
handled by kernel. 
So who is turning that on/off gpio into an input at driver removal? And why?

[...]
> > 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.
> 
I will go through it and create dtb patches.

> 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.
>
set_muxconf_regs
in board/goldelico/gta04/gta04.c
The MUX_GTA04 is defined in
board/goldelico/gta04/gta04.h

It is quite complete. 3.7 kernel relied on it.

Regards,
Andreas
-------------- 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/5bf95992/attachment.asc>


More information about the Letux-kernel mailing list