From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from netrider.rowland.org ([192.131.102.5]:44089 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751297Ab0LVBnA (ORCPT ); Tue, 21 Dec 2010 20:43:00 -0500 Date: Tue, 21 Dec 2010 20:42:59 -0500 (EST) From: Alan Stern To: "Rafael J. Wysocki" cc: Ohad Ben-Cohen , , Johannes Berg , , , Ido Yariv , Kevin Hilman Subject: Re: [linux-pm] subtle pm_runtime_put_sync race and sdio functions In-Reply-To: <201012212231.57420.rjw@sisk.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-wireless-owner@vger.kernel.org List-ID: On Tue, 21 Dec 2010, Rafael J. Wysocki wrote: > 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. I still don't know. It would require a lot of special conditions: no child devices, not runtime-PM-disabled, not runtime-PM-forbidden... Also, A's parent would have to be coded carefully; otherwise A's runtime resume would prevent the parent from suspending. This just doesn't fit very well with the runtime PM model, or at least, not in the form you described. Consider this instead: Since A is required to be functional before B can be used, A must be registered before B and hence B gets suspended before A. Therefore during the prepare phase we can runtime-resume A and leave it powered up; when B needs to suspend, it won't matter that the runtime-PM calls are ineffective. Then when A's dpm_suspend occurs, it can safely go to a low-power state and stay there. Alan Stern From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Stern Subject: Re: [linux-pm] subtle pm_runtime_put_sync race and sdio functions Date: Tue, 21 Dec 2010 20:42:59 -0500 (EST) Message-ID: References: <201012212231.57420.rjw@sisk.pl> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: In-Reply-To: <201012212231.57420.rjw-KKrjLPT3xs0@public.gmane.org> Sender: linux-wireless-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "Rafael J. Wysocki" Cc: Ohad Ben-Cohen , linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Johannes Berg , linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Ido Yariv , Kevin Hilman List-Id: linux-mmc@vger.kernel.org On Tue, 21 Dec 2010, Rafael J. Wysocki wrote: > 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. I still don't know. It would require a lot of special conditions: no child devices, not runtime-PM-disabled, not runtime-PM-forbidden... Also, A's parent would have to be coded carefully; otherwise A's runtime resume would prevent the parent from suspending. This just doesn't fit very well with the runtime PM model, or at least, not in the form you described. Consider this instead: Since A is required to be functional before B can be used, A must be registered before B and hence B gets suspended before A. Therefore during the prepare phase we can runtime-resume A and leave it powered up; when B needs to suspend, it won't matter that the runtime-PM calls are ineffective. Then when A's dpm_suspend occurs, it can safely go to a low-power state and stay there. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html