backlight device, suspend/resume...
pj at place.org
Wed Jul 9 04:53:09 CEST 2008
Andy Green wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Somebody in the thread at some point said:
> | While we're musing on this, let me add another use case to the mix:
> | suspend/resume of selected devices.
> | Currently the cpufreq mechanism (Cesar's work) is constrained by
> | devices that need very specific clocks.
> | I'd like to see if we can support a partial suspend state that could
> | remove some of the constraints and let the CPU run at slower clocks.
> | For example, if we have nothing plugged into the USB connector,
> | suspending that device alone may allow us to select a lower clock
> | frequency. Another constraint is the requirement for 115200 baud for
> | the GSM; forcing flow-control and suspending the serial driver until
> | GSM interrupts may permit another bit of power savings.
> Yes a "purposeful suspend" ability, that suspended enough so we are
> definitely straight with UARTs and so on, did the Cesar things and then
> came back up again would be an interesting way to guarantee the clock
> modification did not trash anything.
> - -Andy
Is this different from 'disable' as in 'disable bluetooth', 'disable
WLAN', and 'disable GSM' (aka "airplane mode")? Those things should
also probably be able to be as 'purposefully suspended' as possible in
the interest of battery life.
More information about the openmoko-kernel