From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [PATCH] PM: Introduce core framework for run-time PM of I/O devices (rev. 3) Date: Wed, 24 Jun 2009 02:08:22 +0200 Message-ID: <200906240208.23482.rjw@sisk.pl> References: Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: Received: from ogre.sisk.pl ([217.79.144.158]:40028 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752761AbZFXAII (ORCPT ); Tue, 23 Jun 2009 20:08:08 -0400 In-Reply-To: Content-Disposition: inline Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Alan Stern Cc: linux-pm@lists.linux-foundation.org, Oliver Neukum , Magnus Damm , ACPI Devel Maling List , Ingo Molnar , LKML , Greg KH , Arjan van de Ven On Tuesday 23 June 2009, Alan Stern wrote: > On Tue, 23 Jun 2009, Rafael J. Wysocki wrote: > > > Hi, > > > > Below is a new revision of the patch introducing the run-time PM framework. > > > > The most visible changes from the last version: > > > > * I realized that if child_count is atomic, we can drop the parent locking from > > all of the functions, so I did that. > > > > * Introduced pm_runtime_put() that decrements the resume counter and queues > > up an idle notification if the counter went down to 0 (and wasn't 0 previously). > > Using asynchronous notification makes it possible to call pm_runtime_put() > > from interrupt context, if necessary. > > > > * Changed the meaning of the RPM_WAKE bit slightly (it is now also used for > > disabling run-time PM for a device along with the resume counter). > > > > Please let me know if I've overlooked anything. :-) > > This first thing to strike me was that you moved the idle notifications > into the workqueue. Yes, I did. > Is that really needed? Would we be better off just make the idle > callbacks directly from pm_runtime_put? They would run in whatever > context the driver happened to be in at the time. > > It's not clear exactly how much work the idle callbacks will need to > do, but it seems likely that they won't have to do too much more than > call pm_request_suspend. And of course, that can be done in_interrupt. I just don't want to put any constraints on the implementation of ->runtime_idle(). The requirement that it be suitable for calling from interrupt context may be quite inconvenient for some drivers and I'm afraid they may have problems with meeting it. Best, Rafael