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

andrzej zaborowski balrogg at
Fri Jul 11 11:52:35 CEST 2008

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.

> 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

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.


More information about the openmoko-kernel mailing list