On Mon, May 3, 2010 at 5:09 PM, Arve Hjønnevåg <arve@xxxxxxxxxxx> wrote: > On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman >> >> In addition, it will likely cause duplicate work to be done in >> drivers. Presumably, PM aware drivers will want to know if the system >> is in opportunistic mode. For example, for many drivers, doing >> runtime PM may not be worth the effort if the system is in >> opportunistic mode. > > Why? If a device is not in use it should be off regardless of what > state the rest of the system is in. > >> This last point is especially troubling. I don't find it a comforting >> path to go down if the drivers have to start caring about which PM >> policy is currently in use. I'll echo Arve here -- all drivers should seek to be in the lowest power state possible at all times. We've never suggested that suspend_block is a substitute for that. Suspend blockers give us some flexibility on systems where runtime pm will not get us all the way there. If you can meet your power needs without needing suspend blockers, awesome, you don't need them on that platform. The patchset Arve sent out makes this feature an off-by-default kernel configuration option that compiles out to no-ops when disabled. In our experience, periodic timers and polling, both userspace side and kernelside make suspend blockers a win even on platforms like OMAP which have pretty flexible hardware power management. Going to low power states in idle results in higher average power consumption than going to the same states in full suspend, at least on Android devices shipping today. Brian _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
