From patchwork Tue Dec 18 08:37:54 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 1891311 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by patchwork2.kernel.org (Postfix) with ESMTP id 31DF2DF23A for ; Tue, 18 Dec 2012 10:56:06 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 381E4E620E for ; Tue, 18 Dec 2012 02:56:06 -0800 (PST) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-ea0-f177.google.com (mail-ea0-f177.google.com [209.85.215.177]) by gabe.freedesktop.org (Postfix) with ESMTP id EB75EE5E04 for ; Tue, 18 Dec 2012 00:47:36 -0800 (PST) Received: by mail-ea0-f177.google.com with SMTP id c10so129450eaa.36 for ; Tue, 18 Dec 2012 00:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=x-received:from:to:cc:subject:date:message-id:x-mailer; bh=9yP7q+pzoHsJrpvwdCbOo7iaI+aYtgyaIU/zg6GY8C8=; b=CFgXxgMxE2oMPD163XTqi5HtNvhebemOU4WLa/EjcbT9GARx7Ru9ffg8MO2qbCqbln F5yhTCRKKcRO2adMKeriZAEQXBga0c8809u2XcenyyFoJbVHiOIeiUL0nvT9Kp+zCx4e xydaVBIedqpVTWT0C7QWgYJxpF+IwtGptlZAs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:x-mailer :x-gm-message-state; bh=9yP7q+pzoHsJrpvwdCbOo7iaI+aYtgyaIU/zg6GY8C8=; b=QJn6rpR3jSYSDYHV+1UvCspHTmThkRbB9r2nxZSNfNVoqJIPfo80nuYhA3AB5PCQr3 oLmjbTjxj5bGm7IqV6i3jmbId9hbGJKxbPbkJAanMM6r02M5wWrPWMubKD9vQeBAIuB4 cfvHUbC5j58YRW/vdYNswGTezSxYiFK5mi8NISLTKd2nLiSiYu7qQGdB3RCRhFOQFUSu 35JSZNRnmPJB0Lk5CEDBbDuN88eRLiZMNpFPtvrZn41bTK3RI/vAAHSL2hox0Go5qCqn tj8XSivJyv14j4/Sk2gXqFvrPAdc2HFJyK+KMZ4sueaCrKMF0SNIVQbJVh0cU4vGIJ3t +vXA== X-Received: by 10.14.213.134 with SMTP id a6mr3564691eep.45.1355820455773; Tue, 18 Dec 2012 00:47:35 -0800 (PST) Received: from wespe.ffwll.local (178-83-130-250.dynamic.hispeed.ch. [178.83.130.250]) by mx.google.com with ESMTPS id e2sm1948299eeo.8.2012.12.18.00.47.34 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Dec 2012 00:47:35 -0800 (PST) From: Daniel Vetter To: Intel Graphics Development Date: Tue, 18 Dec 2012 09:37:54 +0100 Message-Id: <1355819874-29163-1-git-send-email-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 1.7.11.7 X-Gm-Message-State: ALoCoQnRLQMASvGs0eTrtPPQUEHGstP7D+R39lMXrKr7svcdheJd20pz6ThHNB3UDIapHyKiHb9x Cc: Daniel Vetter , stable@vger.kernel.org Subject: [Intel-gfx] [PATCH] drm/i915: don't disable disconnected outputs X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: intel-gfx-bounces+patchwork-intel-gfx=patchwork.kernel.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+patchwork-intel-gfx=patchwork.kernel.org@lists.freedesktop.org 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 disconnected a cable and before you reconnect it, userspace (or the kernel) does an set_crtc call, this will result in that connector getting disabled. Which will result in a nice black screen when plugging in the cable again. There's absolutely no reason the kernel does such policy enforcements - 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. Note that this fixes a NULL deref at BIOS takeover when the firmware sets up a disconnected output in a clone configuration with a connected output on the 2nd pipe: When doing the full modeset we don't have a mode for the 2nd pipe and OOPS. On the first pipe this doesn't matter, since at boot-up the fbdev helpers will set up the choosen configuration on that on first. Since this is now the umptenth bug around handling this imo brain-dead semantics correctly, I think it's time to kill it and see whether there's any userspace out there which relies on this. It also nicely demonstrates that we have a tiny window where DP hotplug can still kill the driver. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58396 Cc: stable@vger.kernel.org Tested-by: Peter Ujfalusi Signed-off-by: Daniel Vetter Reviewed-by: Rodrigo Vivi Reviewed-by: Jesse Barnes --- drivers/gpu/drm/i915/intel_display.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 34832bc0..399f862 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7632,10 +7632,6 @@ intel_modeset_stage_output_state(struct drm_device *dev, DRM_DEBUG_KMS("encoder changed, full mode switch\n"); config->mode_changed = true; } - - /* Disable all disconnected encoders. */ - if (connector->base.status == connector_status_disconnected) - connector->new_encoder = NULL; } /* connector->new_encoder is now updated for all connectors. */