On Thu, 11 Oct 2012 19:46:27 +0200, Daniel Vetter <daniel.vetter at ffwll.ch> wrote: > This piece of neat lore has been ported painstakingly and bug-for-bug > compatible from the old crtc helper code. > > Imo it's utter nonsense. > > If you have disconnect a cable and before you reconnect it, userspace > (or the kernel) does an set_crtc call, this will result in that > connector getting disable. Which will result in a nice black screen > when plugging in the cable again. > > There's absolutely no reason the kernel does such policy changes - if > userspace tries to set up a mode on something disconnected we might > fail loudly (since the dp link training fails), but silently adjusting > the output configuration behind userspace's back is a recipe for > disaster. Specifically I think that this could explain some of our > MI_WAIT hangs around suspend, where userspace issues a scanline wait > on a disable pipe. This mechanisims here could explain how that pipe > got disabled without userspace noticing. Indeed, it might just explain all those funky disables on other crtc after a setcrtc. Won't a side effect of this be that the system continues to power a disconnected output if userspace is asleep and fails to notice the disconnect? -Chris -- Chris Wilson, Intel Open Source Technology Centre
