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

     \ /
      Last update: 2010-05-05 15:59    [W:0.022 / U:11.056 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site