Created attachment 37322 [details] Xorg.0.log reproducible: always laptop LCD screen turns black as soon as KMS starts, either with i915.modeset=0/1. screen can be recovered by running xrandr: first set to another mode, then set to the original proper mode. (like: xrandr --output LVDS0 --mode 1024x768;xrandr --output LVDS0 --mode 1600x900) external HDMI monitor works properly with KMS. video card: 00:02.0 VGA compatible controller: Intel Corporation Arrandale Integrated Graphics Controller (rev 12) kernel: Linux gateway 2.6.34-gentoo-r2 #3 SMP Fri Jul 16 16:53:22 EDT 2010 x86_64 Intel(R) Core(TM) i5 CPU M 430 @ 2.27GHz GenuineIntel GNU/Linux xf86-video-intel: 2.12.0 or -git xorg-server: 1.8.1.902
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.