backlight device, suspend/resume...
mwester at dls.net
Tue Jul 8 18:10:48 CEST 2008
Andy Green wrote:
> Now it looks like we come to a point that the userspace guy wants to hit
> it with the userspace hammer and the kernel guy thinks it better to
> whack it with the kernel hammer. I don't mind overmuch if you want to
> take care of it :-) but it'd be unfortunate if when we considered more
> contexts that want to be part of it we found we started down a less than
> ideal path. It's worth having a muse about all the things plugging into
> this and just checking it is the best way.
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 certain
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 the
GSM interrupts may permit another bit of power savings.
More information about the openmoko-kernel