> On Wed, May 05, 2010 at 03:55:34PM -0400,
tytso@mit.edu wrote:
>
> > I confess I've completely lost track of (a) what problem you are
> > trying to solve, and (b) how this might relate to some change that
> > you'd like to see in the suspend block API. Could you do a quick
> > summary and recap? I've gone over the entire thread, and it's still
> > not clear what change you're advocating for in suspend blockers.
>
> The issue isn't suspend blockers, it's the opportunistic suspend stuff
> that goes along with them. When that is in use the system suspends
> vastly more aggressively, including in situations where a runtime PM
> based approach like mainline had been adopting would not suspend since
> some devices still need to be active, the classic case being keeping the
> audio subsystem and baseband live when in a phone call. This problem
> did not appear to have been considered as things stood.
>
> I'm not really advocating a change in what's there. What I'm looking
> for is some sort of agreement as to how subsystems and drivers that need
> to not act on suspend requests from the core in these situations should
> do that. If there is a generic solution it'd probably be an additional
> mostly orthogonal interface rather than a change to what's being
> proposed here.
>
> What we look like we're converging on is a subsystem/driver local
> solution since it doesn't look like a terribly widespread problem.
> That's totally OK, it's just that as I have said I don't want to go off
> and do that without the general PM community being aware of it so we
> avoid anyone running into nasty surprises further down the line.
