GTA series power design
joerg at openmoko.org
joerg at openmoko.org
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)
jOERG
More information about the openmoko-kernel
mailing list