[Letux-kernel] letux v5.4 + suspend

[Andreas Kemnade]

On Sun, 1 Dec 2019 09:55:00 +0100
Andreas Kemnade <andreas at kemnade.info> wrote:

> On Sat, 30 Nov 2019 22:29:40 +0100
> Andreas Kemnade <andreas at kemnade.info> wrote:
> 
> > On Thu, 28 Nov 2019 16:35:51 +0100
> > Andreas Kemnade <andreas at kemnade.info> wrote:
> >   
> > > On Wed, 27 Nov 2019 21:38:36 +0100
> > > Andreas Kemnade <andreas at kemnade.info> wrote:
> > >     
> > > > Hi,
> > > > 
> > > > On Tue, 26 Nov 2019 23:01:08 +0100
> > > > Andreas Kemnade <andreas at kemnade.info> wrote:
> > > >       
> > > > > Hi,
> > > > > 
> > > > > while I get down to the typical 26mA idle current on GTA04A5, I do not
> > > > > wake up from suspend there. 
> > > > > Not investigated yet.
> > > > >         
> > > > Played around on the letux3704:
> > > > 
> > > > init=/bin/bash
> > > > mounting sysfs, proc
> > > > /etc/rcS.d/udev start
> > > > 
> > > > and then doing rtcwake -s 20 -m mem
> > > > does not wake up
> > > > 
> > > > rm -rf /lib/modules/5.4.0-letux+/kernel/drivers/gpu/drm/pvrsgx
> > > > 
> > > > fixes the issue.
> > > >       
> > > But we have 50mA suspend current if musb stuff is loaded.
> > >     
> > setting up bisect,
> > test script works,
> > first verdict: letux added stuff on 5.4 is not guilty.
> > v5.3 is good in terms of suspend current but with g_ether ifup current
> > consumption is at 50mA. So for nice idle current (at least without
> > ehci-omap), choose 5.4 and for nice suspend current 5.3 is better.
> > That is crazy.
> > 
> > Testing suspend is a bit tricky. I soft-connect usb for transferring
> > kernel to the target, but turn it off afterwards and again on after
> > suspend to collect results.
> > And during kernel compile it is time to charge the battery.
> > 
> > Lets hope this gives some interesting results.
> > 
> > git bisect run
> > is active now. 
> >   
> # first bad commit: [219d54332a09e8d8741c1e1982f5eae56099de85] Linux 5.4
> 
> hmmmmm
> head->scratch()
> 
> the first try was a clean rebuild with out-of-tree dtb and config.
> Now, I am doing another clean build and the problem is not there.
> 
> so maybe my first v5.4 test was bad?
> With letux-5.4 without 1Ghz opp and pvrsgx I have seen the issue on the
> letux3704 and also on the gta04a5 booting the ordinary µSD-way.
> 
some log diff of the various v5.4 mainline runs.
@@ -499,9 +499,9 @@
 bq27xxx_battery        20480  1 bq27xxx_battery_hdq
 omap_hdq               16384  0 
 overlay                86016  1 
-+musb,g_ether cur: 44982 delta: 13566
-+ifup cur: 31416 delta: -13566
better idle current

-musb+phy+charger  DELTA current: NOK
++musb,g_ether cur: 55156 delta: 23740
++ifup cur: 52122 delta: -3034
+musb+phy+charger  DELTA current: OK
      CM_IDLEST1_CORE 00000042
      CM_IDLEST3_CORE 00000000
      CM_FCLKEN1_CORE 00000000
-- without different bits set.

@@ -515,17 +515,16 @@
        CM_IDLEST_CAM 00000000
        CM_FCLKEN_PER 00000000
        CM_IDLEST_PER 00030000
-before: 582060
-after: 577076
-suspend VERY HIGH
= good vs. bad keyword

-average 59808 uA over 300 seconds
- cur: 130840 delta: 99424
-     CM_IDLEST1_CORE 00401042
+before: 422038
+after: 419724
+average 27768 uA over 300 seconds
+ cur: 132804 delta: 80682
+     CM_IDLEST1_CORE 00001042
      CM_IDLEST3_CORE 00000000
-     CM_FCLKEN1_CORE 00401000
+     CM_FCLKEN1_CORE 00001000
hmm, this is hdq on. Does it stick
from the last measurement before suspend and I am really debugging hdq races here?
So is the cat dead or alive?!

      CM_FCLKEN3_CORE 00000002
      CM_CLKSTST_CORE 00000003
-     CM_IDLEST_CKGEN 00000a13
+     CM_IDLEST_CKGEN 00000803
     CM_IDLEST2_CKGEN 00000000
        CM_FCLKEN_DSS 00000001
        CM_IDLEST_DSS 00000003

Will try to check thing the next days.

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/20191201/308ed546/attachment.asc>