Comment # 6
on bug 66425
from Christian König
(In reply to comment #5) > Pretty sure the instability has nothing to do with this. Good to know, well at least this bug loses a bit priority then. > As far as I can tell, this would happen whenever the system suspend fails > after deactivating the drivers and the PM system restarts everything when > the system hasn't actually suspended. The "pm_test" file just seems to > cause an error return value at an appropriate point in the suspend code. > When the system actually sleeps the uvd suspend code seems fine, but if it > doesn't sleep then there is this delay. Oh! Do I get this right that it only happens when you try to suspend the system but then doesn't really do the power cycle (for whatever reason)? Well that would explain it, cause thise case isn't really supported by the hardware. A complete manual reset of the UVD block (without an external power cycle) is somewhere between very very tricky and impossible. > I'm not sure if this would help in making a work-around. At least it explains the behavior. We could try to get it working by playing around with the different soft reset methods, but I have my doubts that this will ever work correctly.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
