From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756226Ab0EGKEM (ORCPT ); Fri, 7 May 2010 06:04:12 -0400 Received: from opensource.wolfsonmicro.com ([80.75.67.52]:35500 "EHLO opensource2.wolfsonmicro.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755023Ab0EGKEK (ORCPT ); Fri, 7 May 2010 06:04:10 -0400 Date: Fri, 7 May 2010 11:04:07 +0100 From: Mark Brown To: Arve =?iso-8859-1?B?SGr4bm5lduVn?= Cc: Brian Swetland , Alan Stern , Matthew Garrett , "Rafael J. Wysocki" , Kevin Hilman , linux-pm@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Tejun Heo , Oleg Nesterov , Paul Walmsley , magnus.damm@gmail.com, mark gross , Arjan van de Ven , Geoff Smith , rebecca@android.com Subject: Re: [PATCH 0/8] Suspend block api (version 6) Message-ID: <20100507100406.GA21498@rakim.wolfsonmicro.main> References: <20100505185225.GA4411@srcf.ucam.org> <20100505234025.GB4838@opensource.wolfsonmicro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Cookie: Do not stamp. User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 05, 2010 at 09:25:18PM -0700, Arve Hjønnevåg wrote: > On Wed, May 5, 2010 at 4:40 PM, Mark Brown > > 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. > You can support both in the same driver in some cases (without a > switch). If the hardware cannot wake the system when it needs more > audio buffers, then the driver needs to block suspend while audio is > playing. Since suspend blockers only block opportunistic suspend, the > driver can also implement suspend to stop audio playback and it will > only be called for forced suspend. As discussed elsewhere in the thread a suspend blocker is not desirable here - the AP is not doing anything useful on a voice call so blocking the suspend will just waste power unless runtime PM is good enough to mean opportunistic suspend isn't adding anything anyway. It will avoid the immediate issue with loosing audio but it's not really what we want to happen.