[lkml]   [2010]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [linux-pm] [PATCH 1/8] PM: Add suspend block api.
On Mon, 3 May 2010, mark gross wrote:

> 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.

This won't work right if a second IRQ arrives while the first is being
processed. Suppose the kernel driver for the second IRQ doesn't
activate a suspend blocker, and suppose all the userspace handlers for
the first IRQ end (and the opportunistic policy is re-enabled) before
the userspace handler for the second IRQ can start. Then the system
will go back to sleep before userspace can handle the second IRQ.

Alan Stern

 \ /
  Last update: 2010-05-04 16:03    [W:0.305 / U:1.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site