[Bug 218305] Ryzen 7 7840HS gets stuck at 544MHz frequency after resuming after unplugging the power cord during sleep

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=218305

--- Comment #154 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
> Is this doable/plausible?

Unfortunately; that is filled with hallucinations.  Let me tear it apart.

> **Why it works on Windows:** AMD's Windows drivers explicitly re-initialize
> the SMU CPPC handshake

AMD doesn't have a CPPC driver for Windows, it uses infrastructure built-into
the OS.

> ## How an upstream provider can fix this

If you have Claude code and you think this is viable, use Claude code to make a
patch?

> `drivers/cpufreq/amd-pstate.c` — The driver needs a `.resume()` callback (or
> a
`syscore_ops.resume` hook) that re-writes the CPPC `desired_perf` register for
every online CPU.

There is already a resume hook, please see amd_pstate_resume() that updates the
correct register (MSR_AMD_CPPC_REQ).

> In active mode this means re-issuing the CPPC performance request that was in
> effect before suspend, forcing the SMU to re-accept OS-side CPPC control.

You mean like the code already does?

https://github.com/torvalds/linux/blob/v7.2-rc3/drivers/cpufreq/amd-pstate.c#L2108

> `drivers/platform/x86/amd/pmc/pmc.c` — The `amd_pmc` driver orchestrates the
> s2idle handshake.
> On the exit path (`amd_pmc_resume_handler`) it could call a notifier that
> lets `amd-pstate`
> re-initialize CPPC, ensuring the SMU is back under kernel control before user
> processes resume.

That's not how s2idle resume works.  amd_pmc suspend is unrolled through
acpi_s2idle_restore_early_lps0() -> lps0_s2idle_devops_head.

Then acpi_s2idle_restore() is called and all devices resumed.  amd-pstate
already happens in the latter.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.