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

Carsten Haitzler (The Rasterman) raster at openmoko.org
Fri Jul 11 19:13:57 CEST 2008


On Fri, 11 Jul 2008 19:34:55 +0300 "andrzej zaborowski" <balrogg at gmail.com>
babbled:

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

oh sure - though this is normally done by the wifi card for example - only
packets for your mach address are handled - everything else is ignored and wont
wake u up... :) but yes. there is a minimal set of stuff defines need to know
as if they are to issue an interrupt to not - gsm modem too.

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

sure - but it does have wifi ant bluetooh - it's almost there. just 1 device
missing.

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

sure - thought modern soc's are moving to having separate clocks for more
devices making this all a LOT simpler. you clock them each as needed separately
(from off to slow, medium and full speed etc. etc.)

>  * 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).

that does indeed help.

> 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)
> 
> Cheers


-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>




More information about the openmoko-kernel mailing list