Op 19-08-14 om 15:06 schreef Christian K?nig: > Am 19.08.2014 um 14:22 schrieb Maarten Lankhorst: >> This is needed for the next commit, because the lockup detection >> will need the read lock to run. >> >> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> >> --- >> radeon_pm_compute_clocks already checks if dpm is enabled, so no need to >> check a second time. >> >> Because of locking and waiting stuff the radeon_pm_compute_clocks and >> resume_force_mode calls >> have to be done with read lock held. >> >> Seems to survive on my radeon when catting >> /sys/kernel/debug/dri/0/radeon_gpu_reset although >> uvd fails to reset, and that ring gets disabled as a result. > > Depending on what hardware you have it's normal that UVD doesn't reset > properly. I still haven't figured out the correct sequence in which I need to > disable/enable the different UVD blocks on all hardware generations. > > It seems to work fine on my Cayman, but doesn't for example on Turks (which > at least theoretically should have the same UVD block). It should be fine as > long as the engines gets properly disabled when the IB test fails after an > reset. > > Another common source of reset instability is DPM, while it now seems to be > stable on NI and BTC I can't get a single reset to work once I use it. Ah, in my testing I've hit both (on redwood). :-) But with DPM failures far less frequent than UVD failures, which trigger consistently.
Turks had some issues before, but my laptop completely fails early during boot with 3.17-rc1 so I can't test it. ~Maarten
