2010/5/3 mark gross <640e9920@xxxxxxxxx>: > On Fri, Apr 30, 2010 at 03:36:54PM -0700, Arve Hjønnevåg wrote: ... >> +When the policy is "opportunisic", there is a special value, "on", that can be >> +written to /sys/power/state. This will block the automatic sleep request, as if >> +a suspend blocker was used by a device driver. This way the opportunistic >> +suspend may be blocked by user space whithout switching back to the "forced" >> +mode. > > You know things would be so much easier if the policy was a one-shot > styled thing. i.e. when enabled it does what it does, but upon resume > the policy must be re-enabled by user mode to get the opportunistic > behavior. That way we don't need to grab the suspend blocker from the > wake up irq handler all the way up to user mode as the example below > calls out. I suppose doing this would put a burden on the user mode code > to keep track of if it has no pending blockers registered after a wake > up from the suspend. but that seems nicer to me than sprinkling > overlapping blocker critical sections from the mettle up to user mode. > > Please consider making the policy a one shot API that needs to be > re-enabled after resume by user mode. That would remove my issue with > the design. > Making it one shot does not change where kernel code needs to block suspend, but it does force user space to poll trying to suspend while suspend is blocked by a driver. -- Arve Hjønnevåg -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
