Re: [Intel-gfx] SNB LVDS goes all stripy at times with rc6 enabled
On Wed, 27 Jul 2011 23:08:08 -0700 Keith Packard kei...@keithp.com wrote: On Wed, 27 Jul 2011 09:06:09 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: I tried this last week with my patch So, with the intel_crtc DPMS tracking fixed, this problem can now be easily reproduced in a wide range of situations. It does not depend on the output in question -- Jesse and I have managed to make this happen on VGA, DP, LVDS and HDMI. The only thing we haven't tested is eDP. That one would be particularly interesting as it doesn't depend on the PCH. Anyone have an SNB machine with an eDP panel and an external monitor to try? It does not depend on the position of the outputs on the screen, all that it requires is that one output be disabled and then the other output get a new mode. Something like: $ xrandr --output LVDS1 --pos 0x0 --mode 1024x768 --output DP2 --pos 0x0 --mode 1024x768 $ xrandr --output DP2 --off $ xrandr --output LVDS1 --auto # this assumes that LVDS1 is larger than 1024x768 The PCH reports no FDI data errors, and if you send the errant monitor the PCH-internal test signal (bit 31, register 0xf0e30 and 0xf1e30), it displays that correctly. So, it surely looks like the CPU is sending the wrong data to the PCH in this case. At this point, I have only two proposed ugly work-arounds: 1) Disable rc6. 2) Once a crtc is turned on, leave it on. Neither of these is appealing for obvious reasons. At this point, it seems like the most likely cause is in the crtc disabling code; some ordering issue or missing pieces may be scrambling some hidden internal state. Yes this problem has me very frustrated. We still have two big open questions to answer before we really understand things: 1) why the heck does rc6 make any difference at all? 2) why does enabling the second pipe make things good again? Theoretically, we're coming pretty close to shutting everything down after we disable the second crtc and set a mode on the first again. I wonder if an even bigger hammer (shut *everything* down and wait a few ms) would improve the situation... I guess we have more things to try today... -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add quirk to disable SSC on Sony Vaio Y2
Using the new quirk added to support disabling SSC on Lenovo U160
(#36656, commit 435793dfb8aec7b2e19f72d5bce8a22fd0b57839), also register
the Vaio as a special case and disable SSC for it.
This patch fixes #34437 on fdo bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=34437
Signed-off-by: Michel Alexandre Salim sali...@fedoraproject.org
---
drivers/gpu/drm/i915/intel_display.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0f1c799..11eb831 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7851,6 +7851,9 @@ struct intel_quirk intel_quirks[] = {
/* Lenovo U160 cannot use SSC on LVDS */
{ 0x0046, 0x17aa, 0x3920, quirk_ssc_force_disable },
+
+ /* Sony Vaio Y cannot use SSC on LVDS */
+ { 0x0046, 0x104d, 0x9076, quirk_ssc_force_disable },
};
static void intel_init_quirks(struct drm_device *dev)
--
1.7.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: make sure plane control reg changes take effect
After writing to the plane control reg we need to write to the surface reg to trigger the double buffered register latch. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/intel_display.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 32ffde2..9fefba3 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1333,6 +1333,8 @@ static void intel_disable_plane(struct drm_i915_private *dev_priv, return; I915_WRITE(reg, val ~DISPLAY_PLANE_ENABLE); + /* Flush out the double buffered plane control reg */ + I915_WRITE(DSPSURF(plane), I915_READ(DSPSURF(plane))); intel_flush_display_plane(dev_priv, plane); intel_wait_for_vblank(dev_priv-dev, pipe); } -- 1.7.4.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: apply phase pointer override on SNB+ too
These bits moved around on SNB and above.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h |7 +++
drivers/gpu/drm/i915/intel_display.c | 34 ++
2 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7377ae4..ae28549 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3081,6 +3081,13 @@
#define TRANS_CHICKEN2(pipe) _PIPE(pipe, _TRANSA_CHICKEN2, _TRANSB_CHICKEN2)
#define TRANS_AUTOTRAIN_GEN_STALL_DIS(131)
+#define SOUTH_CHICKEN1 0xc2000
+#define FDIA_PHASE_SYNC_OVR (119)
+#define FDIA_PHASE_SYNC_EN(118)
+#define FDIB_PHASE_SYNC_OVR (117)
+#define FDIB_PHASE_SYNC_EN(116)
+#define FDIC_PHASE_SYNC_OVR (115)
+#define FDIC_PHASE_SYNC_EN(114)
#define SOUTH_CHICKEN2 0xc2004
#define DPLS_EDP_PPS_FIX_DIS (10)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 73bf235..2a367de 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2295,6 +2295,23 @@ static void ironlake_fdi_link_train(struct drm_crtc
*crtc)
I915_WRITE(FDI_RX_CHICKEN(pipe), FDI_RX_PHASE_SYNC_POINTER_OVR);
I915_WRITE(FDI_RX_CHICKEN(pipe), FDI_RX_PHASE_SYNC_POINTER_OVR |
FDI_RX_PHASE_SYNC_POINTER_EN);
+ } else if (HAS_PCH_CPT(dev)) {
+ u32 flags;
+ switch (pipe) {
+ case 0:
+ flags = FDIA_PHASE_SYNC_OVR | FDIA_PHASE_SYNC_EN;
+ break;
+ case 2:
+ flags = FDIA_PHASE_SYNC_OVR | FDIA_PHASE_SYNC_EN;
+ break;
+ case 3:
+ flags = FDIA_PHASE_SYNC_OVR | FDIA_PHASE_SYNC_EN;
+ break;
+ default:
+ break;
+ }
+ I915_WRITE(SOUTH_CHICKEN1, flags); /* once to unlock... */
+ I915_WRITE(SOUTH_CHICKEN1, flags); /* then again to enable */
}
reg = FDI_RX_IIR(pipe);
@@ -2652,6 +2669,23 @@ static void ironlake_fdi_disable(struct drm_crtc *crtc)
I915_WRITE(FDI_RX_CHICKEN(pipe),
I915_READ(FDI_RX_CHICKEN(pipe)
~FDI_RX_PHASE_SYNC_POINTER_EN));
+ } else if (HAS_PCH_CPT(dev)) {
+ u32 flags;
+ switch (pipe) {
+ case 0:
+ flags = FDIA_PHASE_SYNC_OVR;
+ break;
+ case 2:
+ flags = FDIA_PHASE_SYNC_OVR;
+ break;
+ case 3:
+ flags = FDIA_PHASE_SYNC_OVR;
+ break;
+ default:
+ break;
+ }
+ I915_WRITE(SOUTH_CHICKEN1, flags); /* once to unlock... */
+ I915_WRITE(SOUTH_CHICKEN1, flags); /* then again to enable */
}
/* still set train pattern 1 */
--
1.7.4.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: don't use uninitialized EDID bpc values when picking pipe bpp
The EDID parser will zero out the bpc value, and the driver needs to handle
that case. In our picker, we'll just ignore 0 values as far as bpp
picking goes.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39323.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2a367de..09d5683 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4571,7 +4571,9 @@ static bool intel_choose_pipe_bpp_dither(struct drm_crtc
*crtc,
if (connector-encoder != encoder)
continue;
- if (connector-display_info.bpc display_bpc) {
+ /* Don't use an invalid EDID bpc value */
+ if (connector-display_info.bpc
+ connector-display_info.bpc display_bpc) {
DRM_DEBUG_DRIVER(clamping display bpc (was %d)
to EDID reported max of %d\n, display_bpc, connector-display_info.bpc);
display_bpc = connector-display_info.bpc;
}
@@ -5186,7 +5188,8 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
temp |= PIPE_12BPC;
break;
default:
- WARN(1, intel_choose_pipe_bpp returned invalid value\n);
+ WARN(1, intel_choose_pipe_bpp returned invalid value %d\n,
+ pipe_bpp);
temp |= PIPE_8BPC;
pipe_bpp = 24;
break;
--
1.7.4.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: flush plane control changes on ILK+ as well
On Thu, 28 Jul 2011 11:52:45 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: After writing to the plane control reg we need to write to the surface reg to trigger the double buffered register latch. On previous chipsets, writing to DSPADDR was enough, but on ILK+ DSPSURF is the reg that triggers the double buffer latch. Yup, that's what the docs say too. And, it fixes the stripey-monitor bug nicely. Thanks jbarnes! Reviewed-by: Keith Packard kei...@keithp.com Tested-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgppXHXHudULe.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix CB tuning check for ILK+
CB tuning is needed to handle potential process variations that might cause clock jitter for certain PLL settings. However, we were setting it incorrectly since we were using the wrong M value as a check (M1 when we needed to use the whole M value). Fix it up, making my HDMI attached display a little prettier (used to have occasional dots crawl across the display). Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/intel_display.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 09d5683..01b6b08 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -5274,7 +5274,7 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc, } else if (is_sdvo is_tv) factor = 20; - if (clock.m1 factor * clock.n) + if (clock.m factor * clock.n) fp |= FP_CB_TUNE; dpll = 0; -- 1.7.4.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing
On Wed, 27 Jul 2011 09:03:31 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 27 Jul 2011 02:21:24 -0700 Keith Packard kei...@keithp.com wrote: On Tue, 26 Jul 2011 12:12:25 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: I'd like to amend my reviewed by and say the lock shouldn't be held around the call to the drm helper function. It queues some work that also takes the mode config lock, which will break. So you can drop it before that... Previously I had only checked our internal driver callbacks but missed that the lock was held across the helper too. So the work may get executed immediately rather than being run later at some point? It sure looks that way... but I don't remember any rule about work queue items having inter dependencies like this. Sounds fine; I've stuck a fixup that moves the mutex_unlock: if (encoder-hot_plug) encoder-hot_plug(encoder); + mutex_unlock(mode_config-mutex); + /* Just fire off a uevent and let userspace tell us what to do */ drm_helper_hpd_irq_event(dev); - - mutex_unlock(mode_config-mutex); } -- keith.pack...@intel.com pgpNWPHfP4boK.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: apply phase pointer override on SNB+ too
These bits moved around on SNB and above.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h | 12
drivers/gpu/drm/i915/intel_display.c | 34 ++
2 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5d5def7..d5a9812 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3075,6 +3075,18 @@
#define TRANS_6BPC (25)
#define TRANS_12BPC(35)
+#define _TRANSA_CHICKEN20xf0064
+#define _TRANSB_CHICKEN20xf1064
+#define TRANS_CHICKEN2(pipe) _PIPE(pipe, _TRANSA_CHICKEN2, _TRANSB_CHICKEN2)
+#define TRANS_AUTOTRAIN_GEN_STALL_DIS(131)
+
+#define SOUTH_CHICKEN1 0xc2000
+#define FDIA_PHASE_SYNC_OVR (119)
+#define FDIA_PHASE_SYNC_EN(118)
+#define FDIB_PHASE_SYNC_OVR (117)
+#define FDIB_PHASE_SYNC_EN(116)
+#define FDIC_PHASE_SYNC_OVR (115)
+#define FDIC_PHASE_SYNC_EN(114)
#define SOUTH_CHICKEN2 0xc2004
#define DPLS_EDP_PPS_FIX_DIS (10)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5609c06..187b035 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2133,6 +2133,23 @@ static void ironlake_fdi_link_train(struct drm_crtc
*crtc)
I915_WRITE(FDI_RX_CHICKEN(pipe), FDI_RX_PHASE_SYNC_POINTER_OVR);
I915_WRITE(FDI_RX_CHICKEN(pipe), FDI_RX_PHASE_SYNC_POINTER_OVR |
FDI_RX_PHASE_SYNC_POINTER_EN);
+ } else if (HAS_PCH_CPT(dev)) {
+ u32 flags;
+ switch (pipe) {
+ case 0:
+ flags = FDIA_PHASE_SYNC_OVR | FDIA_PHASE_SYNC_EN;
+ break;
+ case 2:
+ flags = FDIA_PHASE_SYNC_OVR | FDIA_PHASE_SYNC_EN;
+ break;
+ case 3:
+ flags = FDIA_PHASE_SYNC_OVR | FDIA_PHASE_SYNC_EN;
+ break;
+ default:
+ break;
+ }
+ I915_WRITE(SOUTH_CHICKEN1, flags); /* once to unlock... */
+ I915_WRITE(SOUTH_CHICKEN1, flags); /* then again to enable */
}
reg = FDI_RX_IIR(pipe);
@@ -2490,6 +2507,23 @@ static void ironlake_fdi_disable(struct drm_crtc *crtc)
I915_WRITE(FDI_RX_CHICKEN(pipe),
I915_READ(FDI_RX_CHICKEN(pipe)
~FDI_RX_PHASE_SYNC_POINTER_EN));
+ } else if (HAS_PCH_CPT(dev)) {
+ u32 flags;
+ switch (pipe) {
+ case 0:
+ flags = FDIA_PHASE_SYNC_OVR;
+ break;
+ case 2:
+ flags = FDIA_PHASE_SYNC_OVR;
+ break;
+ case 3:
+ flags = FDIA_PHASE_SYNC_OVR;
+ break;
+ default:
+ break;
+ }
+ I915_WRITE(SOUTH_CHICKEN1, flags); /* once to unlock... */
+ I915_WRITE(SOUTH_CHICKEN1, flags); /* then again to enable */
}
/* still set train pattern 1 */
--
1.7.4.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: apply phase pointer override on SNB+ too
These bits moved around on SNB and above.
v2: again with the git send-email fail
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h |8
drivers/gpu/drm/i915/intel_display.c | 29 -
2 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5d5def7..7261113 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3075,6 +3075,14 @@
#define TRANS_6BPC (25)
#define TRANS_12BPC(35)
+#define _TRANSA_CHICKEN20xf0064
+#define _TRANSB_CHICKEN20xf1064
+#define TRANS_CHICKEN2(pipe) _PIPE(pipe, _TRANSA_CHICKEN2, _TRANSB_CHICKEN2)
+#define TRANS_AUTOTRAIN_GEN_STALL_DIS(131)
+
+#define SOUTH_CHICKEN1 0xc2000
+#define FDIA_PHASE_SYNC_SHIFT 18
+#define FDI_PHASE_SYNC_OVR_EN (3)
#define SOUTH_CHICKEN2 0xc2004
#define DPLS_EDP_PPS_FIX_DIS (10)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5609c06..65ead57 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2086,6 +2086,18 @@ static void intel_fdi_normal_train(struct drm_crtc *crtc)
FDI_FE_ERRC_ENABLE);
}
+static void cpt_phase_pointer_enable(struct drm_device *dev, int pipe)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 flags = I915_READ(SOUTH_CHICKEN1);
+
+ flags |= FDI_PHASE_SYNC_OVR_EN (FDIA_PHASE_SYNC_SHIFT - (pipe * 2));
+
+ I915_WRITE(SOUTH_CHICKEN1, flags); /* once to unlock... */
+ I915_WRITE(SOUTH_CHICKEN1, flags); /* then again to enable */
+ POSTING_READ(SOUTH_CHICKEN1);
+}
+
/* The FDI link training functions for ILK/Ibexpeak. */
static void ironlake_fdi_link_train(struct drm_crtc *crtc)
{
@@ -2133,7 +2145,8 @@ static void ironlake_fdi_link_train(struct drm_crtc *crtc)
I915_WRITE(FDI_RX_CHICKEN(pipe), FDI_RX_PHASE_SYNC_POINTER_OVR);
I915_WRITE(FDI_RX_CHICKEN(pipe), FDI_RX_PHASE_SYNC_POINTER_OVR |
FDI_RX_PHASE_SYNC_POINTER_EN);
- }
+ } else if (HAS_PCH_CPT(dev))
+ cpt_phase_pointer_enable(dev, pipe);
reg = FDI_RX_IIR(pipe);
for (tries = 0; tries 5; tries++) {
@@ -2461,6 +2474,18 @@ static void ironlake_fdi_pll_enable(struct drm_crtc
*crtc)
}
}
+static void cpt_phase_pointer_disable(struct drm_device *dev, int pipe)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 flags = I915_READ(SOUTH_CHICKEN1);
+
+ flags = ~(FDI_PHASE_SYNC_OVR_EN (FDIA_PHASE_SYNC_SHIFT -
+(pipe * 2)));
+
+ I915_WRITE(SOUTH_CHICKEN1, flags); /* once to unlock... */
+ I915_WRITE(SOUTH_CHICKEN1, flags); /* then again to enable */
+ POSTING_READ(SOUTH_CHICKEN1);
+}
static void ironlake_fdi_disable(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc-dev;
@@ -2490,6 +2515,8 @@ static void ironlake_fdi_disable(struct drm_crtc *crtc)
I915_WRITE(FDI_RX_CHICKEN(pipe),
I915_READ(FDI_RX_CHICKEN(pipe)
~FDI_RX_PHASE_SYNC_POINTER_EN));
+ } else if (HAS_PCH_CPT(dev)) {
+ cpt_phase_pointer_disable(dev, pipe);
}
/* still set train pattern 1 */
--
1.7.4.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
