From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758278Ab0EEU1f (ORCPT ); Wed, 5 May 2010 16:27:35 -0400 Received: from ogre.sisk.pl ([217.79.144.158]:48201 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753596Ab0EEU1d (ORCPT ); Wed, 5 May 2010 16:27:33 -0400 From: "Rafael J. Wysocki" To: Alan Stern Subject: Re: [PATCH 0/8] Suspend block api (version 6) Date: Wed, 5 May 2010 22:28:19 +0200 User-Agent: KMail/1.12.4 (Linux/2.6.34-rc6-rjw; KDE/4.3.5; x86_64; ; ) Cc: Matthew Garrett , Mark Brown , Brian Swetland , Kevin Hilman , Arve =?iso-8859-1?q?Hj=F8nnev=E5g?= , 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 References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005052228.19851.rjw@sisk.pl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 05 May 2010, Alan Stern wrote: > On Wed, 5 May 2010, Matthew Garrett wrote: > > > On Wed, May 05, 2010 at 03:20:40PM -0400, Alan Stern wrote: > > > > > One the face of it, a runtime-PM solution would dictate that the > > > codec's driver ought to turn off the codec whenever the driver thinks > > > it isn't being used. Ergo, if the driver didn't know when a call was > > > in progress, it would use runtime PM to turn off the codec during a > > > call. > > > > Well, part of the problem is that right now most of our beliefs about > > imposed constraints tend to be based on what userspace is doing - "Don't > > power down the audio codec when userspace has it open", for instance. > > But that goes away with opportunistic suspend. In most cases you don't > > want the audio codec to stay awake just because userspace was using it > > to make bouncing cow noises, especially if you've just frozen userspace. > > So the problem becomes more complicated than it would otherwise be. > > It sounds like the problem can be stated simply enough: At the moment, > nobody knows when the codec should be powered down! Userspace might > have some idea, but even if its ideas are right it has no way of > communicating them to the kernel. > > The power/control sysfs attribute was intended for just that purpose, > although it was aimed at runtime PM rather than system PM. > Nevertheless, it or something like it could be used. Of course, there > would still remain the issue of userspace telling the kernel not to > power down the codec while making bouncing cow noises -- but at this > point it's not really a kernel problem any more. We'd need a separate control, I think. The problem is, though, that the Android user space, for example, doesn't use the sysfs attributes of devices, so this control wouldn't be particularly useful for it. > P.S.: What happens if a suspend occurs while a call is in progress, so > the codec is left powered up, and then the call ends? Does the system > wake up at that point? Or does it stay suspended with the codec still > powered, even though it's not needed any more? I guess you end up telling the user that the call ended, so the system wakes up. That's only a guess, though. Rafael