Thanks everyone. > My suggestion would be to call pm_compute_clocks() inside notify_ac_dc()
I tried this patch and it's not working. 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/083a2bbe81d6fdc670b5890de661a3bdd42e9b80> 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 < [email protected]> 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 <[email protected]> > *Sent:* Sunday, May 24, 2026 7:32 AM > *To:* [email protected] <[email protected]>; > Deucher, Alexander <[email protected]>; Jeremy Klarenbeek < > [email protected]> > *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 > > > >
