From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [PATCH 7/9] PM / ACPI: Enable the runtime PM centric approach for system sleep Date: Thu, 22 Jun 2017 16:32:16 +0200 Message-ID: <2162861.FQgDXG4xnB@aspire.rjw.lan> References: <1498072888-14782-1-git-send-email-ulf.hansson@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Return-path: Received: from cloudserver094114.home.net.pl ([79.96.170.134]:48401 "EHLO cloudserver094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751167AbdFVOjf (ORCPT ); Thu, 22 Jun 2017 10:39:35 -0400 In-Reply-To: Sender: linux-i2c-owner@vger.kernel.org List-Id: linux-i2c@vger.kernel.org To: Ulf Hansson Cc: "Rafael J. Wysocki" , Wolfram Sang , Len Brown , ACPI Devel Maling List , Linux PM , Kevin Hilman , Jarkko Nikula , Andy Shevchenko , Mika Westerberg , Jisheng Zhang , John Stultz , Guodong Xu , Sumit Semwal , Haojian Zhuang , "linux-arm-kernel@lists.infradead.org" , linux-i2c On Thursday, June 22, 2017 11:42:11 AM Ulf Hansson wrote: > On 21 June 2017 at 23:47, Rafael J. Wysocki wrote: > > On Wed, Jun 21, 2017 at 9:21 PM, Ulf Hansson wrote: > >> This change extends the interpretation of the ACPI's no_direct_complete > >> flag to be used to enable the so called runtime PM centric approach, for > >> devices being attached to the ACPI PM domain. > >> > >> The principle behind the runtime PM centric approach is to re-use the > >> runtime PM callbacks to implement system sleep for drivers/subsystems. > >> Moreover, using the runtime PM centric approach gives an optimized > >> behaviour around avoiding to wake up a device from its low power state > >> during system sleep, unless really needed. > >> > >> To deploy the runtime PM centric approach for a subsystem/driver, the > >> following adaptations needs to be made. > >> > >> First, the runtime PM callbacks may be called when runtime PM has been > >> disabled for the device. This serves as an indication for the callbacks to > >> understand they are running in the system sleep sequence, instead of in the > >> regular runtime PM path. In some cases, a callback needs to take different > >> actions depending in what path it is being executed in, as is the case for > >> the ACPI PM domain. > >> > >> In particular for the ACPI PM domain's ->runtime_suspend|resume() > >> callbacks, when those finds runtime PM being disabled for the device, it > >> instead executes the same operations as normally being run when > >> ->suspend_late() and ->resume_early() callbacks are invoked during system > >> sleep. > >> > >> Second, at the PM domain level, it is expected that the driver for the > >> device makes use of pm_runtime_force_suspend|resume(), to re-use the > >> runtime PM callbacks to put the device into low power state and to wake it > >> up when needed during system sleep. > > > > What if it doesn't do that? > > > > Do all drivers of devices that may fall into the ACPI PM domain use > > pm_runtime_force_suspend|resume()? > > No, no - the runtime PM centric path is optional by all ACPI > devices/drivers. The default is still for the ACPI PM domain to try > the direct_complete path. > > However if an ACPI device/driver (i2c designware in this case) likes > to do that, they need to inform the ACPI PM domain about it. Then they > call acpi_dev_disable_direct_complete() and makes use of > pm_runtime_force_suspend|resume() to deal with system sleep. > > Does that makes sense? Overall, yes, it does, but then it should be made clear that when you use "no_direct_complete" (all what you are going to call that eventually), you also must use pm_runtime_force_suspend|resume() as your sleep callbacks. Otherwise things may not work correctly if my understanding is correct. Thanks, Rafael