From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulf Hansson Subject: Re: [PATCH V3] PM / Runtime: Defer resuming of the device in pm_runtime_force_resume() Date: Fri, 18 Nov 2016 11:50:07 +0100 Message-ID: References: <1476370734-23168-1-git-send-email-ulf.hansson@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from mail-wm0-f51.google.com ([74.125.82.51]:35287 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751634AbcKRK5V (ORCPT ); Fri, 18 Nov 2016 05:57:21 -0500 Received: by mail-wm0-f51.google.com with SMTP id a197so30157143wmd.0 for ; Fri, 18 Nov 2016 02:57:21 -0800 (PST) In-Reply-To: Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: "Rafael J. Wysocki" Cc: "Rafael J. Wysocki" , Geert Uytterhoeven , Len Brown , Pavel Machek , "linux-pm@vger.kernel.org" , Kevin Hilman , Lina Iyer , Jon Hunter , Marek Szyprowski , Andy Gross , Laurent Pinchart , Alan Stern , Linus Walleij On 17 November 2016 at 22:00, Rafael J. Wysocki wrote: > On Thu, Nov 17, 2016 at 9:21 PM, Ulf Hansson wrote: >> On 13 October 2016 at 16:58, Ulf Hansson wrote: >>> When the pm_runtime_force_suspend|resume() helpers were invented, we still >>> had CONFIG_PM_RUNTIME and CONFIG_PM_SLEEP as separate Kconfig options. >>> >>> To make sure these helpers worked for all combinations and without >>> introducing too much of complexity, the device was always resumed in >>> pm_runtime_force_resume(). >>> >>> More precisely, when CONFIG_PM_SLEEP was set and CONFIG_PM_RUNTIME was >>> unset, we needed to resume the device as the subsystem/driver couldn't >>> rely on using runtime PM to do it. >>> >>> As the CONFIG_PM_RUNTIME option was merged into CONFIG_PM a while ago, it >>> removed this combination, of using CONFIG_PM_SLEEP without the earlier >>> CONFIG_PM_RUNTIME. >>> >>> For this reason we can now rely on the subsystem/driver to use runtime PM >>> to resume the device, instead of forcing that to be done in all cases. In >>> other words, let's defer the runtime resume to a later point when it's >>> actually needed. >>> >>> Signed-off-by: Ulf Hansson >> >> Rafael, this one is ready to be queued. Unless there are other objections. > > Not an objection, but I'd like to revisit this when the device > dependencies work gets in, as something similar may need to be done > for suppliers, in principle. I certainly think it would make sense to extend this approach to also respect device-dependencies. However, I suggest we deal with that as a second step, on top of $subject patch. It should not be a problem, as we don't have any users of device-dependencies that also uses pm_runtime_force_suspend|resume(), right? Queuing this now, also allow us to get this more widely tested, before we continue extending it for dependencies. Kind regards Uffe