From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH] drm/i915: don't disable disconnected outputs Date: Fri, 12 Oct 2012 10:02:05 +0100 Message-ID: <453bf0$626hb2@azsmga001.ch.intel.com> References: <1349977587-7534-1-git-send-email-daniel.vetter@ffwll.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by gabe.freedesktop.org (Postfix) with ESMTP id E6527A0DF7 for ; Fri, 12 Oct 2012 02:02:22 -0700 (PDT) In-Reply-To: <1349977587-7534-1-git-send-email-daniel.vetter@ffwll.ch> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Intel Graphics Development Cc: Daniel Vetter List-Id: intel-gfx@lists.freedesktop.org On Thu, 11 Oct 2012 19:46:27 +0200, Daniel Vetter 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