Re: [PATCH 0/5] drm/amd/pm: Fix laptop issues on SMU6-7

["Timur Kristóf" <timur.kristof@gmail.com>]

On 2026. május 30., szombat 12:07:12 közép-európai nyári idő Jeremy Klarenbeek 
wrote:
> Thanks everyone.
> 
> > My suggestion would be to call pm_compute_clocks() inside notify_ac_dc()
> 
> I tried this patch and it's not working.

Of course not. It wouldn't work without also inverting the HARDWAREDC check.

> The specific behavior I see:
> 1. Clocks do not respond to plugging/unplugging. Always idle.
> 2. Severe system stability issues. After opening a process that uses the
> AMDGPU, opening any more GPU processes (glxgears, radeontop, etc.) hangs
> forever during init. The system hangs while shutting down and requires
> force power off.
> 3. This message is seen in dmesg. Not sure if it's related.
> [  151.684427] amdgpu 0000:01:00.0: bo 00000000c5a63ba0 va
> 0x000010cb00-0x000010cb53 conflict with 0x000010cb44-0x000010cb45
> 
> > Are you actually sure that the PPSMC_MSG_RunningOnAC is necessary on your
> 
> laptop?
> Yes, without sending this message, the SMC switches to idle speeds instead
> of AC/performance speeds. Unplugging the laptop ironically makes it clock
> back up instead of down. This fix was found while reverse engineering the
> SMC and confirmed by the clock speeds beginning to rise after implementing
> the message. Commenting out just the one line that sends the message undoes
> the fix.
> 
> > the ATOM_PP_PLATFORM_CAP_HARDWAREDC check is inverted
> 
> I've implemented this into my branch. Thanks for checking.
> 
> Here is the current state, still a 6th commit on top of the original series
> of 5: https://github.com/luisfonsivevo/linux/commit/083a2bbe81d6for
> applyingfdc670b5890de661a3bdd42e9b80
> <https://github.com/luisfonsivevo/linux/commit/083a2bbe81d6fdc670b5890de661a
> 3bdd42e9b80>
> 
> This has been working reliably for a week without any problems and I'd be
> happy to submit it if there are no objections. A separate commit will be
> needed to apply this to SMU7.
> 
> On Fri, May 29, 2026 at 10:33 PM Deucher, Alexander <
> 
> Alexander.Deucher@amd.com> wrote:
> > AMD General
> > 
> > I dug into this a bit more and the ATOM_PP_PLATFORM_CAP_HARDWAREDC check
> > is inverted.  Switching that should fix it.
> > 
> > Alex
> > 
> > ------------------------------
> > *From:* Timur Kristóf <timur.kristof@gmail.com>
> > *Sent:* Sunday, May 24, 2026 7:32 AM
> > *To:* amd-gfx@lists.freedesktop.org <amd-gfx@lists.freedesktop.org>;
> > Deucher, Alexander <Alexander.Deucher@amd.com>; Jeremy Klarenbeek <
> > jeremy.klarenbeek99@gmail.com>
> > *Subject:* Re: [PATCH 0/5] drm/amd/pm: Fix laptop issues on SMU6-7
> > 
> > Hi Jeremy & Alex,
> > 
> > > Apologies for my late reply. I tested the patch series (SI laptop
> > > 1002:6606) and the problem remains where the clock speeds don't boost
> > 
> > upon
> > 
> > > switching to AC. Timur and I investigated this and found 2 problems
> > 
> > Thanks for getting back to us on this topic.
> > At Alex's suggestion, I removed the clock recalculation and added the
> > check to
> > verify ATOM_PP_PLATFORM_CAP_HARDWAREDC. I'm sad to hear that this broke
> > your
> > patches. I apologize for that.
> > 
> > Unfortunately I don't have a SI laptop GPU to test this stuff, so there
> > was no
> > way for me to verify the correctness of those changes before I sent the
> > patches to the mailing list.
> > 
> > > 1. It seems that it is necessary after all to recompute clock speeds
> > > when
> > > toggling AC/DC. Sending PPSMC_MSG_RunningOnAC on its own has no effect.
> > > Each ASIC family's apply_state_adjust_rules appears to be responsible
> > > for
> > > the switch by setting the max_limits, and this function is only called
> > > as
> > > part of computing clocks.
> > 
> > That's right. I took another look at:
> > si_apply_state_adjust_rules()
> > smu7_apply_state_adjust_rules()
> > 
> > Both of these rely on adev->pm.ac_power when determining max_limits, and
> > they
> > set the maximum clocks accordingly. We should indeed re-calculate these
> > clocks
> > on both SI and SMU7 when there is an AC/DC switch to make sure to apply
> > the
> > updated max_limits. Additionally I think we should probably lock the
> > mutexes
> > to ensure that we are sending only one message at a time.
> > 
> > My suggestion would be to call pm_compute_clocks() inside notify_ac_dc(),
> > and
> > also to lock the mutexes:
> > https://gitlab.freedesktop.org/Venemo/linux/-/commit/
> > e98279dff480cc297cbb1fe50c2b71ebd65b9576
> > 
> > if that works, I'd like to submit that patch (and will also port it to
> > SMU7).
> > 
> > > I'm considering removing the .notify_ac_dc field
> > > from the IP block entirely and just calling .pm_compute_clocks from
> > > amdgpu_pm_acpi_event_handler, but I only know for certain that this
> > > works
> > > for my GPU.
> > 
> > I don't agree with that. amdgpu_dpm is generic between all supported HW
> > generations and shouldn't contain HW generation specific code. Also, it
> > clearly
> > doesn't work the same way on every GPU generation, so we shouldn't
> > generalize.
> > 
> > Furthermore, we should minimize the amount of messages we send to the SMU,
> > so
> > we shouldn't send the RunningOnAC message every time we recompute the
> > clocks,
> > only when it actually switches to AC.
> > 
> > > 2. The ATOM_PP_PLATFORM_CAP_HARDWAREDC flag is enabled for my GPU,
> > 
> > causing
> > 
> > > PPSMC_MSG_RunningOnAC to never be sent. Either the flag is enabled
> > > erroneously, or we're interpreting its intended usage incorrectly.
> > 
> > It's hard to judge that without having access to the hardware or docs.
> > Are you actually sure that the PPSMC_MSG_RunningOnAC is necessary on your
> > laptop? Isn't it enough to just re-compute the clocks?
> > 
> > Can you check what exactly is the value of adev->pm.dpm.platform_caps on
> > your
> > laptop? Maybe we are looking at the wrong flag, or maybe the HARDWAREDC
> > flag
> > only refers to the AC->DC transition and not the DC->AC transition.
> > 
> > This is just guesswork on my part, but maybe we should look at the
> > SBIOSPOWERSOURCE flag instead, which is explained in pptable_v1_0.h:
> > /* This cap indicates whether power source notificaiton is done by SBIOS
> > directly. */
> > Can you check if this flag is set on your laptop?
> > 
> > Thanks & best regards,
> > Timur