From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [PATCH V3] PM / Runtime: Defer resuming of the device in pm_runtime_force_resume() Date: Thu, 17 Nov 2016 22:00:20 +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-f68.google.com ([74.125.82.68]:33608 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750866AbcKQVAW (ORCPT ); Thu, 17 Nov 2016 16:00:22 -0500 Received: by mail-wm0-f68.google.com with SMTP id u144so24956555wmu.0 for ; Thu, 17 Nov 2016 13:00:21 -0800 (PST) In-Reply-To: Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Ulf Hansson 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 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. Thanks, Rafael