[PATCH] gpu/stub: try to make help text readable

[Randy Dunlap]

From: Randy Dunlap 

I couldn't parse the STUB_POULSBO help text and the module names
were misleading, so try to make it more readable, use corrected
module names, and spell "acpi" as "ACPI".

Signed-off-by: Randy Dunlap 
Cc: Lee, Chun-Yi 
Cc: Lee, Chun-Yi 
Cc: Dave Airlie 
---
 drivers/gpu/stub/Kconfig |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- linux-3.0-git22.orig/drivers/gpu/stub/Kconfig
+++ linux-3.0-git22/drivers/gpu/stub/Kconfig
@@ -12,7 +12,7 @@ config STUB_POULSBO
help
  Choose this option if you have a system that has Intel GMA500
  (Poulsbo) integrated graphics. If M is selected, the module will
- be called Poulsbo. This driver is a stub driver for Poulsbo that
- will call poulsbo.ko to enable the acpi backlight control sysfs
- entry file because there have no poulsbo native driver can support
+ be called poulsbo. This driver is a stub driver for Poulsbo that
+ will call psb_gfx.ko to enable the ACPI backlight control sysfs
+ entry file because there is no poulsbo native driver that supports
  intel opregion.

[Bug 40622] [radeon] - kms wrong resolution mode used after backlight on/off switch

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=40622





--- Comment #3 from Torsten Krah   
2011-08-06 10:40:09 ---
Config is all autodetect, got no xorg.conf. I am attaching 2.6.32 ones and 3.0
ones. Commented Xorg.0.log-* with my "on"/"off" toggles.
The interesting thing is - this error seems to be a little bit random -
sometimes the on resolution is ok, sometimes its wrong - but i guess i should
not try to understand because  you are the expert and have the knowledge ;).
Hope the logs helps.

--- Comment #4 from Torsten Krah   
2011-08-06 10:46:47 ---
Created an attachment (id=67742)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=67742)
xrandr output 2.6.32.x

xrandr --verbose

--- Comment #5 from Torsten Krah   
2011-08-06 10:51:25 ---
Created an attachment (id=67752)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=67752)
xrandr output 3.0

xrandr --verbose

--- Comment #6 from Torsten Krah   
2011-08-06 10:56:54 ---
Created an attachment (id=67762)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=67762)
dmesg 2.6.32

--- Comment #7 from Torsten Krah   
2011-08-06 11:04:51 ---
Created an attachment (id=67772)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=67772)
dmesg 3.0

Additional Info - these ones are not generated via Fn+Backlight Switch but are
caused by Fn+F2 (Battery Info); so this has nothing to do with this task -
don't know if i should open another task for those ones or to ignore ... 

[  736.991529] kbd_keycode: 48 callbacks suppressed
[  736.991540] keyboard: can't emulate rawmode for keycode 240
[  736.991567] keyboard: can't emulate rawmode for keycode 240
[  747.397902] keyboard: can't emulate rawmode for keycode 240
[  747.397933] keyboard: can't emulate rawmode for keycode 240

--- Comment #8 from Torsten Krah   
2011-08-06 11:08:49 ---
Created an attachment (id=67782)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=67782)
Xorg.0.log 2.6.32

--- Comment #9 from Torsten Krah   
2011-08-06 11:18:40 ---
Created an attachment (id=67792)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=67792)
Xorg.0.log 3.0

--- Comment #10 from Alex Deucher   2011-08-06 
13:33:46 ---
Looks like some program is listening for hotkey events and trying to
change the mode with xrandr.  Older xservers used to add 1600x1024 mode by
default so that's probably where the mode is coming from.  I'm not sure why
that mode is getting picked when you hit the backlight key, but it's not
something the driver handles.  The driver does not listen for hotkey events. 
You'll have to find out what program is handling the hotkey events on your
system.  This doesn't look like a driver bug.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH v3] pass ELD to HDMI/DP audio driver

[Keith Packard]

> Good questions!  In general the audio functionalities should not
> depend on the display activeness. There are even audio-only HDMI
> devices. So I'll need to make intel_write_eld() work even without
> information about the current display mode.

Yeah, we'll need to figure out what the ELD should look like with no
display active. I think you've got the whole link available, so there
shouldn't be any restrictions on formats.

> That would be a good feature. For one thing, I find it annoying that
> the music playback fades out when the screen goes to power saving
> mode..

I'm not sure we can make it completely seamless without keeping most of
the pipe active (which will consume some power). Probably we'll just
leave the clock alone while the display is DPMS'd, but if we actually
need the resources for another display, I'm afraid there may be some
noise on the HDMI audio link. Will need experimentation to figure out
how to make this work as nicely as possible.

I was just reading through the reference manual and found that there is
a mode that leaves the HDMI running without requiring a pipe or plane,
just the FDI PLL. So, audio without display seems pretty simple now;
just a matter of a bit of API negotiation between the audio and video
drivers.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110806/688c0a75/attachment.pgp>

[Bug 39882] Regression: Plugging in a HDMI connector makes the LCD of X120e go dark

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39882

--- Comment #5 from gottfried.haider at gmail.com 2011-08-06 12:26:19 PDT ---
Sorry, I tried bisecting, but defconfig does not boot here.. and my normal
config takes ages for a full rebuild.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 33348] [r300g] Display corruption (artifacts) when using 3D graphics...

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=33348

Dawit Alemayehu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #25 from Dawit Alemayehu  2011-08-06 12:19:07 
PDT ---
Seems to be finally fixed in Mesa 7.11. Dunno what the cause was, but it works
fine for me on the hardware and driver I reported with the shinny new Mesa
7.11. Big thanks for whomever fixed this problem.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36602] Hierarchical Z support for R600

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36602

Sven Arvidsson  changed:

   What|Removed |Added

  Attachment #49931|0   |1
is obsolete||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36602] Hierarchical Z support for R600

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36602

--- Comment #22 from Sven Arvidsson  2011-08-06 12:18:04 PDT ---
I followed Andy's advice and grabbed a d-r-t kernel, now everything seems to be
running okay.

On my HD5670 I haven't noticed any difference in performance, OTOH neither do I
get the corruption mentioned, cubemap renders correctly.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 4/4] drm/i915: Remove unused 'reg' argument to dp_pipe_enabled

[Keith Packard]

Just an extra parameter which isn't actually needed.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/intel_display.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 4c4c903..f6f18c7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -980,8 +980,8 @@ static void assert_transcoder_disabled(struct 
drm_i915_private *dev_priv,
 pipe_name(pipe));
 }

-static bool dp_pipe_enabled(struct drm_i915_private *dev_priv, enum pipe pipe,
-   int reg, u32 port_sel, u32 val)
+static bool dp_pipe_enabled(struct drm_i915_private *dev_priv,
+   enum pipe pipe, u32 port_sel, u32 val)
 {
if ((val & DP_PORT_EN) == 0)
return false;
@@ -1049,7 +1049,7 @@ static void assert_pch_dp_disabled(struct 
drm_i915_private *dev_priv,
   enum pipe pipe, int reg, u32 port_sel)
 {
u32 val = I915_READ(reg);
-   WARN(dp_pipe_enabled(dev_priv, pipe, reg, port_sel, val),
+   WARN(dp_pipe_enabled(dev_priv, pipe, port_sel, val),
 "PCH DP (0x%08x) enabled on transcoder %c, should be disabled\n",
 reg, pipe_name(pipe));
 }
@@ -1407,7 +1407,7 @@ static void disable_pch_dp(struct drm_i915_private 
*dev_priv,
   enum pipe pipe, int reg, u32 port_sel)
 {
u32 val = I915_READ(reg);
-   if (dp_pipe_enabled(dev_priv, pipe, reg, port_sel, val)) {
+   if (dp_pipe_enabled(dev_priv, pipe, port_sel, val)) {
DRM_DEBUG_KMS("Disabling pch dp %x on pipe %d\n", reg, pipe);
I915_WRITE(reg, val & ~DP_PORT_EN);
}
-- 
1.7.5.4

[PATCH 3/4] drm/i915: Fix PCH port pipe select in CPT disable paths

[Keith Packard]

CPT pipe select is different from previous generations (using two bits
instead of one). All of the paths from intel_disable_pch_ports were
not making this distinction.

Mode setting with pipe A turned off would then also force all outputs
on pipe B to get turned off as the disable code would mistakenly
decide that all of these outputs were on pipe A and turn them off.

This is an extension of the CPT DP disable fix (why didn't I fix this then?)

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/i915_reg.h  |   13 ++-
 drivers/gpu/drm/i915/intel_display.c |   60 ++---
 2 files changed, 58 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d1331f7..5baaef4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1318,6 +1318,7 @@
 #define   ADPA_PIPE_SELECT_MASK(1<<30)
 #define   ADPA_PIPE_A_SELECT   0
 #define   ADPA_PIPE_B_SELECT   (1<<30)
+#define   ADPA_PIPE_SELECT(pipe) ((pipe) << 30)
 #define   ADPA_USE_VGA_HVPOLARITY (1<<15)
 #define   ADPA_SETS_HVPOLARITY 0
 #define   ADPA_VSYNC_CNTL_DISABLE (1<<11)
@@ -1460,6 +1461,7 @@
 /* Selects pipe B for LVDS data.  Must be set on pre-965. */
 #define   LVDS_PIPEB_SELECT(1 << 30)
 #define   LVDS_PIPE_MASK   (1 << 30)
+#define   LVDS_PIPE(pipe)  ((pipe) << 30)
 /* LVDS dithering flag on 965/g4x platform */
 #define   LVDS_ENABLE_DITHER   (1 << 25)
 /* LVDS sync polarity flags. Set to invert (i.e. negative) */
@@ -1499,9 +1501,6 @@
 #define   LVDS_B0B3_POWER_DOWN (0 << 2)
 #define   LVDS_B0B3_POWER_UP   (3 << 2)

-#define LVDS_PIPE_ENABLED(V, P) \
-   (((V) & (LVDS_PIPE_MASK | LVDS_PORT_EN)) == ((P) << 30 | LVDS_PORT_EN))
-
 /* Video Data Island Packet control */
 #define VIDEO_DIP_DATA 0x61178
 #define VIDEO_DIP_CTL  0x61170
@@ -3256,14 +3255,12 @@
 #define  ADPA_CRT_HOTPLUG_VOLREF_475MV  (1<<17)
 #define  ADPA_CRT_HOTPLUG_FORCE_TRIGGER (1<<16)

-#define ADPA_PIPE_ENABLED(V, P) \
-   (((V) & (ADPA_TRANS_SELECT_MASK | ADPA_DAC_ENABLE)) == ((P) << 30 | 
ADPA_DAC_ENABLE))
-
 /* or SDVOB */
 #define HDMIB   0xe1140
 #define  PORT_ENABLE(1 << 31)
 #define  TRANSCODER_A   (0)
 #define  TRANSCODER_B   (1 << 30)
+#define  TRANSCODER(pipe)  ((pipe) << 30)
 #define  TRANSCODER_MASK   (1 << 30)
 #define  COLOR_FORMAT_8bpc  (0)
 #define  COLOR_FORMAT_12bpc (3 << 26)
@@ -3280,9 +3277,6 @@
 #define  HSYNC_ACTIVE_HIGH  (1 << 3)
 #define  PORT_DETECTED  (1 << 2)

-#define HDMI_PIPE_ENABLED(V, P) \
-   (((V) & (TRANSCODER_MASK | PORT_ENABLE)) == ((P) << 30 | PORT_ENABLE))
-
 /* PCH SDVOB multiplex with HDMIB */
 #define PCH_SDVOB  HDMIB

@@ -3349,6 +3343,7 @@
 #define  PORT_TRANS_B_SEL_CPT  (1<<29)
 #define  PORT_TRANS_C_SEL_CPT  (2<<29)
 #define  PORT_TRANS_SEL_MASK   (3<<29)
+#define  PORT_TRANS_SEL_CPT(pipe)  ((pipe) << 29)

 #define TRANS_DP_CTL_A 0xe0300
 #define TRANS_DP_CTL_B 0xe1300
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 35364e6..4c4c903 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -998,6 +998,53 @@ static bool dp_pipe_enabled(struct drm_i915_private 
*dev_priv, enum pipe pipe,
return true;
 }

+static bool hdmi_pipe_enabled(struct drm_i915_private *dev_priv,
+ enum pipe pipe, u32 val)
+{
+   if ((val & PORT_ENABLE) == 0)
+   return false;
+
+   if (HAS_PCH_CPT(dev_priv->dev)) {
+   if ((val & PORT_TRANS_SEL_MASK) != PORT_TRANS_SEL_CPT(pipe))
+   return false;
+   } else {
+   if ((val & TRANSCODER_MASK) != TRANSCODER(pipe))
+   return false;
+   }
+   return true;
+}
+
+static bool lvds_pipe_enabled(struct drm_i915_private *dev_priv,
+ enum pipe pipe, u32 val)
+{
+   if ((val & LVDS_PORT_EN) == 0)
+   return false;
+
+   if (HAS_PCH_CPT(dev_priv->dev)) {
+   if ((val & PORT_TRANS_SEL_MASK) != PORT_TRANS_SEL_CPT(pipe))
+   return false;
+   } else {
+   if ((val & LVDS_PIPE_MASK) != LVDS_PIPE(pipe))
+   return false;
+   }
+   return true;
+}
+
+static bool adpa_pipe_enabled(struct drm_i915_private *dev_priv,
+ enum pipe pipe, u32 val)
+{
+   if ((val & ADPA_DAC_ENABLE) == 0)
+   return false;
+   if (HAS_PCH_CPT(dev_priv->dev)) {
+   if ((val & PORT_TRANS_SEL_MASK) != PORT_TRANS_SEL_CPT(pipe))
+   return false;
+   } else {
+   if ((val & ADPA_PIPE_SELECT_MASK) != ADPA_PIPE_SELECT(pipe))
+   return false;
+   }
+   return true;
+}
+
 static void assert_pch_dp_disabled(struct drm_i915_private *dev_priv,

[PATCH 2/4] drm/i915: Leave LVDS registers unlocked

[Keith Packard]

There's no reason to relock them; it just makes operations more
complex. This fixes DPMS where the panel registers were locked making
the disable not work.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/intel_lvds.c |   46 +++-
 1 files changed, 19 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 6985e42..cc85618 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -414,46 +414,32 @@ static void intel_lvds_prepare(struct drm_encoder 
*encoder)
/* We try to do the minimum that is necessary in order to unlock
 * the registers for mode setting.
 *
-* On Ironlake, this is quite simple as we just set the unlock key
-* and ignore all subtleties. (This may cause some issues...)
+* On Ironlake, this is quite simple as we just set the unlock
+* key in the driver init code and ignore all subtleties.
+* (This may cause some issues...)
 *
 * Prior to Ironlake, we must disable the pipe if we want to adjust
 * the panel fitter. However at all other times we can just reset
 * the registers regardless.
 */

-   if (HAS_PCH_SPLIT(dev)) {
-   I915_WRITE(PCH_PP_CONTROL,
-  I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS);
-   } else if (intel_lvds->pfit_dirty) {
-   I915_WRITE(PP_CONTROL,
-  (I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS)
-  & ~POWER_TARGET_ON);
-   } else {
-   I915_WRITE(PP_CONTROL,
-  I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
+   if (!HAS_PCH_SPLIT(dev)) {
+   if (intel_lvds->pfit_dirty) {
+   I915_WRITE(PP_CONTROL,
+  (I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS)
+  & ~POWER_TARGET_ON);
+   } else {
+   I915_WRITE(PP_CONTROL,
+  I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
+   }
}
+   intel_lvds_disable(intel_lvds);
 }

 static void intel_lvds_commit(struct drm_encoder *encoder)
 {
-   struct drm_device *dev = encoder->dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_lvds *intel_lvds = to_intel_lvds(encoder);

-   /* Undo any unlocking done in prepare to prevent accidental
-* adjustment of the registers.
-*/
-   if (HAS_PCH_SPLIT(dev)) {
-   u32 val = I915_READ(PCH_PP_CONTROL);
-   if ((val & PANEL_UNLOCK_REGS) == PANEL_UNLOCK_REGS)
-   I915_WRITE(PCH_PP_CONTROL, val & 0x3);
-   } else {
-   u32 val = I915_READ(PP_CONTROL);
-   if ((val & PANEL_UNLOCK_REGS) == PANEL_UNLOCK_REGS)
-   I915_WRITE(PP_CONTROL, val & 0x3);
-   }
-
/* Always do a full power on as we do not know what state
 * we were left in.
 */
@@ -1049,6 +1035,12 @@ out:
pwm = I915_READ(BLC_PWM_PCH_CTL1);
pwm |= PWM_PCH_ENABLE;
I915_WRITE(BLC_PWM_PCH_CTL1, pwm);
+   /*
+* Unlock registers and just
+* leave them unlocked
+*/
+   I915_WRITE(PCH_PP_CONTROL,
+  I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS);
}
dev_priv->lid_notifier.notifier_call = intel_lid_notify;
if (acpi_lid_notifier_register(_priv->lid_notifier)) {
-- 
1.7.5.4

[PATCH 1/4] drm/i915: Wait for LVDS panel power sequence

[Keith Packard]

During mode setting, check to make sure the panel power sequencing has
completed before doing further operations on the device. This
uncovered errors with DPMS not turning the device off as it was left locked.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/intel_lvds.c |   13 +++--
 1 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 2e8ddfc..6985e42 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -72,14 +72,16 @@ static void intel_lvds_enable(struct intel_lvds *intel_lvds)
 {
struct drm_device *dev = intel_lvds->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   u32 ctl_reg, lvds_reg;
+   u32 ctl_reg, lvds_reg, stat_reg;

if (HAS_PCH_SPLIT(dev)) {
ctl_reg = PCH_PP_CONTROL;
lvds_reg = PCH_LVDS;
+   stat_reg = PCH_PP_STATUS;
} else {
ctl_reg = PP_CONTROL;
lvds_reg = LVDS;
+   stat_reg = PP_STATUS;
}

I915_WRITE(lvds_reg, I915_READ(lvds_reg) | LVDS_PORT_EN);
@@ -105,6 +107,8 @@ 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);
+   if (wait_for((I915_READ(stat_reg) & PP_ON) != 0, 1000))
+   DRM_ERROR("timed out waiting for panel to power on\n");

intel_panel_enable_backlight(dev);
 }
@@ -113,19 +117,24 @@ static void intel_lvds_disable(struct intel_lvds 
*intel_lvds)
 {
struct drm_device *dev = intel_lvds->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   u32 ctl_reg, lvds_reg;
+   u32 ctl_reg, lvds_reg, stat_reg;

if (HAS_PCH_SPLIT(dev)) {
ctl_reg = PCH_PP_CONTROL;
lvds_reg = PCH_LVDS;
+   stat_reg = PCH_PP_STATUS;
} else {
ctl_reg = PP_CONTROL;
lvds_reg = LVDS;
+   stat_reg = PP_STATUS;
}

intel_panel_disable_backlight(dev);

I915_WRITE(ctl_reg, I915_READ(ctl_reg) & ~POWER_TARGET_ON);
+   if (wait_for((I915_READ(stat_reg) & PP_ON) == 0, 1000))
+   DRM_ERROR("timed out waiting for panel to power off status 
0x%08x control 0x%08x\n",
+ I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));

if (intel_lvds->pfit_control) {
if (wait_for((I915_READ(PP_STATUS) & PP_ON) == 0, 1000))
-- 
1.7.5.4

drm/i915: Disabling unused outputs on CPT is broken

[Keith Packard]

Here's a fun sequence:

$ xrandr --output LVDS1 --auto --crtc 1
$ sudo chvt 1

(then switch back to X)

The LVDS goes black. Why? The LVDS is *disabled*. Turns out that the
cause was that after the mode was all nicely set,
intel_disable_pch_ports went and turned it back off.

Well, a couple of weeks ago, we found that intel_disable_pch_ports was
doing the same thing to DP ports, and the cause was that the way to
tell which port a DP output was running from is different on CPT that
on every other chip. We fixed that, but didn't (foolishly) review the
non-DP code.

Oddly, the non-DP code had essentially the same bug:

 [PATCH 3/4] drm/i915: Fix PCH port pipe select in CPT disable paths

Also in this sequence is some code that validates the LVDS panel power
sequencing which discovered that the LVDS panel wasn't being disabled
correctly because the LVDS registers were locked in the DPMS
function. Instead of trying to get the LVDS locking right, I've just
unlocked the registers in the lvds initialization code and left them
unlocked after that:

 [PATCH 1/4] drm/i915: Wait for LVDS panel power sequence
 [PATCH 2/4] drm/i915: Leave LVDS registers unlocked

Finally, I removed an unused argument to dp_pipe_enable while I was
poking around in that code:

 [PATCH 4/4] drm/i915: Remove unused 'reg' argument to dp_pipe_enable

--
keith.packard at intel.com

[Bug 37662] Upgrade to version 2.6.38, disable the laptop display back light

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=37662


Gary Liddle  changed:

   What|Removed |Added

 CC||gary.liddle at sp1der.co.uk




--- Comment #3 from njin   2011-06-21 16:30:44 
---
@ Len Brown
Go up and below assigned to there's the launchpad URL, if this is not the right
procedure, please advice me.
Thanks
Fabio

--- Comment #4 from Gary Liddle   2011-08-06 
10:42:14 ---
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/740893

Hey

I have the same laptop and have the same problem when i updated the Kernel.

I've been running 2.6.35.22 which has no problems.

I initially updated to 2.6.38-8 which i thought at first had failed, but
noticed the screen was only usable (and i use that word very lightly) in direct
sunlight.

I've now updated to 2.6.38-10 which has the same problem as 2.6.38-8, no back
light on the monitor.

I'm currently viewing the laptop on 2.6.38-10 through an external monitor so i
can try to resolve the problem and can run any diagnostic commands you require.

Please see the above launchpad link for all the debug information regarding
this problem.

Thanks,
Gary

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH 2/5] drm/i915: Leave LVDS registers unlocked

[Keith Packard]

There's no reason to relock them; it just makes operations more
complex. This fixes DPMS where the panel registers were locked making
the disable not work.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/intel_lvds.c |   53 ++--
 1 files changed, 15 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 6318828..03a9e6d 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -400,53 +400,17 @@ out:

 static void intel_lvds_prepare(struct drm_encoder *encoder)
 {
-   struct drm_device *dev = encoder->dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_lvds *intel_lvds = to_intel_lvds(encoder);

-   /* We try to do the minimum that is necessary in order to unlock
-* the registers for mode setting.
-*
-* On Ironlake, this is quite simple as we just set the unlock key
-* and ignore all subtleties. (This may cause some issues...)
-*
-* Prior to Ironlake, we must disable the pipe if we want to adjust
-* the panel fitter. However at all other times we can just reset
-* the registers regardless.
+   /* Safest to just always power off for mode setting.
 */
-
-   if (HAS_PCH_SPLIT(dev)) {
-   I915_WRITE(PCH_PP_CONTROL,
-  I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS);
-   } else if (intel_lvds->pfit_dirty) {
-   I915_WRITE(PP_CONTROL,
-  (I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS)
-  & ~POWER_TARGET_ON);
-   } else {
-   I915_WRITE(PP_CONTROL,
-  I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
-   }
+   intel_lvds_disable(intel_lvds);
 }

 static void intel_lvds_commit(struct drm_encoder *encoder)
 {
-   struct drm_device *dev = encoder->dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_lvds *intel_lvds = to_intel_lvds(encoder);

-   /* Undo any unlocking done in prepare to prevent accidental
-* adjustment of the registers.
-*/
-   if (HAS_PCH_SPLIT(dev)) {
-   u32 val = I915_READ(PCH_PP_CONTROL);
-   if ((val & PANEL_UNLOCK_REGS) == PANEL_UNLOCK_REGS)
-   I915_WRITE(PCH_PP_CONTROL, val & 0x3);
-   } else {
-   u32 val = I915_READ(PP_CONTROL);
-   if ((val & PANEL_UNLOCK_REGS) == PANEL_UNLOCK_REGS)
-   I915_WRITE(PP_CONTROL, val & 0x3);
-   }
-
/* Always do a full power on as we do not know what state
 * we were left in.
 */
@@ -1042,6 +1006,19 @@ out:
pwm = I915_READ(BLC_PWM_PCH_CTL1);
pwm |= PWM_PCH_ENABLE;
I915_WRITE(BLC_PWM_PCH_CTL1, pwm);
+   /*
+* Unlock registers and just
+* leave them unlocked
+*/
+   I915_WRITE(PCH_PP_CONTROL,
+  I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS);
+   } else {
+   /*
+* Unlock registers and just
+* leave them unlocked
+*/
+   I915_WRITE(PP_CONTROL,
+  I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
}
dev_priv->lid_notifier.notifier_call = intel_lid_notify;
if (acpi_lid_notifier_register(_priv->lid_notifier)) {
-- 
1.7.5.4



-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[PATCH 2/5] drm/i915: Leave LVDS registers unlocked

[Keith Packard]

There's no reason to relock them; it just makes operations more
complex. This fixes DPMS where the panel registers were locked making
the disable not work.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/intel_lvds.c |   51 +++-
 1 files changed, 16 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 6318828..8b521a2 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -400,53 +400,21 @@ out:

 static void intel_lvds_prepare(struct drm_encoder *encoder)
 {
-   struct drm_device *dev = encoder->dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_lvds *intel_lvds = to_intel_lvds(encoder);

-   /* We try to do the minimum that is necessary in order to unlock
-* the registers for mode setting.
-*
-* On Ironlake, this is quite simple as we just set the unlock key
-* and ignore all subtleties. (This may cause some issues...)
-*
+   /*
 * Prior to Ironlake, we must disable the pipe if we want to adjust
 * the panel fitter. However at all other times we can just reset
 * the registers regardless.
 */
-
-   if (HAS_PCH_SPLIT(dev)) {
-   I915_WRITE(PCH_PP_CONTROL,
-  I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS);
-   } else if (intel_lvds->pfit_dirty) {
-   I915_WRITE(PP_CONTROL,
-  (I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS)
-  & ~POWER_TARGET_ON);
-   } else {
-   I915_WRITE(PP_CONTROL,
-  I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
-   }
+   if (!HAS_PCH_SPLIT(encoder->dev) && intel_lvds->pfit_dirty)
+   intel_lvds_disable(intel_lvds);
 }

 static void intel_lvds_commit(struct drm_encoder *encoder)
 {
-   struct drm_device *dev = encoder->dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_lvds *intel_lvds = to_intel_lvds(encoder);

-   /* Undo any unlocking done in prepare to prevent accidental
-* adjustment of the registers.
-*/
-   if (HAS_PCH_SPLIT(dev)) {
-   u32 val = I915_READ(PCH_PP_CONTROL);
-   if ((val & PANEL_UNLOCK_REGS) == PANEL_UNLOCK_REGS)
-   I915_WRITE(PCH_PP_CONTROL, val & 0x3);
-   } else {
-   u32 val = I915_READ(PP_CONTROL);
-   if ((val & PANEL_UNLOCK_REGS) == PANEL_UNLOCK_REGS)
-   I915_WRITE(PP_CONTROL, val & 0x3);
-   }
-
/* Always do a full power on as we do not know what state
 * we were left in.
 */
@@ -1042,6 +1010,19 @@ out:
pwm = I915_READ(BLC_PWM_PCH_CTL1);
pwm |= PWM_PCH_ENABLE;
I915_WRITE(BLC_PWM_PCH_CTL1, pwm);
+   /*
+* Unlock registers and just
+* leave them unlocked
+*/
+   I915_WRITE(PCH_PP_CONTROL,
+  I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS);
+   } else {
+   /*
+* Unlock registers and just
+* leave them unlocked
+*/
+   I915_WRITE(PP_CONTROL,
+  I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
}
dev_priv->lid_notifier.notifier_call = intel_lid_notify;
if (acpi_lid_notifier_register(_priv->lid_notifier)) {
-- 
1.7.5.4



-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[PATCH] drm/i915: Wait for LVDS panel power sequence

[Keith Packard]

During mode setting, check to make sure the panel power sequencing has
completed before doing further operations on the device. This
uncovered errors with DPMS not turning the device off as it was left locked.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/intel_lvds.c |   26 ++
 1 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 2e8ddfc..6318828 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -72,14 +72,16 @@ static void intel_lvds_enable(struct intel_lvds *intel_lvds)
 {
struct drm_device *dev = intel_lvds->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   u32 ctl_reg, lvds_reg;
+   u32 ctl_reg, lvds_reg, stat_reg;

if (HAS_PCH_SPLIT(dev)) {
ctl_reg = PCH_PP_CONTROL;
lvds_reg = PCH_LVDS;
+   stat_reg = PCH_PP_STATUS;
} else {
ctl_reg = PP_CONTROL;
lvds_reg = LVDS;
+   stat_reg = PP_STATUS;
}

I915_WRITE(lvds_reg, I915_READ(lvds_reg) | LVDS_PORT_EN);
@@ -94,17 +96,16 @@ static void intel_lvds_enable(struct intel_lvds *intel_lvds)
DRM_DEBUG_KMS("applying panel-fitter: %x, %x\n",
  intel_lvds->pfit_control,
  intel_lvds->pfit_pgm_ratios);
-   if (wait_for((I915_READ(PP_STATUS) & PP_ON) == 0, 1000)) {
-   DRM_ERROR("timed out waiting for panel to power off\n");
-   } else {
-   I915_WRITE(PFIT_PGM_RATIOS, 
intel_lvds->pfit_pgm_ratios);
-   I915_WRITE(PFIT_CONTROL, intel_lvds->pfit_control);
-   intel_lvds->pfit_dirty = false;
-   }
+
+   I915_WRITE(PFIT_PGM_RATIOS, intel_lvds->pfit_pgm_ratios);
+   I915_WRITE(PFIT_CONTROL, intel_lvds->pfit_control);
+   intel_lvds->pfit_dirty = false;
}

I915_WRITE(ctl_reg, I915_READ(ctl_reg) | POWER_TARGET_ON);
POSTING_READ(lvds_reg);
+   if (wait_for((I915_READ(stat_reg) & PP_ON) != 0, 1000))
+   DRM_ERROR("timed out waiting for panel to power on\n");

intel_panel_enable_backlight(dev);
 }
@@ -113,24 +114,25 @@ static void intel_lvds_disable(struct intel_lvds 
*intel_lvds)
 {
struct drm_device *dev = intel_lvds->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   u32 ctl_reg, lvds_reg;
+   u32 ctl_reg, lvds_reg, stat_reg;

if (HAS_PCH_SPLIT(dev)) {
ctl_reg = PCH_PP_CONTROL;
lvds_reg = PCH_LVDS;
+   stat_reg = PCH_PP_STATUS;
} else {
ctl_reg = PP_CONTROL;
lvds_reg = LVDS;
+   stat_reg = PP_STATUS;
}

intel_panel_disable_backlight(dev);

I915_WRITE(ctl_reg, I915_READ(ctl_reg) & ~POWER_TARGET_ON);
+   if (wait_for((I915_READ(stat_reg) & PP_ON) == 0, 1000))
+   DRM_ERROR("timed out waiting for panel to power off\n");

if (intel_lvds->pfit_control) {
-   if (wait_for((I915_READ(PP_STATUS) & PP_ON) == 0, 1000))
-   DRM_ERROR("timed out waiting for panel to power off\n");
-
I915_WRITE(PFIT_CONTROL, 0);
intel_lvds->pfit_dirty = true;
}
-- 
1.7.5.4

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[Bug 39882] Regression: Plugging in a HDMI connector makes the LCD of X120e go dark

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39882

--- Comment #4 from Alex Deucher  2011-08-06 07:27:46 PDT 
---
Can you bisect?  If I had to guess, it's probably one of the display rework
patches added in 3.0.  Does a VT switch help?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39882] Regression: Plugging in a HDMI connector makes the LCD of X120e go dark

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39882

--- Comment #3 from gottfried.haider at gmail.com 2011-08-06 06:33:29 PDT ---
Created an attachment (id=49994)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=49994)
Xorg.log (HDMI insertion happened just before 906.688)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39882] Regression: Plugging in a HDMI connector makes the LCD of X120e go dark

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39882

--- Comment #2 from gottfried.haider at gmail.com 2011-08-06 06:31:57 PDT ---
Created an attachment (id=49993)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=49993)
dmesg (nothing interesting after HDMI insertion)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39882] Regression: Plugging in a HDMI connector makes the LCD of X120e go dark

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39882

--- Comment #1 from gottfried.haider at gmail.com 2011-08-06 06:28:25 PDT ---
Created an attachment (id=49992)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=49992)
lspci of Lenovo X120e

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39882] New: Regression: Plugging in a HDMI connector makes the LCD of X120e go dark

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39882

   Summary: Regression: Plugging in a HDMI connector makes the LCD
of X120e go dark
   Product: DRI
   Version: XOrg CVS
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: gottfried.haider at gmail.com


When I plug in my external TFT monitor while my X120e is in use, the laptop's
internal LCD immediately goes dark - yet I don't have a picture on the TFT.

I first noticed this with kernel 3.0.0, this is fully reproducible also on
3.0.1. Since I did not remember this happening before, I tested with an older
kernel (Ubuntu's 2.6.38, but should not make a difference), and indeed: with
2.6.38 the internal LCD stays on (which is the expected behavior).

The TFT is connected via a HDMI-to-DVI cable. Userspace is Xubuntu 11.04 with
xorg-edgers PPA.

At a first glance, I do not see anything interesting in either dmesg or
Xorg.log when this happens. Note: the machine does not hang, since I can still
(blindly) launch a terminal and make the machine restart - for which I briefly
get a picture on the LCD again after XOrg shutdown.

I am attaching lspci and a dmesg/Xorg.log below - please let me know if I can
help with anything else (I can easily test kernel patches).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39877] Games rendered pixelated

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39877

--- Comment #2 from Alex Deucher  2011-08-06 06:20:00 PDT 
---
Update mesa to 7.11 or disable colortiling:
Option "ColorTiling" "False"
in the device section of your xorg conf.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39877] Games rendered pixelated

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39877

Alex Deucher  changed:

   What|Removed |Added

  Attachment #49985|text/x-log  |text/plain
  mime type||
  Attachment #49985|0   |1
   is patch||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 33790] [r300g] Black windows with opengl apps (ex. glxgears)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=33790

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTOURBUG

--- Comment #7 from Alex Deucher  2011-08-06 06:15:36 PDT 
---
(In reply to comment #6)
> You got it,
> adding pci=nomsi to kernel solves all issues.
> Is this a real solution or just a workaround for a known bug?

It seems MSIs aren't working on your system.  Probably motherboard chipset
issue or system bios bug.  You might want to bring it up on the linux kernel
mailing list.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 29136] compiz + wallpaper plugin + expo causes X to crash

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=29136

aaron  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
 CC||chainsawbike at gmail.com

--- Comment #1 from aaron  2011-08-06 03:50:52 PDT 
---
works with gallium

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39683] radeon "hd6770 flex" dpms fails to unblank one display sometimes

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39683

--- Comment #7 from aaron  2011-08-06 03:45:40 PDT 
---
i checked the settings and found nothing, so i decided to switch the displays
around to see what happens...
original layout (1):
dvi -> 1
hdmi -> 2
dp -> 3

layout 2:
dvi -> 2
hdmi -> 1
dp -> 3
ran xset dpms force off via ssh
all 3 turned back on but "3" was distinctly after 1,2
(under setup 1 they all turn back on at about the same time the second time
round)
xset -q says displays off
same result every time

layout 3:
dvi -> 3
hdmi -> 2
dp -> 1
same result as layout 1 but it starts  at a different point in the loop -
xrandr says display on but display 3 is off immediately after starting X

it may have something to do with a race condition relating to the speeds the
dislays "start" ( i probably have no idea what i am talking about...) as when
setting up xorg.conf if i used "right-of" it complained about missing modes or
something - it only worked as i expected it to when "left-of"'d from display 3
will investigate further in the next few days

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39877] Games rendered pixelated

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39877

--- Comment #1 from Alex  2011-08-06 01:32:10 PDT 
---
Created an attachment (id=49985)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=49985)
My latest Xorg.0.log

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39877] New: Games rendered pixelated

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39877

   Summary: Games rendered pixelated
   Product: DRI
   Version: XOrg CVS
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: cerebro.alexiel at gmail.com


Created an attachment (id=49984)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=49984)
The main menu of the game, pixelated

The title says it all.

I attached a picture of Crayon Physics Deluxe showing the issue (the linux
version, not via wine).
With LIBGL_ALWAYS_INDIRECT=1 or LIBGL_ALWAYS_SOFTWARE=1, the game is correctly
rendered though very slow using the software rasterizer.

I'm using Ubuntu 11.04 x86_64 with xorg-edgers packages, and I'm up-to-date.

Also, when running the game from the console, I got spammed with :
/usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so: wrong ELF class: ELFCLASS64
(:4547): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/immodules/im-ibus.so:
wrong ELF class: ELFCLASS64

So maybe it's an issue with 32 vs 64 bits.

FYI :
alex at Leon:~$ LIBGL_DEBUG=verbose glxinfo
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/r600_dri.so

-> means symbolic link
/usr/lib/libGL.so.1 -> /usr/lib/libGL.so -> /usr/lib32/libGL.so ->
/usr/lib32/mesa/libGL.so.1 -> /usr/lib32/mesa/libGL.so.1.2
alex at Leon:~$ file /usr/lib32/mesa/libGL.so.1.2 
/usr/lib32/mesa/libGL.so.1.2: ELF 32-bit LSB shared object, Intel 80386,
version 1 (SYSV), dynamically linked, for GNU/Linux 2.4.20, stripped

Note that I've done
/usr/lib/libGL.so.1 -> /usr/lib/libGL.so -> /usr/lib32/libGL.so
to make wine happy.
I guess for 32 bits it's ok but not for 64 bit :

/usr/lib64/libGL.so.1 -> /usr/lib64/libGL.so
alex at Leon:~$ file /usr/lib64/libGL.so
/usr/lib64/libGL.so: symbolic link to `/usr/lib32/libGL.so'

alex at Leon:~$ sudo ldconfig -p | grep libGL.so
libGL.so.1 (libc6,x86-64, OS ABI: Linux 2.4.20) =>
/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
libGL.so.1 (libc6, OS ABI: Linux 2.4.20) => /usr/lib/libGL.so.1
libGL.so (libc6,x86-64, OS ABI: Linux 2.4.20) =>
/usr/lib/x86_64-linux-gnu/libGL.so
libGL.so (libc6,x86-64, OS ABI: Linux 2.4.20) =>
/usr/lib/x86_64-linux-gnu/mesa/libGL.so
libGL.so (libc6, OS ABI: Linux 2.4.20) => /usr/lib32/libGL.so
libGL.so (libc6, OS ABI: Linux 2.4.20) => /usr/lib/libGL.so

I know the driver is being actively developed and hacked but maybe it's related
to a mis-configuration or something like that.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 27314] displayport link training fails on certain panels (channel equalization fails)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=27314

--- Comment #53 from Ortwin Gl?ck  2011-08-06 01:29:30 PDT ---
I am happy to report that with kernel 3.0.1 all works well on the iMac 27".

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 27314] displayport link training fails on certain panels (channel equalization fails)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=27314

--- Comment #53 from Ortwin Glück o...@odi.ch 2011-08-06 01:29:30 PDT ---
I am happy to report that with kernel 3.0.1 all works well on the iMac 27.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39877] New: Games rendered pixelated

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39877

   Summary: Games rendered pixelated
   Product: DRI
   Version: XOrg CVS
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: cerebro.alex...@gmail.com


Created an attachment (id=49984)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=49984)
The main menu of the game, pixelated

The title says it all.

I attached a picture of Crayon Physics Deluxe showing the issue (the linux
version, not via wine).
With LIBGL_ALWAYS_INDIRECT=1 or LIBGL_ALWAYS_SOFTWARE=1, the game is correctly
rendered though very slow using the software rasterizer.

I'm using Ubuntu 11.04 x86_64 with xorg-edgers packages, and I'm up-to-date.

Also, when running the game from the console, I got spammed with :
/usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so: wrong ELF class: ELFCLASS64
(unknown:4547): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/immodules/im-ibus.so:
wrong ELF class: ELFCLASS64

So maybe it's an issue with 32 vs 64 bits.

FYI :
alex@Leon:~$ LIBGL_DEBUG=verbose glxinfo
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/r600_dri.so

- means symbolic link
/usr/lib/libGL.so.1 - /usr/lib/libGL.so - /usr/lib32/libGL.so -
/usr/lib32/mesa/libGL.so.1 - /usr/lib32/mesa/libGL.so.1.2
alex@Leon:~$ file /usr/lib32/mesa/libGL.so.1.2 
/usr/lib32/mesa/libGL.so.1.2: ELF 32-bit LSB shared object, Intel 80386,
version 1 (SYSV), dynamically linked, for GNU/Linux 2.4.20, stripped

Note that I've done
/usr/lib/libGL.so.1 - /usr/lib/libGL.so - /usr/lib32/libGL.so
to make wine happy.
I guess for 32 bits it's ok but not for 64 bit :

/usr/lib64/libGL.so.1 - /usr/lib64/libGL.so
alex@Leon:~$ file /usr/lib64/libGL.so
/usr/lib64/libGL.so: symbolic link to `/usr/lib32/libGL.so'

alex@Leon:~$ sudo ldconfig -p | grep libGL.so
libGL.so.1 (libc6,x86-64, OS ABI: Linux 2.4.20) =
/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
libGL.so.1 (libc6, OS ABI: Linux 2.4.20) = /usr/lib/libGL.so.1
libGL.so (libc6,x86-64, OS ABI: Linux 2.4.20) =
/usr/lib/x86_64-linux-gnu/libGL.so
libGL.so (libc6,x86-64, OS ABI: Linux 2.4.20) =
/usr/lib/x86_64-linux-gnu/mesa/libGL.so
libGL.so (libc6, OS ABI: Linux 2.4.20) = /usr/lib32/libGL.so
libGL.so (libc6, OS ABI: Linux 2.4.20) = /usr/lib/libGL.so

I know the driver is being actively developed and hacked but maybe it's related
to a mis-configuration or something like that.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39877] Games rendered pixelated

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39877

--- Comment #1 from Alex cerebro.alex...@gmail.com 2011-08-06 01:32:10 PDT ---
Created an attachment (id=49985)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=49985)
My latest Xorg.0.log

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 37662] Upgrade to version 2.6.38, disable the laptop display back light

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=37662


Gary Liddle gary.lid...@sp1der.co.uk changed:

   What|Removed |Added

 CC||gary.lid...@sp1der.co.uk




--- Comment #3 from njin marconifa...@ubuntu-it.org  2011-06-21 16:30:44 ---
@ Len Brown
Go up and below assigned to there's the launchpad URL, if this is not the right
procedure, please advice me.
Thanks
Fabio

--- Comment #4 from Gary Liddle gary.lid...@sp1der.co.uk  2011-08-06 10:42:14 
---
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/740893

Hey

I have the same laptop and have the same problem when i updated the Kernel.

I've been running 2.6.35.22 which has no problems.

I initially updated to 2.6.38-8 which i thought at first had failed, but
noticed the screen was only usable (and i use that word very lightly) in direct
sunlight.

I've now updated to 2.6.38-10 which has the same problem as 2.6.38-8, no back
light on the monitor.

I'm currently viewing the laptop on 2.6.38-10 through an external monitor so i
can try to resolve the problem and can run any diagnostic commands you require.

Please see the above launchpad link for all the debug information regarding
this problem.

Thanks,
Gary

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39683] radeon hd6770 flex dpms fails to unblank one display sometimes

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39683

--- Comment #7 from aaron chainsawb...@gmail.com 2011-08-06 03:45:40 PDT ---
i checked the settings and found nothing, so i decided to switch the displays
around to see what happens...
original layout (1):
dvi - 1
hdmi - 2
dp - 3

layout 2:
dvi - 2
hdmi - 1
dp - 3
ran xset dpms force off via ssh
all 3 turned back on but 3 was distinctly after 1,2
(under setup 1 they all turn back on at about the same time the second time
round)
xset -q says displays off
same result every time

layout 3:
dvi - 3
hdmi - 2
dp - 1
same result as layout 1 but it starts  at a different point in the loop -
xrandr says display on but display 3 is off immediately after starting X

it may have something to do with a race condition relating to the speeds the
dislays start ( i probably have no idea what i am talking about...) as when
setting up xorg.conf if i used right-of it complained about missing modes or
something - it only worked as i expected it to when left-of'd from display 3
will investigate further in the next few days

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 29136] compiz + wallpaper plugin + expo causes X to crash

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=29136

aaron chainsawb...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
 CC||chainsawb...@gmail.com

--- Comment #1 from aaron chainsawb...@gmail.com 2011-08-06 03:50:52 PDT ---
works with gallium

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 33790] [r300g] Black windows with opengl apps (ex. glxgears)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=33790

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTOURBUG

--- Comment #7 from Alex Deucher ag...@yahoo.com 2011-08-06 06:15:36 PDT ---
(In reply to comment #6)
 You got it,
 adding pci=nomsi to kernel solves all issues.
 Is this a real solution or just a workaround for a known bug?

It seems MSIs aren't working on your system.  Probably motherboard chipset
issue or system bios bug.  You might want to bring it up on the linux kernel
mailing list.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39877] Games rendered pixelated

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39877

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

  Attachment #49985|text/x-log  |text/plain
  mime type||
  Attachment #49985|0   |1
   is patch||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39877] Games rendered pixelated

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39877

--- Comment #2 from Alex Deucher ag...@yahoo.com 2011-08-06 06:20:00 PDT ---
Update mesa to 7.11 or disable colortiling:
Option ColorTiling False
in the device section of your xorg conf.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39882] New: Regression: Plugging in a HDMI connector makes the LCD of X120e go dark

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39882

   Summary: Regression: Plugging in a HDMI connector makes the LCD
of X120e go dark
   Product: DRI
   Version: XOrg CVS
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: gottfried.hai...@gmail.com


When I plug in my external TFT monitor while my X120e is in use, the laptop's
internal LCD immediately goes dark - yet I don't have a picture on the TFT.

I first noticed this with kernel 3.0.0, this is fully reproducible also on
3.0.1. Since I did not remember this happening before, I tested with an older
kernel (Ubuntu's 2.6.38, but should not make a difference), and indeed: with
2.6.38 the internal LCD stays on (which is the expected behavior).

The TFT is connected via a HDMI-to-DVI cable. Userspace is Xubuntu 11.04 with
xorg-edgers PPA.

At a first glance, I do not see anything interesting in either dmesg or
Xorg.log when this happens. Note: the machine does not hang, since I can still
(blindly) launch a terminal and make the machine restart - for which I briefly
get a picture on the LCD again after XOrg shutdown.

I am attaching lspci and a dmesg/Xorg.log below - please let me know if I can
help with anything else (I can easily test kernel patches).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39882] Regression: Plugging in a HDMI connector makes the LCD of X120e go dark

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39882

--- Comment #1 from gottfried.hai...@gmail.com 2011-08-06 06:28:25 PDT ---
Created an attachment (id=49992)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=49992)
lspci of Lenovo X120e

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39882] Regression: Plugging in a HDMI connector makes the LCD of X120e go dark

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39882

--- Comment #2 from gottfried.hai...@gmail.com 2011-08-06 06:31:57 PDT ---
Created an attachment (id=49993)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=49993)
dmesg (nothing interesting after HDMI insertion)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39882] Regression: Plugging in a HDMI connector makes the LCD of X120e go dark

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39882

--- Comment #3 from gottfried.hai...@gmail.com 2011-08-06 06:33:29 PDT ---
Created an attachment (id=49994)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=49994)
Xorg.log (HDMI insertion happened just before 906.688)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39882] Regression: Plugging in a HDMI connector makes the LCD of X120e go dark

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39882

--- Comment #4 from Alex Deucher ag...@yahoo.com 2011-08-06 07:27:46 PDT ---
Can you bisect?  If I had to guess, it's probably one of the display rework
patches added in 3.0.  Does a VT switch help?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

drm/i915: Disabling unused outputs on CPT is broken

[Keith Packard]

Here's a fun sequence:

$ xrandr --output LVDS1 --auto --crtc 1
$ sudo chvt 1

(then switch back to X)

The LVDS goes black. Why? The LVDS is *disabled*. Turns out that the
cause was that after the mode was all nicely set,
intel_disable_pch_ports went and turned it back off.

Well, a couple of weeks ago, we found that intel_disable_pch_ports was
doing the same thing to DP ports, and the cause was that the way to
tell which port a DP output was running from is different on CPT that
on every other chip. We fixed that, but didn't (foolishly) review the
non-DP code.

Oddly, the non-DP code had essentially the same bug:

 [PATCH 3/4] drm/i915: Fix PCH port pipe select in CPT disable paths

Also in this sequence is some code that validates the LVDS panel power
sequencing which discovered that the LVDS panel wasn't being disabled
correctly because the LVDS registers were locked in the DPMS
function. Instead of trying to get the LVDS locking right, I've just
unlocked the registers in the lvds initialization code and left them
unlocked after that:

 [PATCH 1/4] drm/i915: Wait for LVDS panel power sequence
 [PATCH 2/4] drm/i915: Leave LVDS registers unlocked

Finally, I removed an unused argument to dp_pipe_enable while I was
poking around in that code:

 [PATCH 4/4] drm/i915: Remove unused 'reg' argument to dp_pipe_enable

--
keith.pack...@intel.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] drm/i915: Wait for LVDS panel power sequence

[Keith Packard]

During mode setting, check to make sure the panel power sequencing has
completed before doing further operations on the device. This
uncovered errors with DPMS not turning the device off as it was left locked.

Signed-off-by: Keith Packard kei...@keithp.com
---
 drivers/gpu/drm/i915/intel_lvds.c |   13 +++--
 1 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 2e8ddfc..6985e42 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -72,14 +72,16 @@ static void intel_lvds_enable(struct intel_lvds *intel_lvds)
 {
struct drm_device *dev = intel_lvds-base.base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
-   u32 ctl_reg, lvds_reg;
+   u32 ctl_reg, lvds_reg, stat_reg;
 
if (HAS_PCH_SPLIT(dev)) {
ctl_reg = PCH_PP_CONTROL;
lvds_reg = PCH_LVDS;
+   stat_reg = PCH_PP_STATUS;
} else {
ctl_reg = PP_CONTROL;
lvds_reg = LVDS;
+   stat_reg = PP_STATUS;
}
 
I915_WRITE(lvds_reg, I915_READ(lvds_reg) | LVDS_PORT_EN);
@@ -105,6 +107,8 @@ 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);
+   if (wait_for((I915_READ(stat_reg)  PP_ON) != 0, 1000))
+   DRM_ERROR(timed out waiting for panel to power on\n);
 
intel_panel_enable_backlight(dev);
 }
@@ -113,19 +117,24 @@ static void intel_lvds_disable(struct intel_lvds 
*intel_lvds)
 {
struct drm_device *dev = intel_lvds-base.base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
-   u32 ctl_reg, lvds_reg;
+   u32 ctl_reg, lvds_reg, stat_reg;
 
if (HAS_PCH_SPLIT(dev)) {
ctl_reg = PCH_PP_CONTROL;
lvds_reg = PCH_LVDS;
+   stat_reg = PCH_PP_STATUS;
} else {
ctl_reg = PP_CONTROL;
lvds_reg = LVDS;
+   stat_reg = PP_STATUS;
}
 
intel_panel_disable_backlight(dev);
 
I915_WRITE(ctl_reg, I915_READ(ctl_reg)  ~POWER_TARGET_ON);
+   if (wait_for((I915_READ(stat_reg)  PP_ON) == 0, 1000))
+   DRM_ERROR(timed out waiting for panel to power off status 
0x%08x control 0x%08x\n,
+ I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
 
if (intel_lvds-pfit_control) {
if (wait_for((I915_READ(PP_STATUS)  PP_ON) == 0, 1000))
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/4] drm/i915: Leave LVDS registers unlocked

[Keith Packard]

There's no reason to relock them; it just makes operations more
complex. This fixes DPMS where the panel registers were locked making
the disable not work.

Signed-off-by: Keith Packard kei...@keithp.com
---
 drivers/gpu/drm/i915/intel_lvds.c |   46 +++-
 1 files changed, 19 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 6985e42..cc85618 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -414,46 +414,32 @@ static void intel_lvds_prepare(struct drm_encoder 
*encoder)
/* We try to do the minimum that is necessary in order to unlock
 * the registers for mode setting.
 *
-* On Ironlake, this is quite simple as we just set the unlock key
-* and ignore all subtleties. (This may cause some issues...)
+* On Ironlake, this is quite simple as we just set the unlock
+* key in the driver init code and ignore all subtleties.
+* (This may cause some issues...)
 *
 * Prior to Ironlake, we must disable the pipe if we want to adjust
 * the panel fitter. However at all other times we can just reset
 * the registers regardless.
 */
 
-   if (HAS_PCH_SPLIT(dev)) {
-   I915_WRITE(PCH_PP_CONTROL,
-  I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS);
-   } else if (intel_lvds-pfit_dirty) {
-   I915_WRITE(PP_CONTROL,
-  (I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS)
-   ~POWER_TARGET_ON);
-   } else {
-   I915_WRITE(PP_CONTROL,
-  I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
+   if (!HAS_PCH_SPLIT(dev)) {
+   if (intel_lvds-pfit_dirty) {
+   I915_WRITE(PP_CONTROL,
+  (I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS)
+   ~POWER_TARGET_ON);
+   } else {
+   I915_WRITE(PP_CONTROL,
+  I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
+   }
}
+   intel_lvds_disable(intel_lvds);
 }
 
 static void intel_lvds_commit(struct drm_encoder *encoder)
 {
-   struct drm_device *dev = encoder-dev;
-   struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_lvds *intel_lvds = to_intel_lvds(encoder);
 
-   /* Undo any unlocking done in prepare to prevent accidental
-* adjustment of the registers.
-*/
-   if (HAS_PCH_SPLIT(dev)) {
-   u32 val = I915_READ(PCH_PP_CONTROL);
-   if ((val  PANEL_UNLOCK_REGS) == PANEL_UNLOCK_REGS)
-   I915_WRITE(PCH_PP_CONTROL, val  0x3);
-   } else {
-   u32 val = I915_READ(PP_CONTROL);
-   if ((val  PANEL_UNLOCK_REGS) == PANEL_UNLOCK_REGS)
-   I915_WRITE(PP_CONTROL, val  0x3);
-   }
-
/* Always do a full power on as we do not know what state
 * we were left in.
 */
@@ -1049,6 +1035,12 @@ out:
pwm = I915_READ(BLC_PWM_PCH_CTL1);
pwm |= PWM_PCH_ENABLE;
I915_WRITE(BLC_PWM_PCH_CTL1, pwm);
+   /*
+* Unlock registers and just
+* leave them unlocked
+*/
+   I915_WRITE(PCH_PP_CONTROL,
+  I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS);
}
dev_priv-lid_notifier.notifier_call = intel_lid_notify;
if (acpi_lid_notifier_register(dev_priv-lid_notifier)) {
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/4] drm/i915: Remove unused 'reg' argument to dp_pipe_enabled

[Keith Packard]

Just an extra parameter which isn't actually needed.

Signed-off-by: Keith Packard kei...@keithp.com
---
 drivers/gpu/drm/i915/intel_display.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 4c4c903..f6f18c7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -980,8 +980,8 @@ static void assert_transcoder_disabled(struct 
drm_i915_private *dev_priv,
 pipe_name(pipe));
 }
 
-static bool dp_pipe_enabled(struct drm_i915_private *dev_priv, enum pipe pipe,
-   int reg, u32 port_sel, u32 val)
+static bool dp_pipe_enabled(struct drm_i915_private *dev_priv,
+   enum pipe pipe, u32 port_sel, u32 val)
 {
if ((val  DP_PORT_EN) == 0)
return false;
@@ -1049,7 +1049,7 @@ static void assert_pch_dp_disabled(struct 
drm_i915_private *dev_priv,
   enum pipe pipe, int reg, u32 port_sel)
 {
u32 val = I915_READ(reg);
-   WARN(dp_pipe_enabled(dev_priv, pipe, reg, port_sel, val),
+   WARN(dp_pipe_enabled(dev_priv, pipe, port_sel, val),
 PCH DP (0x%08x) enabled on transcoder %c, should be disabled\n,
 reg, pipe_name(pipe));
 }
@@ -1407,7 +1407,7 @@ static void disable_pch_dp(struct drm_i915_private 
*dev_priv,
   enum pipe pipe, int reg, u32 port_sel)
 {
u32 val = I915_READ(reg);
-   if (dp_pipe_enabled(dev_priv, pipe, reg, port_sel, val)) {
+   if (dp_pipe_enabled(dev_priv, pipe, port_sel, val)) {
DRM_DEBUG_KMS(Disabling pch dp %x on pipe %d\n, reg, pipe);
I915_WRITE(reg, val  ~DP_PORT_EN);
}
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/4] drm/i915: Fix PCH port pipe select in CPT disable paths

[Keith Packard]

CPT pipe select is different from previous generations (using two bits
instead of one). All of the paths from intel_disable_pch_ports were
not making this distinction.

Mode setting with pipe A turned off would then also force all outputs
on pipe B to get turned off as the disable code would mistakenly
decide that all of these outputs were on pipe A and turn them off.

This is an extension of the CPT DP disable fix (why didn't I fix this then?)

Signed-off-by: Keith Packard kei...@keithp.com
---
 drivers/gpu/drm/i915/i915_reg.h  |   13 ++-
 drivers/gpu/drm/i915/intel_display.c |   60 ++---
 2 files changed, 58 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d1331f7..5baaef4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1318,6 +1318,7 @@
 #define   ADPA_PIPE_SELECT_MASK(130)
 #define   ADPA_PIPE_A_SELECT   0
 #define   ADPA_PIPE_B_SELECT   (130)
+#define   ADPA_PIPE_SELECT(pipe) ((pipe)  30)
 #define   ADPA_USE_VGA_HVPOLARITY (115)
 #define   ADPA_SETS_HVPOLARITY 0
 #define   ADPA_VSYNC_CNTL_DISABLE (111)
@@ -1460,6 +1461,7 @@
 /* Selects pipe B for LVDS data.  Must be set on pre-965. */
 #define   LVDS_PIPEB_SELECT(1  30)
 #define   LVDS_PIPE_MASK   (1  30)
+#define   LVDS_PIPE(pipe)  ((pipe)  30)
 /* LVDS dithering flag on 965/g4x platform */
 #define   LVDS_ENABLE_DITHER   (1  25)
 /* LVDS sync polarity flags. Set to invert (i.e. negative) */
@@ -1499,9 +1501,6 @@
 #define   LVDS_B0B3_POWER_DOWN (0  2)
 #define   LVDS_B0B3_POWER_UP   (3  2)
 
-#define LVDS_PIPE_ENABLED(V, P) \
-   (((V)  (LVDS_PIPE_MASK | LVDS_PORT_EN)) == ((P)  30 | LVDS_PORT_EN))
-
 /* Video Data Island Packet control */
 #define VIDEO_DIP_DATA 0x61178
 #define VIDEO_DIP_CTL  0x61170
@@ -3256,14 +3255,12 @@
 #define  ADPA_CRT_HOTPLUG_VOLREF_475MV  (117)
 #define  ADPA_CRT_HOTPLUG_FORCE_TRIGGER (116)
 
-#define ADPA_PIPE_ENABLED(V, P) \
-   (((V)  (ADPA_TRANS_SELECT_MASK | ADPA_DAC_ENABLE)) == ((P)  30 | 
ADPA_DAC_ENABLE))
-
 /* or SDVOB */
 #define HDMIB   0xe1140
 #define  PORT_ENABLE(1  31)
 #define  TRANSCODER_A   (0)
 #define  TRANSCODER_B   (1  30)
+#define  TRANSCODER(pipe)  ((pipe)  30)
 #define  TRANSCODER_MASK   (1  30)
 #define  COLOR_FORMAT_8bpc  (0)
 #define  COLOR_FORMAT_12bpc (3  26)
@@ -3280,9 +3277,6 @@
 #define  HSYNC_ACTIVE_HIGH  (1  3)
 #define  PORT_DETECTED  (1  2)
 
-#define HDMI_PIPE_ENABLED(V, P) \
-   (((V)  (TRANSCODER_MASK | PORT_ENABLE)) == ((P)  30 | PORT_ENABLE))
-
 /* PCH SDVOB multiplex with HDMIB */
 #define PCH_SDVOB  HDMIB
 
@@ -3349,6 +3343,7 @@
 #define  PORT_TRANS_B_SEL_CPT  (129)
 #define  PORT_TRANS_C_SEL_CPT  (229)
 #define  PORT_TRANS_SEL_MASK   (329)
+#define  PORT_TRANS_SEL_CPT(pipe)  ((pipe)  29)
 
 #define TRANS_DP_CTL_A 0xe0300
 #define TRANS_DP_CTL_B 0xe1300
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 35364e6..4c4c903 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -998,6 +998,53 @@ static bool dp_pipe_enabled(struct drm_i915_private 
*dev_priv, enum pipe pipe,
return true;
 }
 
+static bool hdmi_pipe_enabled(struct drm_i915_private *dev_priv,
+ enum pipe pipe, u32 val)
+{
+   if ((val  PORT_ENABLE) == 0)
+   return false;
+
+   if (HAS_PCH_CPT(dev_priv-dev)) {
+   if ((val  PORT_TRANS_SEL_MASK) != PORT_TRANS_SEL_CPT(pipe))
+   return false;
+   } else {
+   if ((val  TRANSCODER_MASK) != TRANSCODER(pipe))
+   return false;
+   }
+   return true;
+}
+
+static bool lvds_pipe_enabled(struct drm_i915_private *dev_priv,
+ enum pipe pipe, u32 val)
+{
+   if ((val  LVDS_PORT_EN) == 0)
+   return false;
+
+   if (HAS_PCH_CPT(dev_priv-dev)) {
+   if ((val  PORT_TRANS_SEL_MASK) != PORT_TRANS_SEL_CPT(pipe))
+   return false;
+   } else {
+   if ((val  LVDS_PIPE_MASK) != LVDS_PIPE(pipe))
+   return false;
+   }
+   return true;
+}
+
+static bool adpa_pipe_enabled(struct drm_i915_private *dev_priv,
+ enum pipe pipe, u32 val)
+{
+   if ((val  ADPA_DAC_ENABLE) == 0)
+   return false;
+   if (HAS_PCH_CPT(dev_priv-dev)) {
+   if ((val  PORT_TRANS_SEL_MASK) != PORT_TRANS_SEL_CPT(pipe))
+   return false;
+   } else {
+   if ((val  ADPA_PIPE_SELECT_MASK) != ADPA_PIPE_SELECT(pipe))
+   return false;
+   }
+   return true;
+}
+
 static void assert_pch_dp_disabled(struct drm_i915_private *dev_priv,
   enum pipe pipe, 

[Bug 36602] Hierarchical Z support for R600

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36602

--- Comment #22 from Sven Arvidsson s...@whiz.se 2011-08-06 12:18:04 PDT ---
I followed Andy's advice and grabbed a d-r-t kernel, now everything seems to be
running okay.

On my HD5670 I haven't noticed any difference in performance, OTOH neither do I
get the corruption mentioned, cubemap renders correctly.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36602] Hierarchical Z support for R600

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36602

Sven Arvidsson s...@whiz.se changed:

   What|Removed |Added

  Attachment #49931|0   |1
is obsolete||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 33348] [r300g] Display corruption (artifacts) when using 3D graphics...

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=33348

Dawit Alemayehu ada...@kde.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #25 from Dawit Alemayehu ada...@kde.org 2011-08-06 12:19:07 PDT 
---
Seems to be finally fixed in Mesa 7.11. Dunno what the cause was, but it works
fine for me on the hardware and driver I reported with the shinny new Mesa
7.11. Big thanks for whomever fixed this problem.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39882] Regression: Plugging in a HDMI connector makes the LCD of X120e go dark

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39882

--- Comment #5 from gottfried.hai...@gmail.com 2011-08-06 12:26:19 PDT ---
Sorry, I tried bisecting, but defconfig does not boot here.. and my normal
config takes ages for a full rebuild.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] pass ELD to HDMI/DP audio driver

[Keith Packard]

 Good questions!  In general the audio functionalities should not
 depend on the display activeness. There are even audio-only HDMI
 devices. So I'll need to make intel_write_eld() work even without
 information about the current display mode.

Yeah, we'll need to figure out what the ELD should look like with no
display active. I think you've got the whole link available, so there
shouldn't be any restrictions on formats.

 That would be a good feature. For one thing, I find it annoying that
 the music playback fades out when the screen goes to power saving
 mode..

I'm not sure we can make it completely seamless without keeping most of
the pipe active (which will consume some power). Probably we'll just
leave the clock alone while the display is DPMS'd, but if we actually
need the resources for another display, I'm afraid there may be some
noise on the HDMI audio link. Will need experimentation to figure out
how to make this work as nicely as possible.

I was just reading through the reference manual and found that there is
a mode that leaves the HDMI running without requiring a pipe or plane,
just the FDI PLL. So, audio without display seems pretty simple now;
just a matter of a bit of API negotiation between the audio and video
drivers.

-- 
keith.pack...@intel.com


pgpxzhCNvG4Rt.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] gpu/stub: try to make help text readable

[Randy Dunlap]

From: Randy Dunlap rdun...@xenotime.net

I couldn't parse the STUB_POULSBO help text and the module names
were misleading, so try to make it more readable, use corrected
module names, and spell acpi as ACPI.

Signed-off-by: Randy Dunlap rdun...@xenotime.net
Cc: Lee, Chun-Yi j...@novell.com
Cc: Lee, Chun-Yi joeyli.ker...@gmail.com
Cc: Dave Airlie airl...@redhat.com
---
 drivers/gpu/stub/Kconfig |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- linux-3.0-git22.orig/drivers/gpu/stub/Kconfig
+++ linux-3.0-git22/drivers/gpu/stub/Kconfig
@@ -12,7 +12,7 @@ config STUB_POULSBO
help
  Choose this option if you have a system that has Intel GMA500
  (Poulsbo) integrated graphics. If M is selected, the module will
- be called Poulsbo. This driver is a stub driver for Poulsbo that
- will call poulsbo.ko to enable the acpi backlight control sysfs
- entry file because there have no poulsbo native driver can support
+ be called poulsbo. This driver is a stub driver for Poulsbo that
+ will call psb_gfx.ko to enable the ACPI backlight control sysfs
+ entry file because there is no poulsbo native driver that supports
  intel opregion.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel