On Sat, May 29, 2010 at 8:03 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Sat, 29 May 2010, Brian Swetland wrote: >> On Sat, May 29, 2010 at 7:10 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> > If no such constraints are active, the QoS-based suspend blocks in an >> > interruptible wait until the number of active QOS_EVENTUALLY >> > constraints drops to 0. When that happens, it carries out a normal >> > suspend-to-RAM -- except that it checks along the way to make sure that >> > no new QoS constraints are activated while the suspend is in progress. >> > If they are, the PM core backs out and fails the QoS-based suspend. >> >> The issue with this approach is that if userspace wants to suspend >> while a driver is holding a QOS_EVENTUALLY constraint, it's basically >> going to spin constantly writing "qos" and failing. > > No, no. If userspace wants to suspend while a driver is holding a > QOS_EVENTUALLY constraint, the user process blocks in an interruptible > wait state as described in the first paragraph above. Oops -- I misread the first paragraph. The behavior you described is indeed what I would want. Brian _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
