Suspend block api (version 6)
in [Kernel]
|
Prev: mm: fix race between shift_arg_pages and rmap_walk
Next: [PATCH -next] power: fix block_io.c printk warning
From: Rafael J. Wysocki on 5 May 2010 16:50 On Wednesday 05 May 2010, Mark Brown wrote: > On Wed, May 05, 2010 at 03:55:34PM -0400, tytso(a)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. To me, the above may be summarized that in your opinion some components of the system will generally need to stay powered when it's suspended opportunistically, so we need an interface to specify which components they are. Is that correct? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Brian Swetland on 5 May 2010 17:00 On Wed, May 5, 2010 at 12:13 PM, Alan Stern <stern(a)rowland.harvard.edu> wrote: > On Wed, 5 May 2010, Matthew Garrett wrote: > >> > Clearly if there's a call in progress you don't want to shut the codec >> > down. Are there any other circumstances? Would they vary according to >> > whether the suspend was forced or opportunistic? >> >> Yeah, ok. We probably do need to figure this out. >> >> (Cc:ing Rebecca to see how this got handled on Droid) >> >> The current state of affairs is that a system suspend request is >> expected to put the device in as low a power state as possible given the >> required wakeup events. Runtime power management is expected to put the >> device in as low a power state as possible given its usage constraints. >> If opportunistic suspend does the former then it'll tear down devices >> that may be in use, but we don't have any real way to indicate usage >> constraints other than the phone app taking a wakelock - and that means >> leaving userspace running during calls, which seems excessive. >> >> Mark's right in that the only case I can think of that's really relevant >> right now is the audio hardware, so the inelegant solution is that this >> is something that could be provided at the audio level. Is this >> something we want a generic solution for? If so, what should it look >> like? > > Should the audio driver be smart enough to know that the codec needs to > remain powered up during every opportunistic suspend? > > Or only during opportunistic suspends while a call is in progress? > > Does it know when a call is in progress? From my point of view, the codec should be powered up while audio is playing and powered down when it's not -- that's the approach I've taken on MSM, regardless of suspend state. I don't view suspend as something that stops audio playback in progress. Sort of similar to how the modem doesn't power off down when the system is in suspend, etc. In effect, we have followed a sort of runtime pm model of clocking/powering peripherals at the lowest possible level at all times, which is why I've never viewed suspend_block as somehow competing with runtime pm -- we always want all drivers/peripherals in the lowers power state. Sometimes the lowest power state possible is higher than "full suspend" (for example when we can't meet latency requirements on audio on 7201A) and suspend_blockers cover that case. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mark Brown on 5 May 2010 18:00 On Wed, May 05, 2010 at 10:44:03PM +0200, Rafael J. Wysocki wrote: > To me, the above may be summarized that in your opinion some components of > the system will generally need to stay powered when it's suspended > opportunistically, so we need an interface to specify which components they are. > Is that correct? Yes, though I think I'd be inclined to treat the problem orthogonally to opportunistic suspend to allow more flexibility in use and since treating it as part of opportunistic suspend would imply that there's some meaningful difference between the end result of that and a manual suspend which AIUI there isn't. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Brian Swetland on 5 May 2010 18:10 On Wed, May 5, 2010 at 2:57 PM, Mark Brown <broonie(a)opensource.wolfsonmicro.com> wrote: > On Wed, May 05, 2010 at 10:44:03PM +0200, Rafael J. Wysocki wrote: > >> To me, the above may be summarized that in your opinion some components of >> the system will generally need to stay powered when it's suspended >> opportunistically, so we need an interface to specify which components they are. >> Is that correct? > > Yes, though I think I'd be inclined to treat the problem orthogonally to > opportunistic suspend to allow more flexibility in use and since > treating it as part of opportunistic suspend would imply that there's > some meaningful difference between the end result of that and a manual > suspend which AIUI there isn't. I'd agree with this. This is one of the reasons I haven't felt opportunistic suspend is a big departure from other work here -- there are always some cases in which drivers will need to keep external resources active even when suspended. Also, as I mentioned earlier, we (Android at least, but hopefully this is non-controversial) would always like drivers to put everything in the lowest possible power state they can get away with. Every little savings adds up. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 5 May 2010 18:10
On Wednesday 05 May 2010, Mark Brown wrote: > On Wed, May 05, 2010 at 10:44:03PM +0200, Rafael J. Wysocki wrote: > > > To me, the above may be summarized that in your opinion some components of > > the system will generally need to stay powered when it's suspended > > opportunistically, so we need an interface to specify which components they are. > > Is that correct? > > Yes, though I think I'd be inclined to treat the problem orthogonally to > opportunistic suspend to allow more flexibility in use and since > treating it as part of opportunistic suspend would imply that there's > some meaningful difference between the end result of that and a manual > suspend which AIUI there isn't. No, there's no such difference. So, gnerenally, we may need a mechanism to specify which components of the system need to stay powered while the whole system is suspended (in addition to wakeup devices, that is). That certainly I can agree with. I'm not sure, however, in what way this is relevant to the $subject patchset. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |