Bug 60858 - [radeon HD 4570m] Error setting UVD clocks
Summary: [radeon HD 4570m] Error setting UVD clocks
Status: RESOLVED INVALID
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-05 15:16 UTC by Pinak Ahuja
Modified: 2014-01-09 09:06 UTC (History)
3 users (show)

See Also:
Kernel Version: 3.11
Subsystem:
Regression: No
Bisected commit-id:


Attachments
generated using $dmesg > dmesg.txt (66.37 KB, text/plain)
2013-09-05 15:16 UTC, Pinak Ahuja
Details
Possible fix. (1.32 KB, patch)
2013-09-15 12:31 UTC, Christian König
Details | Diff
print some additional information (636 bytes, patch)
2013-09-16 03:36 UTC, Alex Deucher
Details | Diff
The dmesg log with extra information patch applied. (65.83 KB, text/plain)
2013-09-16 15:45 UTC, Pinak Ahuja
Details
dmesg with reset and reprogramming patch. (65.88 KB, text/plain)
2013-09-16 16:26 UTC, Pinak Ahuja
Details
register dump with reset and reprogramming patch. (231 bytes, text/plain)
2013-09-16 16:26 UTC, Pinak Ahuja
Details

Description Pinak Ahuja 2013-09-05 15:16:44 UTC
Created attachment 107431 [details]
generated using $dmesg > dmesg.txt

I'm using the dell studio 1555 laptop with radeon HD 4570m graphic card. Running the stable 3.11 kernel with the latest linux-firmware files. I am not able to play any video using VDPAU regardless of the codec. During boot up there are a few errors regarding setting UVD clocks

[    8.936898] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!
[    9.983683] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!
[    9.983695] [drm:r600_uvd_ib_test] *ERROR* radeon: failed to raise UVD clocks (-110).

I've attached the full dmesg.
Comment 1 Christian König 2013-09-05 15:20:23 UTC
Does it work when you disable dpm?
Comment 2 Pinak Ahuja 2013-09-05 15:23:10 UTC
(In reply to Christian König from comment #1)
> Does it work when you disable dpm?

No, even with DPM disabled it doesn't work. Do you want a dmesg with DPM disabled?
Comment 3 Christian König 2013-09-05 15:24:18 UTC
No, not necessary.
Comment 4 Christian König 2013-09-05 15:32:34 UTC
Can you get me a dump of the registers, 0x0718, 0x071c and 0x0720 using radeontool?

Something like "sudo radeontool regmatch 0x0718" should do it.
Comment 5 Pinak Ahuja 2013-09-05 15:43:02 UTC
Here are the dumps of the required registers

# radeontool regmatch 0x0718
0x0718  0x20010004 (536936452)

# radeontool regmatch 0x071c
0x071c  0x021f0000 (35586048)

# radeontool regmatch 0x0720
0x0720  0x10050001 (268763137)
Comment 6 Christian König 2013-09-05 15:55:45 UTC
(In reply to Pinak Ahuja from comment #5)
> # radeontool regmatch 0x071c
> 0x071c  0x021f0000 (35586048)

Well, that's no wonder those parameters doesn't work. Either you have a buggy BIOS or our clock calculation code has a bug, anyway I'm going to test that tomorrow with my RV710.

Anyway thanks for the info.
Comment 7 Pinak Ahuja 2013-09-09 06:47:52 UTC
Is there anything i can do to check that my BIOS is buggy.
Comment 8 Christian König 2013-09-09 08:20:56 UTC
You could dig into the code and try to figure out why the post dividers (vclk_div and dclk_div) turn out as 0.

The two involved functions are rv770_set_uvd_clocks which can be found here drivers/gpu/drm/radeon/rv770.c and radeon_uvd_calc_upll_dividers which can be found here drivers/gpu/drm/radeon/radeon_uvd.c.

The most interesting value is rdev->clock.spll.reference_freq, it is the reference clock frequency coming from a bios table. If that is wrong the whole calculation doesn't work any more and the UPLL generates an invalid frequency.

Insert something like DRM_ERROR("Test %d\n", rdev->clock.spll.reference_freq) into the code and see what it spits out on the next reboot.

Unfortunately I currently don't have much time to look into this and it seems to still work fine with my RV710, so it must be something special with your laptop.
Comment 9 Pinak Ahuja 2013-09-09 19:43:24 UTC
(In reply to Christian König from comment #8)
> You could dig into the code and try to figure out why the post dividers
> (vclk_div and dclk_div) turn out as 0.
> 
> The two involved functions are rv770_set_uvd_clocks which can be found here
> drivers/gpu/drm/radeon/rv770.c and radeon_uvd_calc_upll_dividers which can
> be found here drivers/gpu/drm/radeon/radeon_uvd.c.

I'll go through the code a little later and see if i can find something useful.


> The most interesting value is rdev->clock.spll.reference_freq, it is the
> reference clock frequency coming from a bios table. If that is wrong the
> whole calculation doesn't work any more and the UPLL generates an invalid
> frequency.
> 
> Insert something like DRM_ERROR("Test %d\n",
> rdev->clock.spll.reference_freq) into the code and see what it spits out on
> the next reboot.

I did this, heres the output:
[    8.346601] [drm:radeon_uvd_calc_upll_dividers] *ERROR* Test 2700

here's the full log:

http://pastebin.com/31Pe119f
Comment 10 Christian König 2013-09-15 12:31:25 UTC
Created attachment 108421 [details]
Possible fix.

Please try the attached patch.

It just looks like the BIOS left the UPLL in an complete invalid state. Maybe the following reset and reprogramming sequence gets us back to normal, but apart from that I'm running out of ideas how to solve this.
Comment 11 Alex Deucher 2013-09-16 03:36:59 UTC
Created attachment 108461 [details]
print some additional information

Can you also apply this patch and attach the dmesg output?  It prints some debugging info about the clock dividers.
Comment 12 Pinak Ahuja 2013-09-16 15:45:28 UTC
Created attachment 108501 [details]
The dmesg log with extra information patch applied.
Comment 13 Pinak Ahuja 2013-09-16 15:46:54 UTC
(In reply to Christian König from comment #10)
> Created attachment 108421 [details]
> Possible fix.
> 
> Please try the attached patch.
> 
> It just looks like the BIOS left the UPLL in an complete invalid state.
> Maybe the following reset and reprogramming sequence gets us back to normal,
> but apart from that I'm running out of ideas how to solve this.

This does not make a difference, still getting the same errors.
Comment 14 Christian König 2013-09-16 15:56:00 UTC
(In reply to Pinak Ahuja from comment #13)
> This does not make a difference, still getting the same errors.

Please provide dmesg and register dumps with this patch applied anyway.

Thanks,
Christian.
Comment 15 Pinak Ahuja 2013-09-16 16:26:08 UTC
Created attachment 108611 [details]
dmesg with reset and reprogramming patch.
Comment 16 Pinak Ahuja 2013-09-16 16:26:42 UTC
Created attachment 108621 [details]
register dump with reset and reprogramming patch.
Comment 17 Pinak Ahuja 2013-10-01 11:43:24 UTC
Would it be useful to look into the clock calculation code or is my BIOS buggy?
Comment 18 Christian König 2013-10-01 18:47:01 UTC
(In reply to Pinak Ahuja from comment #17)
> Would it be useful to look into the clock calculation code or is my BIOS
> buggy?

The calculation seems to be fine, it's either your BIOS that has incorrect information or you hardware is wired somehow special.

Anyway I can't find a solution to this problem without access to the hardware, sorry.
Comment 19 Pinak Ahuja 2014-01-09 08:06:37 UTC
So it was a hardware problem and not a code problem. I cleaned my laptop and applied a little thermal paste and the issue was fixed. UVD is now working as expected.
Comment 20 Christian König 2014-01-09 09:06:32 UTC
Oh! That's a very interesting information, thanks allot.

We have some other people complaining about that, going to suggest that they check their hardware as well.

Note You need to log in before you can comment on or make changes to this bug.