Re: [PATCH 0/8] Suspend block api (version 6)

[Mark Brown]

On Wed, May 05, 2010 at 05:00:33AM -0700, Brian Swetland wrote:

> I haven't spent much time looking at alsa/asoc yet, but it's on my
> list for 2010 -- I'm hoping to migrate the very simple audio drivers I
> wrote for the msm platform originally to actually be alsa drivers as
> part of the general "try to use existing interfaces if they fit" plan
> we've been working toward.

Yup, that'd be good - even with the AP/CP/CODEC SoCs like the MSM
devices we really need to get ASoC integration since systems are being
built hanging external components such as speaker drivers off the line
outputs, and some of those have registers so really do benefit from the
sequencing, automated PM and so on that ASoC offers.

There was some work on MSM ASoC support posted last year back but there
were a number of review issues with it.  Daniel Walker also talked about
submitting stuff just before Christmas, quite possibly independently of
the other work which looked like a community effort, but I've not seen
anything through from that yet.

> The suspend_block system gets us what we need today (well what we
> needed three years ago too!) to ship and hit reasonable power targets
> on a number of platforms.  There's been a lot of various handwaving
> about "android kernel forks" and what have you, but here we are again,
> trying to work out perhaps the only "new subsystem" type change that
> our driver code depends on (almost all other contentious stuff is self
> contained and you can take or leave it).

> Our hope here is to get something out there in the near term so that
> the various drivers we maintain would "just work" in mainline (your
> choice of if you use suspend_block or not -- it's designed to be an
> option) and we can move forward.  If in the future runtime power
> management or other systems completely obsolete suspend_blockers,
> awesome, we remove 'em.

Like I've said a few times here I broadly agree with your goals - they
seem to be a reasonable solution to the engineering problems we face
presently, even though they're not where we actually want to be.  What
I do miss from the current proposal is more consideration of how things
that do need to ignore the suspend should integrate.

If the conclusion is that we don't have anything generic within the
kernel then it'd be good to at least have this explicitly spelled out so
that we're clear what everyone thinks is going on here and how things
are supposed to work.  At the minute it doesn't feel like we've had the
discussion so we could end up working at cross purposes.  I don't want
to end up in the situation where I have to work around the APIs I'm
using without the relevant maintainers having sight of that since that
not only am I likely to be missing some existing solution to the problem
but is also prone to causing problems maintaining the underlying API.

This hasn't been a pressing issue while the Android code is out of tree
since we can just say it's an out of tree patch that has a different
design approach to current mainline and it's fairly straightforward for
users to introduce suitable system-specific changes.  Once it's mainline
and part of the standard Linux PM toolkit then obviously subsystems and
drivers need to support opportunistic suspend properly in mainline.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/