Bug 49981

Created attachment 62305 [details] [review]
The hack I use to enable 3 heads on my iMac without torching the Radeon

I can replicate this on all radeon enabled kernels including current.

It appears than when more than one head is enabled, a separate set of power profiles is used which attempts to set fire to the graphics card.

I simply edited the second set of power profiles to re-enable low power mode. It's a nasty hack, but it at least makes my 2011 iMac usable with the radeon driver.

The profiles appear to be set in r600_pm_init_profile in r600.c, and it seems that the power profile is one higher than the single head settings, but the clock mode steps up the same. That doesn't appear to be the behaviour seen though, as in multi-head mode on the HD6k the clock mode stays on full all the time. 

That leads me to think maybe the r600 profile is not suitable for HD6k cards. That would depend on whether the same behaviour is seen on other cards that use r600 profile, as it's used for many more families than just Northern Islands (see radeon_asic.c, radeon_asic btc_asic is used for hd6k series).

Also, why is it necessary to increase the power profile just for an extra head? I can't actually figure out the logic in some of the power state and clock mode differences between the card families, are they based on anything other than guesswork?

The code on line 510 of r600.c suggests that there is expected to be two power states for both POWER_STATE_TYPE_BATTERY and POWER_STATE_TYPE_PERFORMANCE, presumably one for single-head and one for multi-head. Changing the number to 0 (the first instance of the each power state) fixes the bug and allows low power mode. 

Could it be that there is actually only one power state for the HD6000? And the function radeon_pm_get_type_index in radeon_pm.c is failing to find the power state at index 1, and so is returning the default, high power state?

Also, where would I find the list of power states found in radeon_atombios.c?

If anyone with an hd6k can add drm.debug=2 to the kernel options and then post the result of dmesg | grep "radeon_pm_print_states" it would help. For me it is showing 4 power states, only 1 of which is 'performance', which the rest being default. I think there is something wrong in atombios, as there should only be one default.

Created attachment 67892 [details]
power states for HD6870

Created attachment 67893 [details]
power states for HD6650M

Power states for HD6650M (on HP Pavilion dv6-6030er). Linux kernel 3.2.30-1 amd64 (debian stock).

Yours would have the mobility flag set, so it would go to the second battery state (state 4) in multi-head mode. It seems like the wrong setting too. Stepping up though the clock modes would do nothing. It'd be better to switch from power state 3, 5 and then 4 when going from low to high, and just leave the clock mode on 1.

Created attachment 67903 [details]
HD6850 radeon_pm_print_states

Linux triQuad 3.5.4-3-desktop #1 SMP PREEMPT Tue Sep 25 08:12:55 UTC 2012 (f1a1fe2) x86_64 x86_64 x86_64 GNU/Linux
ATI Radeon 6850

K, using AMD overdrive in windows it seems in single head mode it steps from 100Mhz to 777Mhz and then 900Mhz, but in dual head it idles at 300 Mhz, but switches back to 775Mhz and 900Mhz for mid and high. It doesn't seem to use 600 Mhz (ps3) at all, but it's a fairly safe bet that it's the idle state for triple head, eyefinity stuff.

So the order should be;
single-head: ps1/cm0, ps1/cm1, ps1/cm2
dual-head: ps2/cm(any), ps1/cm1, ps1/cm2
triple-head: ps3/cm(any), ps1/cm1, ps1/cm2

Thanks for the power states. Need cayman, caicos and turks still. Hopefully they are all the same though.

Created attachment 67937 [details]
patch for barts and caicos mobility

Tested on barts, not caicos. It's restricted to only the power state profiles that I have data on so far, and falls back to the r600 profile for everything else. The mobility profile assumes the laptop will be plugged in when in multi-monitor mode, and so it puts it in performance mode for mid and high.

I want to sort out dynpm too, but dynpm seems to be a huge WIP at the moment, as it just disables it completely if there is more than one monitor. With a single monitor, NI is the same as r600, so it can use the same dynpm.

Created attachment 67953 [details] [review]
proposed patch

Had a look round on google for some other profiles. Not entirely sure about cayman, as the idle is higher than on less powerful cards.

I pushed a patch to handle this properly to my drm-next-3.7-wip branch:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip

>  starting with BTC, there is one state that is used for both
> + * MH and SH. Difference is that we always use the high clock index for
> + * mclk.

I don't think that is correct. It can clearly be seen in Windows that Barts uses different idles for multi head than it does for single head, but uses the same mid and high. Cayman has a different system to barts too I suspect.

> ((rdev->pm.profile_index == PM_PROFILE_MID_MH_IDX) ||
> + (rdev->pm.profile_index == PM_PROFILE_LOW_MH_IDX)))
> + mclk = rdev->pm.power_state[rdev->pm.requested_power_state_index].
> + clock_info[rdev->pm.profiles[PM_PROFILE_HIGH_MH_IDX].dpms_on_cm_idx].mclk;

Isn't that dangerous? It makes the card operate outside of the bios table profiles. You would, in some cases, be increasing the memory clock without increasing the voltage.

(In reply to comment #14)
> I don't think that is correct. It can clearly be seen in Windows that Barts
> uses different idles for multi head than it does for single head, but uses
> the same mid and high. Cayman has a different system to barts too I suspect.

Windows has a very different implementation at the moment, but uses the tables in a similar manor.

> Isn't that dangerous? It makes the card operate outside of the bios table
> profiles. You would, in some cases, be increasing the memory clock without
> increasing the voltage.

Good catch.  Fixed in v3 of the patch.

> Windows has a very different implementation at the moment, but uses the tables
in a similar manor.

From what I can tell, it uses a method very similar to dynpm, but it uses it to switch between the fixed modes in the bios tables. I haven't seen it ever break out of them and start setting engine clocks and memory clocks independently. Maybe you have access to documentation that shows otherwise though?

(In reply to comment #15)
> Good catch.  Fixed in v3 of the patch.

Um, you now seem to be putting mclk and voltage in the high state, while leaving the engine clock really low. Surely you'll fry the gpu by over-volting it.

(In reply to comment #17)
> Um, you now seem to be putting mclk and voltage in the high state, while
> leaving the engine clock really low. Surely you'll fry the gpu by
> over-volting it.

No, it's fine.  You can run with higher voltage, you just have to make sure it's high enough to support the requested clocks.

And temperature?

With voltage on high for every mode, temperature and power usage will be exactly the same as high profile, even with engine clocks low. Setting low profile will just mean you lose all the processing power, yet still have all the problems associated with high power profile. Seems a bizarre fix to me tbh.

I've gone ahead and re-pushed v2 of the patch.  The lower voltages are are to support the higher mclks, so there's no need to keep them high.  They only need to be adjusted up when both clocks are raised.

Well, that patch isn't touching my card. Cya.

A patch referencing this bug report has been merged in Linux v3.7-rc1:

commit 27810fb2d2edacf2961dbedfe9e9f8d2e5080ea5
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Oct 1 19:25:11 2012 -0400

    drm/radeon/pm: fix multi-head profile handling on BTC+ (v2)

On a HD6950 this patches causes the GPU to lock up if the GPU is in the low power profile and the x server is started with multiple monitors attached.  The x server doesn't crash immediatly, but crashes upon opening anything. I am unable to SSH in so I cannot obtain a dmesg upon the crash.

Here are more details
1. Start up computer
2. Put gpu into low power profile through `echo low > /sys/class/drm/card0/device/power_profile`
3. radeon_pm_info shows something like
default engine clock: 800000 kHz
current engine clock: 249990 kHz
default memory clock: 1250000 kHz
current memory clock: 1250000 kHz
voltage: 900 mV
(as expected because the patch pushesh the memory clock to the maximum with multiple heads)
4. start the x server and open an application, GPU locks up/crashes and displays corruption some times

However, if the GPU is set to be in the high power profile it doesn't crash.  Here are the power tables from the GPU

[    0.814049] [drm:radeon_pm_print_states], 4 Power State(s)
[    0.814050] [drm:radeon_pm_print_states], State 0: 
[    0.814051] [drm:radeon_pm_print_states],    Default
[    0.814052] [drm:radeon_pm_print_states], 
[    0.814053]  16 PCIE Lanes
[    0.814138] [drm:radeon_pm_print_states],    3 Clock Mode(s)
[    0.814138] [drm:radeon_pm_print_states],            0 e: 800000     m: 1250000      v: 1175
[    0.814140] [drm:radeon_pm_print_states],            1 e: 800000     m: 1250000      v: 1175
[    0.814141] [drm:radeon_pm_print_states],            2 e: 800000     m: 1250000      v: 1175
[    0.814142] [drm:radeon_pm_print_states], State 1: Performance
[    0.814143] [drm:radeon_pm_print_states],    16 PCIE Lanes
[    0.814144] [drm:radeon_pm_print_states],    3 Clock Mode(s)
[    0.814145] [drm:radeon_pm_print_states],            0 e: 250000     m: 150000       v: 900
[    0.814146] [drm:radeon_pm_print_states],            1 e: 500000     m: 1250000      v: 1000
[    0.814147] [drm:radeon_pm_print_states],            2 e: 870000     m: 1250000      v: 1175
[    0.814148] [drm:radeon_pm_print_states], State 2: 
[    0.814149] [drm:radeon_pm_print_states],    16 PCIE Lanes
[    0.814150] [drm:radeon_pm_print_states],    3 Clock Mode(s)
[    0.814150] [drm:radeon_pm_print_states],            0 e: 500000     m: 1250000      v: 1000
[    0.814151] [drm:radeon_pm_print_states],            1 e: 500000     m: 1250000      v: 1000
[    0.814152] [drm:radeon_pm_print_states],            2 e: 870000     m: 1250000      v: 1175
[    0.814154] [drm:radeon_pm_print_states], State 3: 
[    0.814154] [drm:radeon_pm_print_states],    16 PCIE Lanes
[    0.814155] [drm:radeon_pm_print_states],    3 Clock Mode(s)
[    0.814156] [drm:radeon_pm_print_states],            0 e: 500000     m: 1250000      v: 1000
[    0.814157] [drm:radeon_pm_print_states],            1 e: 500000     m: 1250000      v: 1000
[    0.814158] [drm:radeon_pm_print_states],            2 e: 870000     m: 1250000      v: 1175

To summarize (all with multiple heads)

1. e: 250000 m: 1250000 v: 900 - crash
2. e: 800000 m: 1250000 v: 1175 - no crash
3. e: 250000 m: 150000  v: 900 - no crash

*** Bug 42854 has been marked as a duplicate of this bug. ***

I'm with a radeon 6750m mbp 8.2
It's a TURK chip 
From Linux >= 3.7 I can't have low power working :
# cat /sys/class/drm/card0/device/power_method
profile
# cat /sys/class/drm/card0/device/power_profile
low

but  # cat /sys/kernel/debug/dri/0/radeon_pm_info :
default engine clock: 600000 kHz
current engine clock: 599970 kHz
default memory clock: 793750 kHz
current memory clock: 793750 kHz
voltage: 1000 mV

I've an external screen connected with HDMI cable, and laptop screen is off.

If the two screens are ON, the GPU and memory power go high, but not with only one screen (LCD or external) on Linux 3.6.11 :

# cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 600000 kHz
current engine clock: 99990 kHz
default memory clock: 793750 kHz
current memory clock: 150000 kHz
voltage: 900 mV

I've tried 3.8rcXXX and 3.9 WIP from here :
http://cgit.freedesktop.org/~agd5f/linux/snapshot/linux-drm-next-3.9-wip.tar.gz

Nothing can turn my radeon card at low power, Linux 3.7, 3.8, 3.9 burn my laptop ...

Created attachment 74554 [details]
HD6750m_radeon_pm_print_states

Created attachment 74606 [details] [review]
fix multi-head stability

This should fix stability problems with profiles and multi-head.

No luck for me, the patch "fix multi-head stability" apply on linux 3.9-DRM-next-WIP, doesn't change anything on 6750m, boot with linux efi stub.

Macbook Pro 8,2 Late 2011 with Radeon 6750m like Ludovic Watteaux. 

In order to get the power profile working with the kernel 3.8rc4 I had to revert the following commits:

"drm/radeon/pm: fix multi-head profile handling on BTC+ (v2)"
27810fb2d2edacf2961dbedfe9e9f8d2e5080ea5

"drm/radeon: only adjust default clocks on NI GPUs"
2e3b3b105ab3bb5b6a37198da4f193cd13781d13.

And apply the following:

--------------------- drivers/gpu/drm/radeon/radeon_pm.c ----------------------
index dfc59c3..c045985 100644
@@ -98,7 +98,7 @@ static void radeon_pm_update_profile(struct radeon_device *rdev)
 		break;
 	case PM_PROFILE_LOW:
 		if (rdev->pm.active_crtc_count > 1)
-			rdev->pm.profile_index = PM_PROFILE_LOW_MH_IDX;
+			rdev->pm.profile_index = PM_PROFILE_LOW_SH_IDX;
 		else
 			rdev->pm.profile_index = PM_PROFILE_LOW_SH_IDX;
 		break;

Thanks Chav,
Revert the two comits and apply the patch fix it !

On my TURKS chip (HD 6750M) the radeon_pm_print_states() output shows that I should be using POWER_STATE_TYPE_POWERSAVE instead of POWER_STATE_TYPE_BATTERY.

I don't know if this is true for all TURKS chips or what other chips are affected, but the following patch against 3.9-rc5 fixes power profiles on my MacBookPro8,2.

diff -ruN linux-3.9-rc5.orig/drivers/gpu/drm/radeon/evergreen.c linux-3.9-rc5/drivers/gpu/drm/radeon/evergreen.c
--- linux-3.9-rc5.orig/drivers/gpu/drm/radeon/evergreen.c       2013-03-31 15:12:43.000000000 -0700
+++ linux-3.9-rc5/drivers/gpu/drm/radeon/evergreen.c    2013-04-05 17:45:04.179779729 -0700
@@ -343,7 +343,9 @@
         * MH and SH.  Difference is that we always use the high clock index for
         * mclk.
         */
-       if (rdev->flags & RADEON_IS_MOBILITY)
+       if ((rdev->flags & RADEON_IS_MOBILITY) && (rdev->family == CHIP_TURKS))
+               idx = radeon_pm_get_type_index(rdev, POWER_STATE_TYPE_POWERSAVE, 0);
+       else if (rdev->flags & RADEON_IS_MOBILITY)
                idx = radeon_pm_get_type_index(rdev, POWER_STATE_TYPE_BATTERY, 0);
        else
                idx = radeon_pm_get_type_index(rdev, POWER_STATE_TYPE_PERFORMANCE, 0);

Sorry, my previous patch was bogus -- TURKS mobility actually needs POWER_STATE_TYPE_PERFORMANCE.  radeon_pm_get_type_index() currently fails to find the requested state (POWER_STATE_TYPE_BATTERY).

Here is a trivial patch against linux-3.8.8:

diff -ruN linux-3.8.8.orig/drivers/gpu/drm/radeon/evergreen.c linux-3.8.8/drivers/gpu/drm/radeon/evergreen.c
--- linux-3.8.8.orig/drivers/gpu/drm/radeon/evergreen.c 2013-04-16 22:11:28.000000000 -0700
+++ linux-3.8.8/drivers/gpu/drm/radeon/evergreen.c      2013-04-17 16:51:04.858752564 -0700
@@ -343,7 +343,7 @@
         * MH and SH.  Difference is that we always use the high clock index for
         * mclk.
         */
-       if (rdev->flags & RADEON_IS_MOBILITY)
+       if ((rdev->flags & RADEON_IS_MOBILITY) && (rdev->family != CHIP_TURKS))
                idx = radeon_pm_get_type_index(rdev, POWER_STATE_TYPE_BATTERY, 0);
        else
                idx = radeon_pm_get_type_index(rdev, POWER_STATE_TYPE_PERFORMANCE, 0);

Running with the patch in multi-head shows reduced engine clock and voltage, but high memory clock as expected:

blee@supra ~ $ cat /sys/class/drm/card0/device/power_method
profile
blee@supra ~ $ cat /sys/class/drm/card0/device/power_profile
low
blee@supra ~ $ sudo cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 600000 kHz
current engine clock: 99990 kHz
default memory clock: 793750 kHz
current memory clock: 793750 kHz
voltage: 900 mV

Excuse me for disturbing all of you here, but, please, can anyone help me finding kernel with these patches already packaged? Some PPAs?

I have the same overheating problem with a Sony Vaio i5 with ATI Redeon 5400 graphics.
Idle temperature quickly rises to 70oC and then any desktop activity takes the temperature into the 80's. Running a video fullscreen causes the machine to shutdown.

Starting with kernel 3.11 you can enable the dynamic power management hardware on the gpu by booting with radeon.dpm=1 on the kernel command line in grub.  You will also need the latest smc firmware for your card.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/273.