i915 blank issue on kernel 3.1.0
Woody Suwalski
Problem exists on 3.1.0, no problem on 3.0.3
Intel 945GJME 8086:27ac, intel 2.15 x driver, libdrm-intel 2.4.26,
Debian wheezy.
Recently I have noticed that on Asus EeePCs once X screensaver kicks in
- system is hosed. Screen goes black and I can not wake it - even
restarting X does not work, only reboot.
Over ssh I have captured some action from drm.debug=0x0e:
<7>[ 787.953399] [drm:intel_panel_get_backlight], get backlight PWM = 312
<7>[ 787.953421] [drm:intel_panel_set_backlight], set backlight PWM = 0
<7>[ 788.232114] [drm:intel_update_fbc],
<7>[ 788.232125] [drm:i9xx_get_fifo_size], FIFO size - (0x00001d9c) A: 28
<7>[ 788.232134] [drm:intel_calculate_wm], FIFO entries required for
mode: 15
<7>[ 788.232142] [drm:intel_calculate_wm], FIFO watermark level: 11
<7>[ 788.232149] [drm:i9xx_get_fifo_size], FIFO size - (0x00001d9c) B: 31
<7>[ 788.232157] [drm:i9xx_update_wm], FIFO watermarks - A: 11, B: 29
<7>[ 788.232165] [drm:i9xx_update_wm], self-refresh entries: 64
<7>[ 788.232171] [drm:i9xx_update_wm], Setting FIFO watermarks - A: 11,
B: 29, C: 2, SR 63
<7>[ 788.232180] [drm:i9xx_update_wm], memory self refresh enabled
<7>[ 788.232320] [drm:intel_panel_get_backlight], get backlight PWM = 0
<7>[ 788.232393] [drm:intel_panel_set_backlight], set backlight PWM = 0
<7>[ 788.232623] [drm:intel_panel_set_backlight], set backlight PWM = 0
<7>[ 1132.017589] [drm:i9xx_get_fifo_size], FIFO size - (0x00001d9c) A: 28
<7>[ 1132.017614] [drm:intel_calculate_wm], FIFO entries required for
mode: 15
<7>[ 1132.017629] [drm:intel_calculate_wm], FIFO watermark level: 11
<7>[ 1132.017643] [drm:i9xx_get_fifo_size], FIFO size - (0x00001d9c) B: 31
<7>[ 1132.017658] [drm:i9xx_update_wm], FIFO watermarks - A: 11, B: 29
<7>[ 1132.017674] [drm:i9xx_update_wm], self-refresh entries: 64
<7>[ 1132.017687] [drm:i9xx_update_wm], Setting FIFO watermarks - A: 11,
B: 29, C: 2, SR 63
<7>[ 1132.017704] [drm:i9xx_update_wm], memory self refresh enabled
<7>[ 1132.036216] [drm:intel_update_fbc],
<7>[ 1132.036248] [drm:intel_lvds_enable], applying panel-fitter: 8, 0
<7>[ 1132.038081] [drm:intel_panel_set_backlight], set backlight PWM = 312
<7>[ 1132.038299] [drm:intel_panel_set_backlight], set backlight PWM = 0
It looks that the problem is the last line - sets back to 0???
I have tried to write 312 back to /sys/class/backlight/intel-backlight/
bl-power or brightness, and touch uevent - no help.
On 3.0.3 system I see that there is no /sys/../intel-backlight, just eeepc.
And on touching a key it produces
drm:intel_lvds_enable, followed by set backlight PWM=312 (but skips
resetting it back to 0 right after enable).
So:
is there a way to fix "intel_panel" to call lvds_enable logic?
Is there a way to force usage of eeepc backlight instead (as a workaround)?
Thanks, Woody Suwalski
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Keith Packard
> Chris, I do not know if it is i915 driver or X'drm or what..
> Problem exists on 3.1.0, no problem on 3.0.3
Any way you could narrow it down a bit more? A bisect should sort it out
pretty quickly, given that you've got working code in 3.0 and
not-working code in 3.1-rc. You can start by manually bisecting across the
3.1 release candidates, and then narrow it down from there by bisecting
only across the drivers/gpu/drm/i915 directory.
Woody Suwalski
for kernel build on Eeepc...
The problem has appeared in 3.1-rc3, it is a regression.
I have tested -rc1 and -rc2, they are OK ( not that there was much
activity regarding i915 in -rc2). The problem is still present in -rc7.
I see these entries in the changelog, these are Keith's additions to
-rc3 which maight impact the blanker:
Keith Packard (6):
drm/i915: Wait for LVDS panel power sequence
drm/i915: Leave LVDS registers unlocked
drm/i915: Fix PCH port pipe select in CPT disable paths
drm/i915: Remove unused 'reg' argument to dp_pipe_enabled
drm/i915: Can't do accurate vblank timestamps with UMS
drm/i915: Cannot set clock gating under UMS
I can do a fast incremental rebuild of my current -rc3 tree, if Keith could send me some patches...
Thanks, Woody
Alex Davis
I'm having the same problem.
http://marc.info/?l=linux-kernel&m=131695739702141&w=2
Please keep me on the CC list for this thread.
Thanks.
I code, therefore I am
Woody Suwalski
kernel.org downtime is really impacting testing...
Anyway, for Eeepc reverting the
aaa6fd2a004147bf32fce05720938236de3361d9
seems to be fixing the issue. Which is not of course the way we want to go ;-(
Woody
Keith Packard
> Anyway, for Eeepc reverting the
>
> aaa6fd2a004147bf32fce05720938236de3361d9
>
> seems to be fixing the issue. Which is not of course the way we want
> to go ;-(
Matthew - this is your most excellent patch which adds a native
backlight mechanism. What other info do you need to help figure out how
to make it play well on other machines? We've got a handful of
regressions about backligh in the 3.1 RC series, and I'd hate to have to
revert this...
--
keith....@intel.com
Alex Davis
>Matthew - this is your most excellent patch which adds a native
>backlight mechanism. What other info do you need to help figure out how
>to make it play well on other machines? We've got a handful of
>regressions about backligh in the 3.1 RC series, and I'd hate to have to
>revert this...
I'd hate to have it reverted as well. Without this patch, my laptop screen is too bright to
look at comfortably. Fortunately the workarounds make it usable even in its current state.
I code, therefore I am
Alex Davis
>To: "terral...@gmail.com" <terral...@gmail.com>; "linux-...@vger.kernel.org" <linux-...@vger.kernel.org>
>Cc:
>Sent: Sunday, September 25, 2011 9:37 AM
>Subject: Re: Regression: i915 blank issue on kernel 3.1.0-rc3
>I'm having the same problem.
>
>http://marc.info/?l=linux-kernel&m=131695739702141&w=2
>
>Please keep me on the CC list for this thread.
>
>Thanks.
>
>
> I code, therefore I am
diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
index a9e0c7b..6f56676 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -262,8 +262,6 @@ void intel_panel_disable_backlight(struct drm_device *dev)
dev_priv->backlight_level = intel_panel_get_backlight(dev);
dev_priv->backlight_enabled = false;
}
-
- intel_panel_set_backlight(dev, 0);
}
void intel_panel_enable_backlight(struct drm_device *dev)
I've been using it since yesterday morning with no issues.
Keith Packard
> The following patch fixed my backlight issues:
>
> diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
> index a9e0c7b..6f56676 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -262,8 +262,6 @@ void intel_panel_disable_backlight(struct drm_device *dev)
> dev_priv->backlight_level = intel_panel_get_backlight(dev);
> dev_priv->backlight_enabled = false;
> }
> -
> - intel_panel_set_backlight(dev, 0);
> }
>
> void intel_panel_enable_backlight(struct drm_device *dev)
>
> I've been using it since yesterday morning with no issues.
Matthew -- if we cannot resolve this backlight issue, we're going to
need to disable the new backlight code for 3.1. Do you want to try and
fix it? Or should we bail for now?
Alex Davis
>> The following patch fixed my backlight issues:
>>
>> diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
>> index a9e0c7b..6f56676 100644
>> --- a/drivers/gpu/drm/i915/intel_panel.c
>> +++ b/drivers/gpu/drm/i915/intel_panel.c
>> @@ -262,8 +262,6 @@ void intel_panel_disable_backlight(struct drm_device *dev)
>> dev_priv->backlight_level = intel_panel_get_backlight(dev);
>> dev_priv->backlight_enabled = false;
>> }
>> -
>> - intel_panel_set_backlight(dev, 0);
>> }
>>
>> void intel_panel_enable_backlight(struct drm_device *dev)
>>
>> I've been using it since yesterday morning with no issues.
>
>Matthew -- if we cannot resolve this backlight issue, we're going to
>need to disable the new backlight code for 3.1. Do you want to try and
>fix it? Or should we bail for now?
By 'disable', do you mean revert? If so, I would the like chance to submit a patch that adds a boot parameter
for the driver to disable the backlight by default, e.g: i915_disable_bl. Once the issues are sorted, the
parameter could be removed.
Keith Packard
> By 'disable', do you mean revert? If so, I would the like chance to submit a patch that adds a boot parameter
> for the driver to disable the backlight by default, e.g: i915_disable_bl. Once the issues are sorted, the
> parameter could be removed.
then we need to fix the driver so that, with no configuration changes,
your machine continues to work. Preventing regressions is our primary
responsibility when changing the drivers.
Does reverting Matthew's backlight patch fix a regression on your machine?
--
keith....@intel.com
Alex Davis
I code, therefore I am
From: Keith Packard <kei...@keithp.com>
>> By 'disable', do you mean revert? If so, I would the like chance to submit a patch that adds a boot parameter
>> for the driver to disable the backlight by default, e.g: i915_disable_bl. Once the issues are sorted, the
>> parameter could be removed.
>
>If your machine used to work (with 3.0) and does not work with 3.1-rc,
>then we need to fix the driver so that, with no configuration changes,
>your machine continues to work. Preventing regressions is our primary
>responsibility when changing the drivers.
If I added an explanation and a 'Signed-by' line, could someone pick it up?
> Does reverting Matthew's backlight patch fix a regression on your machine?
Keith Packard
> The patch I sent in a previous message in this thread makes it work correctly.
> If I added an explanation and a 'Signed-by' line, could someone pick it up?
use a quirk to make your machine work, but that's something of a
last-resort as it won't fix any other machines.
> Yes, but I have no backlight control: the screen is too bright to look at comfortably.
previous backlight driver (whatever that was). Adding support for the
native backlight driver (Matthew's patch) and disabling the old
backlight mechanisms makes everything better. Right?
--
keith....@intel.com
Alex Davis
>> The patch I sent in a previous message in this thread makes it work correctly.
>> If I added an explanation and a 'Signed-by' line, could someone pick it up?
>
>It would almost certainly break some other machine. We could, of course,
>use a quirk to make your machine work, but that's something of a
>last-resort as it won't fix any other machines.
>> Yes, but I have no backlight control: the screen is too bright to look at comfortably.
This sounds whiny. I'm sorry about that.
>Ok, so the new native backlight driver works, but conflicts with your
>previous backlight driver (whatever that was).
It does not conflict. The previous backlight driver, dell_backlight, is still present
on my machine; it just doesn't work, and never did.
> Adding support for the native backlight driver (Matthew's patch) and disabling the old
>backlight mechanisms makes everything better. Right?
No. The patch is against the native backlight code; it's not necessary to disable
the other backlight.
Alex Davis
I agree that this patch is not suitable for inclusion.