--- On Fri, 6/11/10, James Bottomley <James.Bottomley@xxxxxxx> 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. Except, we're not talking "wakelock" ... :) So ... no, these cases still have no solution. (I think that's at least five years now.) > The one thing that does look difficult is that these power > constraints > are device (and sometimes SoC) specific. Exactly why they make good examples for turning up framework limitations... like having overlooked constraints coming from various SoC peripherals. > Expressing them in a generic way > for the cpu govenors to make sense of might be hard. Requiring "CPU governors" to be involved in such stuff feels a bit off-course to me. At least, if the involvement is very deep. The constraints are from the integrated peripherals, not (usually) from the CPU There are plent of places to hang SoC or device specific data, once there's awareness that without such data, (which PCs hide behind ACPI bytecode) the PM framework is missing out on support for some desirable low power modes. > > > (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, I don't quite see that. The drivers get called in enough places, and they'll know if the system is going to be in a suspend state where they need to be partially aactive (with various QOS constraints, or they can't work. > since user hotplug might (or > might not) be one of the wakeup sources. If it wakes via hotplug, then the driver must already Do The Right Thing; what input would be needed (Beyond changing the cable config)? > > 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
