Re: Linux 2.6.37
On Wed, 12 Jan 2011 01:35:49 +0100 (CET), Indan Zupancic in...@nul.nu wrote:
Yeah, the second patch is a bit of a desperate attempt because Larry reported
that
it didn't fix his problem.
About your patch, you still do:
+void intel_panel_setup_backlight(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ dev_priv-backlight_level = intel_panel_get_max_backlight(dev);
+ dev_priv-backlight_enabled = dev_priv-backlight_level != 0;
+}
While my patch changes that to:
+ u32 level;
- if (dev_priv-backlight_level == 0)
- dev_priv-backlight_level = intel_panel_get_max_backlight(dev);
+ if (dev_priv-backlight_level == 0) {
+ level = intel_panel_get_backlight(dev);
+ if (level == 0)
+ level = intel_panel_get_max_backlight(dev);
+ dev_priv-backlight_level = level;
+ }
Your patch uses intel_panel_get_max_backlight() to check if the backlight is
enabled. Is this always correct, or may it cause bugs in the future?
That was a typo, cut'n'pasting the line from above.
Anyway, my main concern with unconditionally setting the backlight level to
the maximum is that any stored brightness level (by the BIOS or whatever) may
be lost, and that the screen is set to maximum brightness at each boot. This
is certainly the behaviour I've seen with an unpatched kernel. So I propose to
do what my patch does and set it to intel_panel_get_backlight(dev) if that
returns non-zero. Something like this:
Sure, s/intel_panel_get_max_backlight/intel_panel_get_backlight/ and we
get the behaviour we both want - preserving the current backlight unless
none is set.
While I'm glad this problem is being fixed upstream, it would be nice to get
some credit for finding the source of the problem.
Sorry. You found the bug but I felt your rationale was off. However, I was
amiss in not giving you the credit you fully deserved.
-Chris
commit 9c1c388a53e5df8819e898106a64e34d0994a5d4
Author: Indan Zupancic in...@nul.nu
Date: Wed Jan 12 11:59:19 2011 +
drm/i915/panel: The backlight is enabled if the current value is non-zero
... and not if the maximum is non-zero. This fixes the typo introduced
in 47356eb6728501452 and preserves the backlight value from boot.
[ickle: My thanks also to Indan Zupancic for diagnosing the original
regression and suggesting the appropriate fix.]
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: sta...@kernel.org # after 47356eb6728501452
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_pan
index e00d200..27c79c7 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -278,6 +278,6 @@ void intel_panel_setup_backlight(struct drm_device
*dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- dev_priv-backlight_level = intel_panel_get_max_backlight(dev);
+ dev_priv-backlight_level = intel_panel_max_backlight(dev);
dev_priv-backlight_enabled = dev_priv-backlight_level != 0;
}
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
On Wed, 12 Jan 2011 12:07:23 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_pan
index e00d200..27c79c7 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -278,6 +278,6 @@ void intel_panel_setup_backlight(struct drm_device
*dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- dev_priv-backlight_level = intel_panel_get_max_backlight(dev);
+ dev_priv-backlight_level = intel_panel_max_backlight(dev);
dev_priv-backlight_enabled = dev_priv-backlight_level != 0;
dev_priv-backlight_level = intel_panel_get_backlight(dev);
-ETIRED
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
On Wed, January 12, 2011 13:07, Chris Wilson wrote: Sure, s/intel_panel_get_max_backlight/intel_panel_get_backlight/ and we get the behaviour we both want - preserving the current backlight unless none is set. Indeed, I hadn't noticed that shortcut. That's a lot nicer than my ifdefery. While I'm glad this problem is being fixed upstream, it would be nice to get some credit for finding the source of the problem. Sorry. You found the bug but I felt your rationale was off. However, I was amiss in not giving you the credit you fully deserved. Thank you very much! The rationale was that intel_panel_set_backlight(0) was somehow called twice, and that the current code unconditionally stored the old backlight, and thus losing the original brightness level. This is exactly what happened. My fix was to prevent backlight_level from being overwritten by zero. Your fix was more structural and properly fixed backlight enabled/disabled state. In the end both have the same effect and solve the bug. Perhaps I was unclear in the bug description. Anyhow, it's a pleasure working with you. I'll try to not bother you too much, you got enough on your plate as it is. I'll leave you alone for a while after you looked into my fix for bug 23472, after that all my Intel graphics are pretty much solved. :-) Take care, Indan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
Hi, On Tue 04-01-11 17:15:45, Linus Torvalds wrote: [...] We did have another revert to fix hopefullythe last blank screen regression on intel graphics. It seems that there is still a regression for intel graphic cards backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672. I can reproduce the problem easily by: xset dpms force standby; sleep 3s; xset dpms force on (You are using vesa or fbcon X11 driver, right? I seen same problem until I switched to intel X11 driver). -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
On Tue 11-01-11 14:33:20, Pavel Machek wrote: Hi, On Tue 04-01-11 17:15:45, Linus Torvalds wrote: [...] We did have another revert to fix hopefullythe last blank screen regression on intel graphics. It seems that there is still a regression for intel graphic cards backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672. I can reproduce the problem easily by: xset dpms force standby; sleep 3s; xset dpms force on (You are using vesa or fbcon X11 driver, right? I seen same problem until I switched to intel X11 driver). I am using intel X11 driver: [...] (II) Loading extension DRI2 (II) LoadModule: intel (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so [...] So this doesn't look like the case. -- Michal Hocko L3 team SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
On Tue, Jan 11, 2011 at 14:33, Pavel Machek pa...@ucw.cz wrote: I can reproduce the problem easily by: xset dpms force standby; sleep 3s; xset dpms force on (You are using vesa or fbcon X11 driver, right? I seen same problem until I switched to intel X11 driver). No, the intel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
[Let's CC Indan - author of the bugzilla patches] On Thu 06-01-11 11:48:16, Michal Hocko wrote: Hi, On Tue 04-01-11 17:15:45, Linus Torvalds wrote: [...] We did have another revert to fix hopefullythe last blank screen regression on intel graphics. It seems that there is still a regression for intel graphic cards backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672. I can reproduce the problem easily by: xset dpms force standby; sleep 3s; xset dpms force on backlight doesn't get up (there is really dark picture though which doesn't get brighter by function keys which work normally) after dpms on until I close and open lid. The problem wasn't present in 2.6.36 I can confirm that this problem is not present if both patches from bko#22672 are applied on top of 2.6.37 kernel. I haven't tried both patches separately, but I can surely try it if it makes any sense. $ lspci -vv [...] 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller]) Subsystem: Fujitsu Limited. Device 137a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at f030 (32-bit, non-prefetchable) [size=512K] Region 1: I/O ports at 1800 [size=8] Region 2: Memory at e000 (32-bit, prefetchable) [size=256M] Region 3: Memory at f040 (32-bit, non-prefetchable) [size=256K] Expansion ROM at unassigned [disabled] Capabilities: access denied Kernel driver in use: i915 [...] -- Michal Hocko L3 team SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
On Tue 11-01-11 18:17:44, Michal Hocko wrote: [Let's CC Indan - author of the bugzilla patches] On Thu 06-01-11 11:48:16, Michal Hocko wrote: Hi, On Tue 04-01-11 17:15:45, Linus Torvalds wrote: [...] We did have another revert to fix hopefullythe last blank screen regression on intel graphics. It seems that there is still a regression for intel graphic cards backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672. I can reproduce the problem easily by: xset dpms force standby; sleep 3s; xset dpms force on backlight doesn't get up (there is really dark picture though which doesn't get brighter by function keys which work normally) after dpms on until I close and open lid. The problem wasn't present in 2.6.36 I can confirm that this problem is not present if both patches from bko#22672 are applied on top of 2.6.37 kernel. I haven't tried both patches separately, but I can surely try it if it makes any sense. I have just tried that and they are really both necessary. -- Michal Hocko L3 team SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
On Tue, 11 Jan 2011 18:19:17 +0100, Michal Hocko mho...@suse.cz wrote: [Let's CC Indan - author of the bugzilla patches] On Thu 06-01-11 11:48:16, Michal Hocko wrote: Hi, On Tue 04-01-11 17:15:45, Linus Torvalds wrote: [...] We did have another revert to fix hopefullythe last blank screen regression on intel graphics. It seems that there is still a regression for intel graphic cards backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672. I can reproduce the problem easily by: xset dpms force standby; sleep 3s; xset dpms force on backlight doesn't get up (there is really dark picture though which doesn't get brighter by function keys which work normally) after dpms on until I close and open lid. The problem wasn't present in 2.6.36 I can confirm that this problem is not present if both patches from bko#22672 are applied on top of 2.6.37 kernel. I haven't tried both patches separately, but I can surely try it if it makes any sense. The second patch is wrong in that it will prevent changing resolutions using the panel fitter. The first patch looks along the right lines, just misses the possibility that the backlight can be modified by other means. So hopefully, you just need the first patch. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
On Tue 11-01-11 17:39:42, Chris Wilson wrote: On Tue, 11 Jan 2011 18:19:17 +0100, Michal Hocko mho...@suse.cz wrote: [Let's CC Indan - author of the bugzilla patches] On Thu 06-01-11 11:48:16, Michal Hocko wrote: Hi, On Tue 04-01-11 17:15:45, Linus Torvalds wrote: [...] We did have another revert to fix hopefullythe last blank screen regression on intel graphics. It seems that there is still a regression for intel graphic cards backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672. I can reproduce the problem easily by: xset dpms force standby; sleep 3s; xset dpms force on backlight doesn't get up (there is really dark picture though which doesn't get brighter by function keys which work normally) after dpms on until I close and open lid. The problem wasn't present in 2.6.36 I can confirm that this problem is not present if both patches from bko#22672 are applied on top of 2.6.37 kernel. I haven't tried both patches separately, but I can surely try it if it makes any sense. The second patch is wrong in that it will prevent changing resolutions using the panel fitter. The first patch looks along the right lines, just misses the possibility that the backlight can be modified by other means. So hopefully, you just need the first patch. I would have bet I have tested the 1st patch but let me double check. The 2nd patch alone doesn't fix the problem. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- Michal Hocko L3 team SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
On Tue 11-01-11 18:37:41, Michal Hocko wrote: On Tue 11-01-11 18:17:44, Michal Hocko wrote: [Let's CC Indan - author of the bugzilla patches] On Thu 06-01-11 11:48:16, Michal Hocko wrote: Hi, On Tue 04-01-11 17:15:45, Linus Torvalds wrote: [...] We did have another revert to fix hopefullythe last blank screen regression on intel graphics. It seems that there is still a regression for intel graphic cards backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672. I can reproduce the problem easily by: xset dpms force standby; sleep 3s; xset dpms force on backlight doesn't get up (there is really dark picture though which doesn't get brighter by function keys which work normally) after dpms on until I close and open lid. The problem wasn't present in 2.6.36 I can confirm that this problem is not present if both patches from bko#22672 are applied on top of 2.6.37 kernel. I haven't tried both patches separately, but I can surely try it if it makes any sense. I have just tried that and they are really both necessary. I must have mixed something. After retesting with the first patch (https://bugzilla.kernel.org/show_bug.cgi?id=22672#c33) the usecase works just fine (backlight is on without need to closeopen the lid) Sorry for confusion -- Michal Hocko L3 team SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
Hello,
On Tue, January 11, 2011 18:39, Chris Wilson wrote:
On Tue, 11 Jan 2011 18:19:17 +0100, Michal Hocko mho...@suse.cz wrote:
[Let's CC Indan - author of the bugzilla patches]
On Thu 06-01-11 11:48:16, Michal Hocko wrote:
Hi,
On Tue 04-01-11 17:15:45, Linus Torvalds wrote:
[...]
We did have another revert to fix hopefullythe last blank screen
regression on intel graphics.
It seems that there is still a regression for intel graphic cards
backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672.
I can reproduce the problem easily by:
xset dpms force standby; sleep 3s; xset dpms force on
backlight doesn't get up (there is really dark picture though which
doesn't get brighter by function keys which work normally) after dpms on
until I close and open lid.
The problem wasn't present in 2.6.36
I can confirm that this problem is not present if both patches from
bko#22672 are applied on top of 2.6.37 kernel.
I haven't tried both patches separately, but I can surely try it if it
makes any sense.
The second patch is wrong in that it will prevent changing resolutions
using the panel fitter.
I can confirm that with the second patch changing resolutions doesn't always go
right.
$ xrandr
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2048 x 2048
LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x
0mm
1024x768 50.0*+ 85.0 75.0 70.1 60.0
832x62474.6
800x60085.1 72.2 75.0 60.3 56.2
640x48085.0 72.8 75.0 59.9
720x40085.0
640x40085.1
640x35085.1
VGA1 disconnected (normal left inverted right x axis y axis)
Going from xrandr -s 1, 2 or 3 back to 0 works, but not from 4, 5 or 6 to 0.
The second patch was really a stab in the dark, I'm happy it was in the right
direction at least.
The first patch looks along the right lines, just
misses the possibility that the backlight can be modified by other means.
I'm not sure about that. All it does is avoiding setting backlight_level to
0. If it's modified some other way and intel_panel_get_backlight() returns 0,
backlight_level is just never set and will stay zero. If there is a way to
switch between ways to modify the backlight then I can see how this may not
always work, because then backlight_level is stuck on the last non-zero value
before it was switched to intel_panel_set_backlight(0) and the different method.
Alex reported a slightly dimmer display after resume, so I wonder what I missed
in my patch. Larry's problem was probably fixed with just the first patch, but
then I wonder why he reported that it didn't work first. Maybe he meant the
setpci thing, or made a mistake.
So hopefully, you just need the first patch.
-Chris
Yeah, the second patch is a bit of a desperate attempt because Larry reported
that
it didn't fix his problem.
About your patch, you still do:
+void intel_panel_setup_backlight(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ dev_priv-backlight_level = intel_panel_get_max_backlight(dev);
+ dev_priv-backlight_enabled = dev_priv-backlight_level != 0;
+}
While my patch changes that to:
+ u32 level;
- if (dev_priv-backlight_level == 0)
- dev_priv-backlight_level = intel_panel_get_max_backlight(dev);
+ if (dev_priv-backlight_level == 0) {
+ level = intel_panel_get_backlight(dev);
+ if (level == 0)
+ level = intel_panel_get_max_backlight(dev);
+ dev_priv-backlight_level = level;
+ }
Your patch uses intel_panel_get_max_backlight() to check if the backlight is
enabled. Is this always correct, or may it cause bugs in the future?
Anyway, my main concern with unconditionally setting the backlight level to
the maximum is that any stored brightness level (by the BIOS or whatever) may
be lost, and that the screen is set to maximum brightness at each boot. This
is certainly the behaviour I've seen with an unpatched kernel. So I propose to
do what my patch does and set it to intel_panel_get_backlight(dev) if that
returns non-zero. Something like this:
+void intel_panel_setup_backlight(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 max, level;
+
+ max = intel_panel_get_max_backlight(dev);
+ if (max) {
+ dev_priv-backlight_enabled = 1;
+ level = intel_panel_get_backlight(dev);
+ if (!level)
+ level = max;
+ dev_priv-backlight_level = level;
+ }
+}
While I'm glad this problem is being fixed upstream, it would be nice to get
some credit for finding the source of the problem.
Greetings,
Indan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Re: Linux 2.6.37
On Thu, 06 Jan 2011 11:50:02 +0100, Michal Hocko wrote: Hi, On Tue 04-01-11 17:15:45, Linus Torvalds wrote: [...] We did have another revert to fix hopefullythe last blank screen regression on intel graphics. It seems that there is still a regression for intel graphic cards backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672. I can reproduce the problem easily by: xset dpms force standby; sleep 3s; xset dpms force on backlight doesn't get up (there is really dark picture though which doesn't get brighter by function keys which work normally) after dpms on until I close and open lid. The problem wasn't present in 2.6.36 And I have a different regression. On 2.6.36.2 everything is fine, on 2.6.37 my laptop's display is more or less blank, backlight on, with a white pattern slowly moving across the screen like it was a (bad) moving spot light effect. dmesg output and .configs at https://bugs.freedesktop.org/show_bug.cgi?id=32903 Zephaniah E. Loss-Cutler-Hull. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
On Thu 06-01-11 22:08:46, Alex Riesen wrote:
On Thu, Jan 6, 2011 at 21:55, Alex Riesen raa.l...@gmail.com wrote:
On Thu, Jan 6, 2011 at 18:49, Chris Wilson ch...@chris-wilson.co.uk wrote:
My fear is that some machines have a dependency between the backlight
and panel power status. The patch in question changed the timing between
turning on the panel and adjusting the backlight which would be restore
with:
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index aa23070..0b40b4f 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -106,6 +106,12 @@ static void intel_lvds_enable(struct intel_lvds
*intel_lvds)
?? ?? ?? ??I915_WRITE(ctl_reg, I915_READ(ctl_reg) | POWER_TARGET_ON);
?? ?? ?? ??POSTING_READ(lvds_reg);
+ ?? ?? ?? {
+ ?? ?? ?? ?? ?? ?? ?? u32 reg = HAS_PCH_SPLIT(dev) ? PCH_PP_STATUS :
PPS_STATUS;
...
FWIW it does not compile:
??CC ?? ?? ??drivers/gpu/drm/i915/intel_lvds.o
drivers/gpu/drm/i915/intel_lvds.c: In function ???intel_lvds_enable???:
drivers/gpu/drm/i915/intel_lvds.c:110: error: ???PPS_STATUS??? undeclared
Ah, I see. Should be PP_STATUS. Whatever. It does not help. The backlight
stays off.
It didn't help in my case either
--
Michal Hocko
L3 team
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
On Thu, Jan 6, 2011 at 2:48 AM, Michal Hocko mho...@suse.cz wrote: It seems that there is still a regression for intel graphic cards backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672. I can reproduce the problem easily by: xset dpms force standby; sleep 3s; xset dpms force on backlight doesn't get up (there is really dark picture though which doesn't get brighter by function keys which work normally) after dpms on until I close and open lid. Hmm. That commit no longer reverts cleanly, so it's not trivial to test whether all those things are exactly the same issue. It's been bisected in the bugzilla entry, but it would be good to verify that yes, reverting it really does fix the issue, and your issue is the exact same one. Chris, any ideas? Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
Hi, On Tue 04-01-11 17:15:45, Linus Torvalds wrote: [...] We did have another revert to fix hopefullythe last blank screen regression on intel graphics. It seems that there is still a regression for intel graphic cards backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672. I can reproduce the problem easily by: xset dpms force standby; sleep 3s; xset dpms force on backlight doesn't get up (there is really dark picture though which doesn't get brighter by function keys which work normally) after dpms on until I close and open lid. The problem wasn't present in 2.6.36 $ lspci -vv [...] 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller]) Subsystem: Fujitsu Limited. Device 137a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at f030 (32-bit, non-prefetchable) [size=512K] Region 1: I/O ports at 1800 [size=8] Region 2: Memory at e000 (32-bit, prefetchable) [size=256M] Region 3: Memory at f040 (32-bit, non-prefetchable) [size=256K] Expansion ROM at unassigned [disabled] Capabilities: access denied Kernel driver in use: i915 [...] -- Michal Hocko L3 team SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
Just for reference, my initial report was: https://lkml.org/lkml/2010/11/23/146 On Thu 06-01-11 08:29:22, Linus Torvalds wrote: On Thu, Jan 6, 2011 at 2:48 AM, Michal Hocko mho...@suse.cz wrote: It seems that there is still a regression for intel graphic cards backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672. I can reproduce the problem easily by: xset dpms force standby; sleep 3s; xset dpms force on backlight doesn't get up (there is really dark picture though which doesn't get brighter by function keys which work normally) after dpms on until I close and open lid. Hmm. That commit no longer reverts cleanly, so it's not trivial to test whether all those things are exactly the same issue. It's been bisected in the bugzilla entry, but it would be good to verify that yes, reverting it really does fix the issue, and your issue is the exact same one. Chris, any ideas? Linus -- Michal Hocko L3 team SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
On Thu, 6 Jan 2011 08:29:22 -0800, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, Jan 6, 2011 at 2:48 AM, Michal Hocko mho...@suse.cz wrote:
It seems that there is still a regression for intel graphic cards
backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672.
I can reproduce the problem easily by:
xset dpms force standby; sleep 3s; xset dpms force on
backlight doesn't get up (there is really dark picture though which
doesn't get brighter by function keys which work normally) after dpms on
until I close and open lid.
Hmm. That commit no longer reverts cleanly, so it's not trivial to
test whether all those things are exactly the same issue. It's been
bisected in the bugzilla entry, but it would be good to verify that
yes, reverting it really does fix the issue, and your issue is the
exact same one.
Chris, any ideas?
My fear is that some machines have a dependency between the backlight
and panel power status. The patch in question changed the timing between
turning on the panel and adjusting the backlight which would be restore
with:
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index aa23070..0b40b4f 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -106,6 +106,12 @@ static void intel_lvds_enable(struct intel_lvds
*intel_lvds)
I915_WRITE(ctl_reg, I915_READ(ctl_reg) | POWER_TARGET_ON);
POSTING_READ(lvds_reg);
+ {
+ u32 reg = HAS_PCH_SPLIT(dev) ? PCH_PP_STATUS : PPS_STATUS;
+ if (wait_for(I915_READ(reg) PP_ON, 1000))
+ DRM_ERROR(timed out waiting for panel to power up\n);
+ }
+
intel_panel_set_backlight(dev, dev_priv-backlight_level);
}
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
On Thu, Jan 6, 2011 at 18:49, Chris Wilson ch...@chris-wilson.co.uk wrote:
My fear is that some machines have a dependency between the backlight
and panel power status. The patch in question changed the timing between
turning on the panel and adjusting the backlight which would be restore
with:
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index aa23070..0b40b4f 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -106,6 +106,12 @@ static void intel_lvds_enable(struct intel_lvds
*intel_lvds)
I915_WRITE(ctl_reg, I915_READ(ctl_reg) | POWER_TARGET_ON);
POSTING_READ(lvds_reg);
+ {
+ u32 reg = HAS_PCH_SPLIT(dev) ? PCH_PP_STATUS : PPS_STATUS;
+ if (wait_for(I915_READ(reg) PP_ON, 1000))
+ DRM_ERROR(timed out waiting for panel to power
up\n);
+ }
+
intel_panel_set_backlight(dev, dev_priv-backlight_level);
}
FWIW it does not compile:
CC drivers/gpu/drm/i915/intel_lvds.o
drivers/gpu/drm/i915/intel_lvds.c: In function ‘intel_lvds_enable’:
drivers/gpu/drm/i915/intel_lvds.c:110: error: ‘PPS_STATUS’ undeclared
(first use in this function)
drivers/gpu/drm/i915/intel_lvds.c:110: error: (Each undeclared
identifier is reported only once
drivers/gpu/drm/i915/intel_lvds.c:110: error: for each function it appears in.)
make[4]: *** [drivers/gpu/drm/i915/intel_lvds.o] Error 1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
On Thu, 6 Jan 2011 21:55:23 +0100, Alex Riesen raa.l...@gmail.com wrote:
On Thu, Jan 6, 2011 at 18:49, Chris Wilson ch...@chris-wilson.co.uk wrote:
My fear is that some machines have a dependency between the backlight
and panel power status. The patch in question changed the timing between
turning on the panel and adjusting the backlight which would be restore
with:
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index aa23070..0b40b4f 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -106,6 +106,12 @@ static void intel_lvds_enable(struct intel_lvds
*intel_lvds)
    I915_WRITE(ctl_reg, I915_READ(ctl_reg) | POWER_TARGET_ON);
    POSTING_READ(lvds_reg);
+ Â Â Â {
+ Â Â Â Â Â Â Â u32 reg = HAS_PCH_SPLIT(dev) ? PCH_PP_STATUS :
PPS_STATUS;
+ Â Â Â Â Â Â Â if (wait_for(I915_READ(reg) PP_ON, 1000))
+ Â Â Â Â Â Â Â Â Â Â Â DRM_ERROR(timed out waiting for panel
to power up\n);
+ Â Â Â }
+
    intel_panel_set_backlight(dev, dev_priv-backlight_level);
 }
FWIW it does not compile:
CC drivers/gpu/drm/i915/intel_lvds.o
drivers/gpu/drm/i915/intel_lvds.c: In function âintel_lvds_enableâ:
drivers/gpu/drm/i915/intel_lvds.c:110: error: âPPS_STATUSâ undeclared
(first use in this function)
drivers/gpu/drm/i915/intel_lvds.c:110: error: (Each undeclared
identifier is reported only once
drivers/gpu/drm/i915/intel_lvds.c:110: error: for each function it appears
in.)
make[4]: *** [drivers/gpu/drm/i915/intel_lvds.o] Error 1
Daniel quickly pointed out my typo: s/PPS_STATUS/PP_STATUS/
Apologies,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37
On Thu, Jan 6, 2011 at 21:55, Alex Riesen raa.l...@gmail.com wrote:
On Thu, Jan 6, 2011 at 18:49, Chris Wilson ch...@chris-wilson.co.uk wrote:
My fear is that some machines have a dependency between the backlight
and panel power status. The patch in question changed the timing between
turning on the panel and adjusting the backlight which would be restore
with:
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index aa23070..0b40b4f 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -106,6 +106,12 @@ static void intel_lvds_enable(struct intel_lvds
*intel_lvds)
I915_WRITE(ctl_reg, I915_READ(ctl_reg) | POWER_TARGET_ON);
POSTING_READ(lvds_reg);
+ {
+ u32 reg = HAS_PCH_SPLIT(dev) ? PCH_PP_STATUS : PPS_STATUS;
...
FWIW it does not compile:
CC drivers/gpu/drm/i915/intel_lvds.o
drivers/gpu/drm/i915/intel_lvds.c: In function ‘intel_lvds_enable’:
drivers/gpu/drm/i915/intel_lvds.c:110: error: ‘PPS_STATUS’ undeclared
Ah, I see. Should be PP_STATUS. Whatever. It does not help. The backlight
stays off.
P.S. Probably unrelated, but I just noticed that the backlight never goes
off when closing the lid. Am I supposed to hook up on the corresponding
input event and put the panel in standby? It used to work all by itself,
I think...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc8 (no fb)
On Thu, 30 Dec 2010 10:49:33 +0800 (SGT)
Jeff Chua jeff.chua.li...@gmail.com wrote:
On Thu, Dec 30, 2010 at 4:16 AM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Randy, Jeff and Alex, does the below help at all? If so, it may be the
minimal fix we want for 2.6.37.
Jesse,
Yes, that worked for me. I improved on the patch a bit below.
Thanks,
Jeff
--- a/drivers/gpu/drm/i915/intel_bios.c 2010-12-29 13:35:57.0
+0800
+++ a/drivers/gpu/drm/i915/intel_bios.c 2010-12-30 10:18:39.0
+0800
@@ -262,7 +262,10 @@
if (general) {
dev_priv-int_tv_support = general-int_tv_support;
dev_priv-int_crt_support = general-int_crt_support;
- dev_priv-lvds_use_ssc = general-enable_ssc;
+
+ /* force disable until we can parse this correctly */
+ dev_priv-lvds_use_ssc = (IS_GEN5(dev) || IS_GEN6(dev)) ?
+ 0 : general-enable_ssc;
For some expressions, the ternary operator is more compact readable.
For others (like this one imo) it doesn't really add anything, so I
prefer the if statement. In this case I think the if statement is more
readable since it communicates that we're overriding the default value
on certain generations (i.e. it's a standalone clause).
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc8 (no fb)
On Wed, 29 Dec 2010 11:40:04 -0800, Linus Torvalds torva...@linux-foundation.org wrote: On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap randy.dun...@oracle.com wrote: The only significant difference that I can see in the kernel message log is this: Hmm. I suspect that difference should have gone away with commit 92971021c6328 (Revert drm: Don't try and disable an encoder that was never enabled), but clearly that didn't fix your blank screen. Does reverting commit 448f53a1ede54eb854d036abf54573281412d650 (drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks) fix it for you? It does for some people.. Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can we please just disable spread-spectrum entirely? Or perhaps only if we notice that it was enabled already? Or something? It appeared to be the easiest fix for the machines I had to hand and was confirmed by several people with identical machines. However, it definitely caused a regression for working panels and therefore it will be reverted. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc8 (no fb)
On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap randy.dun...@oracle.com wrote: The only significant difference that I can see in the kernel message log is this: Hmm. I suspect that difference should have gone away with commit 92971021c6328 (Revert drm: Don't try and disable an encoder that was never enabled), but clearly that didn't fix your blank screen. Does reverting commit 448f53a1ede54eb854d036abf54573281412d650 (drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks) fix it for you? It does for some people.. Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can we please just disable spread-spectrum entirely? Or perhaps only if we notice that it was enabled already? Or something? Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc8 (no fb)
On Wed, 29 Dec 2010 11:40:04 -0800
Linus Torvalds torva...@linux-foundation.org wrote:
On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap randy.dun...@oracle.com
wrote:
The only significant difference that I can see in the kernel message log
is this:
Hmm. I suspect that difference should have gone away with commit
92971021c6328 (Revert drm: Don't try and disable an encoder that was
never enabled), but clearly that didn't fix your blank screen.
Does reverting commit 448f53a1ede54eb854d036abf54573281412d650
(drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks) fix it for
you? It does for some people..
Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can
we please just disable spread-spectrum entirely? Or perhaps only if we
notice that it was enabled already? Or something?
Randy, Jeff and Alex, does the below help at all? If so, it may be the
minimal fix we want for 2.6.37.
diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios
index 2b20786..d27d016 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private *dev_priv,
dev_priv-int_tv_support = general-int_tv_support;
dev_priv-int_crt_support = general-int_crt_support;
dev_priv-lvds_use_ssc = general-enable_ssc;
+ /* force disable until we can parse this correctly */
+ if (IS_GEN5(dev) || IS_GEN6(dev))
+ dev_priv-lvds_use_ssc = 0;
if (dev_priv-lvds_use_ssc) {
if (IS_I85X(dev))
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc8 (no fb)
Le 29/12/10 21:16, Jesse Barnes a écrit :
On Wed, 29 Dec 2010 11:40:04 -0800
Linus Torvalds torva...@linux-foundation.org wrote:
On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap randy.dun...@oracle.com
wrote:
The only significant difference that I can see in the kernel message log
is this:
Hmm. I suspect that difference should have gone away with commit
92971021c6328 (Revert drm: Don't try and disable an encoder that was
never enabled), but clearly that didn't fix your blank screen.
Does reverting commit 448f53a1ede54eb854d036abf54573281412d650
(drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks) fix it for
you? It does for some people..
Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can
we please just disable spread-spectrum entirely? Or perhaps only if we
notice that it was enabled already? Or something?
Randy, Jeff and Alex, does the below help at all? If so, it may be the
minimal fix we want for 2.6.37.
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios
index 2b20786..d27d016 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private *dev_priv,
dev_priv-int_tv_support = general-int_tv_support;
dev_priv-int_crt_support = general-int_crt_support;
dev_priv-lvds_use_ssc = general-enable_ssc;
+ /* force disable until we can parse this correctly */
+ if (IS_GEN5(dev) || IS_GEN6(dev))
+ dev_priv-lvds_use_ssc = 0;
if (dev_priv-lvds_use_ssc) {
if (IS_I85X(dev))
I also encountered the black screen problem after commit 448f53a1. I can
confirm that the above patch solves the problem.
François Valenduc
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc8 (no fb)
On Wed, Dec 29, 2010 at 21:16, Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 29 Dec 2010 11:40:04 -0800 Linus Torvalds torva...@linux-foundation.org wrote: Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can we please just disable spread-spectrum entirely? Or perhaps only if we notice that it was enabled already? Or something? Randy, Jeff and Alex, does the below help at all? If so, it may be the minimal fix we want for 2.6.37. Something broke your patch: whitespace instead of tabs. diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios index 2b20786..d27d016 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private *dev_priv, dev_priv-int_tv_support = general-int_tv_support; dev_priv-int_crt_support = general-int_crt_support; dev_priv-lvds_use_ssc = general-enable_ssc; + /* force disable until we can parse this correctly */ This comment seems to imply that SSC wasn't used at all until recently, right? + if (IS_GEN5(dev) || IS_GEN6(dev)) + dev_priv-lvds_use_ssc = 0; Doesn't change anything here. Display stays blank. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc8 (no fb)
Doesn't change anything here. Display stays blank.
Sounds like your problem is separate from SSC then, more likely related
to panel power or backlight control. Have you tried bisecting for the
problem between 2.6.35 and 2.6.36?
Nevermind, I just checked out the bug, looks like it is panel power
related. Can you try this patch?
If it doesn't work, can you send me the output of intel_reg_dumper from
before you turn off the display and after you try to turn it back on?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index aa23070..830e3b0 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -82,8 +82,6 @@ static void intel_lvds_enable(struct intel_lvds *intel_lvds)
lvds_reg = LVDS;
}
- I915_WRITE(lvds_reg, I915_READ(lvds_reg) | LVDS_PORT_EN);
-
if (intel_lvds-pfit_dirty) {
/*
* Enable automatic panel scaling so that non-native modes
@@ -104,7 +102,7 @@ static void intel_lvds_enable(struct intel_lvds *intel_lvds)
}
I915_WRITE(ctl_reg, I915_READ(ctl_reg) | POWER_TARGET_ON);
- POSTING_READ(lvds_reg);
+ POSTING_READ(ctl_reg);
intel_panel_set_backlight(dev, dev_priv-backlight_level);
}
@@ -136,8 +134,7 @@ static void intel_lvds_disable(struct intel_lvds
*intel_lvds)
intel_lvds-pfit_dirty = true;
}
- I915_WRITE(lvds_reg, I915_READ(lvds_reg) ~LVDS_PORT_EN);
- POSTING_READ(lvds_reg);
+ POSTING_READ(ctl_reg);
}
static void intel_lvds_dpms(struct drm_encoder *encoder, int mode)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc8 (no fb)
On Wed, Dec 29, 2010 at 22:18, Jesse Barnes jbar...@virtuousgeek.org wrote: + if (IS_GEN5(dev) || IS_GEN6(dev)) + dev_priv-lvds_use_ssc = 0; Doesn't change anything here. Display stays blank. Sounds like your problem is separate from SSC then, more likely related to panel power or backlight control. Have you tried bisecting for the problem between 2.6.35 and 2.6.36? No. I assumed the bisection in the bug https://bugzilla.kernel.org/show_bug.cgi?id=22672 was for the same problem as mine. It probably is not... I'm running a bisect right now. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc8 (no fb)
On Wed, 29 Dec 2010 12:16:01 -0800 Jesse Barnes wrote:
On Wed, 29 Dec 2010 11:40:04 -0800
Linus Torvalds torva...@linux-foundation.org wrote:
On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap randy.dun...@oracle.com
wrote:
The only significant difference that I can see in the kernel message log
is this:
Hmm. I suspect that difference should have gone away with commit
92971021c6328 (Revert drm: Don't try and disable an encoder that was
never enabled), but clearly that didn't fix your blank screen.
Does reverting commit 448f53a1ede54eb854d036abf54573281412d650
(drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks) fix it for
you? It does for some people..
Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can
we please just disable spread-spectrum entirely? Or perhaps only if we
notice that it was enabled already? Or something?
Randy, Jeff and Alex, does the below help at all? If so, it may be the
minimal fix we want for 2.6.37.
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios
index 2b20786..d27d016 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private *dev_priv,
dev_priv-int_tv_support = general-int_tv_support;
dev_priv-int_crt_support = general-int_crt_support;
dev_priv-lvds_use_ssc = general-enable_ssc;
+ /* force disable until we can parse this correctly */
+ if (IS_GEN5(dev) || IS_GEN6(dev))
+ dev_priv-lvds_use_ssc = 0;
if (dev_priv-lvds_use_ssc) {
if (IS_I85X(dev))
--
Ugh, looks like I have confused things horribly. Sorry about this.
2.6.37-rc8 with no patches works for me. My original report was incorrect --
I was using -rc7 when I thought I was using -rc8. :(
Regrets,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
desserts: http://www.xenotime.net/linux/recipes/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc8 (no fb)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios
index 2b20786..d27d016 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private
*dev_priv,
dev_priv-int_tv_support = general-int_tv_support;
dev_priv-int_crt_support = general-int_crt_support;
dev_priv-lvds_use_ssc = general-enable_ssc;
+ /* force disable until we can parse this correctly */
+ if (IS_GEN5(dev) || IS_GEN6(dev))
+ dev_priv-lvds_use_ssc = 0;
if (dev_priv-lvds_use_ssc) {
if (IS_I85X(dev))
--
Ugh, looks like I have confused things horribly. Sorry about this.
2.6.37-rc8 with no patches works for me. My original report was incorrect --
I was using -rc7 when I thought I was using -rc8. :(
Can you confirm that the above doesn't break your setup just in case we
need to apply it?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc8 (no fb)
On Wed, Dec 29, 2010 at 22:53, Jesse Barnes jbar...@virtuousgeek.org wrote: Doesn't change anything here. Display stays blank. Sounds like your problem is separate from SSC then, more likely related to panel power or backlight control. Have you tried bisecting for the problem between 2.6.35 and 2.6.36? Nevermind, I just checked out the bug, looks like it is panel power related. Can you try this patch? Tried. Does not work. If it doesn't work, can you send me the output of intel_reg_dumper from before you turn off the display and after you try to turn it back on? See the links below (sorry, they files are a bit large): Before running xset dpms force standby: http://vin-soft.org/~raa/public/test/intel_gpu_dump-before After running sleep 3 http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-suspend After running xset dpms force on http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-xset-on After closing and opening the lid (displays backlight is back) http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc8 (no fb)
On Thu, 30 Dec 2010 00:09:56 +0100 Alex Riesen raa.l...@gmail.com wrote: On Wed, Dec 29, 2010 at 22:53, Jesse Barnes jbar...@virtuousgeek.org wrote: Doesn't change anything here. Display stays blank. Sounds like your problem is separate from SSC then, more likely related to panel power or backlight control. Have you tried bisecting for the problem between 2.6.35 and 2.6.36? Nevermind, I just checked out the bug, looks like it is panel power related. Can you try this patch? Tried. Does not work. If it doesn't work, can you send me the output of intel_reg_dumper from before you turn off the display and after you try to turn it back on? See the links below (sorry, they files are a bit large): Before running xset dpms force standby: http://vin-soft.org/~raa/public/test/intel_gpu_dump-before After running sleep 3 http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-suspend After running xset dpms force on http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-xset-on After closing and opening the lid (displays backlight is back) http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid I need the intel_reg_dumper output, not intel_gpu_dump. :) -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc8 (no fb)
On Thu, Dec 30, 2010 at 00:20, Alex Riesen raa.l...@gmail.com wrote: On Thu, Dec 30, 2010 at 00:13, Jesse Barnes jbar...@virtuousgeek.org wrote: After closing and opening the lid (displays backlight is back) http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid I need the intel_reg_dumper output, not intel_gpu_dump. :) Hmm, there is no intel_reg_dumper in intel-gpu-tools-1.0.2, which is the latest on http://xorg.freedesktop.org/archive/individual/app/, so I assumed you just mistyped the name. Is it in git only? ... Yeah, look like it is in git only, which I have problems to compile (I have a bit of obsoleted system). Is there any other way to get at the dump? Because it looks like it is plainly impossible to build the tools. A lot of dependencies, all really hard to get at on Ubuntu Jaunty. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc8 (no fb)
On Wed, 29 Dec 2010 14:46:14 -0800 Jesse Barnes wrote:
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios
index 2b20786..d27d016 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private
*dev_priv,
dev_priv-int_tv_support = general-int_tv_support;
dev_priv-int_crt_support = general-int_crt_support;
dev_priv-lvds_use_ssc = general-enable_ssc;
+ /* force disable until we can parse this correctly */
+ if (IS_GEN5(dev) || IS_GEN6(dev))
+ dev_priv-lvds_use_ssc = 0;
if (dev_priv-lvds_use_ssc) {
if (IS_I85X(dev))
--
Ugh, looks like I have confused things horribly. Sorry about this.
2.6.37-rc8 with no patches works for me. My original report was incorrect
--
I was using -rc7 when I thought I was using -rc8. :(
Can you confirm that the above doesn't break your setup just in case we
need to apply it?
Yes, confirmed, my test platform still works with this patch applied.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
desserts: http://www.xenotime.net/linux/recipes/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc8 (no fb)
On Thu, 30 Dec 2010 00:35:15 +0100 Alex Riesen raa.l...@gmail.com wrote: On Thu, Dec 30, 2010 at 00:20, Alex Riesen raa.l...@gmail.com wrote: On Thu, Dec 30, 2010 at 00:13, Jesse Barnes jbar...@virtuousgeek.org wrote: After closing and opening the lid (displays backlight is back) http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid I need the intel_reg_dumper output, not intel_gpu_dump. :) Hmm, there is no intel_reg_dumper in intel-gpu-tools-1.0.2, which is the latest on http://xorg.freedesktop.org/archive/individual/app/, so I assumed you just mistyped the name. Is it in git only? ... Yeah, look like it is in git only, which I have problems to compile (I have a bit of obsoleted system). Is there any other way to get at the dump? Because it looks like it is plainly impossible to build the tools. A lot of dependencies, all really hard to get at on Ubuntu Jaunty. That's the easiest way; I think there are existing packages available as well, but you may have to check Karmic or newer. -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc8 (no fb)
On Thu, Dec 30, 2010 at 01:02, Jesse Barnes jbar...@virtuousgeek.org wrote: That's the easiest way; I think there are existing packages available as well, but you may have to check Karmic or newer. Never mind. I'm lazy (that's not to say someone is too). I redid the test: Before running xset dpms force standby: http://vin-soft.org/~raa/public/test/intel_reg_dumper-before After running sleep 3 http://vin-soft.org/~raa/public/test/intel_reg_dumper-suspend After running xset dpms force on; sleep 3 http://vin-soft.org/~raa/public/test/intel_reg_dumper-xset-on After closing and opening the lid (displays backlight is back) http://vin-soft.org/~raa/public/test/intel_reg_dumper-lid ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc6
On Thu, Dec 16, 2010 at 08:37:03PM +, ext Chris Wilson wrote: On Thu, 16 Dec 2010 18:30:11 +0100, Domenico Andreoli cav...@gmail.com wrote: Hi, On Wed, Dec 15, 2010 at 07:10:28PM -0800, ext Linus Torvalds wrote: Go forth and test. And please do remember to ping bugzilla (or developers) about any regressions you find, whether new or old. I have some problem with i945, display remains blank. I also tried adding i915.modeset=0 but nothing changed. Machine is well alive and responds to basic commands like Ctrl+Alt+F1 and Ctrl+Alt+Del but I have not other machine to enter via network. If i915.modeset=0 doesn't restore the display then something is extremely fishy. Do you see any console output before the i915.ko is loaded? no, I can only see what is in /var/log/messages [1.284262] [drm] Initialized drm 1.1.0 20060810 [1.284334] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [1.485212] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [1.485642] [drm] initialized overlay support [2.526011] No connectors reported connected with modes [2.526053] [drm] Cannot find any crtc or sizes - going 1024x768 [1.277898] [drm] Initialized drm 1.1.0 20060810 [1.277966] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [1.476151] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [1.476552] [drm] initialized overlay support [2.516008] No connectors reported connected with modes [2.516049] [drm] Cannot find any crtc or sizes - going 1024x768 [2.526296] Console: switching to colour frame buffer device 128x48 [2.528880] fb0: inteldrmfb frame buffer device [2.528907] drm: registered panic notifier [2.528937] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 this is the log with reverted e7dbb2f2. The issue appears to be that no outputs are being detected. I presume that you have instead a VGA connected to the box and that the regression is in fact e7dbb2f2. If I'm guessing rightly: yes, display is attached to the VGA port. I reverted this commit on -rc6, the only improvement is that with i915.modeset=0 I get the display back to normal VGA mode but when KMS is enabled I still get the blank screen. diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c index 8df5743..14c276e 100644 --- a/drivers/gpu/drm/i915/intel_crt.c +++ b/drivers/gpu/drm/i915/intel_crt.c @@ -148,7 +148,9 @@ static void intel_crt_mode_set(struct drm_encoder *encoder, dpll_md ~DPLL_MD_UDI_MULTIPLIER_MASK); } - adpa = ADPA_HOTPLUG_BITS; + adpa = 0; + if (INTEL_INFO(dev)-gen = 4) + adpa |= ADPA_HOTPLUG_BITS; if (adjusted_mode-flags DRM_MODE_FLAG_PHSYNC) adpa |= ADPA_HSYNC_ACTIVE_HIGH; if (adjusted_mode-flags DRM_MODE_FLAG_PVSYNC) I tried this patch on -rc6 but does not help at all. cheers, Domenico ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc6
On Thu, 16 Dec 2010 18:30:11 +0100, Domenico Andreoli cav...@gmail.com wrote: Hi, On Wed, Dec 15, 2010 at 07:10:28PM -0800, ext Linus Torvalds wrote: Go forth and test. And please do remember to ping bugzilla (or developers) about any regressions you find, whether new or old. I have some problem with i945, display remains blank. I also tried adding i915.modeset=0 but nothing changed. Machine is well alive and responds to basic commands like Ctrl+Alt+F1 and Ctrl+Alt+Del but I have not other machine to enter via network. If i915.modeset=0 doesn't restore the display then something is extremely fishy. Do you see any console output before the i915.ko is loaded? [1.284262] [drm] Initialized drm 1.1.0 20060810 [1.284334] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [1.485212] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [1.485642] [drm] initialized overlay support [2.526011] No connectors reported connected with modes [2.526053] [drm] Cannot find any crtc or sizes - going 1024x768 The issue appears to be that no outputs are being detected. I presume that you have instead a VGA connected to the box and that the regression is in fact e7dbb2f2. If I'm guessing rightly: diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c index 8df5743..14c276e 100644 --- a/drivers/gpu/drm/i915/intel_crt.c +++ b/drivers/gpu/drm/i915/intel_crt.c @@ -148,7 +148,9 @@ static void intel_crt_mode_set(struct drm_encoder *encoder, dpll_md ~DPLL_MD_UDI_MULTIPLIER_MASK); } - adpa = ADPA_HOTPLUG_BITS; + adpa = 0; + if (INTEL_INFO(dev)-gen = 4) + adpa |= ADPA_HOTPLUG_BITS; if (adjusted_mode-flags DRM_MODE_FLAG_PHSYNC) adpa |= ADPA_HSYNC_ACTIVE_HIGH; if (adjusted_mode-flags DRM_MODE_FLAG_PVSYNC) -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
