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

[Rafael J. Wysocki (Intel)]

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.