On Thu, 2010-06-10 at 21:21 -0700, David Brownell wrote:
quoted text
> Do we at least have a clean way that a driver can
> reject a system suspend?  I've lost track of many
> issues, but maybe this could be phrased as a QOS
> constraint:  the current config of driver X needs
> clock Y active to enter the  target system suspend
> state, driver's suspend() method reports as much.  Then the entry to
> that system state gets blocked
> if the clock isn't enabled.

So in QoS modifications to android patches, the answer is "yes" ...
except that the current android patch set didn't actually have this type
of wakelock in it.

Android wants an idleness suspend block (or pm qos constraint) that a
driver can set to prevent the system idleness power govenor from
dropping into a power state too low for the driver, so in USB terms this
would prevent the states that shut down the clock.  For android, it
prevented shutdown of an internal i2c bus.

The one thing that does look difficult is that these power constraints
are device (and sometimes SoC) specific.  Expressing them in a generic
way for the cpu govenors to make sense of might be hard.

quoted text
> (That QOS constraint should be removed when that
> driver no longer needs to issue wakeups; that's
> not quite the same as "removed by driver.resume().

The USB one needs user input, doesn't it, since user hot plug might (or
might not) be one of the wakeup sources.

James


--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/