From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [PATCH v2 5/9] PM / ACPI: Provide option to disable direct_complete for ACPI devices Date: Thu, 24 Aug 2017 02:20:00 +0200 Message-ID: <9174364.s7oU13Tavs@aspire.rjw.lan> References: <1503499329-28834-1-git-send-email-ulf.hansson@linaro.org> <3774251.HUIR40xRhc@aspire.rjw.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Return-path: In-Reply-To: <3774251.HUIR40xRhc@aspire.rjw.lan> Sender: linux-pm-owner@vger.kernel.org To: Ulf Hansson Cc: "Rafael J. Wysocki" , "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 List-Id: linux-acpi@vger.kernel.org On Thursday, August 24, 2017 2:13:55 AM CEST Rafael J. Wysocki wrote: > On Thursday, August 24, 2017 1:39:44 AM CEST Rafael J. Wysocki wrote: > > On Wed, Aug 23, 2017 at 4:42 PM, Ulf Hansson wrote: > > > In some cases a driver for an ACPI device needs to be able to prevent the > > > ACPI PM domain from using the direct_complete path during system sleep. > > > > > > One typical case is when the driver for the device needs its device to stay > > > runtime enabled, during the __device_suspend phase. This isn't the case > > > when the direct_complete path is being executed by the PM core, as it then > > > disables runtime PM for the device in __device_suspend(). Any following > > > attempts to runtime resume the device after that point, just fails. > > > > OK, that is a problem. > > > > > A workaround to this problem is to let the driver runtime resume its device > > > from its ->prepare() callback, as that would prevent the direct_complete > > > path from being executed. However, that may often be a waste, especially if > > > it turned out that no one really needed the device. > > > > > > For this reason, invent acpi_dev_disable|enable_direct_complete(), to allow > > > drivers to inform the ACPI PM domain to change its default behaviour during > > > system sleep, and thus control whether it may use the direct_complete path > > > or not. > > > > But I'm not sure this is the right place to address it as it very well > > may affect a PCI device too. > > > > Also, this is about the device and not about its ACPI companion > > object, so putting the flag in there is somewhat unclean, so to speak. > > > > It looks like we need a flag in dev_pm_info saying something along the > > lines of "my system suspend callback can deal with runtime PM" that > > will cause the direct_complete update to occur in > > __device_suspend_late() instead of __device_suspend(). > > IOW, something like the patch below. > > It actually should work with the ACPI PM domain code as is except that it > will cause the device to be runtime resumed every time during suspend. > > But acpi_subsys_suspend() can be changed to avoid resuming the device if > power.force_suspend is set. Or better yet, if power.direct_complete is not set, because that means the device needs to be resumed anyway. And if power.direct_complete is set at that point, power.force_suspend has to be set too. From mboxrd@z Thu Jan 1 00:00:00 1970 From: rjw@rjwysocki.net (Rafael J. Wysocki) Date: Thu, 24 Aug 2017 02:20:00 +0200 Subject: [PATCH v2 5/9] PM / ACPI: Provide option to disable direct_complete for ACPI devices In-Reply-To: <3774251.HUIR40xRhc@aspire.rjw.lan> References: <1503499329-28834-1-git-send-email-ulf.hansson@linaro.org> <3774251.HUIR40xRhc@aspire.rjw.lan> Message-ID: <9174364.s7oU13Tavs@aspire.rjw.lan> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thursday, August 24, 2017 2:13:55 AM CEST Rafael J. Wysocki wrote: > On Thursday, August 24, 2017 1:39:44 AM CEST Rafael J. Wysocki wrote: > > On Wed, Aug 23, 2017 at 4:42 PM, Ulf Hansson wrote: > > > In some cases a driver for an ACPI device needs to be able to prevent the > > > ACPI PM domain from using the direct_complete path during system sleep. > > > > > > One typical case is when the driver for the device needs its device to stay > > > runtime enabled, during the __device_suspend phase. This isn't the case > > > when the direct_complete path is being executed by the PM core, as it then > > > disables runtime PM for the device in __device_suspend(). Any following > > > attempts to runtime resume the device after that point, just fails. > > > > OK, that is a problem. > > > > > A workaround to this problem is to let the driver runtime resume its device > > > from its ->prepare() callback, as that would prevent the direct_complete > > > path from being executed. However, that may often be a waste, especially if > > > it turned out that no one really needed the device. > > > > > > For this reason, invent acpi_dev_disable|enable_direct_complete(), to allow > > > drivers to inform the ACPI PM domain to change its default behaviour during > > > system sleep, and thus control whether it may use the direct_complete path > > > or not. > > > > But I'm not sure this is the right place to address it as it very well > > may affect a PCI device too. > > > > Also, this is about the device and not about its ACPI companion > > object, so putting the flag in there is somewhat unclean, so to speak. > > > > It looks like we need a flag in dev_pm_info saying something along the > > lines of "my system suspend callback can deal with runtime PM" that > > will cause the direct_complete update to occur in > > __device_suspend_late() instead of __device_suspend(). > > IOW, something like the patch below. > > It actually should work with the ACPI PM domain code as is except that it > will cause the device to be runtime resumed every time during suspend. > > But acpi_subsys_suspend() can be changed to avoid resuming the device if > power.force_suspend is set. Or better yet, if power.direct_complete is not set, because that means the device needs to be resumed anyway. And if power.direct_complete is set at that point, power.force_suspend has to be set too.