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
