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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Comment # 18 on bug 73378 from
(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:
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux