All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)
@ 2026-07-13  6:14 Timur Kristóf
  2026-07-13  8:28 ` Thorsten Leemhuis
  2026-07-13 13:57 ` Alex Deucher
  0 siblings, 2 replies; 7+ messages in thread
From: Timur Kristóf @ 2026-07-13  6:14 UTC (permalink / raw)
  To: amd-gfx, Alex Deucher, Tvrtko Ursulin, Natalie Vock; +Cc: Timur Kristóf

The old radeon driver has a documented workaround in ci_dpm.c
which claims that Bonaire 0x6658 with old memory controller
firmware is unstable with MCLK DPM, so as a precaution I
disabled MCLK DPM on this ASIC in amdgpu.

Note that the old MC firmware is not actually used with
amdgpu, but in theory it's possible that the VBIOS sets
up the ASIC with an old MC firmware that is already running
when amdgpu initializes (in which case amdgpu doesn't
load its own firmware).

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
and upon a closer look it seems that the GPU seems to
not actually use the highest MCLK value, despite the SMU
reporting that it does.

Let's not disable MCLK DPM on Bonaire 0x6658 (R7 260X).

Keep MCLK DPM disabled on R9 M380 in the 2015 iMac
because that still hangs if we enable it.

Fixes: 9851f29cb06c ("drm/amd/pm/ci: Disable MCLK DPM on problematic CI ASICs")
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
---
 drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
index 1d6e30269d56..4d553be56396 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
@@ -106,11 +106,8 @@ int hwmgr_early_init(struct pp_hwmgr *hwmgr)
 		hwmgr->od_enabled = false;
 		switch (hwmgr->chip_id) {
 		case CHIP_BONAIRE:
-			/* R9 M380 in iMac 2015: SMU hangs when enabling MCLK DPM
-			 * R7 260X cards with old MC ucode: MCLK DPM is unstable
-			 */
-			if (adev->pdev->subsystem_vendor == 0x106B ||
-			    adev->pdev->device == 0x6658) {
+			/* R9 M380 in iMac 2015: SMU hangs when enabling MCLK DPM */
+			if (adev->pdev->subsystem_vendor == 0x106B) {
 				dev_info(adev->dev, "disabling MCLK DPM on quirky ASIC");
 				adev->pm.pp_feature &= ~PP_MCLK_DPM_MASK;
 				hwmgr->feature_mask &= ~PP_MCLK_DPM_MASK;
-- 
2.55.0


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)
  2026-07-13  6:14 [PATCH] drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X) Timur Kristóf
@ 2026-07-13  8:28 ` Thorsten Leemhuis
  2026-07-13 10:00   ` Timur Kristóf
  2026-07-13 13:57 ` Alex Deucher
  1 sibling, 1 reply; 7+ messages in thread
From: Thorsten Leemhuis @ 2026-07-13  8:28 UTC (permalink / raw)
  To: Timur Kristóf, amd-gfx, Alex Deucher, Tvrtko Ursulin,
	Natalie Vock

On 7/13/26 08:14, Timur Kristóf wrote:
> The old radeon driver has a documented workaround in ci_dpm.c
> which claims that Bonaire 0x6658 with old memory controller
> firmware is unstable with MCLK DPM, so as a precaution I
> disabled MCLK DPM on this ASIC in amdgpu.
> 
> Note that the old MC firmware is not actually used with
> amdgpu, but in theory it's possible that the VBIOS sets
> up the ASIC with an old MC firmware that is already running
> when amdgpu initializes (in which case amdgpu doesn't
> load its own firmware).
> 
> 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).

Ciao, Thorsten

> and upon a closer look it seems that the GPU seems to
> not actually use the highest MCLK value, despite the SMU
> reporting that it does.
> 
> Let's not disable MCLK DPM on Bonaire 0x6658 (R7 260X).
> 
> Keep MCLK DPM disabled on R9 M380 in the 2015 iMac
> because that still hangs if we enable it.
> 
> Fixes: 9851f29cb06c ("drm/amd/pm/ci: Disable MCLK DPM on problematic CI ASICs")
> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
> ---
>  drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
> index 1d6e30269d56..4d553be56396 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
> @@ -106,11 +106,8 @@ int hwmgr_early_init(struct pp_hwmgr *hwmgr)
>  		hwmgr->od_enabled = false;
>  		switch (hwmgr->chip_id) {
>  		case CHIP_BONAIRE:
> -			/* R9 M380 in iMac 2015: SMU hangs when enabling MCLK DPM
> -			 * R7 260X cards with old MC ucode: MCLK DPM is unstable
> -			 */
> -			if (adev->pdev->subsystem_vendor == 0x106B ||
> -			    adev->pdev->device == 0x6658) {
> +			/* R9 M380 in iMac 2015: SMU hangs when enabling MCLK DPM */
> +			if (adev->pdev->subsystem_vendor == 0x106B) {
>  				dev_info(adev->dev, "disabling MCLK DPM on quirky ASIC");
>  				adev->pm.pp_feature &= ~PP_MCLK_DPM_MASK;
>  				hwmgr->feature_mask &= ~PP_MCLK_DPM_MASK;


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)
  2026-07-13  8:28 ` Thorsten Leemhuis
@ 2026-07-13 10:00   ` Timur Kristóf
  2026-07-13 10:56     ` Thorsten Leemhuis
  0 siblings, 1 reply; 7+ messages in thread
From: Timur Kristóf @ 2026-07-13 10:00 UTC (permalink / raw)
  To: amd-gfx, Alex Deucher, Tvrtko Ursulin, Natalie Vock,
	Thorsten Leemhuis

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:
> > The old radeon driver has a documented workaround in ci_dpm.c
> > which claims that Bonaire 0x6658 with old memory controller
> > firmware is unstable with MCLK DPM, so as a precaution I
> > disabled MCLK DPM on this ASIC in amdgpu.
> > 
> > Note that the old MC firmware is not actually used with
> > amdgpu, but in theory it's possible that the VBIOS sets
> > up the ASIC with an old MC firmware that is already running
> > when amdgpu initializes (in which case amdgpu doesn't
> > load its own firmware).
> > 
> > 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).
> 
> Ciao, Thorsten

Hi Thorsten,

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, and this patch here is the best fix I 
could find.

Best regards,
Timur

> 
> > and upon a closer look it seems that the GPU seems to
> > not actually use the highest MCLK value, despite the SMU
> > reporting that it does.
> > 
> > Let's not disable MCLK DPM on Bonaire 0x6658 (R7 260X).
> > 
> > Keep MCLK DPM disabled on R9 M380 in the 2015 iMac
> > because that still hangs if we enable it.
> > 
> > Fixes: 9851f29cb06c ("drm/amd/pm/ci: Disable MCLK DPM on problematic CI
> > ASICs") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
> > ---
> > 
> >  drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c | 7 ++-----
> >  1 file changed, 2 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
> > b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c index
> > 1d6e30269d56..4d553be56396 100644
> > --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
> > +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
> > @@ -106,11 +106,8 @@ int hwmgr_early_init(struct pp_hwmgr *hwmgr)
> > 
> >  		hwmgr->od_enabled = false;
> >  		switch (hwmgr->chip_id) {
> > 
> >  		case CHIP_BONAIRE:
> > -			/* R9 M380 in iMac 2015: SMU hangs when 
enabling MCLK DPM
> > -			 * R7 260X cards with old MC ucode: MCLK DPM 
is unstable
> > -			 */
> > -			if (adev->pdev->subsystem_vendor == 0x106B 
||
> > -			    adev->pdev->device == 0x6658) {
> > +			/* R9 M380 in iMac 2015: SMU hangs when 
enabling MCLK DPM */
> > +			if (adev->pdev->subsystem_vendor == 0x106B) 
{
> > 
> >  				dev_info(adev->dev, "disabling 
MCLK DPM on quirky ASIC");
> >  				adev->pm.pp_feature &= 
~PP_MCLK_DPM_MASK;
> >  				hwmgr->feature_mask &= 
~PP_MCLK_DPM_MASK;





^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)
  2026-07-13 10:00   ` Timur Kristóf
@ 2026-07-13 10:56     ` Thorsten Leemhuis
  2026-07-13 11:11       ` Timur Kristóf
  0 siblings, 1 reply; 7+ messages in thread
From: Thorsten Leemhuis @ 2026-07-13 10:56 UTC (permalink / raw)
  To: Timur Kristóf, amd-gfx, Alex Deucher, Tvrtko Ursulin,
	Natalie Vock

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.

> and this patch here is the best fix I  could find.

Great, thx.

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?

To provide an example of what I want:

https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16043#note_3563809
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&search_code=true

Is there some trick to do this?

Ciao, Thorsten

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)
  2026-07-13 10:56     ` Thorsten Leemhuis
@ 2026-07-13 11:11       ` Timur Kristóf
  2026-07-13 11:20         ` Thorsten Leemhuis
  0 siblings, 1 reply; 7+ messages in thread
From: Timur Kristóf @ 2026-07-13 11:11 UTC (permalink / raw)
  To: amd-gfx, Alex Deucher, Tvrtko Ursulin, Natalie Vock,
	Thorsten Leemhuis

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)
  2026-07-13 11:11       ` Timur Kristóf
@ 2026-07-13 11:20         ` Thorsten Leemhuis
  0 siblings, 0 replies; 7+ messages in thread
From: Thorsten Leemhuis @ 2026-07-13 11:20 UTC (permalink / raw)
  To: Timur Kristóf, amd-gfx, Alex Deucher, Tvrtko Ursulin,
	Natalie Vock

On 7/13/26 13:11, Timur Kristóf wrote:
>> 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.

Ahh, great, thx, you helped me quite a lot. Fun fact: I had briefly
looked at pages like that for a reference already, but seem I didn't
scroll down far enough. :-/

Ciao, Thorsten

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)
  2026-07-13  6:14 [PATCH] drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X) Timur Kristóf
  2026-07-13  8:28 ` Thorsten Leemhuis
@ 2026-07-13 13:57 ` Alex Deucher
  1 sibling, 0 replies; 7+ messages in thread
From: Alex Deucher @ 2026-07-13 13:57 UTC (permalink / raw)
  To: Timur Kristóf; +Cc: amd-gfx, Alex Deucher, Tvrtko Ursulin, Natalie Vock

Applied.  Thanks!

On Mon, Jul 13, 2026 at 2:54 AM Timur Kristóf <timur.kristof@gmail.com> wrote:
>
> The old radeon driver has a documented workaround in ci_dpm.c
> which claims that Bonaire 0x6658 with old memory controller
> firmware is unstable with MCLK DPM, so as a precaution I
> disabled MCLK DPM on this ASIC in amdgpu.
>
> Note that the old MC firmware is not actually used with
> amdgpu, but in theory it's possible that the VBIOS sets
> up the ASIC with an old MC firmware that is already running
> when amdgpu initializes (in which case amdgpu doesn't
> load its own firmware).
>
> 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
> and upon a closer look it seems that the GPU seems to
> not actually use the highest MCLK value, despite the SMU
> reporting that it does.
>
> Let's not disable MCLK DPM on Bonaire 0x6658 (R7 260X).
>
> Keep MCLK DPM disabled on R9 M380 in the 2015 iMac
> because that still hangs if we enable it.
>
> Fixes: 9851f29cb06c ("drm/amd/pm/ci: Disable MCLK DPM on problematic CI ASICs")
> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
> ---
>  drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
> index 1d6e30269d56..4d553be56396 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c
> @@ -106,11 +106,8 @@ int hwmgr_early_init(struct pp_hwmgr *hwmgr)
>                 hwmgr->od_enabled = false;
>                 switch (hwmgr->chip_id) {
>                 case CHIP_BONAIRE:
> -                       /* R9 M380 in iMac 2015: SMU hangs when enabling MCLK DPM
> -                        * R7 260X cards with old MC ucode: MCLK DPM is unstable
> -                        */
> -                       if (adev->pdev->subsystem_vendor == 0x106B ||
> -                           adev->pdev->device == 0x6658) {
> +                       /* R9 M380 in iMac 2015: SMU hangs when enabling MCLK DPM */
> +                       if (adev->pdev->subsystem_vendor == 0x106B) {
>                                 dev_info(adev->dev, "disabling MCLK DPM on quirky ASIC");
>                                 adev->pm.pp_feature &= ~PP_MCLK_DPM_MASK;
>                                 hwmgr->feature_mask &= ~PP_MCLK_DPM_MASK;
> --
> 2.55.0
>

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2026-07-13 13:57 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-13  6:14 [PATCH] drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X) Timur Kristóf
2026-07-13  8:28 ` Thorsten Leemhuis
2026-07-13 10:00   ` Timur Kristóf
2026-07-13 10:56     ` Thorsten Leemhuis
2026-07-13 11:11       ` Timur Kristóf
2026-07-13 11:20         ` Thorsten Leemhuis
2026-07-13 13:57 ` Alex Deucher

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.