lkml.org 
[lkml]   [2010]   [May]   [12]   [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 Tue, May 11, 2010 at 06:11:09PM -0700, Arve Hj?nnev?g wrote:

    > > 2.2 Usage in PM aware drivers
    > > ==============================

    > > [An example of how a driver already using runtime PM would use
    > > ?a suspend blocker would also be helpful.

    > An audio driver can block suspend while audio is playing. We don't
    > currently use the runtime pm framework since this is new, but we do
    > runtime pm by turning off clocks and power when the device is
    > inactive.

    Could you clarify what's going on here please? What do you mean by an
    "audio driver" here - there's several different classes of driver which
    work together to produce the embedded audio subsystem and I'm not clear
    which you're referring to here. I'd not expect a chip-specific audio
    driver to be taking suspend blockers at all except during things like
    accessory detect handling which can take a long time. A system-specific
    driver could reasonably block during playback but doing it in a chip
    specific driver sounds like a bit too much of a policy decision.

    The kernel runtime PM framwwork tends not to come into play for anything
    except MFD and SoC drivers with audio where they're a component of PM on
    the larger chip and it's useful for coordinating with the other drivers
    in play. Otherwise we already have very detailed automatic power
    management (especially for the CODECs) and there's no benefit in
    bouncing through runtime PM.


    \
     
     \ /
      Last update: 2010-05-12 13:25    [W:4.186 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site