Arve Hjønnevåg <arve@xxxxxxxxxxx> writes: > This patch series adds a suspend-block api that provides the same > functionality as the android wakelock api. This patch series removes > the sysdev that was used to abort suspend and adds a direct check in > suspend_enter instead. It also has some other code style changes. Sorry for joining the wakelock/suspend-block discussion a bit late, but I have a very basic, and possibly stupid question on the need for such a feature. My basic question: is why not use idle (dynamic PM) instead of suspend (static PM) for this? IOW, why not use CPUidle + PM QoS to achieve the same goal? It seems to me that you're trying to add some dynamic PM features onto a static PM subsystem. I could see PM QoS possibly needing some extending but the basic abilities to constrain the low-power states are there. The one reason I can think of is that you can always have broken drivers or apps that prevent you from hitting idle. But with tools like powertop, it's pretty easy to find these problems and fix them. If that is the primary concern, it seems to me that we're introducing a new kernel API to work around broken drivers and apps that should be fixed instead. What am I missing? Kevin _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
