All of lore.kernel.org
 help / color / mirror / Atom feed
* Broken LVDS output at mode changes
@ 2012-03-28 13:29 Takashi Iwai
  2012-03-29 12:16 ` Daniel Vetter
  0 siblings, 1 reply; 11+ messages in thread
From: Takashi Iwai @ 2012-03-28 13:29 UTC (permalink / raw)
  To: intel-gfx

Hi,

we've encountered a broken LVDS output on some IVY/SNB machines when
the mode is changed (from/to native resolution).  When this happens,
the whole laptop panel gets half white and half black.  This doesn't
recover until the LVDS is turned off once.

And, there is no signficant difference between working and non-working
cases in the register dumps.  From the software POV, all looks sane.
So, we suspect this is rather specific to some panel hardware.

However, through debugging, I found that disabling LVDS at mode change
works around the problem.  A test patch is attached below.

My question now is: can this workaround have any serious drawback?
I thought of a longer blank time, but I didn't notice any difference
before and after the patch.

Or, any other suggestion as a saner fix?


thanks,

Takashi

---
---
 drivers/gpu/drm/i915/intel_lvds.c |   23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -398,6 +398,26 @@ out:
 	return true;
 }
 
+static int intel_disable_at_modeset_callback(const struct dmi_system_id *id)
+{
+	DRM_DEBUG_KMS("Disabling LVDS at modeset for %s\n", id->ident);
+	return 1;
+}
+
+/* Requires to disable LVDS for avoiding a broken screen at mode change */
+static const struct dmi_system_id intel_disable_at_modeset[] = {
+	{
+		.callback = intel_disable_at_modeset_callback,
+		.ident = "HP ProBook",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "HP ProBook"),
+		},
+	},
+
+	{ }	/* terminating entry */
+};
+
 static void intel_lvds_prepare(struct drm_encoder *encoder)
 {
 	struct intel_lvds *intel_lvds = to_intel_lvds(encoder);
@@ -407,7 +427,8 @@ static void intel_lvds_prepare(struct dr
 	 * the panel fitter. However at all other times we can just reset
 	 * the registers regardless.
 	 */
-	if (!HAS_PCH_SPLIT(encoder->dev) && intel_lvds->pfit_dirty)
+	if ((!HAS_PCH_SPLIT(encoder->dev) && intel_lvds->pfit_dirty) ||
+	    dmi_check_system(intel_disable_at_modeset))
 		intel_lvds_disable(intel_lvds);
 }

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Broken LVDS output at mode changes
  2012-03-28 13:29 Broken LVDS output at mode changes Takashi Iwai
@ 2012-03-29 12:16 ` Daniel Vetter
  2012-03-29 12:44   ` Chris Wilson
  0 siblings, 1 reply; 11+ messages in thread
From: Daniel Vetter @ 2012-03-29 12:16 UTC (permalink / raw)
  To: Takashi Iwai, Chris Wilson; +Cc: intel-gfx

On Wed, Mar 28, 2012 at 03:29:04PM +0200, Takashi Iwai wrote:
> Hi,
> 
> we've encountered a broken LVDS output on some IVY/SNB machines when
> the mode is changed (from/to native resolution).  When this happens,
> the whole laptop panel gets half white and half black.  This doesn't
> recover until the LVDS is turned off once.
> 
> And, there is no signficant difference between working and non-working
> cases in the register dumps.  From the software POV, all looks sane.
> So, we suspect this is rather specific to some panel hardware.
> 
> However, through debugging, I found that disabling LVDS at mode change
> works around the problem.  A test patch is attached below.
> 
> My question now is: can this workaround have any serious drawback?
> I thought of a longer blank time, but I didn't notice any difference
> before and after the patch.
> 
> Or, any other suggestion as a saner fix?

No idea, I'm wondering though whether we should just accept some
flickering while modesetting unconditionally. Does anyone know what
Windows does in this case and at least on my work machine here it looks
like Windows just blanks the screen. I haven't checked with reg dumps
though how exactly they upscale stuff on lvds.

git blame says that Chris Wilson created the original PCH_SPLIT check.
Chris, any comments on this?

Yours, Daniel
> 
> 
> thanks,
> 
> Takashi
> 
> ---
> ---
>  drivers/gpu/drm/i915/intel_lvds.c |   23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -398,6 +398,26 @@ out:
>  	return true;
>  }
>  
> +static int intel_disable_at_modeset_callback(const struct dmi_system_id *id)
> +{
> +	DRM_DEBUG_KMS("Disabling LVDS at modeset for %s\n", id->ident);
> +	return 1;
> +}
> +
> +/* Requires to disable LVDS for avoiding a broken screen at mode change */
> +static const struct dmi_system_id intel_disable_at_modeset[] = {
> +	{
> +		.callback = intel_disable_at_modeset_callback,
> +		.ident = "HP ProBook",
> +		.matches = {
> +			DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> +			DMI_MATCH(DMI_PRODUCT_NAME, "HP ProBook"),
> +		},
> +	},
> +
> +	{ }	/* terminating entry */
> +};
> +
>  static void intel_lvds_prepare(struct drm_encoder *encoder)
>  {
>  	struct intel_lvds *intel_lvds = to_intel_lvds(encoder);
> @@ -407,7 +427,8 @@ static void intel_lvds_prepare(struct dr
>  	 * the panel fitter. However at all other times we can just reset
>  	 * the registers regardless.
>  	 */
> -	if (!HAS_PCH_SPLIT(encoder->dev) && intel_lvds->pfit_dirty)
> +	if ((!HAS_PCH_SPLIT(encoder->dev) && intel_lvds->pfit_dirty) ||
> +	    dmi_check_system(intel_disable_at_modeset))
>  		intel_lvds_disable(intel_lvds);
>  }
>  
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Broken LVDS output at mode changes
  2012-03-29 12:16 ` Daniel Vetter
@ 2012-03-29 12:44   ` Chris Wilson
  2012-03-29 12:51     ` Daniel Vetter
                       ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Chris Wilson @ 2012-03-29 12:44 UTC (permalink / raw)
  To: Daniel Vetter, Takashi Iwai; +Cc: intel-gfx

On Thu, 29 Mar 2012 14:16:38 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Mar 28, 2012 at 03:29:04PM +0200, Takashi Iwai wrote:
> > Hi,
> > 
> > we've encountered a broken LVDS output on some IVY/SNB machines when
> > the mode is changed (from/to native resolution).  When this happens,
> > the whole laptop panel gets half white and half black.  This doesn't
> > recover until the LVDS is turned off once.
> > 
> > And, there is no signficant difference between working and non-working
> > cases in the register dumps.  From the software POV, all looks sane.
> > So, we suspect this is rather specific to some panel hardware.
> > 
> > However, through debugging, I found that disabling LVDS at mode change
> > works around the problem.  A test patch is attached below.
> > 
> > My question now is: can this workaround have any serious drawback?
> > I thought of a longer blank time, but I didn't notice any difference
> > before and after the patch.
> > 
> > Or, any other suggestion as a saner fix?
> 
> No idea, I'm wondering though whether we should just accept some
> flickering while modesetting unconditionally. Does anyone know what
> Windows does in this case and at least on my work machine here it looks
> like Windows just blanks the screen. I haven't checked with reg dumps
> though how exactly they upscale stuff on lvds.
> 
> git blame says that Chris Wilson created the original PCH_SPLIT check.
> Chris, any comments on this?

It dates back from an earlier commit that presupposes that we can modify
the panel on the fly and avoid the power-cycling delays.

PP_STATUS: Panel Power On Status [bit 31]

In conjunction with bits Power Sequence Progress field and Power Cycle
Delay Active, this bit set to a one indicates that the panel is
currently powered up or is currently in the power down sequence and it
is unsafe to change the timing, port, and DPLL registers for the pipe or
transcoder that is assigned to the panel output.

Guess that rules that out.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Broken LVDS output at mode changes
  2012-03-29 12:44   ` Chris Wilson
@ 2012-03-29 12:51     ` Daniel Vetter
  2012-03-29 12:55       ` Takashi Iwai
  2012-03-29 15:07     ` Keith Packard
  2012-03-30 16:56     ` Jesse Barnes
  2 siblings, 1 reply; 11+ messages in thread
From: Daniel Vetter @ 2012-03-29 12:51 UTC (permalink / raw)
  To: Chris Wilson; +Cc: Takashi Iwai, intel-gfx

On Thu, Mar 29, 2012 at 01:44:28PM +0100, Chris Wilson wrote:
> On Thu, 29 Mar 2012 14:16:38 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Wed, Mar 28, 2012 at 03:29:04PM +0200, Takashi Iwai wrote:
> > > Hi,
> > > 
> > > we've encountered a broken LVDS output on some IVY/SNB machines when
> > > the mode is changed (from/to native resolution).  When this happens,
> > > the whole laptop panel gets half white and half black.  This doesn't
> > > recover until the LVDS is turned off once.
> > > 
> > > And, there is no signficant difference between working and non-working
> > > cases in the register dumps.  From the software POV, all looks sane.
> > > So, we suspect this is rather specific to some panel hardware.
> > > 
> > > However, through debugging, I found that disabling LVDS at mode change
> > > works around the problem.  A test patch is attached below.
> > > 
> > > My question now is: can this workaround have any serious drawback?
> > > I thought of a longer blank time, but I didn't notice any difference
> > > before and after the patch.
> > > 
> > > Or, any other suggestion as a saner fix?
> > 
> > No idea, I'm wondering though whether we should just accept some
> > flickering while modesetting unconditionally. Does anyone know what
> > Windows does in this case and at least on my work machine here it looks
> > like Windows just blanks the screen. I haven't checked with reg dumps
> > though how exactly they upscale stuff on lvds.
> > 
> > git blame says that Chris Wilson created the original PCH_SPLIT check.
> > Chris, any comments on this?
> 
> It dates back from an earlier commit that presupposes that we can modify
> the panel on the fly and avoid the power-cycling delays.
> 
> PP_STATUS: Panel Power On Status [bit 31]
> 
> In conjunction with bits Power Sequence Progress field and Power Cycle
> Delay Active, this bit set to a one indicates that the panel is
> currently powered up or is currently in the power down sequence and it
> is unsafe to change the timing, port, and DPLL registers for the pipe or
> transcoder that is assigned to the panel output.
> 
> Guess that rules that out.

Takashi, can you respin your patch to just unconditionally switch of the
lvds also on PCH_SPLIT platforms then?
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Broken LVDS output at mode changes
  2012-03-29 12:51     ` Daniel Vetter
@ 2012-03-29 12:55       ` Takashi Iwai
  0 siblings, 0 replies; 11+ messages in thread
From: Takashi Iwai @ 2012-03-29 12:55 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

At Thu, 29 Mar 2012 14:51:32 +0200,
Daniel Vetter wrote:
> 
> On Thu, Mar 29, 2012 at 01:44:28PM +0100, Chris Wilson wrote:
> > On Thu, 29 Mar 2012 14:16:38 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> > > On Wed, Mar 28, 2012 at 03:29:04PM +0200, Takashi Iwai wrote:
> > > > Hi,
> > > > 
> > > > we've encountered a broken LVDS output on some IVY/SNB machines when
> > > > the mode is changed (from/to native resolution).  When this happens,
> > > > the whole laptop panel gets half white and half black.  This doesn't
> > > > recover until the LVDS is turned off once.
> > > > 
> > > > And, there is no signficant difference between working and non-working
> > > > cases in the register dumps.  From the software POV, all looks sane.
> > > > So, we suspect this is rather specific to some panel hardware.
> > > > 
> > > > However, through debugging, I found that disabling LVDS at mode change
> > > > works around the problem.  A test patch is attached below.
> > > > 
> > > > My question now is: can this workaround have any serious drawback?
> > > > I thought of a longer blank time, but I didn't notice any difference
> > > > before and after the patch.
> > > > 
> > > > Or, any other suggestion as a saner fix?
> > > 
> > > No idea, I'm wondering though whether we should just accept some
> > > flickering while modesetting unconditionally. Does anyone know what
> > > Windows does in this case and at least on my work machine here it looks
> > > like Windows just blanks the screen. I haven't checked with reg dumps
> > > though how exactly they upscale stuff on lvds.
> > > 
> > > git blame says that Chris Wilson created the original PCH_SPLIT check.
> > > Chris, any comments on this?
> > 
> > It dates back from an earlier commit that presupposes that we can modify
> > the panel on the fly and avoid the power-cycling delays.
> > 
> > PP_STATUS: Panel Power On Status [bit 31]
> > 
> > In conjunction with bits Power Sequence Progress field and Power Cycle
> > Delay Active, this bit set to a one indicates that the panel is
> > currently powered up or is currently in the power down sequence and it
> > is unsafe to change the timing, port, and DPLL registers for the pipe or
> > transcoder that is assigned to the panel output.
> > 
> > Guess that rules that out.
> 
> Takashi, can you respin your patch to just unconditionally switch of the
> lvds also on PCH_SPLIT platforms then?

The hardware I've tested are actually on PCH_SPLIT, IvyBridge and
SandyBridge machines.  I'll test IronLake and GM45 machines whether
unconditonally switching will give any regressions.


Takashi

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Broken LVDS output at mode changes
  2012-03-29 12:44   ` Chris Wilson
  2012-03-29 12:51     ` Daniel Vetter
@ 2012-03-29 15:07     ` Keith Packard
  2012-03-29 16:12       ` Takashi Iwai
  2012-03-30 16:56     ` Jesse Barnes
  2 siblings, 1 reply; 11+ messages in thread
From: Keith Packard @ 2012-03-29 15:07 UTC (permalink / raw)
  To: Chris Wilson, Daniel Vetter, Takashi Iwai; +Cc: intel-gfx

<#part sign=pgpmime>
On Thu, 29 Mar 2012 13:44:28 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote:

> In conjunction with bits Power Sequence Progress field and Power Cycle
> Delay Active, this bit set to a one indicates that the panel is
> currently powered up or is currently in the power down sequence and it
> is unsafe to change the timing, port, and DPLL registers for the pipe or
> transcoder that is assigned to the panel output.

The theory was that as we don't touch the DPLL and only modify the
scaler, that the panel wouldn't care. I wonder what's confusing this one...

-- 
keith.packard@intel.com

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Broken LVDS output at mode changes
  2012-03-29 15:07     ` Keith Packard
@ 2012-03-29 16:12       ` Takashi Iwai
  2012-03-29 16:57         ` Keith Packard
  0 siblings, 1 reply; 11+ messages in thread
From: Takashi Iwai @ 2012-03-29 16:12 UTC (permalink / raw)
  To: Keith Packard; +Cc: intel-gfx

At Thu, 29 Mar 2012 08:07:05 -0700,
Keith Packard wrote:
> 
> On Thu, 29 Mar 2012 13:44:28 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> 
> > In conjunction with bits Power Sequence Progress field and Power Cycle
> > Delay Active, this bit set to a one indicates that the panel is
> > currently powered up or is currently in the power down sequence and it
> > is unsafe to change the timing, port, and DPLL registers for the pipe or
> > transcoder that is assigned to the panel output.
> 
> The theory was that as we don't touch the DPLL and only modify the
> scaler, that the panel wouldn't care. I wonder what's confusing this one...

The strange thing is that, although you can recover the display by
turning off LVDS and on again once when the problem happens, but then
the display starts flickering.  And, the flickering continues even
after reboot on BIOS boot screen.  Even BIOS can't recover the problem
by itself, too, as it seems.  Then, keep the machine rest for long
time and boot up, now the problem is gone.

BTW, now I tested to disable LVDS unconditionally on different
platforms as Daniel suggested.  All worked fine, and I saw no
regressions.  Tested on IVY, SNB, ILK, GM45 and PineView.


thanks,

Takashi

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Broken LVDS output at mode changes
  2012-03-29 16:12       ` Takashi Iwai
@ 2012-03-29 16:57         ` Keith Packard
  2012-03-29 18:02           ` Takashi Iwai
  0 siblings, 1 reply; 11+ messages in thread
From: Keith Packard @ 2012-03-29 16:57 UTC (permalink / raw)
  To: Takashi Iwai; +Cc: intel-gfx

<#part sign=pgpmime>
On Thu, 29 Mar 2012 18:12:56 +0200, Takashi Iwai <tiwai@suse.de> wrote:

> The strange thing is that, although you can recover the display by
> turning off LVDS and on again once when the problem happens, but then
> the display starts flickering.  And, the flickering continues even
> after reboot on BIOS boot screen.

Yeah, it's clearly the panel which is confused. It would be nice to know
what happened to the LVDS signal which caused this problem with the
panel.

> BTW, now I tested to disable LVDS unconditionally on different
> platforms as Daniel suggested.  All worked fine, and I saw no
> regressions.  Tested on IVY, SNB, ILK, GM45 and PineView.

That's not surprising -- pre-PCH platforms disabled the LVDS
anyways.

I wonder if we could fix this by being more careful about the order of
register operations during LVDS mode setting...

-- 
keith.packard@intel.com

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Broken LVDS output at mode changes
  2012-03-29 16:57         ` Keith Packard
@ 2012-03-29 18:02           ` Takashi Iwai
  2012-03-30  4:27             ` Keith Packard
  0 siblings, 1 reply; 11+ messages in thread
From: Takashi Iwai @ 2012-03-29 18:02 UTC (permalink / raw)
  To: Keith Packard; +Cc: intel-gfx

At Thu, 29 Mar 2012 09:57:41 -0700,
Keith Packard wrote:
> 
> <#part sign=pgpmime>
> On Thu, 29 Mar 2012 18:12:56 +0200, Takashi Iwai <tiwai@suse.de> wrote:
> 
> > The strange thing is that, although you can recover the display by
> > turning off LVDS and on again once when the problem happens, but then
> > the display starts flickering.  And, the flickering continues even
> > after reboot on BIOS boot screen.
> 
> Yeah, it's clearly the panel which is confused. It would be nice to know
> what happened to the LVDS signal which caused this problem with the
> panel.

I'll try to poke someone in HP.

> > BTW, now I tested to disable LVDS unconditionally on different
> > platforms as Daniel suggested.  All worked fine, and I saw no
> > regressions.  Tested on IVY, SNB, ILK, GM45 and PineView.
> 
> That's not surprising -- pre-PCH platforms disabled the LVDS
> anyways.
> 
> I wonder if we could fix this by being more careful about the order of
> register operations during LVDS mode setting...

Sure, that'd be a preferred option.
If you have any easy test in mind, let me know.


thanks,

Takashi

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Broken LVDS output at mode changes
  2012-03-29 18:02           ` Takashi Iwai
@ 2012-03-30  4:27             ` Keith Packard
  0 siblings, 0 replies; 11+ messages in thread
From: Keith Packard @ 2012-03-30  4:27 UTC (permalink / raw)
  To: Takashi Iwai; +Cc: intel-gfx

<#part sign=pgpmime>
On Thu, 29 Mar 2012 20:02:01 +0200, Takashi Iwai <tiwai@suse.de> wrote:

> Sure, that'd be a preferred option.
> If you have any easy test in mind, let me know.

The way I'd love to see it tested would be to capture signal traces on
the LVDS link across mode set and see what glitches appear. That sounds
hard to do without an LVDS signal analyser...

-- 
keith.packard@intel.com

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Broken LVDS output at mode changes
  2012-03-29 12:44   ` Chris Wilson
  2012-03-29 12:51     ` Daniel Vetter
  2012-03-29 15:07     ` Keith Packard
@ 2012-03-30 16:56     ` Jesse Barnes
  2 siblings, 0 replies; 11+ messages in thread
From: Jesse Barnes @ 2012-03-30 16:56 UTC (permalink / raw)
  To: Chris Wilson; +Cc: Takashi Iwai, intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 2622 bytes --]

On Thu, 29 Mar 2012 13:44:28 +0100
Chris Wilson <chris@chris-wilson.co.uk> wrote:

> On Thu, 29 Mar 2012 14:16:38 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Wed, Mar 28, 2012 at 03:29:04PM +0200, Takashi Iwai wrote:
> > > Hi,
> > > 
> > > we've encountered a broken LVDS output on some IVY/SNB machines when
> > > the mode is changed (from/to native resolution).  When this happens,
> > > the whole laptop panel gets half white and half black.  This doesn't
> > > recover until the LVDS is turned off once.
> > > 
> > > And, there is no signficant difference between working and non-working
> > > cases in the register dumps.  From the software POV, all looks sane.
> > > So, we suspect this is rather specific to some panel hardware.
> > > 
> > > However, through debugging, I found that disabling LVDS at mode change
> > > works around the problem.  A test patch is attached below.
> > > 
> > > My question now is: can this workaround have any serious drawback?
> > > I thought of a longer blank time, but I didn't notice any difference
> > > before and after the patch.
> > > 
> > > Or, any other suggestion as a saner fix?
> > 
> > No idea, I'm wondering though whether we should just accept some
> > flickering while modesetting unconditionally. Does anyone know what
> > Windows does in this case and at least on my work machine here it looks
> > like Windows just blanks the screen. I haven't checked with reg dumps
> > though how exactly they upscale stuff on lvds.
> > 
> > git blame says that Chris Wilson created the original PCH_SPLIT check.
> > Chris, any comments on this?
> 
> It dates back from an earlier commit that presupposes that we can modify
> the panel on the fly and avoid the power-cycling delays.
> 
> PP_STATUS: Panel Power On Status [bit 31]
> 
> In conjunction with bits Power Sequence Progress field and Power Cycle
> Delay Active, this bit set to a one indicates that the panel is
> currently powered up or is currently in the power down sequence and it
> is unsafe to change the timing, port, and DPLL registers for the pipe or
> transcoder that is assigned to the panel output.
> 
> Guess that rules that out.

Yeah but the docs are too conservative there.  In many cases it's fine
to modify things while the panel is on, it just requires lots of
testing for the different cases.

On newer chips changing the panel fitting should be ok while the panel
is active, but on older ones we need to shut down the panel first (I
think the split is around Cantiga/Ironlake).

-- 
Jesse Barnes, Intel Open Source Technology Center

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2012-03-30 16:56 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-03-28 13:29 Broken LVDS output at mode changes Takashi Iwai
2012-03-29 12:16 ` Daniel Vetter
2012-03-29 12:44   ` Chris Wilson
2012-03-29 12:51     ` Daniel Vetter
2012-03-29 12:55       ` Takashi Iwai
2012-03-29 15:07     ` Keith Packard
2012-03-29 16:12       ` Takashi Iwai
2012-03-29 16:57         ` Keith Packard
2012-03-29 18:02           ` Takashi Iwai
2012-03-30  4:27             ` Keith Packard
2012-03-30 16:56     ` Jesse Barnes

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.