Re: power management problems in ehci-omap

[Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2895 bytes --]

On Tue, 6 Feb 2018 09:17:37 -0800
Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:

> * Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> [180206 16:56]:
> > On Tue, 6 Feb 2018 08:04:52 -0800
> > Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> >   
> > > * Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> [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:

https://misc.andi.de1.cc/measure4.sh

and

https://misc.andi.de1.cc/measure5.sh

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
https://misc.andi.de1.cc/measure5.sh
the second suspend compared with the first whether the phy (the USB
2233) stays on. 

Regards,
Andreas

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]