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: Theodore Tso on 7 May 2010 07:40 On May 7, 2010, at 7:21 AM, Mark Brown wrote: > > This goes back to the thing about a full system suspend being a > sledgehammer which doesn't give enough information about what's going > on when it's used like this. As discussed we need a way to know that > the connections involved are able to stay live during suspend (on a > large proportion of systems suspend is going to mean that the relevant > bits of the board will loose power so need to be shut down) and that > that the intention of the user is that they should do so (this isn't > clear in the general system, especially not if the suspend is initiated > manually). This sounds like it may be something unique to your board/product. Or am I missing something? One of the challenges with PM in the embedded world is that everybody seems to have slightly different assumptions, and hardware that doesn't behave the same way. More than once this discussion has wandered off into the weeds wrt to whether this patch series is ready to be merged, since there are so many drivers blocked on it.... -- Ted -- 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: Arve Hjønnevåg on 7 May 2010 07:50 2010/5/7 Mark Brown <broonie(a)opensource.wolfsonmicro.com>: > On Fri, May 07, 2010 at 03:57:37AM -0700, Arve Hj�nnev�g wrote: >> 2010/5/7 Mark Brown <broonie(a)opensource.wolfsonmicro.com>: > >> > As discussed elsewhere in the thread a suspend blocker is not desirable >> > here - the AP is not doing anything useful on a voice call so blocking >> > the suspend will just waste power unless runtime PM is good enough to >> > mean opportunistic suspend isn't adding anything anyway. �It will avoid >> > the immediate issue with loosing audio but it's not really what we want >> > to happen. > >> I was talking about audio from the AP. Why would you ever turn off >> another core's audio path on suspend? > > This goes back to the thing about a full system suspend being a > sledgehammer which doesn't give enough information about what's going > on when it's used like this. �As discussed we need a way to know that > the connections involved are able to stay live during suspend (on a > large proportion of systems suspend is going to mean that the relevant > bits of the board will loose power so need to be shut down) and that Are you trying to use the same driver on systems that can support audio while suspend and on systems where this is impossible? If audio cannot work while suspended, supporting opportunistic suspend is easy. You block suspend while audio is active. If the hardware does support some audio paths while suspended, I'll ask again, is there a reason to turn them off on suspend? > that the intention of the user is that they should do so (this isn't > clear in the general system, especially not if the suspend is initiated > manually). > > With a runtime PM approach this is trivial - we just turn off anything > that isn't in use at the current time. �I'll need to extend ASoC to add > information about what to do on suspend to the existing power data. > OK, but is this at all related to opportunistic suspend? -- Arve Hj�nnev�g -- 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 7 May 2010 08:30 On Fri, May 07, 2010 at 07:29:47AM -0400, Theodore Tso wrote: > This sounds like it may be something unique to your board/product. Or > am I missing something? I suspect you're missing something here - I'm approaching this as one of the maintainers of the embedded audio subsystem for the kernel. I need to worry about any system running Linux which has an embedded style audio subsystem. The problem might be unique to audio, but I can't say that for certain. > One of the challenges with PM in the embedded world is that everybody > seems to have slightly different assumptions, and hardware that doesn't > behave the same way. This isn't really a problem for audio - we've already got a subsystem which copes well with pretty much all systems and does runtime PM that's equivalent to suspending already, which is half the problem here. If we had less generalisation this would probably not have come up. > More than once this discussion has wandered off into the weeds wrt to > whether this patch series is ready to be merged, since there are so many > drivers blocked on it.... Once more, my main objective here has been to make sure that when this is merged we've got a joined up story about how people think this hangs together, which I think we have now. As I say now that we have that understanding I don't see any reason to block merge. It's unfortunate that I only noticed that this was actually wakelocks very late in the day but I think I can get an implementation which handles paths that ignore suspends done quickly. -- 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 7 May 2010 08:40 On Fri, May 7, 2010 at 5:25 AM, Mark Brown <broonie(a)opensource.wolfsonmicro.com> wrote: > On Fri, May 07, 2010 at 07:29:47AM -0400, Theodore Tso wrote: > >> This sounds like it may be something unique to your board/product. Or >> am I missing something? > > I suspect you're missing something here - I'm approaching this as one of > the maintainers of the embedded audio subsystem for the kernel. I need > to worry about any system running Linux which has an embedded style > audio subsystem. The problem might be unique to audio, but I can't say > that for certain. > >> One of the challenges with PM in the embedded world is that everybody >> seems to have slightly different assumptions, and hardware that doesn't >> behave the same way. > > This isn't really a problem for audio - we've already got a subsystem > which copes well with pretty much all systems and does runtime PM that's > equivalent to suspending already, which is half the problem here. If we > had less generalisation this would probably not have come up. > >> More than once this discussion has wandered off into the weeds wrt to >> whether this patch series is ready to be merged, since there are so many >> drivers blocked on it.... > > Once more, my main objective here has been to make sure that when this > is merged we've got a joined up story about how people think this hangs > together, which I think we have now. As I say now that we have that > understanding I don't see any reason to block merge. > > It's unfortunate that I only noticed that this was actually wakelocks > very late in the day but I think I can get an implementation which > handles paths that ignore suspends done quickly. Do you mean an implementation of embedded linux audio or an implementation of suspend blockers "which handles paths that ignore suspends"? I assume you mean the former, but maybe I misunderstand. We've done a lot of work around multicore SoCs where the baseband generally owns a lot of the audio routing and so on, but we do as general policy not disable audio, codecs, and amps while playback or record is underway. I suppose for environments more like a pc laptop where the expectation is the world stops when you close the lid a different policy would be preferable. We typically fire up codecs and amps when playback starts (if they were off), and usually set a timer for a couple seconds after playback stops to spin them down (since you tend to have to delay while they're powering up to avoid pops, etc, and if the system just played a short sound there's a reasonable chance it'll follow that with another). Apologies about the name confusion -- last year when we first started pushing these patches out there was much dislike for the name wakelock and after a lot of back and forth suspend_block ended up as the least hated of the suggested alternatives (I kinda like "wakelock" as a name, but maybe that's just brain rot after dealing with 'em for four years now). 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 7 May 2010 09:40
On Fri, May 07, 2010 at 05:37:21AM -0700, Brian Swetland wrote: > On Fri, May 7, 2010 at 5:25 AM, Mark Brown > > It's unfortunate that I only noticed that this was actually wakelocks > > very late in the day but I think I can get an implementation which > > handles paths that ignore suspends done quickly. > Do you mean an implementation of embedded linux audio or an > implementation of suspend blockers "which handles paths that ignore > suspends"? I assume you mean the former, but maybe I misunderstand. I mean that I will extend the embedded audio subsystem that the kernel already has (ASoC, in sound/soc) to support ignoring suspends for some audio paths so that they can be kept up during suspend. This will be primarily intended for use with opportunistic suspend but not specific to it. I have no intention of touching suspend blockers, except in that some of the drivers I'm responsible for should probably use suspend blockers for similar reasons to the other users you're merging but that's less urgent. > We've done a lot of work around multicore SoCs where the baseband > generally owns a lot of the audio routing and so on, Multicore isn't really the term here - obviously on something like the OMAP4 or the current nVidia devices you've got a multicore AP but may or may not have an integrated baseband. The distinction is down to how much visibility the AP has of the audio hardware, which is in general orthogonal to how the silicon is split and packaged. > but we do as > general policy not disable audio, codecs, and amps while playback or > record is underway. Yeah, I know. I have been keeping an eye on the Android stuff, though none of the audio side has been mainlined yet. > I suppose for environments more like a pc laptop > where the expectation is the world stops when you close the lid a > different policy would be preferable. Yes, quite. It all depends on what the intention of the user is when they do a suspend. Clearly if the suspend was initiated automatically because the system is apparently idle the intention is different to if it was initiated because the user performed some explicit action. > We typically fire up codecs and amps when playback starts (if they > were off), and usually set a timer for a couple seconds after playback > stops to spin them down (since you tend to have to delay while they're > powering up to avoid pops, etc, and if the system just played a short > sound there's a reasonable chance it'll follow that with another). This is exactly what ASoC does - the two biggest wins it offers are that it allows reuse of the code specific to a given piece of silicon on all boards using that silicon and that it provides automatic runtime power management in the core by keeping track of which audio paths are live. There is the slight wrinkle that you don't really want to *fully* power down devices that don't have ground referenced outputs since they take a relatively long time to bring their reference level up without audible artifacts in the output. -- 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/ |