Bug 73378 - [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!
Summary: [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-08 01:38 UTC by atmouse
Modified: 2015-03-23 14:29 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:


Attachments
linux-x86_64-full-dmesg (81.09 KB, text/plain)
2014-01-08 01:38 UTC, atmouse
no flags Details
full-dmesg (74.25 KB, text/plain)
2014-03-23 19:09 UTC, Sgt. Garcia
no flags Details
lspci of my graphic card (3.77 KB, text/plain)
2014-10-12 20:40 UTC, sterfield
no flags Details
dmesg (63.29 KB, text/plain)
2014-10-12 20:41 UTC, sterfield
no flags Details
dmesg 3.18.1 with drm debug=0x06 (215 bytes, text/plain)
2014-12-26 12:25 UTC, Öyvind Saether
no flags Details
fglrx mmiotrace dump (1.06 MB, text/plain)
2015-02-16 21:15 UTC, Chernovsky Oleg
no flags Details
Possible fix (1.51 KB, patch)
2015-02-19 08:43 UTC, Christian König
no flags Details | Splinter Review

Description atmouse 2014-01-08 01:38:06 UTC
Created attachment 91631 [details]
linux-x86_64-full-dmesg

I'm try to play video through vdpau , but vainfo shows no h264 VLD codec detecting.
libva info: VA-API version 0.34.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'vdpau'
libva info: Trying to open /usr/lib/dri/vdpau_drv_video.so
libva info: Found init function __vaDriverInit_0_33
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.34 (libva 1.2.1)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.4
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD

env:
LIBVA_DRIVER_NAME=vdpau
VDPAU_DRIVER=radeonsi

The dmesg show me some ib ring test failed, but i don't know how to going on, even pass (radeon.dpm=0) to kernel as the same error.
[    5.236963] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!
[    5.236972] [drm:uvd_v1_0_ib_test] *ERROR* radeon: failed to raise UVD clocks (-110).
[    5.236977] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-110).

And this command result that i don't know what its mean:
root@ArchCC /home/atmouse # radeontool regmatch 0x0718  
0x0718	0x0000001a (26)
root@ArchCC /home/atmouse # radeontool regmatch 0x071c
0x071c	0xc080001c (-1065353188)
root@ArchCC /home/atmouse # radeontool regmatch 0x0720
0x0720	0x3168680e (828925966)
Comment 1 Christian König 2014-01-09 09:57:59 UTC
Please double check that your hardware isn't overheating.

Did you changed anything on the timing parameters (Over-clocking tools etc...)? Cause the clocks for UVD mode look a bit odd.
Comment 2 Sgt. Garcia 2014-03-23 19:09:30 UTC
Created attachment 96253 [details]
full-dmesg

grep for uvd_send
Comment 3 Sgt. Garcia 2014-03-23 19:10:10 UTC
same problem here. UVD is initialised properly but setting clocks timesout.
Comment 4 Alex Deucher 2014-03-24 14:45:32 UTC
(In reply to comment #3)
> same problem here. UVD is initialised properly but setting clocks timesout.

If this is a regression, can you bisect?
Comment 5 Öyvind Saether 2014-05-05 08:04:39 UTC
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Pitcairn PRO [Radeon HD 7850]

3.14.2-gentoo

[    2.360636] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!
[    2.360795] [drm:uvd_v1_0_ib_test] *ERROR* radeon: failed to raise UVD clocks (-110).
[    2.360954] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-110).

such fail. wow.

also, suspend and resume does not work with 3.13 and 3.14 but works with 3.12 but I haz no clue if this has anything to do with radeon but those errors ^^ are present in this bug & latest kernels.
Comment 6 Alex Deucher 2014-05-05 13:22:38 UTC
(In reply to comment #5)
> 
> also, suspend and resume does not work with 3.13 and 3.14 but works with
> 3.12 but I haz no clue if this has anything to do with radeon but those
> errors ^^ are present in this bug & latest kernels.

Can you bisect?
Comment 7 Öyvind Saether 2014-05-14 22:00:59 UTC
> Can you bisect?

Not sure how to do that but if you want to point me to some instructions then please do.

Basically suspend and resume works with 3.12 kernels but in later kernels I can suspend and then resume once but after that the system does not suspend anymore.
Comment 8 sterfield 2014-10-12 20:40:54 UTC
Created attachment 107749 [details]
lspci of my graphic card

This is a result of "lspci -s 01:00.0 -vvv", showing all the details of my graphic card.
Comment 9 sterfield 2014-10-12 20:41:46 UTC
Created attachment 107750 [details]
dmesg

Full dmesg after a cold boot, showing the UVD error.
Comment 10 sterfield 2014-10-12 20:49:46 UTC
Hi,

I've got the exact same error, preventing me to use UVD for H264 decoding

[   12.836644] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off
[   12.878552] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!
[   12.878574] [drm:uvd_v1_0_ib_test] *ERROR* radeon: failed to raise UVD clocks (-110).
[   12.878595] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-110).


I've tried with kernel 3.16-2-amd64 (from Debian testing), kernel 3.12.6 (from Debian backports), the issue is the same.

As someone ask for "bisect", I did some google, and it apparently means that I have to find the previous package / library where the problem is not present. I supposed that it's located in libdrm-radeon1, so I tried last available package in sid (2.4.58-2) and back in wheezy (2.4.40-1), but the problem is still present in both version.

I'm willing to help to find the root of this issue, and I'm able to do some test (I've spent several hours on this issue already), but I may just need some indication on where to search.

Thanks for your help.
Comment 11 equeim 2014-12-07 15:20:53 UTC
I have the same issue with Radeon R9 280X. This happens only on cold boot. I've tried various kernels (3.14, 3.15, 3.17) without success.
Comment 12 equeim 2014-12-08 15:52:13 UTC
Same on 3.18.0
Comment 13 Öyvind Saether 2014-12-26 12:25:56 UTC
Created attachment 111366 [details]
dmesg 3.18.1 with drm debug=0x06

[    6.976062] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!
[    6.976064] [drm:uvd_v1_0_ib_test] *ERROR* radeon: failed to raise UVD clocks (-110).
[    6.976066] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-110).

on 3.18.1, could this be because the card is factory overclocked?

[    5.613512] [drm:radeon_pm_print_states] 4 Power State(s)
[    5.613512] [drm:radeon_pm_print_states] State 0: 
[    5.613513] [drm:radeon_pm_print_states]     Default
[    5.613514] [drm:radeon_pm_print_states]     16 PCIE Lanes
[    5.613514] [drm:radeon_pm_print_states]     1 Clock Mode(s)
[    5.613515] [drm:radeon_pm_print_states]             0 e: 860000     m: 1200000      v: 1210
[    5.613516] [drm:radeon_pm_print_states] State 1: Performance
[    5.613517] [drm:radeon_pm_print_states]     16 PCIE Lanes
[    5.613517] [drm:radeon_pm_print_states]     3 Clock Mode(s)
[    5.613518] [drm:radeon_pm_print_states]             0 e: 300000     m: 500000       v: 825
[    5.613519] [drm:radeon_pm_print_states]             1 e: 450000     m: 1225000      v: 900
[    5.613520] [drm:radeon_pm_print_states]             2 e: 1000000    m: 1225000      v: 1210
[    5.613520] [drm:radeon_pm_print_states] State 2: 
[    5.613521] [drm:radeon_pm_print_states]     16 PCIE Lanes
[    5.613521] [drm:radeon_pm_print_states]     3 Clock Mode(s)
[    5.613522] [drm:radeon_pm_print_states]             0 e: 450000     m: 1225000      v: 900
[    5.613522] [drm:radeon_pm_print_states]             1 e: 450000     m: 1225000      v: 900
[    5.613523] [drm:radeon_pm_print_states]             2 e: 1000000    m: 1225000      v: 1210
[    5.613524] [drm:radeon_pm_print_states] State 3: 
[    5.613524] [drm:radeon_pm_print_states]     1 PCIE Lanes
[    5.613525] [drm:radeon_pm_print_states]     3 Clock Mode(s)
[    5.613526] [drm:radeon_pm_print_states]             0 e: 300000     m: 500000       v: 825
[    5.613526] [drm:radeon_pm_print_states]             1 e: 300000     m: 500000       v: 825
[    5.613527] [drm:radeon_pm_print_states]             2 e: 300000     m: 500000       v: 825
[    5.613557] [drm] radeon: power management initialized
Comment 14 Christian König 2014-12-26 12:37:03 UTC
(In reply to Öyvind Saether from comment #13)
> on 3.18.1, could this be because the card is factory overclocked?

Yes, that's possible. If you activate UVD you must downclock the system clock for it to work reliable. Not sure if we have implemented that correctly for SI.
Comment 15 Chernovsky Oleg 2015-01-28 17:29:56 UTC
I can help with code here.

What should be implemented, roughly?
Comment 16 Alex Deucher 2015-01-28 18:35:11 UTC
(In reply to Christian König from comment #14)
> (In reply to Öyvind Saether from comment #13)
> > on 3.18.1, could this be because the card is factory overclocked?
> 
> Yes, that's possible. If you activate UVD you must downclock the system
> clock for it to work reliable. Not sure if we have implemented that
> correctly for SI.

We already handle it.  SI has UVD power states which also include validated sclk and mclk levels that are often different than the performance state.  The driver switches to those states when UVD is used.  At driver load time (when the ring and IB tests are done), the hw is still in the boot state (which has really low clocks) anyway.
Comment 17 Alex Deucher 2015-01-28 18:47:22 UTC
On older versions of the driver we init dpm after everything else, so the ring and ib tests happen before we even touch the dpm hw so clocks are at their low boot up levels.

On newer versions of the driver we init dpm early, but we don't enable the non boot states until the end of the init sequence after the ring and ib tests.

From the log:

[    5.237881] == power state 0 ==
[    5.237882] 	ui class: none
[    5.237883] 	internal class: boot 
[    5.237884] 	caps: 
[    5.237885] 	uvd    vclk: 0 dclk: 0
[    5.237887] 		power level 0    sclk: 15000 mclk: 15000 vddc: 900 vddci: 950 pcie gen: 2
[    5.237887] 	status: c r b 

This is the boot state.  The clocks are fixed at 150Mhz for both sclk and mclk.

[    5.237889] == power state 1 ==
[    5.237890] 	ui class: performance
[    5.237890] 	internal class: none
[    5.237891] 	caps: 
[    5.237892] 	uvd    vclk: 0 dclk: 0
[    5.237893] 		power level 0    sclk: 30000 mclk: 15000 vddc: 825 vddci: 850 pcie gen: 2
[    5.237895] 		power level 1    sclk: 45000 mclk: 120000 vddc: 900 vddci: 975 pcie gen: 2
[    5.237896] 		power level 2    sclk: 100000 mclk: 120000 vddc: 1219 vddci: 975 pcie gen: 2
[    5.237896] 	status: 


This is the performance state.  The sclk can range from 300 Mhz to 1Ghz and the mclk can range from 150Mhz to 1.2Ghz based on GPU demand.

[    5.237897] == power state 2 ==
[    5.237898] 	ui class: none
[    5.237898] 	internal class: uvd 
[    5.237899] 	caps: video 
[    5.237901] 	uvd    vclk: 72000 dclk: 56000
[    5.237902] 		power level 0    sclk: 45000 mclk: 120000 vddc: 900 vddci: 975 pcie gen: 2
[    5.237903] 		power level 1    sclk: 45000 mclk: 120000 vddc: 900 vddci: 975 pcie gen: 2
[    5.237904] 		power level 2    sclk: 100000 mclk: 120000 vddc: 1219 vddci: 975 pcie gen: 2
[    5.237905] 	status: 

This is the UVD state.  As you can see there is a floor of 450Mhz on the sclk to maintain the necessary performance level for post processing and presentation.

[    5.237905] == power state 3 ==
[    5.237906] 	ui class: none
[    5.237907] 	internal class: ulv 
[    5.237908] 	caps: 
[    5.237909] 	uvd    vclk: 0 dclk: 0
[    5.237910] 		power level 0    sclk: 30000 mclk: 15000 vddc: 825 vddci: 850 pcie gen: 2
[    5.237911] 		power level 1    sclk: 30000 mclk: 15000 vddc: 825 vddci: 850 pcie gen: 2
[    5.237912] 		power level 2    sclk: 30000 mclk: 15000 vddc: 825 vddci: 850 pcie gen: 2

This is the ulv state which is only active when the board is completely idle.
Comment 18 Chernovsky Oleg 2015-01-28 20:44:25 UTC
(In reply to Alex Deucher from comment #16)
> (In reply to Christian König from comment #14)
> > (In reply to Öyvind Saether from comment #13)
> > > on 3.18.1, could this be because the card is factory overclocked?
> > 
> > Yes, that's possible. If you activate UVD you must downclock the system
> > clock for it to work reliable. Not sure if we have implemented that
> > correctly for SI.
> 
> We already handle it.  SI has UVD power states which also include validated
> sclk and mclk levels that are often different than the performance state. 
> The driver switches to those states when UVD is used.  At driver load time
> (when the ring and IB tests are done), the hw is still in the boot state
> (which has really low clocks) anyway.

Hm-m, just tried drm-next-3.20 branch and:

[  365.200918] [drm:radeon_uvd_send_upll_ctlreq [radeon]] *ERROR* Timeout setting UVD clocks!
[  365.200922] [drm:uvd_v1_0_ib_test [radeon]] *ERROR* radeon: failed to raise UVD clocks (-110).
[  365.200928] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on ring 5 (-110).


Both on cold start and resume from suspend, Pitcairn, Mesa 10.4.3
Ah yes, the card is factory overclocked (at least box states so)

It's not very painful for me but if I can help somehow, I'm in
Comment 19 Alex Deucher 2015-01-28 21:43:12 UTC
(In reply to Chernovsky Oleg from comment #18)
> Hm-m, just tried drm-next-3.20 branch and:
> 
> [  365.200918] [drm:radeon_uvd_send_upll_ctlreq [radeon]] *ERROR* Timeout
> setting UVD clocks!
> [  365.200922] [drm:uvd_v1_0_ib_test [radeon]] *ERROR* radeon: failed to
> raise UVD clocks (-110).
> [  365.200928] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed
> testing IB on ring 5 (-110).
> 
> 
> Both on cold start and resume from suspend, Pitcairn, Mesa 10.4.3
> Ah yes, the card is factory overclocked (at least box states so)
> 
> It's not very painful for me but if I can help somehow, I'm in

I don't think it will make a difference, but you can try limiting the clocks in si_apply_state_adjust_rules().  Take a look at the quirk handling code for how to limit the sclk and mclk.
Comment 20 Christian König 2015-01-29 10:44:43 UTC
(In reply to Chernovsky Oleg from comment #15)
> I can help with code here.
> 
> What should be implemented, roughly?

Sounds good. I assume you got a card with that problem.

First of all try if UVD works otherwise. E.g. we raise the clocks for the boot up test (and lower them again after that), but that's actually not necessary most of the time.

So get into radeon_uvd_send_upll_ctlreq, just comment out the error return value and pretend everything worked fine.

Then check if the following IB test works or not.

If that doesn't work the input clocks to the PLL doesn't seem to work and we have a clock routing problem or something like that. If that works the PLL just doesn't likes our parameters and we need to figure out why.

Feel free to contact me by mail if you have more questions.

Thanks,
Christian.
Comment 21 Chernovsky Oleg 2015-01-30 20:13:41 UTC
(In reply to Christian König from comment #20)
> (In reply to Chernovsky Oleg from comment #15)
> > I can help with code here.
> > 
> > What should be implemented, roughly?
> 
> Sounds good. I assume you got a card with that problem.
> 
> First of all try if UVD works otherwise. E.g. we raise the clocks for the
> boot up test (and lower them again after that), but that's actually not
> necessary most of the time.
> 
> So get into radeon_uvd_send_upll_ctlreq, just comment out the error return
> value and pretend everything worked fine.
> 
> Then check if the following IB test works or not.
> 
> If that doesn't work the input clocks to the PLL doesn't seem to work and we
> have a clock routing problem or something like that. If that works the PLL
> just doesn't likes our parameters and we need to figure out why.
> 
> Feel free to contact me by mail if you have more questions.
> 
> Thanks,
> Christian.

Yes, I have a card with that problem

Ok Christian, I'll be doing tests on this weekend and report here.
If this won't work out, I'll look through the code Alex mentioned.

Thanks for clarifications!
Comment 22 Chernovsky Oleg 2015-01-30 23:35:57 UTC
(In reply to Christian König from comment #20)

It seems you were right, Christian, now I see

[  120.417486] [drm] UVD initialized successfully.

I've played some videos using -vo=vdpau -hwdec=vdpau, all seems smooth

What are our next steps then?
Comment 23 Chernovsky Oleg 2015-01-30 23:43:51 UTC
Wow! Pls forget my last comment completely.

Just tried to watch H264 video and it was slow as hell :(


Playing: Zoku Sayonara Zetsubou Sensei - 06.mkv
[stream] Video (+) --vid=1 (h264)
[stream] Audio (+) --aid=1 --alang=jpn (*) (aac)
Trying to use hardware decoding.
AO: [pulse] 48000Hz stereo 2ch float
VO: [vdpau] 1280x720 vdpau
AV: 00:00:00 / 00:23:59 (0%) A-V:  0.346


           *************************************************
           **** Audio/Video desynchronisation detected! ****
           *************************************************

AV: 00:00:00 / 00:23:59 (0%) A-V:  2.083 Dropped: 3
Exiting... (Quit)
mpv --vo=vdpau --hwdec=vdpau Zoku\ Sayonara\ Zetsubou\ Sensei\ -\ 06.mkv  0,16s user 14,18s system 96% cpu 14,790 total
Comment 24 Christian König 2015-01-31 10:18:06 UTC
(In reply to Chernovsky Oleg from comment #23)
> Wow! Pls forget my last comment completely.
> 
> Just tried to watch H264 video and it was slow as hell :(

Which is the espected result if you don't setup the clocks :)

In this case the UVD block runs with the default 100Mhz instead of the desired 400,500,900 or whatever the power tables say we should programm it to. At least we now knew that the input frequency works well.

Now take a look at si_set_uvd_clocks in si.c. Especially try to figure out if the first or the second call to radeon_uvd_send_upll_ctlreq fails.

Additional to that please install radeontool and get me the content of the CG_UPLL_* registers. E.g. I need the output of:

radeontool regmatch 0x634
radeontool regmatch 0x638
radeontool regmatch 0x63c
radeontool regmatch 0x644
radeontool regmatch 0x648
radeontool regmatch 0x650

Thanks,
Christian.
Comment 25 Chernovsky Oleg 2015-01-31 22:19:01 UTC
(In reply to Christian König from comment #24)
> Now take a look at si_set_uvd_clocks in si.c. Especially try to figure out
> if the first or the second call to radeon_uvd_send_upll_ctlreq fails.
> 
> Additional to that please install radeontool and get me the content of the
> CG_UPLL_* registers. E.g. I need the output of:
> 
> radeontool regmatch 0x634
> radeontool regmatch 0x638
> radeontool regmatch 0x63c
> radeontool regmatch 0x644
> radeontool regmatch 0x648
> radeontool regmatch 0x650
> 
> Thanks,
> Christian.

It's the first call to this function in si_set_uvd_clocks that's failing. Doesn't work in bypass mode? Or maybe too low mdelay before call?

[    2.237380] [drm] At call 1
[    3.278457] [drm] At call 2
[    3.288474] [drm] Passed!

Registers dump:
0x634   0x00000706 (1798)
0x638   0x021e0403 (35521539)
0x63c   0x100ece38 (269405752)
0x644   0x00820000 (8519680)
0x648   0x00000000 (0)
Comment 26 Chernovsky Oleg 2015-01-31 23:33:19 UTC
Ah, forgot the last reg

0x648   0x00000000 (0)

P.S. tried to increase wait delay with no success
Comment 27 Christian König 2015-02-01 10:10:37 UTC
(In reply to Chernovsky Oleg from comment #25)
> It's the first call to this function in si_set_uvd_clocks that's failing.
> Doesn't work in bypass mode? Or maybe too low mdelay before call?
> 
> [    2.237380] [drm] At call 1
> [    3.278457] [drm] At call 2
> [    3.288474] [drm] Passed!

Well just that I got it right: The first call runs into an error, but after issuing the reset and reprogramming everything the second call succeeds?

In this case I would just speculate that somebody (the BIOS?) programmed the PLL with such incorrect values that it locked up and need a reset to work properly again.

Can you just reduce the first call to radeon_uvd_send_upll_ctlreq to a warning and continue? If the second call works we have successfully programmed the PLL and everything is fine.
Comment 28 Chernovsky Oleg 2015-02-01 11:01:06 UTC
(In reply to Christian König from comment #27)
> > 
> > [    2.237380] [drm] At call 1
> > [    3.278457] [drm] At call 2
> > [    3.288474] [drm] Passed!
> 
> Well just that I got it right: The first call runs into an error, but after
> issuing the reset and reprogramming everything the second call succeeds?

Yep, the DRM_INFO was at the "break" line in a loop of radeon_uvd_send_upll_ctlreq.

> 
> In this case I would just speculate that somebody (the BIOS?) programmed the
> PLL with such incorrect values that it locked up and need a reset to work
> properly again.
> 
> Can you just reduce the first call to radeon_uvd_send_upll_ctlreq to a
> warning and continue? If the second call works we have successfully
> programmed the PLL and everything is fine.

But does it differ from previous behaviour when both calls were reduced to return success even on timeout? Could the first call lock PLL somehow?

I'll try again today.
Comment 29 Chernovsky Oleg 2015-02-05 22:36:23 UTC
No luck. Tried various hacks and commenting return values.

Will try mmiotracing these registers from fglrx on weekend
Comment 30 Christian König 2015-02-06 09:19:23 UTC
(In reply to Chernovsky Oleg from comment #29)
> No luck. Tried various hacks and commenting return values.
> 
> Will try mmiotracing these registers from fglrx on weekend

Be careful that to write no irrational values into the PLL registers, e.g. don't use partly radeon partly fglrx settings.

I once over clocked UVD to 4GHz instead of 400MHz by accident and the card is still working, but at least in theory you can damage the hardware with that.
Comment 31 Chernovsky Oleg 2015-02-15 09:37:14 UTC
Tried to launch vdpau-accelerated mpv with fglrx driver and mmiotrace.
Interesting, the CG_UPLL_FUNC_CNTL always has flags 0x100 | 0x600

R 4 456.556542 1 0xf0000634 0x707 0x0 0
W 4 456.556547 1 0xf0000634 0x705 0x0 0
R 4 456.556553 1 0xf0000634 0x705 0x0 0
W 4 456.556576 1 0xf0000634 0x705 0x0 0
R 4 456.556688 1 0xf0000634 0x705 0x0 0
W 4 456.556693 1 0xf0000634 0x705 0x0 0
R 4 456.556709 1 0xf0000634 0x705 0x0 0
R 4 456.556725 1 0xf0000634 0x705 0x0 0
W 4 456.556730 1 0xf0000634 0x705 0x0 0
R 4 456.556771 1 0xf0000634 0x705 0x0 0
W 4 456.556776 1 0xf0000634 0x704 0x0 0
R 4 456.556837 1 0xf0000634 0x704 0x0 0
W 4 456.556842 1 0xf0000634 0x700 0x0 0
W 4 456.556847 1 0xf0000634 0x708 0x0 0

Any ideas what can 0x100 mask be for?
Comment 32 Christian König 2015-02-15 10:12:49 UTC
(In reply to Chernovsky Oleg from comment #31)
> Tried to launch vdpau-accelerated mpv with fglrx driver and mmiotrace.
> Interesting, the CG_UPLL_FUNC_CNTL always has flags 0x100 | 0x600
> 
> R 4 456.556542 1 0xf0000634 0x707 0x0 0
> W 4 456.556547 1 0xf0000634 0x705 0x0 0
> R 4 456.556553 1 0xf0000634 0x705 0x0 0
> W 4 456.556576 1 0xf0000634 0x705 0x0 0
> R 4 456.556688 1 0xf0000634 0x705 0x0 0
> W 4 456.556693 1 0xf0000634 0x705 0x0 0
> R 4 456.556709 1 0xf0000634 0x705 0x0 0
> R 4 456.556725 1 0xf0000634 0x705 0x0 0
> W 4 456.556730 1 0xf0000634 0x705 0x0 0
> R 4 456.556771 1 0xf0000634 0x705 0x0 0
> W 4 456.556776 1 0xf0000634 0x704 0x0 0
> R 4 456.556837 1 0xf0000634 0x704 0x0 0
> W 4 456.556842 1 0xf0000634 0x700 0x0 0
> W 4 456.556847 1 0xf0000634 0x708 0x0 0
> 
> Any ideas what can 0x100 mask be for?

Strange, the hardware docs say this is for routing the reset signal and shouldn't be touched by the driver, e.g. it should always be 1.

Is that bit 0 when you use the open source driver?
Comment 33 Chernovsky Oleg 2015-02-15 11:09:48 UTC
Yep, I rechecked it and it seems set to 1 always...

Anyway I gathered around 18 Mb of mmiotrace logs to investigate. Now digging through divider and clock registers.

P.S. I only fear that maybe I launched mmiotrace too late, I did rmmod and then modprobe fglrx again. Could it setup any registers at the first run? Because at second it touched UVD only when I launched mpv.
Comment 34 Chernovsky Oleg 2015-02-15 11:12:07 UTC
(In reply to Christian König from comment #32)

> Strange, the hardware docs say this is for routing the reset signal and
> shouldn't be touched by the driver, e.g. it should always be 1.

Is this some kind of open hardware docs? Or just internal? Maybe I missed something
Comment 35 Alex Deucher 2015-02-16 17:21:49 UTC
(In reply to Chernovsky Oleg from comment #34)
> 
> Is this some kind of open hardware docs? Or just internal? Maybe I missed
> something

Just internal.

(In reply to Chernovsky Oleg from comment #33)
> P.S. I only fear that maybe I launched mmiotrace too late, I did rmmod and
> then modprobe fglrx again. Could it setup any registers at the first run?
> Because at second it touched UVD only when I launched mpv.

To save power the UVD clocks are only raised when it's actually in use.  I think fglrx does some low level hw init similar to what we do in radeon, but they don't do a ring test so they probably don't change the UVD plls at driver load time only when UVD is in use (although I'm not 100% sure off hand).
Comment 36 Christian König 2015-02-16 17:56:23 UTC
As Alex already noted the detailed register specs are unfortunately only available internally.

We tried to have at least all the bit definitions needed by the driver documented in the header files, but some things are just market as for hardware validation only or debug only etc... and those aren't documented.

(In reply to Chernovsky Oleg from comment #33)
> Yep, I rechecked it and it seems set to 1 always...
> 
> Anyway I gathered around 18 Mb of mmiotrace logs to investigate. Now digging
> through divider and clock registers.

Well it might already help if you provide the values for the UPLL registers together under fglrx, so that we can compare them to the values Radeon uses.

Regards,
Christian.
Comment 37 Chernovsky Oleg 2015-02-16 21:15:37 UTC
Created attachment 113544 [details]
fglrx mmiotrace dump

(In reply to Christian König from comment #36)
> Well it might already help if you provide the values for the UPLL registers
> together under fglrx, so that we can compare them to the values Radeon uses.
> 
> Regards,
> Christian.

Just thought about that.
Here it is, quite near the place where first related register R/W occured.
Comment 38 Chernovsky Oleg 2015-02-18 20:53:35 UTC
I managed to make it work on my machine.

I actually noticed that fglrx code never puts UPLL to sleep like we do.
So I commented out all WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_SLEEP_MASK, ~UPLL_SLEEP_MASK);

After that initialization finishes successfully and I'm able to watch my .mkv's with decent speed.

adonai@Heaven] % mpv --vo=vdpau --hwdec=vdpau Zoku\ Sayonara\ Zetsubou\ Sensei\ -\ 06.mkv           
Playing: Zoku Sayonara Zetsubou Sensei - 06.mkv
 (+) Video --vid=1 (h264)
 (+) Audio --aid=1 --alang=jpn (*) (aac)
     Subs  --sid=1 --slang=eng (*) (ass)
 (+) Subs  --sid=2 'Zoku Sayonara Zetsubou Sensei - 06.ass' (ass) (external)
Trying to use hardware decoding.
AO: [pulse] 48000Hz stereo 2ch float
VO: [vdpau] 1280x720 vdpau
[vo/vdpau] Compositing window manager detected. Assuming timing info is inaccurate.
AV: 00:06:16 / 00:23:59 (26%) A-V:  0.000


Exiting... (Quit)

What kind of further testing can be done from my side?
Comment 39 Christian König 2015-02-19 08:43:52 UTC
Created attachment 113654 [details] [review]
Possible fix

Wow, nice catch!

I have to admit that i just copied the sleep mode handling from previous generations.

Well, in this case please everybody on this bug take a look at the attached patch and see if it does the trick.

Thanks a lot for the help,
Christian.
Comment 40 Alex Deucher 2015-03-10 19:46:39 UTC
(In reply to Christian König from comment #39)
> Created attachment 113654 [details] [review] [review]
> Possible fix
> 
> Wow, nice catch!
> 
> I have to admit that i just copied the sleep mode handling from previous
> generations.
> 
> Well, in this case please everybody on this bug take a look at the attached
> patch and see if it does the trick.
> 
> Thanks a lot for the help,
> Christian.

Do you want me to pick this up for -fixes?
Comment 41 Christian König 2015-03-11 08:29:16 UTC
(In reply to Alex Deucher from comment #40)
> (In reply to Christian König from comment #39)
> > Created attachment 113654 [details] [review] [review] [review]
> > Possible fix
> > 
> > Wow, nice catch!
> > 
> > I have to admit that i just copied the sleep mode handling from previous
> > generations.
> > 
> > Well, in this case please everybody on this bug take a look at the attached
> > patch and see if it does the trick.
> > 
> > Thanks a lot for the help,
> > Christian.
> 
> Do you want me to pick this up for -fixes?

I hoped for some more feedback before we do this, but yeah go ahead.

The patch shouldn't break anything and so should be save for -fixes. Just add the link to this bugreport.

Thanks,
Christian.
Comment 42 equeim 2015-03-22 11:42:42 UTC
This patch fixed my issue of non-working UVD on cold boot. Thanks!


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.