LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <firstname.lastname@example.org>
To: Peng Fan <email@example.com>
Cc: "Rafael J. Wysocki" <firstname.lastname@example.org>,
Ulf Hansson <email@example.com>,
"Rafael J. Wysocki" <firstname.lastname@example.org>,
Fabio Estevam <email@example.com>,
Greg Kroah-Hartman <firstname.lastname@example.org>,
Linux Kernel Mailing List <email@example.com>,
Linux PM <firstname.lastname@example.org>,
Subject: Re: [RFC] platform: detach from PM domains on shutdown
Date: Thu, 17 May 2018 10:01:00 +0200 [thread overview]
Message-ID: <CAJZ5v0ibwRXqaGJW0vFcy+YqMEc_ao9itBErP_w1YjLQWVVtQg@mail.gmail.com> (raw)
On Thu, May 17, 2018 at 4:33 AM, Peng Fan <email@example.com> wrote:
>> -----Original Message-----
>> From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Rafael
>> J. Wysocki
>> Sent: 2018年5月17日 5:35
>> To: Ulf Hansson <firstname.lastname@example.org>
>> Cc: Peng Fan <email@example.com>; Rafael J. Wysocki
>> <firstname.lastname@example.org>; Fabio Estevam <email@example.com>; Greg
>> Kroah-Hartman <firstname.lastname@example.org>; Linux Kernel Mailing List
>> <email@example.com>; Linux PM <firstname.lastname@example.org>;
>> dl-linux-imx <email@example.com>
>> Subject: Re: [RFC] platform: detach from PM domains on shutdown
>> On Wed, May 16, 2018 at 11:52 AM, Ulf Hansson <firstname.lastname@example.org>
>> > On 15 May 2018 at 11:01, Peng Fan <email@example.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 <firstname.lastname@example.org>
>> >> ---
>> >> 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 of
>> turning power domains off on the client OS reboot in theory. If the client OS
>> 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.
next prev parent reply other threads:[~2018-05-17 8:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-15 9:01 Peng Fan
2018-05-16 9:52 ` Ulf Hansson
2018-05-16 12:53 ` Peng Fan
2018-05-16 21:34 ` Rafael J. Wysocki
2018-05-17 2:33 ` Peng Fan
2018-05-17 8:01 ` Rafael J. Wysocki [this message]
2018-05-17 12:37 ` Peng Fan
2018-05-18 7:54 ` Rafael J. Wysocki
2018-05-18 8:53 ` Peng Fan
2018-05-28 8:01 ` Peng Fan
2018-05-28 8:31 ` Rafael J. Wysocki
2018-05-29 7:52 ` Peng Fan
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [RFC] platform: detach from PM domains on shutdown' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).