[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250417050911.xycjkalehqsg3i6x@vireshk-i7>
Date: Thu, 17 Apr 2025 10:39:11 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Nicholas Chin <nic.c3.14@...il.com>
Cc: 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
Copying more information from Bugzilla here (Nicholas, it would be
faster if you can put all your observations here first, more people
are looking at emails than bugzilla).
> Nicholas Chin wrote:
> I did some more testing and debugging and it seems like when
> cpufreq_online() runs after waking the system, policy->boost_enabled
> and cpufreq_boost_enabled() are both 0, so the set_boost() at the end
> of that function is never run.
Right, this is what I wanted to do with the $Subject patch. Don't
update boost anymore in suspend/resume
> cpufreq_boost_enabled() being 0 indicates that the MSR has boosting
> disabled, but when I read out that MSR using rdmsr the bit seems to
> indicate that it is actually enabled (I am aware of the inverted logic
> of that bit). set_boost() seems to be the only place in the kernel
> that causes that MSR to be modified, and I didn't see any extra calls
> to it in my debug logs, so it seems like something else (outside the
> kernel?) is setting that MSR.
And this is what I feel too, something else in kernel or outside of it
is doing something tricky.
--
viresh
Powered by blists - more mailing lists