On Sat, Jul 15, 2017 at 3:23 PM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > On Sat, Jul 15, 2017 at 2:00 PM, Patchwork > <patchwork@xxxxxxxxxxxxxxxxxxxxxx> wrote: >> == Series Details == >> >> Series: RFC: duct-tape for the gpu reset vs. modeset deadlock >> URL : https://patchwork.freedesktop.org/series/27345/ >> State : warning >> >> == Summary == >> >> Series 27345v1 RFC: duct-tape for the gpu reset vs. modeset deadlock >> https://patchwork.freedesktop.org/api/1.0/series/27345/revisions/1/mbox/ >> >> Test drv_hangman: >> Subgroup error-state-basic: >> pass -> DMESG-WARN (fi-blb-e6850) >> pass -> DMESG-WARN (fi-pnv-d510) >> Test gem_busy: >> Subgroup basic-hang-default: >> pass -> DMESG-WARN (fi-blb-e6850) >> pass -> DMESG-WARN (fi-pnv-d510) >> Test gem_exec_fence: >> Subgroup await-hang-default: >> pass -> DMESG-WARN (fi-blb-e6850) >> pass -> DMESG-WARN (fi-pnv-d510) > > Looks like I wreaked something on gpus where the hw reset kills the > display. I'll check it out. Ok, simplest solution seems to be to just not do the special casing between real hw reset and fake reset, and unconditionally shut down all the CRTC. Probably a lot more than just the power domain tracking will get out of whack. I wasn't really sold on that idea either way, so I'll drop both "drm/i915: only disable outputs in simulated gpu resets" and "drm/atomic-helper: add sync_all helper for gpu reset" from the series. They're not needed really anyway. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
