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 < > > [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
