[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=73378

--- Comment #18 from Chernovsky Oleg <adonai at xaker.ru> ---
(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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/53ce7a79/attachment.html>