lkml.org 
[lkml]   [2010]   [May]   [5]   [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 Wed, May 05, 2010 at 01:56:07PM -0700, Brian Swetland wrote:

    > From my point of view, the codec should be powered up while audio is
    > playing and powered down when it's not -- that's the approach I've

    This is what we've got already with Linux - we've had rather aggressive
    runtime PM for embedded audio as standard for years now. It's only very
    recently that mobile hardware has got to the point where you can
    actually totally kill the power without introducing problems but it's
    been getting pretty much as close as possible.

    > taken on MSM, regardless of suspend state. I don't view suspend as
    > something that stops audio playback in progress. Sort of similar to
    > how the modem doesn't power off down when the system is in suspend,
    > etc.

    This really does depend heavily on system design and the intended
    function of the suspend on the part of the initiator. In many systems
    suspend will remove sufficient power to stop audio running even if it
    were desired, and there's the idea with existing manually initiated
    suspends that the system should stop what it's doing and go into a low
    power, low responsiveness state. Some systems will initiate a suspend
    with active audio paths (especially those to or from the AP) which they
    expect to be stopped.

    > In effect, we have followed a sort of runtime pm model of
    > clocking/powering peripherals at the lowest possible level at all
    > times, which is why I've never viewed suspend_block as somehow
    > competing with runtime pm -- we always want all drivers/peripherals in

    Right, and this will work well on systems like your current devices
    because the problem hardware is not directly visible to the AP (the
    actual audio hardware is hidden behind the DSP which functions as
    autonomously as the modem does) so it's not affected by the Linux
    suspend process in the first place. It causes confusion when the power
    for the audio device is managed by Linux since the opportunistic suspend
    will include suspending the audio device and so the code handling the
    suspend then has to decide what exactly it's being asked to do.

    > the lowers power state. Sometimes the lowest power state possible is
    > higher than "full suspend" (for example when we can't meet latency
    > requirements on audio on 7201A) and suspend_blockers cover that case.

    In this situation there's no physical reason why the lower power state
    is not achievable so blocking the suspend would just waste power, it's
    just that our way of getting into it is creating some confusion.


    \
     
     \ /
      Last update: 2010-05-06 01:43    [W:4.677 / U:0.228 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site