On Fri, May 7, 2010 at 5:25 AM, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm