| Summary: | [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks! | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | atmouse <at86mouse> | ||||||||||||||||
| Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> | ||||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||||
| Severity: | normal | ||||||||||||||||||
| Priority: | medium | CC: | adonai, at86mouse, ckoenig.leichtzumerken, darwinskernel, lee295012, oyvinds | ||||||||||||||||
| Version: | unspecified | ||||||||||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||||||||||
| OS: | Linux (All) | ||||||||||||||||||
| Whiteboard: | |||||||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
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. Created attachment 96253 [details]
full-dmesg
grep for uvd_send
same problem here. UVD is initialised properly but setting clocks timesout. (In reply to comment #3) > same problem here. UVD is initialised properly but setting clocks timesout. If this is a regression, can you bisect? 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. (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? > 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.
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.
Created attachment 107750 [details]
dmesg
Full dmesg after a cold boot, showing the UVD error.
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. 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. Same on 3.18.0 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
(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. I can help with code here. What should be implemented, roughly? (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. 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. (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 (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. (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. (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! (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? 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
(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. (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) Ah, forgot the last reg 0x648 0x00000000 (0) P.S. tried to increase wait delay with no success (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. (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. No luck. Tried various hacks and commenting return values. Will try mmiotracing these registers from fglrx on weekend (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. 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? (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? 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. (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 (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). 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. 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. 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?
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. (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? (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. 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.
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)