Re: [PATCH] drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)

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

On Monday, July 13, 2026 12:56:39 PM Central European Summer Time Thorsten 
Leemhuis wrote:
> On 7/13/26 12:00, Timur Kristóf wrote:
> > On Monday, July 13, 2026 10:28:08 AM Central European Summer Time Thorsten
> > 
> > Leemhuis wrote:
> >> On 7/13/26 08:14, Timur Kristóf wrote:
> >>> What I expected to happen is that the GPU would simply use
> >>> its maximum memory clock, and indeed this is what seemed
> >>> to happen according to amdgpu_pm_info which reads the
> >>> current MCLK value from the SMU.
> >>> However, some users reported a huge perf regression
> >> 
> >> Were those private reports? If not, please consider linking them in the
> >> trailers using Link: or Closes: tags, as explained in the patch
> >> submission guidelines (and mandated by Linus, see the quotes and links
> >> in
> >> https://www.kernel.org/doc/html/latest/process/handling-regressions.html#
> >> on-> the-importance-of-pointing-to-bug-reports-using-link-closes-tags for
> >> details).
> 
> Thx for the reply!
> 
> > There is no bug report. I had a conversation on Reddit which brought my
> > attention to this issue, then I actually plugged in the GPU, tested it and
> > noticed that there is indeed a problem,
> 
> FWIW, we occasionally link to reddit threads as well, but sounds like
> this would not make sense here.

There are no details about this on Reddit. I just heard that somebody 
experienced a slowdown with this specific GPU starting from the time when my 
previous patch was backported and I realized the PCI ID matches what I added 
in my previous patch. So I got suspicious that maybe it doesn't work as I had 
thought. Then I just tested it for myself and found what I explained in the 
commit message here.

I apologize for the trouble.

> 
> BTW (feel free to ignore this if you have no idea): I first had wondered
> if there is a bug report about this in
> https://gitlab.freedesktop.org/drm/amd/-/work_items and wanted to search
> if the culprit was mentioned anywhere. Do you by chance know if that is
> somehow possible?

GitLab can show when a commit was mentioned, if it's a commit hash that the 
specific GitHub instance knows about. However I'm not sure how reliable that 
is, because the same commit may have a different hash depending on which tree 
you are working with. It may not know that the different hashes are really the 
same commit.

> 
> To provide an example of what I want:
> 
> https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16043#note_35638
> 09 mentions commit-id 2914709c (Revert "drm/i915/backlight: Remove
> try_vesa_interface"") -- but I didn't find a way to find tickets then
> refer to that commit, for example with a search like this:
> https://gitlab.freedesktop.org/search?search=2914709c&nav_source=navbar&sear
> ch_code=true
> 
> Is there some trick to do this?

For that example, if you open the commit link:
https://gitlab.freedesktop.org/drm/i915/kernel/-/commit/
2914709c914101eb704e01bed2351070d4161ccf

You can scroll down and see that the commit was mentioned, and you can then 
click on the issues where it was mentioned.

Hope this helps,
Timur