Re: [RFC][PATCH 0/9] Suspend block api (version 3)

[Kevin Hilman <khilman@deeprootsystems.com>]

Arve Hjønnevåg <arve@android.com> 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