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

andrzej zaborowski balrogg at
Fri Jul 11 18:34:55 CEST 2008

2008/7/11 The Rasterman Carsten Haitzler <raster at>:
> On Fri, 11 Jul 2008 12:52:35 +0300 "andrzej zaborowski" <balrogg at>
> babbled:
>> 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.

Obviously not. But beside whatever has to be read from the hw (say an
incoming tcp packet from wifi) you need some current state information
which only software has (such as your current IP) to determine if the
wake-up is important enough. That's the information you would have to
explicitely pass to bootloader.

> 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
> appropriate.

I don't know, n8xx doing it doesn't automatically mean it's the
future. Here are some differences:

 * n8xx has no modem to feed.
 * n8xx  has an OMAP chip - their idle state handling is incomparably
better than those of S3C, their CPU sucks the amount of power in the
orders of magnitude of the MCU proposed here (when the load is low).
But they also pay something for it: 500kB of their kernel binary is
actually the code handling power domains and clock domains. The
hundreds of patches that go through the linux-omap ML every week all
concern this, and the patches flow constantly since about 2004
starting with Montavista soft inc. In contrast on the s3c's *nobody*
does any power profiling (at least not in the public) and the code is
super simple. As a bonus making drivers is also simpler.
 * iirc they used the POP revision of omap2420 which has the RAM
stacked in the same chip with the cpu and the cpu does clever things
to reduce ram power consumption (I may be wrong).

Sure it would be nice (the n810 does four days of gps logging on
battery i.e. not even really idle). But even the n810 gets much longer
life if you actually suspend it (you have to do that from commandline
and Maemo gets slightly confused because they don't normally do that)


More information about the openmoko-kernel mailing list