[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20221102093055.GA1963677@dragon>
Date: Wed, 2 Nov 2022 17:30:55 +0800
From: Shawn Guo <shawn.guo@...aro.org>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: "Rafael J . Wysocki" <rafael@...nel.org>,
Kevin Hilman <khilman@...nel.org>,
Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/3] PM: domains: Consolidate genpd_restore_noirq()
and genpd_resume_noirq()
On Tue, Nov 01, 2022 at 11:23:45AM +0100, Ulf Hansson wrote:
> On Tue, 1 Nov 2022 at 03:47, Shawn Guo <shawn.guo@...aro.org> wrote:
> >
> > Most of the logic between genpd_restore_noirq() and genpd_resume_noirq()
> > are same except GENPD_STATE_OFF status reset for hibernation restore.
> > The suspended_count decrement for restore should be the right thing to do
> > anyway, considering there is an increment in genpd_finish_suspend() for
> > hibernation.
> >
> > Consolidate genpd_restore_noirq() and genpd_resume_noirq() into
> > genpd_finish_resume() and handle GENPD_STATE_OFF status reset for
> > restore case specially.
> >
> > Signed-off-by: Shawn Guo <shawn.guo@...aro.org>
>
> I have a comment, see more below.
>
> Nevertheless, please add:
>
> Reviewed-by: Ulf Hansson <ulf.hansson@...aro.org>
>
> > ---
> > drivers/base/power/domain.c | 70 ++++++++++++++++++-------------------
> > 1 file changed, 35 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> > index 54f6b0dd35fb..b81baeb38d81 100644
> > --- a/drivers/base/power/domain.c
> > +++ b/drivers/base/power/domain.c
> > @@ -1247,12 +1247,14 @@ static int genpd_suspend_noirq(struct device *dev)
> > }
> >
> > /**
> > - * genpd_resume_noirq - Start of resume of device in an I/O PM domain.
> > + * genpd_finish_resume - Completion of resume of device in an I/O PM domain.
> > * @dev: Device to resume.
> > + * @resume_noirq: Generic resume_noirq callback.
> > *
> > * Restore power to the device's PM domain, if necessary, and start the device.
> > */
> > -static int genpd_resume_noirq(struct device *dev)
> > +static int genpd_finish_resume(struct device *dev,
> > + int (*resume_noirq)(struct device *dev))
> > {
> > struct generic_pm_domain *genpd;
> > int ret;
> > @@ -1264,9 +1266,25 @@ static int genpd_resume_noirq(struct device *dev)
> > return -EINVAL;
> >
> > if (device_wakeup_path(dev) && genpd_is_active_wakeup(genpd))
> > - return pm_generic_resume_noirq(dev);
> > + return resume_noirq(dev);
> >
> > genpd_lock(genpd);
> > +
> > + /*
> > + * Special handling for hibernation restore:
> > + * At this point suspended_count == 0 means we are being run for the
> > + * first time for the given domain in the present cycle.
> > + */
> > + if (resume_noirq == pm_generic_restore_noirq &&
> > + genpd->suspended_count++ == 0) {
> > + /*
> > + * The boot kernel might put the domain into arbitrary state,
> > + * so make it appear as powered off to genpd_sync_power_on(),
> > + * so that it tries to power it on in case it was really off.
> > + */
> > + genpd->status = GENPD_STATE_OFF;
>
> This has really never worked as intended. Resetting the status like
> this, needs more careful actions.
>
> For example, if the genpd->status was GENPD_STATE_ON, the parent
> domain's ->sd_count have been increased - so that needs to be adjusted
> too.
>
> By looking at patch3/3, I wonder if we shouldn't try to align the
> hibernation behaviors so the above hack can be dropped. Do you think
> that could work?
To be honest, I found this piece of code suspicious when I was fixing my
problem. To be on the safe side, I chose to leave it there because I'm
not sure if it's handling any special cases or platform quirks.
I tested on my platform with dropping the code. Worked perfectly fine.
So I will repost the series by starting with this cleanup.
Shawn
Powered by blists - more mailing lists