[Gta04-owner] Further 3.17 kernel development for GTA04
neilb at suse.de
Sun Nov 9 23:23:19 CET 2014
On Sun, 09 Nov 2014 15:57:04 +0000 Neil Jerram <neil at ossau.homelinux.net>
> 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
> + echo mem
> sh: echo: I/O error
> If I try to suspend explicitly from the command line, here's what
> 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?
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.
> 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:
> 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"
> : "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
> xautolock -unlocknow
> xautolock -enable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 811 bytes
Desc: OpenPGP digital signature
More information about the Gta04-owner