diff mbox

RADEON / DPM: GPU cannot properly up-clock

Message ID CAKL7Q7pTKteC4HxuhtZtzBLOZDe4r3cGGj4cEbWXx4zg3gstHg@mail.gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Joshua C. June 26, 2013, 5:51 p.m. UTC
First of all thank you guys for pushing this out! Great work!

I tried the latest code in drm-next-3.11-wip (up to commit
b3c1e0c3ba885db44 “drm/radeon: fix endian issues in atombios dpm
code”) in connection with the latest radeon_ucode (latest update on
2013-06-26). I also reintroduced the debugfs info so that I can better
observe the gpu-settings. For this I put back the following patch:

--
1.8.2.1

Everything works fine, however I think that my gpu (ati 6670, see
below) doesn't reclock properly (OR doesn't reclock at all). I
observed the gpu-temps and compared those with the readings when using
“profile” and “dynpm”. Usually (with dynpm) the temps stay low and
jump up when I start glxgears or any HD-movie. With the latest dpm my
temps and the gpu stay in the lowest profile all the time. It doesn't
reclock even if I start any demanding work like HD-Movie. Dmesg shows
this:

***
[    1.307529] == power state 0 ==
[    1.307530]  ui class: none
[    1.307531]  internal class: boot
[    1.307532]  caps:
[    1.307533]  uvd    vclk: 0 dclk: 0
[    1.307534]          power level 0    sclk: 10000 mclk: 15000 vddc:
900 vddci: 0
[    1.307535]          power level 1    sclk: 10000 mclk: 15000 vddc:
900 vddci: 0
[    1.307536]          power level 2    sclk: 10000 mclk: 15000 vddc:
900 vddci: 0
[    1.307537]  status: c r b
[    1.307538] == power state 1 ==
[    1.307539]  ui class: performance
[    1.307539]  internal class: none
[    1.307540]  caps:
[    1.307541]  uvd    vclk: 0 dclk: 0
[    1.307542]          power level 0    sclk: 10000 mclk: 15000 vddc:
900 vddci: 0
[    1.307543]          power level 1    sclk: 40000 mclk: 100000
vddc: 1100 vddci: 0
[    1.307544]          power level 2    sclk: 80000 mclk: 100000
vddc: 1100 vddci: 0
[    1.307544]  status:
[    1.307545] == power state 2 ==
[    1.307546]  ui class: none
[    1.307546]  internal class: uvd
[    1.307547]  caps: video
[    1.307549]  uvd    vclk: 70000 dclk: 56000
[    1.307549]          power level 0    sclk: 80000 mclk: 100000
vddc: 1100 vddci: 0
[    1.307550]          power level 1    sclk: 80000 mclk: 100000
vddc: 1100 vddci: 0
[    1.307551]          power level 2    sclk: 80000 mclk: 100000
vddc: 1100 vddci: 0
[    1.307552]  status:
[    1.311858] switching from power state:
[    1.311859]  ui class: none
[    1.311860]  internal class: boot
[    1.311860]  caps:
[    1.311861]  uvd    vclk: 0 dclk: 0
[    1.311862]          power level 0    sclk: 10000 mclk: 15000 vddc:
900 vddci: 0
[    1.311863]          power level 1    sclk: 10000 mclk: 15000 vddc:
900 vddci: 0
[    1.311864]          power level 2    sclk: 10000 mclk: 15000 vddc:
900 vddci: 0
[    1.311865]  status: c b
[    1.311866] switching to power state:
[    1.311866]  ui class: performance
[    1.311867]  internal class: none
[    1.311868]  caps:
[    1.311869]  uvd    vclk: 0 dclk: 0
[    1.311869]          power level 0    sclk: 10000 mclk: 15000 vddc:
900 vddci: 0
[    1.311870]          power level 1    sclk: 40000 mclk: 100000
vddc: 1100 vddci: 0
[    1.311871]          power level 2    sclk: 80000 mclk: 100000
vddc: 1100 vddci: 0
[    1.311872]  status: r

and later (other dmesg output is attached)

[    1.360509] switching from power state:
[    1.360510]  ui class: performance
[    1.360510]  internal class: none
[    1.360511]  caps:
[    1.360511]  uvd    vclk: 0 dclk: 0
[    1.360512]          power level 0    sclk: 10000 mclk: 15000 vddc:
900 vddci: 0
[    1.360512]          power level 1    sclk: 40000 mclk: 100000
vddc: 1100 vddci: 0
[    1.360513]          power level 2    sclk: 80000 mclk: 100000
vddc: 1100 vddci: 0
[    1.360513]  status: c r
[    1.360514] switching to power state:
[    1.360514]  ui class: performance
[    1.360515]  internal class: none
[    1.360515]  caps:
[    1.360515]  uvd    vclk: 0 dclk: 0
[    1.360516]          power level 0    sclk: 10000 mclk: 15000 vddc:
900 vddci: 0
[    1.360516]          power level 1    sclk: 40000 mclk: 100000
vddc: 1100 vddci: 0
[    1.360517]          power level 2    sclk: 80000 mclk: 100000
vddc: 1100 vddci: 0
[    1.360517]  status: c r

***
The radeon_pm_info shows all the time:

[root@localhost ~]# cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 800000 kHz
current engine clock: 99990 kHz
default memory clock: 1000000 kHz
current memory clock: 150000 kHz
voltage: 1100 mV
PCIE lanes: 16

When using the “dynpm” settings I could see the voltage dropping back
to 900mV (as in performace, power level 0) but now it stays high all
the time. When playing a HD-Moving I can see the film in a
“slow-motion” which also confirms that the gpu doesn't reclock.
Setting dynpm reclocks fine and the HD-movie plays smoothly.

My gpu is:

01:00.0 VGA compatible controller: ATI Technologies Inc Turks XT [AMD
Radeon HD 6600 Series] (prog-if 00 [VGA controller])
        Subsystem: PC Partner Limited Device e194
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 56
        Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M]
        Region 2: Memory at fe620000 (64-bit, non-prefetchable) [size=128K]
        Region 4: I/O ports at e000 [size=256]
        Expansion ROM at fe600000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
                DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
<4us, L1 unlimited
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
                        RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+
AuxPwr- TransPend-
                LnkCap: Port #0, Speed 5GT/s, Width x16, ASPM L0s L1,
Latency L0 <64ns, L1 <1us
                        ClockPM- Surprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 5GT/s, Width x16, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Not Supported,
TimeoutDis-, LTR-, OBFF Not Supported
                DevCtl2: Completion Timeout: 50us to 50ms,
TimeoutDis-, LTR-, OBFF Disabled
                LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range,
EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -6dB,
EqualizationComplete-, EqualizationPhase1-
                         EqualizationPhase2-, EqualizationPhase3-,
LinkEqualizationRequest-
        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
                Address: 00000000fee0f00c  Data: 41d2
        Capabilities: [100 v1] Vendor Specific Information: ID=0001
Rev=1 Len=010 <?>
        Capabilities: [150 v1] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
                AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
        Kernel driver in use: radeon

Can some take a look at this?

Thanks,
joshua

Comments

Joshua C. June 26, 2013, 8:57 p.m. UTC | #1
2013/6/26 Deucher, Alexander <Alexander.Deucher@amd.com>:
>
>
>> -----Original Message-----
>> From: Joshua C. [mailto:joshuacov@gmail.com]
>> Sent: Wednesday, June 26, 2013 1:52 PM
>> To: dri-devel@lists.freedesktop.org
>> Cc: Deucher, Alexander
>> Subject: RADEON / DPM: GPU cannot properly up-clock
>>
>> First of all thank you guys for pushing this out! Great work!
>>
>> I tried the latest code in drm-next-3.11-wip (up to commit
>> b3c1e0c3ba885db44 "drm/radeon: fix endian issues in atombios dpm
>> code") in connection with the latest radeon_ucode (latest update on
>> 2013-06-26). I also reintroduced the debugfs info so that I can better
>> observe the gpu-settings. For this I put back the following patch:
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
>> b/drivers/gpu/drm/radeon/radeon_pm.c
>> index 7ba5d6f..9367234 100644
>> --- a/drivers/gpu/drm/radeon/radeon_pm.c
>> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
>> @@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct
>> radeon_device *rdev)
>>          ret = device_create_file(rdev->dev, &dev_attr_power_method);
>>          if (ret)
>>              DRM_ERROR("failed to create device file for power method\n");
>> +
>> +        if (radeon_debugfs_pm_init(rdev)) {
>> +            DRM_ERROR("Failed to register debugfs file for PM!\n");
>> +        }
>> +
>>          DRM_INFO("radeon: dpm initialized\n");
>>      }
>>
>> --
>> 1.8.2.1
>
> I removed that code for a reason when DPM is active.  With DPM the hardware changes the power state dynamically internally so that old debugging information is completely irrelevant when DPM is active.
>
> Alex
>
>

I see. Do you have any idea why I see those delays when playing a
HD-movie? They do not appear when switching to dynpm. I use the latest
llvm(3.4svn), libdrm(2.4.45), mesa(9.2.0 devel), xserver(1.14.99.0),
xf86-video-ati(deve) - all fetched from git as of 2013-06-26.

--
--joshua
Alex Deucher June 27, 2013, 4:22 p.m. UTC | #2
On Wed, Jun 26, 2013 at 4:57 PM, Joshua C. <joshuacov@gmail.com> wrote:
> 2013/6/26 Deucher, Alexander <Alexander.Deucher@amd.com>:
>>
>>
>>> -----Original Message-----
>>> From: Joshua C. [mailto:joshuacov@gmail.com]
>>> Sent: Wednesday, June 26, 2013 1:52 PM
>>> To: dri-devel@lists.freedesktop.org
>>> Cc: Deucher, Alexander
>>> Subject: RADEON / DPM: GPU cannot properly up-clock
>>>
>>> First of all thank you guys for pushing this out! Great work!
>>>
>>> I tried the latest code in drm-next-3.11-wip (up to commit
>>> b3c1e0c3ba885db44 "drm/radeon: fix endian issues in atombios dpm
>>> code") in connection with the latest radeon_ucode (latest update on
>>> 2013-06-26). I also reintroduced the debugfs info so that I can better
>>> observe the gpu-settings. For this I put back the following patch:
>>>
>>> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
>>> b/drivers/gpu/drm/radeon/radeon_pm.c
>>> index 7ba5d6f..9367234 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_pm.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
>>> @@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct
>>> radeon_device *rdev)
>>>          ret = device_create_file(rdev->dev, &dev_attr_power_method);
>>>          if (ret)
>>>              DRM_ERROR("failed to create device file for power method\n");
>>> +
>>> +        if (radeon_debugfs_pm_init(rdev)) {
>>> +            DRM_ERROR("Failed to register debugfs file for PM!\n");
>>> +        }
>>> +
>>>          DRM_INFO("radeon: dpm initialized\n");
>>>      }
>>>
>>> --
>>> 1.8.2.1
>>
>> I removed that code for a reason when DPM is active.  With DPM the hardware changes the power state dynamically internally so that old debugging information is completely irrelevant when DPM is active.
>>
>> Alex
>>
>>
>
> I see. Do you have any idea why I see those delays when playing a
> HD-movie? They do not appear when switching to dynpm. I use the latest
> llvm(3.4svn), libdrm(2.4.45), mesa(9.2.0 devel), xserver(1.14.99.0),
> xf86-video-ati(deve) - all fetched from git as of 2013-06-26.

What type of movie is it and what are you using to decode the movie? UVD?  CPU?

Alex
Joshua C. June 28, 2013, 10:29 a.m. UTC | #3
2013/6/27 Alex Deucher <alexdeucher@gmail.com>:
> On Wed, Jun 26, 2013 at 4:57 PM, Joshua C. <joshuacov@gmail.com> wrote:
>> 2013/6/26 Deucher, Alexander <Alexander.Deucher@amd.com>:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Joshua C. [mailto:joshuacov@gmail.com]
>>>> Sent: Wednesday, June 26, 2013 1:52 PM
>>>> To: dri-devel@lists.freedesktop.org
>>>> Cc: Deucher, Alexander
>>>> Subject: RADEON / DPM: GPU cannot properly up-clock
>>>>
>>>> First of all thank you guys for pushing this out! Great work!
>>>>
>>>> I tried the latest code in drm-next-3.11-wip (up to commit
>>>> b3c1e0c3ba885db44 "drm/radeon: fix endian issues in atombios dpm
>>>> code") in connection with the latest radeon_ucode (latest update on
>>>> 2013-06-26). I also reintroduced the debugfs info so that I can better
>>>> observe the gpu-settings. For this I put back the following patch:
>>>>
>>>> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
>>>> b/drivers/gpu/drm/radeon/radeon_pm.c
>>>> index 7ba5d6f..9367234 100644
>>>> --- a/drivers/gpu/drm/radeon/radeon_pm.c
>>>> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
>>>> @@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct
>>>> radeon_device *rdev)
>>>>          ret = device_create_file(rdev->dev, &dev_attr_power_method);
>>>>          if (ret)
>>>>              DRM_ERROR("failed to create device file for power method\n");
>>>> +
>>>> +        if (radeon_debugfs_pm_init(rdev)) {
>>>> +            DRM_ERROR("Failed to register debugfs file for PM!\n");
>>>> +        }
>>>> +
>>>>          DRM_INFO("radeon: dpm initialized\n");
>>>>      }
>>>>
>>>> --
>>>> 1.8.2.1
>>>
>>> I removed that code for a reason when DPM is active.  With DPM the hardware changes the power state dynamically internally so that old debugging information is completely irrelevant when DPM is active.
>>>
>>> Alex
>>>
>>>
>>
>> I see. Do you have any idea why I see those delays when playing a
>> HD-movie? They do not appear when switching to dynpm. I use the latest
>> llvm(3.4svn), libdrm(2.4.45), mesa(9.2.0 devel), xserver(1.14.99.0),
>> xf86-video-ati(deve) - all fetched from git as of 2013-06-26.
>
> What type of movie is it and what are you using to decode the movie? UVD?  CPU?
>
> Alex

Here is an example of the information from one of the films:

Stream 0
Type: Video
Codec: H264 - MPEG-4 AVC (part 10) (avc1)
Lang: English
Res: 1280x544
Bitrate: 23.976215
Format: Planar 4:2:0 YVU
Stream 1
Type: Audio
Codec: DTS Audio (dts )
Lang: English
Channels: 3F2R/LFE
Freq: 48000 Hz
Bitrate: 1536 kb/s

I recompiled the whole videostack (mesa, llvm, drm, xserver,
xf86-video-ati, vdpau - all from git) against the patched kernel and
can say that currently there are no visible regressions. The "slow
motion" is almost gone. However I still see it in some frames but I'm
not sure if this is a kernel-part-problem or just a mesa-problem.

However I observe the following:

Under windows: smooth play, temps in idle: 34-35C, cpu-usage: up to 5%
on all cores on a 4-core cpu, temps when playing the film: up to 42C,
cpu-usage: up to 5% on all 4 cores

Under linux (updated as described above): some discrepences (those
happen pretty rarely, though), temps in idle: 34-36C, cpu-usage: up to
5%, temps when playing the film: no more than 37C, cpu-usage: one core
is constantly spiking up to 40% the other 3 stay below 7%.

When looking through the dmesg I cannot see that dpm is changing the
power state to "uvd". This makes me believe that I'm maybe using a
cpu-decode rather then the dedicated uvd. The gpu-temps are also
staying surpricingly low comapred to windows...

--
--joshua
Joshua C. July 1, 2013, 10:58 p.m. UTC | #4
2013/6/28 Joshua C. <joshuacov@gmail.com>:
> 2013/6/27 Alex Deucher <alexdeucher@gmail.com>:
>> On Wed, Jun 26, 2013 at 4:57 PM, Joshua C. <joshuacov@gmail.com> wrote:
>>> 2013/6/26 Deucher, Alexander <Alexander.Deucher@amd.com>:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Joshua C. [mailto:joshuacov@gmail.com]
>>>>> Sent: Wednesday, June 26, 2013 1:52 PM
>>>>> To: dri-devel@lists.freedesktop.org
>>>>> Cc: Deucher, Alexander
>>>>> Subject: RADEON / DPM: GPU cannot properly up-clock
>>>>>
>>>>> First of all thank you guys for pushing this out! Great work!
>>>>>
>>>>> I tried the latest code in drm-next-3.11-wip (up to commit
>>>>> b3c1e0c3ba885db44 "drm/radeon: fix endian issues in atombios dpm
>>>>> code") in connection with the latest radeon_ucode (latest update on
>>>>> 2013-06-26). I also reintroduced the debugfs info so that I can better
>>>>> observe the gpu-settings. For this I put back the following patch:
>>>>>
>>>>> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
>>>>> b/drivers/gpu/drm/radeon/radeon_pm.c
>>>>> index 7ba5d6f..9367234 100644
>>>>> --- a/drivers/gpu/drm/radeon/radeon_pm.c
>>>>> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
>>>>> @@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct
>>>>> radeon_device *rdev)
>>>>>          ret = device_create_file(rdev->dev, &dev_attr_power_method);
>>>>>          if (ret)
>>>>>              DRM_ERROR("failed to create device file for power method\n");
>>>>> +
>>>>> +        if (radeon_debugfs_pm_init(rdev)) {
>>>>> +            DRM_ERROR("Failed to register debugfs file for PM!\n");
>>>>> +        }
>>>>> +
>>>>>          DRM_INFO("radeon: dpm initialized\n");
>>>>>      }
>>>>>
>>>>> --
>>>>> 1.8.2.1
>>>>
>>>> I removed that code for a reason when DPM is active.  With DPM the hardware changes the power state dynamically internally so that old debugging information is completely irrelevant when DPM is active.
>>>>
>>>> Alex
>>>>
>>>>
>>>
>>> I see. Do you have any idea why I see those delays when playing a
>>> HD-movie? They do not appear when switching to dynpm. I use the latest
>>> llvm(3.4svn), libdrm(2.4.45), mesa(9.2.0 devel), xserver(1.14.99.0),
>>> xf86-video-ati(deve) - all fetched from git as of 2013-06-26.
>>
>> What type of movie is it and what are you using to decode the movie? UVD?  CPU?
>>
>> Alex
>
> Here is an example of the information from one of the films:
>
> Stream 0
> Type: Video
> Codec: H264 - MPEG-4 AVC (part 10) (avc1)
> Lang: English
> Res: 1280x544
> Bitrate: 23.976215
> Format: Planar 4:2:0 YVU
> Stream 1
> Type: Audio
> Codec: DTS Audio (dts )
> Lang: English
> Channels: 3F2R/LFE
> Freq: 48000 Hz
> Bitrate: 1536 kb/s
>
> I recompiled the whole videostack (mesa, llvm, drm, xserver,
> xf86-video-ati, vdpau - all from git) against the patched kernel and
> can say that currently there are no visible regressions. The "slow
> motion" is almost gone. However I still see it in some frames but I'm
> not sure if this is a kernel-part-problem or just a mesa-problem.
>
> However I observe the following:
>
> Under windows: smooth play, temps in idle: 34-35C, cpu-usage: up to 5%
> on all cores on a 4-core cpu, temps when playing the film: up to 42C,
> cpu-usage: up to 5% on all 4 cores
>
> Under linux (updated as described above): some discrepences (those
> happen pretty rarely, though), temps in idle: 34-36C, cpu-usage: up to
> 5%, temps when playing the film: no more than 37C, cpu-usage: one core
> is constantly spiking up to 40% the other 3 stay below 7%.
>
> When looking through the dmesg I cannot see that dpm is changing the
> power state to "uvd". This makes me believe that I'm maybe using a
> cpu-decode rather then the dedicated uvd. The gpu-temps are also
> staying surpricingly low comapred to windows...
>
> --
> --joshua


With the latest git 7982128c3d447df27db963af67bc6b8dc7efb1de
"drm/radeon/dpm: add debugfs support for SI" from
git://people.freedesktop.org/~agd5f/linux drm-next-3.11 everything
works fine here (on TURKS). Under Linux I get the same temps as under
windows. No more tearing when watching videos. The GPU re-clocks as
desired...


--
--joshua
diff mbox

Patch

diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 7ba5d6f..9367234 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -1066,6 +1066,11 @@  static int radeon_pm_init_dpm(struct radeon_device *rdev)
         ret = device_create_file(rdev->dev, &dev_attr_power_method);
         if (ret)
             DRM_ERROR("failed to create device file for power method\n");
+
+        if (radeon_debugfs_pm_init(rdev)) {
+            DRM_ERROR("Failed to register debugfs file for PM!\n");
+        }
+
         DRM_INFO("radeon: dpm initialized\n");
     }