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. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
