On Thu, May 17, 2018 at 4:33 AM, Peng Fan <peng....@nxp.com> wrote:
>> -----Original Message-----
>> From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael
>> J. Wysocki
>> Sent: 2018年5月17日 5:35
>> To: Ulf Hansson <ulf.hans...@linaro.org>
>> Cc: Peng Fan <peng....@nxp.com>; Rafael J. Wysocki
>> <rafael.j.wyso...@intel.com>; Fabio Estevam <fabio.este...@nxp.com>; Greg
>> Kroah-Hartman <gre...@linuxfoundation.org>; Linux Kernel Mailing List
>> <email@example.com>; Linux PM <linux...@vger.kernel.org>;
>> dl-linux-imx <linux-...@nxp.com>
>> Subject: Re: [RFC] platform: detach from PM domains on shutdown
>> On Wed, May 16, 2018 at 11:52 AM, Ulf Hansson <ulf.hans...@linaro.org>
>> > On 15 May 2018 at 11:01, Peng Fan <peng....@nxp.com> wrote:
>> >> When reboot Linux, the PM domains attached to a device are not
>> >> shutdown. To SoCs which relys on reset the whole SoC, there is no
>> >> need to shutdown PM domains, but to Linux running in a virtual
>> >> machine with devices pass-through, we could not reset the whole SoC.
>> >> Currently we need Linux to shutdown its PM domains when reboot.
>> > I am not sure I understand exactly why the PM domain needs to be
>> > shutdown for these cases, could you please elaborate a bit on that.
>> > BTW, what platform are you running on and also what PM domains are being
>> > Anyway, it seems like there may be need for certain cases, but
>> > certainly not all - especially since it may slow down the shutdown
>> > process, when not needed.
>> > Can we make this runtime configurable, via sysfs or whatever that makes
>> >> commit 2d30bb0b3889 ("platform: Do not detach from PM domains on
>> >> shutdown"), removes what this patch tries to add, because of a warning.
>> >> commit e79aee49bcf9 ("PM: Avoid false-positive warnings in
>> >> dev_pm_domain_set()") already fixes the false alarm warning. So let's
>> >> detach the power domain to shutdown PM domains after driver shutdown.
>> >> Signed-off-by: Peng Fan <peng....@nxp.com>
>> >> ---
>> >> I do not find a better place to shutdown power domain when reboot
>> >> Linux, so add back the line that commit 2d30bb0b3889 removes, because
>> >> it is a false alarm warning as commit e79aee49bcf9 describes.
>> >> drivers/base/platform.c | 1 +
>> >> 1 file changed, 1 insertion(+)
>> >> diff --git a/drivers/base/platform.c b/drivers/base/platform.c index
>> >> 8075ddc70a17..a5929f24dc3c 100644
>> >> --- a/drivers/base/platform.c
>> >> +++ b/drivers/base/platform.c
>> >> @@ -616,6 +616,7 @@ static void platform_drv_shutdown(struct device
>> >> *_dev)
>> >> if (drv->shutdown)
>> >> drv->shutdown(dev);
>> >> + dev_pm_domain_detach(_dev, true);
>> > This would somewhat work, but only for platform devices. To make this
>> > fully work, we need to call dev_pm_domain_detach() from amba, spi, etc
>> > as well.
>> > Perhaps another option to manage this more generally, an without
>> > having detach devices, could be to extend the struct dev_pm_domain
>> > with a new callback, "->shutdown()" and then make the driver core call
>> > it from device_shutdown().
>> I'm sensing a possible ordering slippery slope with this (it will only work
>> if all of
>> the drivers/bus types etc do the right thing in their
>> ->shutdown callbacks so nothing depends on the domain going forward).
>> > Typically, for genpd, I would probably count the number of calls being
>> > made to ->shutdown() per PM domain, then when it reaches the number of
>> > attached devices to it, allow to power off it.
>> > Let's see what Rafael thinks about it.
>> I'm not sure about the use case. The hypervisor should be able to take care
>> turning power domains off on the client OS reboot in theory. If the client
>> leaving the hypervisor needs to worry about what state it leaves behind, the
>> design of the hypervisor is sort of questionable IMO.
> This is valid concern. But moving the power domain logic into hypervisor
> mostly micro-kernel design
> will introduce more complexity and make certification harder.
> Currently, Let Linux shutdown it's power domain is the easiest way to me and
> make things work well
> after reboot.
Well, to put it bluntly, if your hypervisor depends on the guest to do
the right thing on exit, it doesn't do its job. I wouldn't have
certified it for you if that was my decision.