From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: subtle pm_runtime_put_sync race and sdio functions Date: Tue, 21 Dec 2010 22:31:57 +0100 Message-ID: <201012212231.57420.rjw__24759.1763538823$1292969249$gmane$org@sisk.pl> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.linux-foundation.org Errors-To: linux-pm-bounces@lists.linux-foundation.org To: Alan Stern Cc: linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org, Ido Yariv , linux-pm@lists.linux-foundation.org, Johannes Berg List-Id: linux-pm@vger.kernel.org On Tuesday, December 21, 2010, Alan Stern wrote: > On Mon, 20 Dec 2010, Rafael J. Wysocki wrote: > > > > > In that case, if a device if flagged as "runtime only", we can avoid > > > > calling pm_runtime_get_noirq() for it in dpm_prepare() and, analogously, > > > > calling pm_runtime_put_sync() for it in dpm_complete(). However, we will have > > > > to fail system suspend (or hibernation) if a "runtime only" device has the > > > > power.runtime_auto flag unset. > > > > > > Or more generally, if pm_runtime_suspended() doesn't return 'true' for > > > the device. > > > > That's not necessary, because the device may be suspended using > > pm_runtime_suspend() later than we check pm_runtime_suspended(). > > What if the device has a child in the RPM_ACTIVE state? Then > pm_runtime_suspend() won't do anything, even if the child really is > dpm-suspended. Well, in fact I was thinking of leaf devices. Following all of the children for non-leaf devices would pretty much nullify the whole possible gain. > > I'd use the "runtime only" (or perhaps better "no_dpm") flag as a declaration > > (if set) that the device is going to be suspended with the help of "runtime" > > callbacks and the driver takes the responsibility for getting things right. > > I'm still not sure about this; the design isn't clear. Are these > runtime callbacks going to come from the PM core or from the driver? > If from the driver, how will the driver know when to issue them? What > about coordinating async suspends (the device must be suspended after > its children and before its parent)? It basically goes like this. There's device A that is only resumed when it's needed to carry out an operation and is suspended immediately after that. There's another device B that needs A to do something during its suspend. So, when the suspend of B is started, A is woken up, does its work and is suspended again (using pm_runtime_suspend()). Then B is suspended. We currently require that ->suspend() and ->resume() callbacks be defined for A (presumably pointing to the same code as its runtime callbacks) so that things work correctly, but perhaps we can just relax this requirement a bit? I'm not 100% sure that's a good idea, just considering it. Rafael