Re: Linux 2.6.37

2011-01-12 Thread Chris Wilson
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

2011-01-12 Thread Chris Wilson
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

2011-01-12 Thread Indan Zupancic
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

2011-01-11 Thread Pavel Machek
 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

2011-01-11 Thread Michal Hocko
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

2011-01-11 Thread Alex Riesen
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

2011-01-11 Thread Michal Hocko
[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

2011-01-11 Thread Michal Hocko
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

2011-01-11 Thread Chris Wilson
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

2011-01-11 Thread Michal Hocko
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

2011-01-11 Thread Michal Hocko
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

2011-01-11 Thread Indan Zupancic
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

2011-01-10 Thread Zephaniah E. Loss-Cutler-Hull
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

2011-01-07 Thread Michal Hocko
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

2011-01-06 Thread Linus Torvalds
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

2011-01-06 Thread Michal Hocko
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

2011-01-06 Thread Michal Hocko
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

2011-01-06 Thread Chris Wilson
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

2011-01-06 Thread Alex Riesen
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

2011-01-06 Thread Chris Wilson
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

2011-01-06 Thread Alex Riesen
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)

2010-12-30 Thread Jesse Barnes
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)

2010-12-30 Thread Chris Wilson
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)

2010-12-29 Thread Linus Torvalds
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)

2010-12-29 Thread Jesse Barnes
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)

2010-12-29 Thread François Valenduc
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)

2010-12-29 Thread Alex Riesen
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)

2010-12-29 Thread Jesse Barnes
  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)

2010-12-29 Thread Alex Riesen
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)

2010-12-29 Thread Randy Dunlap
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)

2010-12-29 Thread Jesse Barnes
  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)

2010-12-29 Thread Alex Riesen
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)

2010-12-29 Thread Jesse Barnes
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)

2010-12-29 Thread Alex Riesen
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)

2010-12-29 Thread Randy Dunlap
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)

2010-12-29 Thread Jesse Barnes
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)

2010-12-29 Thread Alex Riesen
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

2010-12-17 Thread Domenico Andreoli
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

2010-12-16 Thread Chris Wilson
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