[Gta04-owner] Further 3.17 kernel development for GTA04

[NeilBrown]

On Sun, 09 Nov 2014 15:57:04 +0000 Neil Jerram <neil at ossau.homelinux.net>
wrote:

> Neil Jerram <neil at ossau.homelinux.net> writes:
> 
> > NeilBrown <neilb at suse.de> writes:
> >
> >> On Wed, 05 Nov 2014 00:22:29 +0000 Neil Jerram <neil at ossau.homelinux.net>
> >> wrote:
> >>
> >>> What config do you use when building your kernel for GTA04?  I've
> >>> checked out your 3.17-gta04, but don't see any obvious GTA04 configs
> >>> under arch/arm/configs.
> >>
> >> See below.  I'm in two minds about including this.
> >
> > Thanks.  After some entertaining diversions (*) I've built and booted
> > this kernel and can report that it seems to solve two other problems
> > that were afflicting my last experiments back in June/July [...]
> >
> > Thank you!
> 
> Does suspending work correctly for you with this kernel?  I have a
> script that I use with xautolock to suspend automatically, and its log
> indicates an I/O error when it tries to suspend by writing 'mem' to
> /sys/power/state:
> 
>   + echo mem
>   sh: echo: I/O error
> 
> If I try to suspend explicitly from the command line, here's what
> happens:
> 
>   root at neo:~# cat /sys/power/state 
>   freeze mem
>   root at neo:~# echo mem > /sys/power/state 
> 
> The screen has gone blank, and so the phone now appears to have
> suspended.  However, if I just tap the screen, it comes on again, and
> then in the SSH session I see:
>  
>   -bash: echo: write error: Operation not permitted
>   root at neo:~# 
> 
> Are you seeing similar?

Hi Neil.
I do get "Operation not permitted" when I write to /sys/power/state.

This is directly related to the messages:

[146823.865875] Powerdomain (per_pwrdm) didn't enter target state 1
[146823.865875] Powerdomain (core_pwrdm) didn't enter target state 1

they cause omap3_pm_suspend to return "-1" which percolates all the way up
and comes out the top as "Operations not permitted".

Despite this error, my device does enter "suspend" state until something
wakes it up.  A tap on the screen does *not* wake it up.

So presumably your device isn't actually go into suspend.

One thing you could try is to log the output of

  date ; cat /sys/kernel/debug/wakeup_sources

immediately before and after writing "mem" to "/sys/power/state".
That will tell you how long it was in suspend for, and any change in
'wakeup_sources' might tell you why it woke up ... or might not.

NeilBrown


> 
> Thanks,
>         Neil
> 
> 
> Here's how I use xautolock, in case the detail is useful.  In .xsession
> I have:
> 
>   # Auto-suspend.
>   rm -f /var/log/autolock.log
>   rm -rf /root/autolock/stayalive.d
>   mkdir /root/autolock/stayalive.d
>   xautolock -time 1 -locker /root/autolock/autolock.sh -detectsleep &
> 
> And the content of /root/autolock/autolock.sh is:
> 
>   #!/bin/sh
>   exec >>/var/log/autolock.log 2>&1
>   set -x
>   echo $0 started `date`
>   xautolock -disable
>   if [ "$(ls -A /root/autolock/stayalive.d)" ]; then
>       : "Suspending is disallowed"
>   else
>       : "Suspending is allowed"
>       read AC_ONLINE < /sys/class/power_supply/twl4030_ac/online
>       read USB_ONLINE < /sys/class/power_supply/twl4030_usb/online
>       if [ x$AC_ONLINE != x1 -a x$USB_ONLINE != x1 ]; then
>           echo mem > /sys/power/state
>       fi
>   fi
>   xautolock -unlocknow
>   xautolock -enable

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20141110/dd2452ef/attachment.asc>