lkml.org 
[lkml]   [2010]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/8] Suspend block api (version 6)
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.


\
 
 \ /
  Last update: 2010-05-07 14:27    [W:0.491 / U:1.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site