Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933632Ab3CNPQE (ORCPT ); Thu, 14 Mar 2013 11:16:04 -0400 Received: from cantor2.suse.de ([195.135.220.15]:46085 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757805Ab3CNPP6 (ORCPT ); Thu, 14 Mar 2013 11:15:58 -0400 Date: Thu, 14 Mar 2013 16:15:57 +0100 Message-ID: From: Takashi Iwai To: intel-gfx@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Subject: Regression: HSW eDP broken on 3.9-rc[12] User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.2 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2861 Lines: 80 Hi, I noticed that a Haswell desktop machine with eDP gets only the blank screen on the latest Linus tree. It works fine with 3.8, so it's a regression since 3.9-rc1. Actually, it's not a regression. It's three regressions in a shot! (I had to do painful bisections three times...) c464b2a17c59adedbdc02cc54341d630354edc3 drm/i915: set TRANSCODER_EDP even earlier d6dd9eb1d96d2b7345fe4664066c2b7ed86da898 drm/i915: dynamic Haswell display power well support commit cf0a6584aa6d382f802f2c3cacac23ccbccde0cd drm/i915: write backlight harder The first commit affects no matter whether power well is on or off. It brings the eDP output always blank. The next one has to be reverted completely, too. The power well doesn't seem working correctly after all. At this point, you'll get a blank screen only after the boot until X starts, at least. The blank screen on fb after boot is due to the third commit, which is actually my patch. The patch has been never tested on the machines where the original fix was targeted, so this is a clearly a wrong regression fix :-< Judging from increasing number of bug reports, we should revert this one again and fix properly for the Dell laptop. At least, many HP and Lenovo machines suffer from this commit. The details are found at: https://bugzilla.kernel.org/show_bug.cgi?id=47941 Instead of reverting, a patch like below fixes the issue, too, but I guess this will break Dell machine again, if I understand correctly. A good news is that now I have a machine for a while so that I can test any patch for the third, broken backlight, problem. thanks, Takashi --- diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index a3730e0..99ef9a3 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -317,10 +317,13 @@ void intel_panel_enable_backlight(struct drm_device *dev, enum pipe pipe) { struct drm_i915_private *dev_priv = dev->dev_private; + int prev_level; if (dev_priv->backlight_level == 0) dev_priv->backlight_level = intel_panel_get_max_backlight(dev); + prev_level = intel_panel_get_backlight(dev); + dev_priv->backlight_enabled = true; intel_panel_actually_set_backlight(dev, dev_priv->backlight_level); @@ -363,7 +366,7 @@ set_level: * On some machines, BLC_PWM_CPU_CTL is cleared to zero automatically * when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 are written. */ - if (!intel_panel_get_backlight(dev)) + if (!prev_level && dev_priv->backlight_level) intel_panel_actually_set_backlight(dev, dev_priv->backlight_level); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/