Bug 38917

Summary: [patch] Radeon clocks should not be limited to defaults
Product: DRI Reporter: Antti Lahtinen <ahlaht>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: medium CC: darkbasic, randrik
Version: unspecified   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Do not limit clocks.patch
none
power states by radeon_pm_print_states
none
Add power_table in /sys none

Description Antti Lahtinen 2011-07-02 11:41:29 UTC 
Created attachment 48691 [details] [review]
Do not limit clocks.patch

As of Linux 3.0-rc5 radeon_set_power_state() does not accept clock speeds higher than the defaults set by firmware. However on my HP laptop the default clock speeds are much lower than the maximum speeds accepted by the card.

These are the default values on my HP laptop:
engine 100000 kHz, memory 157000 kHz, vddc 900 mV

And the other values:

echo low > power_profile
power_state 4, clock_mode 0, engine 100000, memory 150000, vddc 900

echo mid > power_profile
power_state 4, clock_mode 1, engine 100000, memory 150000, vddc 900

echo high > power_profile
power_state 1, clock_mode 2, engine 100000, memory 157000, vddc 1000


The problem occurs with the "high" profile and also when using "dynpm". See the provided patch, it fixes the problem. With the patch applied, correct frequencies are set:

echo high > power_profile
power_state 1, clock_mode 2, engine 550000, memory 800000, vddc 1000

Now the question remains: why where those checks added in the first place? They don't make sense to me unless default clock speeds are specified to be the highest possible. Also there is no such check for voltage.

I do not know if this patch can break some other already broken systems, but it's important to fix the problem somehow because it severely limits 3d performance.

The hardware is AMD Mobility Radeon HD 5650 (1002:68C1).

I'm attaching a complete list of power states on this system. Also for reference here are the values used by Windows 7 when on AC power (I forgot to test battery power):

Win 7 Catalyst PowerPlay disabled:
engine 100000, memory 157000, vddc 900

Win 7 Catalyst PowerPlay enabled:
engine 100000, memory 150000, vddc 900   GPU idle
engine 450000, memory 800000, vddc 950   Light load
engine 550000, memory 800000, vddc 1000  Heavy load

The last 2 modes here are identical to what dynpm uses on Linux after the patch.
Comment 1 Antti Lahtinen 2011-07-02 11:43:03 UTC 
Created attachment 48693 [details]
power states by radeon_pm_print_states
Comment 2 Alex Deucher 2011-07-05 06:40:11 UTC 
There's no infrastructure in place yet to automatically lower clocks if the temperature gets to a critical level so we limit the clocks to the boot up levels for now.  On most systems the boot clocks are much closer to the performance clocks.
Comment 3 Antti Lahtinen 2011-07-18 01:55:57 UTC 
Created attachment 49237 [details] [review]
Add power_table in /sys

Here is an another patch I was asked to send. It unfortunately does not add temperature monitoring, but it allows the user to remove the limit optionally.

It adds two new files in /sys/class/drm/card0/device: power_table and allow_overclocking.

power_table contains the system specific list of power states and some extra information. The whole file or just parts of it can be written back to change some of the values run-time.

These 5 values can be changed on each clock mode:
- RADEON_PM_MODE_NO_DISPLAY (It may be useful to remove this flag to enable
  the lowest clock mode for dynpm.)
- engine clock
- memory clock
- vddc
- vddci

The changes actually done are printed to dmesg. Currently the power state is not automatically reset after a change has been made. This must be done manually by switching to another clock mode temporarily:
echo high > /sys/class/drm/card0/device/power_profile
echo mid > /sys/class/drm/card0/device/power_profile

For safety the clock rates and voltages can not be set to unlimited values by default. The safety checks can be disabled with:
echo 1 > /sys/class/drm/card0/device/allow_overclocking

(This should also be done on systems affected by this bug.)

Of course incorrect combinations of clock rates and voltage can still crash the system even with the checks enabled, but hopefully without permanent damage.

This new patch should not change the default behavior in any way other than printing an error if the boot up clocks appear to be low.
Comment 4 Tomas Pospisek 2013-07-22 14:09:58 UTC 
As of linux 3.11 there is additional power management infrastructure for radeons:

http://www.botchco.com/agd5f/?p=57

Does that change anything wrt the here required functionality respectively this bug report?
Comment 5 almos 2014-08-24 11:30:38 UTC 
Shouldn't this be resolved by new dpm method?
Comment 6 Christian König 2014-08-24 12:28:11 UTC 
Yes indeed, this bug report is superfluous now to do DPM.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.