[Letux-kernel] power management problems in ehci-omap

Andreas Kemnade andreas at kemnade.info
Tue Feb 6 19:03:47 CET 2018

On Tue, 6 Feb 2018 09:17:37 -0800
Tony Lindgren <tony at atomide.com> wrote:

> * Andreas Kemnade <andreas at kemnade.info> [180206 16:56]:
> > On Tue, 6 Feb 2018 08:04:52 -0800
> > Tony Lindgren <tony at atomide.com> wrote:
> >   
> > > * Andreas Kemnade <andreas at kemnade.info> [180206 06:42]:  
> > > > rechecked with a board with really nothing connected there
> > > > Same behaviour    
> > > 
> > > I've just verified that my test board power consumption goes
> > > back to normal after rmmod ehci-omap with v4.15.
> > >   
> > yes, for me too, I initially used a test script which does an
> > echo rmmod ehci-omap
> > 
> > without a real
> > rmmod ehci-omap  
> Ah OK :)
> > It just seems to be consistent with my observations in a fully booted
> > system (where many things can play a role). Sorry for that confusion.  
> Try with a minimal set of modules first, then modprobe and rmmod one
> at a time until you find the module breaking PM?
Yes, that is basically what I do with this script:




I start from a bare kernel, check currents, load ehci-omap (I have also
debugged many other pm things that way)
check currents again. 
But since my rough observations with a fully loaded system
seem to match with the 
echo rmmod behaviour, I did not notice my mistake.

> You probably know this already, but just in case it helps..
> First idle the UARTs and enable off mode with something like:
> uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d)
> for uart in $uarts; do
> 	echo 3000 > $uart/autosuspend_delay_ms 2>&1
> done
> uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
> for uart in $uarts; do
> 	echo enabled > $uart/wakeup 2>&1
> 	echo auto > $uart/control 2>&1
> done

hmm, this looks a bit like runtime suspend.

I mean suspend aka echo mem >/sys/power/state

> echo -n 1 > /sys/kernel/debug/pm_debug/enable_off_mode
In earlier times this just caused trouble and a little lower current,
maybe it is time to check again.

> Then if using omap3, the attached debug hack patch can be used to
> see which devices are not idling:
Yes, I will try out. It it about detecting whether the soc itself went
into low power mode. But it does not check e.g. whether the phy is put
into low power mode correctly. So ehci-usb in soc might be powered off
and phy is still on.

When I go to suspend, I get this message:
"Successfully put all powerdomains to target state"

@Nikolaus: Can you check IR at the end of the suspend time in
the second suspend compared with the first whether the phy (the USB
2233) stays on. 

-------------- 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/20180206/c97d5de3/attachment.asc>

More information about the Letux-kernel mailing list