2008/7/10 Sean McNeil <[EMAIL PROTECTED]>: > 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 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. Regards
