backlight device, suspend/resume... [RANT]

Carsten Haitzler (The Rasterman) raster at
Fri Jul 11 13:04:52 CEST 2008

On Fri, 11 Jul 2008 12:52:35 +0300 "andrzej zaborowski" <balrogg at>

> 2008/7/10 Sean McNeil <sean at>:
> > andrzej zaborowski wrote:
> >> To see anything on the LCD you need the backlight, the LCD controller
> >> and various other parts resumed. But if you're checking whether to
> >> really resume, or go back to suspend, you don't want to power up
> >> anything that's not needed before this check. Userspace is much too
> >> late for this. I'd say even the kernel possibly is too late (there's
> >> u-boot before). When you hit userspace, all your processes are again
> >> in the "RUNNING" state (even before your daemon actually starts to
> >> execute), including your mp3 player and anything you had left running
> >> when you suspended (imagine the kernel is a zoo and the processes are
> >> wild crazy animals, that you free all at once when you let userspace
> >> run, somewhere in the mess is your daemon).
> >
> > I'm not certain which position you are advocating. I disagree that userspace
> > is too late to check certain conditions. In fact, I would say that only
> > userspace has all the necessary information to make such a determination.
> All necessary information can be passed on to u-boot or kernel before
> suspending so it can make the correct decision upon waking up and
> reading what the modem has to say. But I kind of agree that with
> TS07.10 muxing enabled, the decoding is a bit heavy for u-boot/linux,
> especially considering there's no TS07.10 in kernel still.

it definitely can't decide before suspend. case: if gsm or wifif interrupts
wakeup userspace has to parse decode and decide on the content of the gsm data
or the network protocol data THEN decide if you need the screen. eg a simple
cell braodcast message is often just an informational update (eg like time
updates, location updates) or you get a icmp ping packet or some other
innocuous ssh keepalive. do you want to turn on the screen every time these
interrupt something? no! but you DONT know UNTIL userspace has woken up and
made that decision (ok ICMP ping excepted - kernel handles it, but any form of
higher-level ping in a protocol will be the same).

> > Again, there is the example where we are in mem suspend to reduce power
> > consumption. You turned the LCD off because you might awaken for some reason
> As far as I understand Raster's daemon doesn't do anything with the
> LCD, only shuts the backlight, which is just one part. The LCD module
> and the Glamo chip are powered separately from the backlight.  We
> don't need them or any of the other peripherals, we need only the
> modem (which is already up) and one s3c2442 uart. But the kernel will
> resume all of the roughly 30 (I think?) platform_devices before
> letting userspace run, and it may turn out that in a moment it needs
> to suspend all of them again. Maybe the benefits outweight that
> though.
> Another fun idea is: shut down and resume all the hardware manually
> from the userspace daemon with sysfs writes. This way we can resume
> only those that we deem necessary. This way we can also implement a
> resume order policy in userspace (dependencies between devices). The
> overall suspend and resume time shouldn't be affected because the
> kernel knows that a given device is already down and doesn't suspend
> it a second time. It's a bit crazy though: you have to know what every
> application on the system does. If you have a music player running and
> you suspend the audio card, the player will likely die, while we just
> wanted to suspend the system. And you need your rootfs up, the kernel
> doesn't need it.

this is actually exactly what is needed for zero-clock, which one way or
another is the real future. nokia does it with the n8xx etc. - this requires
apps to inform the daemon they NEED a resource (eg audio or screen or gsm or
wifi). then the daemon handles making sure those things needed come up when

Carsten Haitzler (The Rasterman) <raster at>

More information about the openmoko-kernel mailing list