Bug 29221

Positive the effect is also with modeset=0? That implies that it is not KMS related at all, but merely an issue with the backlight.

Probably a dupe, see 29141; hopefully the workarounds there will work for you until we have a real fix.

*** This bug has been marked as a duplicate of bug 29141 ***

(In reply to comment #1)
> Positive the effect is also with modeset=0? That implies that it is not KMS
> related at all, but merely an issue with the backlight.

sorry for being misleading, it's black screen only for KMS enabled.

I wanted to say with i915 being built-in kernel or not, by wrote the wrong thing.

Oh I missed that you can restore things with xrandr, it may not be a dupe after all.  What model of laptop do you have?  Can you attach a register dump from a working configuration?

Created attachment 37326 [details]
intel_reg_dumper from a working state

LVDS1 on 1600x900
HDMI1 on 1920x1080

Created attachment 37333 [details]
intel_reg_dumper from a black screen state

LVDS1: 1600x900 but black screen
HDMI1: not connected

(In reply to comment #6)
> Created an attachment (id=37333) [details]
> intel_reg_dumper from a black screen state
> 
> LVDS1: 1600x900 but black screen
> HDMI1: not connected

The laptop model: Gateway NV79
CPU: Core(TM) i5 CPU       M 430 
Video: 00:02.0 VGA compatible controller: Intel Corporation Arrandale Integrated Graphics Controller (rev 12)

Created attachment 37337 [details]
intel_reg_dumper after the display is recovered using xrandr

it may help to add the intel_reg_dumper from a recovered state from black screen using xrandr

the configuration is essentially the same as the previous black screen, but after running:

xrandr --output LVDS1 --mode 1024x768;xrandr --output LVDS1 --mode 1600x900

the LCD display worked properly thereafter and the intel_reg_dumper was taken

--- before-randr.txt    2010-07-23 09:34:39.898811150 -0700
+++ after-randr.txt     2010-07-23 09:34:32.552873147 -0700
@@ -44,7 +44,7 @@
                       DSPBCNTR: 0xd8004400 (enabled)
                       DSPBBASE: 0x00000000
                     DSPBSTRIDE: 0x00001a00 (104)
-                      DSPBSURF: 0x085af000
+                      DSPBSURF: 0x08bf8000
                    DSPBTILEOFF: 0x00000000 (0, 0)
                       PIPEBSRC: 0x063f0383 (1600, 900)
                  PIPEB_DATA_M1: 0x7e1a1110 (TU 64, val 0x1a1110 1708304)
@@ -148,7 +148,7 @@
                       PCH_DP_C: 0x00000018
                       PCH_DP_D: 0x00000018
               BLC_PWM_CPU_CTL2: 0xa0000000
-               BLC_PWM_CPU_CTL: 0x00000000
+               BLC_PWM_CPU_CTL: 0x000004c2
               BLC_PWM_PCH_CTL1: 0xa0000000
               BLC_PWM_PCH_CTL2: 0x04c204c2
                  PCH_PP_STATUS: 0xc0000008

Between the blank screen and xrandr cases there are two differences.  The first is to be expected since your front buffer was likely re-allocated.  The second however is not, and is also a difference between your first working config and the blank screen.  Looks like the backlight is 0 in the blank case, so I'd expect you to see an unlit screen.

Does "intel_reg_write 0x48254 0x4c2" also bring back your display from the broken case?

(In reply to comment #9)
> --- before-randr.txt    2010-07-23 09:34:39.898811150 -0700
> +++ after-randr.txt     2010-07-23 09:34:32.552873147 -0700

> Does "intel_reg_write 0x48254 0x4c2" also bring back your display from the
> broken case?

yes, "intel_reg_write 0x48254 0x4c2" recovers the LCD backlight.

so, the problem is that BLC_PWM_CPU_CTL not set or set to zero by mistake at booting.

Can you see what this patch reports?  Maybe one of our call paths is setting it to zero somehow.

diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds
index 6bc313a..5fee646 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -62,6 +62,8 @@ static void intel_lvds_set_backlight(struct drm_device *dev, i
        else
                reg = BLC_PWM_CTL;
 
+       WARN_ON(!level);
+
        blc_pwm_ctl = I915_READ(reg) & ~BACKLIGHT_DUTY_CYCLE_MASK;
        I915_WRITE(reg, (blc_pwm_ctl |
                                 (level << BACKLIGHT_DUTY_CYCLE_SHIFT)));
@@ -509,6 +511,8 @@ static void intel_lvds_commit( struct drm_encoder *encoder)
                dev_priv->backlight_duty_cycle =
                        intel_lvds_get_max_backlight(dev);
 
+       WARN_ON(!dev_priv->backlight_duty_cycle);
+
        intel_lvds_set_power(dev, true);
 }

Created attachment 37346 [details]
dmesg after applying the patch Jesse suggested in #11

looks like both WARN_ON() hit zero for,

level and dev_priv->backlight_duty_cycle

not really, only WARN_ON(!level) was hit

BLC_PWM_CPU_CTL is zeroed from many times, but it seems to be some sources other than intel_lvds.c. since the last time reported from intel_lvds.c is nonzero, while intel_reg_dumper still finds BLC_PWM_CPU_CTL=0 after the system is up.

--- a/drivers/gpu/drm/i915/intel_lvds.c	2010-07-25 09:15:03.229471130 -0400
+++ b/drivers/gpu/drm/i915/intel_lvds.c	2010-07-25 21:00:44.160678249 -0400
@@ -65,6 +65,8 @@
 	blc_pwm_ctl = I915_READ(reg) & ~BACKLIGHT_DUTY_CYCLE_MASK;
 	I915_WRITE(reg, (blc_pwm_ctl |
 				 (level << BACKLIGHT_DUTY_CYCLE_SHIFT)));
+printk(KERN_INFO "i915: reading of backlight level = 0x%08x\n", I915_READ(BLC_PWM_CPU_CTL));
+
 }
 
 /**

$ dmesg |grep 'i915: reading'
i915: reading of backlight level = 0x00000000
i915: reading of backlight level = 0x00000000
i915: reading of backlight level = 0x00000000
i915: reading of backlight level = 0x00000000
i915: reading of backlight level = 0x00000000
i915: reading of backlight level = 0x00000000
i915: reading of backlight level = 0x000004c2
i915: reading of backlight level = 0x000004c2
i915: reading of backlight level = 0x000004c2
i915: reading of backlight level = 0x00000000
i915: reading of backlight level = 0x00000000
i915: reading of backlight level = 0x00000000
i915: reading of backlight level = 0x00000000
i915: reading of backlight level = 0x00000000
i915: reading of backlight level = 0x00000000
i915: reading of backlight level = 0x000004c2
i915: reading of backlight level = 0x000004c2
i915: reading of backlight level = 0x000004c2
i915: reading of backlight level = 0x000004c2
i915: reading of backlight level = 0x000004c2
i915: reading of backlight level = 0x000004c2
i915: reading of backlight level = 0x00000000
i915: reading of backlight level = 0x00000000
i915: reading of backlight level = 0x00000000
i915: reading of backlight level = 0x000004c2
i915: reading of backlight level = 0x000004c2
i915: reading of backlight level = 0x000004c2

Created attachment 37402 [details] [review]
patch to recover from black screen by brutal force

I have no idea why BLC_PWM_CPU_CTL got zeroed, but it has to be after intel_lvds.c. Here, I set it to a hardcoded 0x4c2 value in i915_opregion.c and the display is very close to what I expected from a normal system: display works as soon as KMS takes over.

I wish this brutal force solution is not dangerous to my hardware.

Created attachment 37406 [details] [review]
patch to recover from black screen by brutal force

looks like BLC_PWM_CPU_CTL is zeroed by one IRQ event which requests zero backlight by error.

I didn't trace upstream for the IRQ event. This patch simply chooses max backlight when requested 0

better than the previously hardcoded 0x4c2

$ dmesg|grep i915
i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
i915 0000:00:02.0: setting latency timer to 64
i915 0000:00:02.0: irq 26 for MSI/MSI-X
i915:i915_opregion.c asle_set_backlight_ironlake bclp=0x800000ff
i915:i915_opregion.c asle_set_backlight_ironlake bclp=0x80000000
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

Ah good catch, so you're getting a spurious opregion event at suspend time...  Hm I'll grab the latest opregion spec and see if there's anything we need to update.

(In reply to comment #17)
> Ah good catch, so you're getting a spurious opregion event at suspend time... 
> Hm I'll grab the latest opregion spec and see if there's anything we need to
> update.

yes, spurious opregion event after suspend, and I suppose it would be black screen again without this bclp patch.

$ dmesg|grep i915
i915 0000:00:02.0: restoring config space at offset 0x1 (was 0x900007, writing 0x900407)
i915 0000:00:02.0: setting latency timer to 64
i915:i915_opregion.c asle_set_backlight_ironlake bclp=0x80000000

still not fixed in 2.6.36 kernel

Does this still occur using the drm-intel-next branch?

I had an issue with the LVDS on a Lenovo U160 that was resolved with

drm-intel-next commit 633f2ea26665d37bb3c8ae30799aa14988622653
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jan 19 13:29:42 2011 +0000

    drm/i915: Disable SSC for outputs other than LVDS or DP
    
    For CRT and SDVO/HDMI, we need to use a normal, non-SSC, clock and so we
    must clear any enabling bits left-over from earlier outputs. And also
    seems to correct the LVDS panel on the Lenovo U160.
    
    However, at one point, it did cause an "ERROR failed to disable
    trancoder". So prolonged testing on top of Jesse's refactored and
    error-checking CRTC logic is desired.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Assuming this is fixed; please re-open if not.