Power profiles low and mid are identical on Radeon HD6470M

Wolfgang Fritz wolfgang.fritz at gmx.net
Wed Oct 12 11:21:28 PDT 2011


Am 11.10.2011 23:53, schrieb Alex Deucher:
> On Sat, Oct 8, 2011 at 2:25 PM, Wolfgang Fritz<wolfgang.fritz at gmx.net>  wrote:
>> Hello,
>>
>> I have an HP Elitebook 8560p with Radeon HD7470M graphics, running Debian
>> sid with kernel 3.0.4.
>>
>> I noticed that the power profiles low and mid are setting identical clocks
>> and voltage, the lowest possible values:
>>
>> default engine clock: 750000 kHz
>> current engine clock: 99990 kHz
>> default memory clock: 900000 kHz
>> current memory clock: 149970 kHz
>> voltage: 900 mV
>>
>> Looking at the code, this seems to be intentional at least for the mobility
>> chips, but the chip provides more modes:
>>
>> [    9.361401] [drm] R600: Number of power states = 7
>> [    9.361402] [drm] Is mobility = YES
>> [    9.361403] [drm] ps #0 type 0, modes=3
>> [    9.361404] [drm] 0: mclk=90000, sclk=75000, volt=1100, vddci=0
>> [    9.361406] [drm] 1: mclk=90000, sclk=75000, volt=1100, vddci=0
>> [    9.361407] [drm] 2: mclk=90000, sclk=75000, volt=1100, vddci=0
>> [    9.361409] [drm] ps #1 type 4, modes=3
>> [    9.361410] [drm] 0: mclk=15000, sclk=10000, volt=900, vddci=0
>> [    9.361411] [drm] 1: mclk=90000, sclk=40000, volt=1000, vddci=0
>> [    9.361413] [drm] 2: mclk=90000, sclk=75000, volt=1100, vddci=0
>> [    9.361414] [drm] ps #2 type 0, modes=3
>> [    9.361415] [drm] 0: mclk=90000, sclk=70000, volt=1100, vddci=0
>> [    9.361417] [drm] 1: mclk=90000, sclk=70000, volt=1100, vddci=0
>> [    9.361418] [drm] 2: mclk=90000, sclk=70000, volt=1100, vddci=0
>> [    9.361419] [drm] ps #3 type 2, modes=3
>> [    9.361420] [drm] 0: mclk=15000, sclk=10000, volt=900, vddci=0
>> [    9.361422] [drm] 1: mclk=15000, sclk=10000, volt=900, vddci=0
>> [    9.361423] [drm] 2: mclk=30000, sclk=30000, volt=900, vddci=0
>> [    9.361424] [drm] ps #4 type 2, modes=3
>> [    9.361426] [drm] 0: mclk=65000, sclk=40000, volt=900, vddci=0
>> [    9.361427] [drm] 1: mclk=65000, sclk=40000, volt=900, vddci=0
>> [    9.361428] [drm] 2: mclk=65000, sclk=40000, volt=900, vddci=0
>> [    9.361430] [drm] ps #5 type 2, modes=3
>> [    9.361431] [drm] 0: mclk=30000, sclk=30000, volt=900, vddci=0
>> [    9.361433] [drm] 1: mclk=30000, sclk=30000, volt=900, vddci=0
>> [    9.361434] [drm] 2: mclk=30000, sclk=30000, volt=900, vddci=0
>> [    9.361435] [drm] ps #6 type 0, modes=3
>> [    9.361436] [drm] 0: mclk=65000, sclk=40000, volt=900, vddci=0
>> [    9.361438] [drm] 1: mclk=65000, sclk=40000, volt=900, vddci=0
>> [    9.361439] [drm] 2: mclk=65000, sclk=40000, volt=900, vddci=0
>> [    9.361440] [drm] NOT CHIP_R600
>>
>> (dmesg output from patched radeon module)
>>
>> Questions:
>> 1. Is this a bug or a feature? (I see that it is not obvious which power
>> state to choose)
>
> It's the way it is.
>

:-)

>> 2. What do the 3 clock/voltage modes per power state mean?
>
> On r6xx+, each power state defines an operating state (e.g., single
> head battery, multi-head battery, single head performance, multi-head
> performance, etc.).  Within each operating state, there are
> high/mid/low clock modes that the define that operating state.  So if
> you have one head active and are on battery, the driver should switch
> between the high/mid/low clock modes defined in that power state based
> on the GPU load.  If you enable multi-head and are still on battery,
> the driver would switch to the multi-head battery state and switch
> between the high/mid/low modes in that state.
>

OK. That's what I assumed after short code inspection.

So, this is not cooperating well with the current dynamic clock 
interface in sysfs (at least as I understand it now).

I understand that there are the dynamic and the profile power methods.
In dynamic, I see the clocks switching, probably using the 3 power 
states in the second operation state in the list above (maximum 
performance). This results in an average power consumption similar to 
the catalyst driver (the fan is off most of the time). But it is not 
usable because the screen flickers when the clock state is changed, and 
this happens quite frequently. Also it seems to be independent of 
battery/mains mode.

In the profile power mode, the clocks are at full speed with clock 
profiles default, high and at lowest speed with profiles mid and low. 
The high profile keeps the fan running continuously. This seems to be 
independent of mains or battery mode (I have to double check this)

Low and mid profiles are unusable slow with 3D effects enabled, but work 
quite well with effects disabled, so this would be a suitable profile on 
low battery.

With power profile auto, power state is high performance in mains mode 
and low in battery mode.

So, as long as true dynamic clocking is not working flicker free, it 
would be nice to be able to change the clock modes manually to a value 
that keeps the fan quiet but is sufficient for ordinary work with 
effects enabled. I am currently running at 400/650 MHz @ 900mV with a 
patched driver.

Finally some questions:

Q1: Are all the power modes safe (maybe not optimal) to be used in all 
configurations (dual/single, battery/mains) or is it dangerous (meaning 
for the HW) using for example a dual head operation state in single head 
mode?

Q2: Is the current behavior best we can achieve (maybe due to lack of 
data sheets etc.) or is there room for improvements and it is just not 
implemented (due to limited resources etc.)

Q3: If improvements are possible, would you accept help? I am coding for 
food and I'm good enough that I and my cat survived until now without 
starving. It's not exactly in the Linux kernel area, but on embedded 
Linux platforms, so it I think it would be sufficient for some of the 
"easier" problems. Of course I would do this for fun in my spare time.

Regards,
Wolfgang


> Alex
>
>>
>> Regards,
>> Wolfgang
>>
>>
>>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>



More information about the dri-devel mailing list