Re: [PATCH] cpufreq: intel_pstate: Restore P-state request on resume without HWP

[Zak Brighton Knight]

I was about to test the patch when I saw your message. Happy to test
any future patches!

On Thu, 29 Oct 2026 at 20:52, Rafael J. Wysocki (Intel)
<rafael@xxxxxxxxxx> wrote:
>
> On Wed, Oct 28, 2026 at 11:28 PM Doug Smythies <dsmythies@xxxxxxxxx> wrote:
> >
> > On 2026.10.28 08:54 Rafael wrote:
> > > On Tue, Oct 27, 2026 at 10:46 PM Doug Smythies <dsmythies@xxxxxxxxx> wrote:
> > >> On 2026.10.27 Rafael wrote:
> > >>> On Tue, Oct 27, 2026 at 5:36 PM Doug Smythies <dsmythies@xxxxxxxxx> wrote:>
> > >>>> On 2026.10.27 07:37 Zak Brighton Knight wrote:
> > >>
> > >> ...
> > >>
> > >>>> I confirm your findings and tested your proposed patch. It all worked fine.
> > >>>> I had not seen Rafaels's reply about a possible race condition until now.
> > >>>>
> > >>>> Test computer: i5-10600K, 6 cores, 12 CPUs, HWP disabled.
> > >>>
> > >>> Passive or active mode?
> > >>
> > >> Apologies for the incomplete report.
> > >
> > > No worries.
> > >
> > >> Passive mode has the issue. Active mode was fine without the need for the patch.
> > >
> > > Thanks for the update.
> > >
> > > Please check the patch I've just posted if poss.
> >
> > Because I had already done so before this email, I tested Zak's V2 patch, and it worked fine.
> >
> > I tested your (Rafael's) patch and it worked fine.
> >
> > Tested-by: Doug Smythies <dsmythies@xxxxxxxxx>
>
> Thanks!
>
> > I have not reviewed the code and will not have time to for a few days.
>
> That patch had problems found by AI and it cannot be done exactly the
> way I wanted to do it because at least the userspace governor depends
> on preserving policy->cur across suspend-resume.  However, there is a
> way to force driver callback invocation in __cpufreq_driver_targer()
> even if policy->cur is equal to the new target frequency which can be
> done during resume.
>
> I'll split the patch and submit a proper series when the AI is happy with it.