linux-kernel - Regression: HSW eDP broken on 3.9-rc[12]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <s5hk3panhaq.wl%tiwai@suse.de>
Date:	Thu, 14 Mar 2013 16:15:57 +0100
From:	Takashi Iwai <tiwai@...e.de>
To:	intel-gfx@...ts.freedesktop.org
Cc:	linux-kernel@...r.kernel.org
Subject: Regression: HSW eDP broken on 3.9-rc[12]

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/