On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi <me@xxxxxxxxxxxxxxx> wrote: > Hi, > > On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote: >> We (Google) would like to allow completely open app distribution with >> minimal hurdles, and avoid the walled garden approach. Toward this >> goal we're not even requiring the use of a central app store for >> distribution. > > I understand that, but still we should be telling developers what > they're doing wrong so that they can improve themselves as professionals > and still make the final device better. I agree. Which is why we develop tools to help developers understand what their apps are doing. >> For a large majority of apps, running in the background while the >> device is asleep (screen off) is not essential, they don't request the >> "keep device awake" permission, never hold a wakelock, etc. Those >> that do need to do this have the permission, may hold suspend >> blockers, and are accounted for. > > but can anyone write an app that holds a suspend_blocker ?? If so, then > your goal is already broken, right ? I mean, if anyone can keep a > suspend_blocker held forever, you'll never ever sleep, right ? While > with runtime, if you keep the keypad open, only the keypad and the paths > directly related to it (probably the i2c controller and the power domain > where the i2c controller sits) will be kept alive, no ? No, you'll never suspend, which is different from never going to the lowest CPU power state. On shipping Android devices we aggressively completely power down the CPU in idle whenever we can (based on latency requirements generally). We power off peripherals whenever they're not in use. This is why I've stated previously that I don't think runtime PM and opportunistic suspend are competitive features. Everyone who cares about minimizing power should want runtime pm or at least similar functionality (our drivers have always powered down peripherals when not in use, even while the device is open, etc, prior to the existence of runtime PM). If your environment is such that going to full suspend will not gain you anything, then don't use opportunistic suspend. We find that there are savings to be had with this model in Android which is why we use it. If you are going to use opportunistic suspend, suspend_blockers provide useful functionality. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
