android goes back to suspend

[Ventanas]

I have been working with a linux kernel 2.6.29 and I now have
implemented the suspend/resume for my machine based on PXA310.

So I can put Android into suspend by typing 'echo mem > /sys/power/
state', so I can wakeup the machine from suspend by a trigger (i.e.
hardware on-off button) and Android wakes up for some seconds and goes
again back to suspend, showing these messages over the serial port:

wakeup wake lock: mmc_delayed_work
wake_lock: mmc_delayed_work, type 0

wake_lock: mmc_delayed_work, type 0, timeout 0.500
wake_lock: mmc_delayed_work, start expire timer, 64
suspend: exit suspend, ret = 0 (2000-01-01 00:01:52.743408205 UTC)
expire_wake_locks: start
wake lock mmc_delayed_work, expired
expired wake lock mmc_delayed_work

expire_wake_locks: done, has_lock 0
suspend: enter suspend
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
Suspending console(s) (use no_console_suspend to debug)

anyone knows why??

if I am able to type 'echo on > /sys/power/state' over the serial port
just one second after the device resumes from suspend, then the
ANDROID wakes and stays on and it doesn't get back to suspend.

Why?

help me, help me....!!!!

Marco

[mark gross]

there is a time out wake lock (1 sec) that gets grabbed at the end of
the pm_suspend code path path (I think). (you'll have to look in your
specific kernel version for it)

Someone needs to grab a wake lock in user mode or echo on before that
wake lock times out or you go back to sleep.

This is by design. (and it has been oh-so-much-fun to discuss on
linux-pm in the past)

User mode should be grabbing a wake lock under this implementation to
hold off subsequent sleeps.

--mark

> --
> unsubscribe: android-kerne...@googlegroups.com
> website: http://groups.google.com/group/android-kernel

--
create interesting things.

[Ventanas]

So do I have to encrease this timeout?
I guess user mode android code will echo on to the /sys/Power/state
file, Right? Or ama I wrong?

On 30 Mar, 19:50, mark gross <mark97...@gmail.com> wrote:
> there is a time out wake lock (1 sec) that gets grabbed at the end of
> the pm_suspend code path path (I think).  (you'll have to look in your
> specific kernel version for it)
>
> Someone needs to grab a wake lock in user mode or echo on before that

> wake lock times out or you gobackto sleep.

>
> This is by design.  (and it has been oh-so-much-fun to discuss on
> linux-pm in the past)
>
> User mode should be grabbing a wake lock under this implementation to
> hold off subsequent sleeps.
>
> --mark
>
>
>
>
>
> On Wed, Mar 28, 2012 at 2:40 PM, Ventanas <guerreromarc...@gmail.com> wrote:
> > I have been working with a linux kernel 2.6.29 and I now have

> > implemented thesuspend/resume for my machine based on PXA310.
>
> > So I can putAndroidintosuspendby typing 'echo mem > /sys/power/
> > state', so I can wakeup the machine fromsuspendby a trigger (i.e.

> > hardware on-off button) andAndroidwakes up for some seconds andgoes

> > againbacktosuspend, showing these messages over the serial port:

>
> > wakeup wake lock: mmc_delayed_work
> > wake_lock: mmc_delayed_work, type 0
>
> > wake_lock: mmc_delayed_work, type 0, timeout 0.500
> > wake_lock: mmc_delayed_work, start expire timer, 64

> >suspend: exitsuspend, ret = 0 (2000-01-01 00:01:52.743408205 UTC)

> > expire_wake_locks: start
> > wake lock mmc_delayed_work, expired
> > expired wake lock mmc_delayed_work
>
> > expire_wake_locks: done, has_lock 0
> >suspend: entersuspend
> > PM: Syncing filesystems ... done.
> > Freezing user space processes ... (elapsed 0.00 seconds) done.
> > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
> > Suspending console(s) (use no_console_suspend to debug)
>
> > anyone knows why??
>
> > if I am able to type 'echo on > /sys/power/state' over the serial port
> > just one second after the device resumes fromsuspend, then the

> >ANDROIDwakes and stays on and it doesn't getbacktosuspend.

[mark gross]

I think that you may be wrong.

Most times when this happens its because there is some user mode service or middle-were that needs to consume the wake event and *that* thing should be grabbing a wake lock from user mode through the normal android API's.

I would say you are missing some integration in your user mode stack that needs fixing more than hacking up the kernel more.

BTW looking at the changes to the kernel/common.git, android-3.3 branch, it looks like there is some significant changes coming WRT the power manager service (the PMS) I look forward to seeing.

Putting more of your own PM hacks into the kernel will come back and bite you.  I'd see about grabbing the user mode wake lock before putting any more code into the kernel wake lock flows.

--mark

[Ventanas]

ok, I am trying to debug the libhardware_legacy.so library that
contains the power.c 'C'-code module that interacts with the linux-
kernel power manager, but I have this problem:

I want to open the /dev/kmsg file and write to it, but I get always
-1, do you know why I cannot open("/dev/kmsg", O_WRONLY); from this
module?

while I can from a classic 'C' main-program in user mode.

Marco

[Ventanas]

found that errno is always 13, that is EACCES, so access no Permission
denied, so what can I do?
M

[Manjeet Pawar]

Y dont u use procfs or ioctl...to check whats goin on inside...

[Ventanas]

another problem: power.c wants to write to this file: /sys/
android_power/auto_off_timeout

I don't see the android_power directory in the sysfs, ?

what is missing???

[Ventanas]

I've checked one more time the power.c code, and the fact that /sys/
android_power doesn't exist should not be a problem as it is the old
device driver for android power management in the linux kernel, while
the newer is named /sys/power

but I have an idea: as libhardware_legacy.so is not able to open/write
to /dev/kmsg, maybe it is also not able to open/write to /sys/power/
state, maybe is this the root cause?

[Ventanas]

I have found a way to trace from libhardware_legacy/power.c, sorry, it
was simpler than what I thought, I'm using logcat through serial port.

And now I can see that power.c is able to write to /sys/power/state,
but again the problem is that when resuming it doesn't write "on" to
"state".

M

[Ventanas]

I have a good news: I think that now I am on the right track, but I
need a little suggestions about how to proceed:

IF I touch the screen (my device has a touch-screen driver working
fine with ANDROID) when ANDROID system is resuming due to the pressure
of the "on/off" physical-hardware button (that is my wakeup source),
then the ANDROID system stays ON, so it doesn't go back to suspend.

So how can I produce the same behavior by software?

My resume code, that is my_platform_pm_enter_sleep routine statically
linked to the kernel, is able to recognize that the wakeup source is
the "on/off" hardware button, so what kind of notification should I
send to Android PowerManagerService in order to make it write 'on' to
the /sys/power/state file?

Marco

[marcero]

Hello,

we have currently the same problem with our kernel.
It wakeups from deepsleep, but enters suspend before it executes the late_resume method.
If it wakes from deepsleep it did not execute the state_store() method, that's why I think that there is nothing written to /sys/power/state succesfully while coming from deepsleep.
If you press power button twice, before the tablet went back to deepsleep, it wakes up, then the state store routine was also executed.

Did you find any solution to your problem?

[Ventanas]

I have found solution to my problem, yes

I have changed my power button device driver in order to report an
input event, like other kerboard keys and touch screen pen , all they
have to report an input event in order to trigger the power manager
system

[ritesh....@gmail.com]

Hello,

I too am facing the same issue here(3.10 kernel) "It wakeups from deepsleep, but enters suspend before it executes the resume"
but I checked my power button device driver, its already reporting the KEY_POWER event via input_report_key. Thus it should tell the PowerManager service to acquire a wake lock right ?

But if I am acquiring a wake_lock_timeout of 1 sec in power button isr then I can see the resume happening every time.
But I think that tweaking kernel is not the correct way. What do you guys say on this ?

Could you guys please tell what should be the correct way to fix this ?