On Sun, Feb 8, 2009 at 2:17 PM, Pavel Machek <pavel@xxxxxx> wrote:
> Hi!
>
> Ok, I think that this wakelock stuff is in "can't be used properly"
> area on Rusty's scale of nasty interfaces.
>
> So... do I understand this correctly that if I want to run "make zImage"
> on Android, I'll need to modify make, gcc, .... to keep system awake?
Or you could grab a wake lock before starting the job. e.g.
"runwithwakelock make".
What prevents the system from suspending while you run make in your
existing system?
> (How to do that? Give all the userland processes access to
> /sys/wakelocks ?)
That depends, do you want users to be able to keep the system on?
> BTW what does android do when battery goes critically low? I believe
> you want to suspend, ignoring wakelocks, at that point.
I don't know for sure, but I believe it does a full shutdown.
> And now, you have some X-like system.
>
> /* We were idle for too long */
> blank_screen();
>
> unlock_all_wakelocks(); /* We want machine to sleep */
>
> wait_for_key();
> /* (here) */
> lock_wakelocks("processing_key_wakelock");
>
> ...is that approximately correct? There's race there, right? If (here)
> processing takes too long, or whatever, kernel will sleep the machine
> before it even displays "do you want to unlock the screen" dialog,
> right?
>
> Can you solve that in a way that works, always?
There is no unlock_all_wakelocks call, you unlock the "main" wakelock
by writing to /sys/power/request_state. There is no race in your
example as long as your wait_for_key function just does a select or
poll call and does not read the key events. The wakelock on the event
queue prevents sleep. This is what my example in the wakelock doc
describes.
--
Arve Hjønnevåg
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
