On Thu, 2010-06-10 at 21:21 -0700, David Brownell wrote: > 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. > (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 -- 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
