GTA series power design

joerg at joerg at
Sun Apr 6 16:00:57 CEST 2008

Am So  6. April 2008 schrieb Andy Green:
> However when the CPU goes in and out of suspend, it goes through the
> normal suspend and resume driver actions and has the chance to make
> power arrangements in there.
For the dead time from driver resume: i think as long as we can have the CPU 
wake up in a few millisec on any interrupt of the driver, we don't need to 
suspend the driver/peripherial at all. Powered down peripherials don't need 
to be resumed anyway.

> Something that I think can work well was in-driver power management
> based on open handles from userspace.  We do this on motion sensor
> driver, if nothing has the input events open then the interrupts are not
> serviced... we can do better and remove power from motion sensors too.
> Again if we do not perform any read of battery then HDQ FIQ does not
> run, driven by if usermode has sys node open.

My idea of yesterday, so 100% ACK! We even can have device nodes with no I/O 
at all, for sole purpose of switching on sth as long as they are open - WIWF

> Cesar had the idea that we break out low power / operation configuration
> action from suspend / resume functions and are able to use it even when
> in CPU active mode, this is a great idea to make a single implementation
> of low power mode for a peripheral that also includes power switching
> decision, but which can be deployed when the CPU is up just not using
> the peripheral.  When combined with monitoring open handles for some
> cases anyway it can be pretty optimal power behaviour without any API.

And no need to add power management extensions to each end every app. When I 
start a browser, it will open the TCP-sockets, these open WiFi device and we 
go WiFi power-up. Same for GPS etc. Not a very precise picture, but the way 
to go. For WiFi maybe we need 2 virtual network devices, one for "user apps" 
that powers up the hardware, and one that's only active while we are really 
connected but doesn't init a network association by itself (for "always 
online" daemons like resolver, ntpdate etc)


More information about the openmoko-kernel mailing list