[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0i4YW760xwXB_u_pf3oSUVkuWPBP150TJRPeUQJxK+B5w@mail.gmail.com>
Date: Thu, 17 Apr 2025 14:36:16 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: Nicholas Chin <nic.c3.14@...il.com>, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org, rafael.j.wysocki@...el.com, rafael@...nel.org,
vincent.guittot@...aro.org, zhenglifeng1@...wei.com
Subject: Re: [PATCH] cpufreq: acpi: Don't enable boost on policy exit
On Thu, Apr 17, 2025 at 7:02 AM Viresh Kumar <viresh.kumar@...aro.org> wrote:
>
> On 16-04-25, 19:54, Nicholas Chin wrote:
> > Unfortunately the issue I reported still seems to be present after
> > applying this patch. Upon resuming from suspend, the system is still
> > entering boost states descpite the boost flag being set to 0.
>
> Okay, so this is what we know so far:
>
> - Force synchronizing (disabling here) boost state at resume was
> making this work earlier.
>
> - Setting the boost flag to "enabled" state during resume works as
> well, as that makes the cpufreq core disable the boost frequencies
> again.
>
> - This patch (though doing the correct thing) doesn't work. This is
> one of the known places where boost was getting enabled before going
> to suspend though.
>
> - This means that some other part of kernel (or hardware ?) is
> enabling the boost frequencies at suspend (or early resume), which
> the kernel was disabling earlier and not anymore.
>
> Rafael, any suggestions ?
This a resume from S3, so the platform firmware may enable the boost
in its resume path.
Powered by blists - more mailing lists