Re: [Intel-gfx] [PATCH] drm/i915: Increase WM memory latency values on SNB with high pixel clock
On Mon, Mar 31, 2014 at 06:29:51PM +, Robert Navarro wrote: Runyan, Arthur J arthur.j.runyan at intel.com writes: Please check the DRAM configuration for the systems that fail. The higher latency is more likely with higher tRFC which is mainly found with 8 Gbit components. What other information do we need to get this included? The DRAM config, is this something that I have to/should check? How do I get this information to you? If decode-dimms works on your machine it might print out potentially interesting stuff. It doesn't seem to work on most of my machines. It does work on the x220 I have here though, so I'm assuming it should work on your x220 too. decode-dimms comes from the i2c-tools package. Here's what I get on mine: # modprobe i2c-i801 # modprobe eeprom # decode-dimms # decode-dimms version 6231 (2014-02-20 10:54:34 +0100) Memory Serial Presence Detect Decoder By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner, Jean Delvare, Trent Piepho and others Decoding EEPROM: /sys/bus/i2c/drivers/eeprom/0-0050 Guessing DIMM is in bank 1 ---=== SPD EEPROM Information ===--- EEPROM CRC of bytes 0-116 OK (0xFC7B) # of bytes written to SDRAM EEPROM 176 Total number of bytes in EEPROM 256 Fundamental Memory type DDR3 SDRAM Module Type SO-DIMM ---=== Memory Characteristics ===--- Fine time base 1.000 ps Medium time base0.125 ns Maximum module speed1333 MHz (PC3-10600) Size4096 MB Banks x Rows x Columns x Bits 8 x 15 x 10 x 64 Ranks 2 SDRAM Device Width 8 bits Bus Width Extension 0 bits tCL-tRCD-tRP-tRAS 9-9-9-24 Supported CAS Latencies (tCL) 9T, 8T, 7T, 6T, 5T ---=== Timing Parameters ===--- Minimum Write Recovery time (tWR) 15.000 ns Minimum Row Active to Row Active Delay (tRRD) 6.000 ns Minimum Active to Auto-Refresh Delay (tRC) 49.125 ns Minimum Recovery Delay (tRFC) 160.000 ns Minimum Write to Read CMD Delay (tWTR) 7.500 ns Minimum Read to Pre-charge CMD Delay (tRTP) 7.500 ns Minimum Four Activate Window Delay (tFAW) 30.000 ns ---=== Optional Features ===--- Operable voltages 1.5V RZQ/6 supported?Yes RZQ/7 supported?Yes DLL-Off Mode supported? Yes Operating temperature range 0-95 degrees C Refresh Rate in extended temp range 1X Auto Self-Refresh? No On-Die Thermal Sensor readout? No Partial Array Self-Refresh? No Thermal Sensor Accuracy Not implemented SDRAM Device Type Standard Monolithic ---=== Physical Characteristics ===--- Module Height (mm) 30 Module Thickness (mm) 2 front, 2 back Module Width (mm) 67.6 Module Reference Card F ---=== Manufacturer Data ===--- Module Manufacturer Samsung DRAM Manufacturer Samsung Manufacturing Location Code 0x03 Manufacturing Date 2012-W04 Assembly Serial Number 0x009B48F1 Part Number M471B5273DH0-CH9 Number of SDRAM DIMMs detected and decoded: 1 Just for figuring out what tRFC is I think the following would do it: # intel_reg_read 0x144298 0x144698 0x144a98 0x145d10 0x145e04 These are from the machines I have lying around on my desk: // dell xps (snb) # ./intel_reg_read 0x144298 0x144698 0x144a98 0x145d10 0x145e04 0x144298 : 0x5A6B1450 0x144698 : 0x5A6B1450 0x144A98 : 0x0 0x145D10 : 0x16040307 0x145E04 : 0x5 // x220 (snb) # ./intel_reg_read 0x144298 0x144698 0x144a98 0x145d10 0x145e04 0x144298 : 0x5A6B1450 0x144698 : 0x46B41004 0x144A98 : 0x0 0x145D10 : 0x16040307 0x145E04 : 0x5 // some ivb desktop # ./intel_reg_read 0x144298 0x144698 0x144a98 0x145d10 0x145e04 0x144298 : 0x5A6B1450 0x144698 : 0x5A6B1450 0x144A98 : 0x0 0x145D10 : 0x2010040C 0x145E04 : 0x5 So on for most things I get an answer of tRFC=107, which means 160ns if my math is any good. And that matches the SPD info from decode-dimms on the x220. The second channel for the x220 has something different but it actually looks like the reset value for the register which makes sense since decode-dimms says it only has one DIMM. No idea if my tRFC is particularly low or high. The latency values are quite different between the
Re: [Intel-gfx] [PATCH] drm/i915: Increase WM memory latency values on SNB with high pixel clock
Runyan, Arthur J arthur.j.runyan at intel.com writes: Please check the DRAM configuration for the systems that fail. The higher latency is more likely with higher tRFC which is mainly found with 8 Gbit components. What other information do we need to get this included? The DRAM config, is this something that I have to/should check? How do I get this information to you? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Increase WM memory latency values on SNB with high pixel clock
From: Ville Syrjälä ville.syrj...@linux.intel.com
On SNB the BIOS provided WM memory latency values seem insufficient to
handle high resolution displays.
In this particular case the display mode was a 2560x1440@60Hz, which
makes the pixel clock 241.5 MHz. It was empirically found that a memory
latency value if 1.2 usec is enough to avoid underruns, whereas the BIOS
provided value of 0.7 usec was clearly too low. Incidentally 1.2 usec
is what the typical BIOS provided values are on IVB systems.
Increase the WM memory latency values to 1.2 usec when encountering a
display mode with pixel clock exceeding 225 MHz. 225 MHz was chosen as
the threshold simply because that's the documented limit of SNB with
HDMI, so one might surmise that the hardware may have been tested up
to that frequency. In theory the latency shouldn't depend on the pixel
clock at all. So it may be that we should just increase the latency
values across the board for all SNB systems. But for now I'm inclined
to limit this quirk to only those cases that are proven to need it,
as doing otherwise might cause some increase in power consumption for
everyone.
Cc: Robert N crsh...@gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
I'm just relaying the patch from bugzilla to the list as it seems to fix
the bug. Don't ask me anything about it.
BR,
Jani.
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_pm.c | 33 +
3 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0b19afdfbaa7..b0ac92d8f461 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9933,6 +9933,16 @@ static int __intel_set_mode(struct drm_crtc *crtc,
*/
drm_calc_timestamping_constants(crtc,
pipe_config-adjusted_mode);
+
+
+ /*
+* The BIOS provided WM memory latency values are often
+* inadequate for high resolution displays. Adjust them.
+*
+* FIXME not sure 225MHz is a good threshold.
+*/
+ if (IS_GEN6(dev) pipe_config-adjusted_mode.crtc_clock
225000)
+ snb_wm_latency_quirk(dev);
}
/* Only after disabling all output pipelines that will be changed can we
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 60ffad376390..b1d631c9dfa5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -903,6 +903,7 @@ void intel_runtime_pm_put(struct drm_i915_private
*dev_priv);
void intel_init_runtime_pm(struct drm_i915_private *dev_priv);
void intel_fini_runtime_pm(struct drm_i915_private *dev_priv);
void ilk_wm_get_hw_state(struct drm_device *dev);
+void snb_wm_latency_quirk(struct drm_device *dev);
/* intel_sdvo.c */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 39f3238bf1c3..226750452637 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2104,6 +2104,39 @@ static void ilk_setup_wm_latency(struct drm_device *dev)
intel_print_wm_latency(dev, Cursor, dev_priv-wm.cur_latency);
}
+static bool ilk_increase_wm_latency(struct drm_i915_private *dev_priv,
+ uint16_t wm[5], uint16_t min)
+{
+ int level, max_level = ilk_wm_max_level(dev_priv-dev);
+
+ if (wm[0] = min)
+ return false;
+
+ wm[0] = max(wm[0], min);
+ for (level = 1; level = max_level; level++)
+ wm[level] = max_t(uint16_t, wm[level], DIV_ROUND_UP(min, 5));
+
+ return true;
+}
+
+void snb_wm_latency_quirk(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ bool changed;
+
+ changed = ilk_increase_wm_latency(dev_priv, dev_priv-wm.pri_latency,
12) |
+ ilk_increase_wm_latency(dev_priv, dev_priv-wm.spr_latency, 12)
|
+ ilk_increase_wm_latency(dev_priv, dev_priv-wm.cur_latency, 12);
+
+ if (!changed)
+ return;
+
+ DRM_DEBUG_KMS(WM latency values increased due to high pixel clock\n);
+ intel_print_wm_latency(dev, Primary, dev_priv-wm.pri_latency);
+ intel_print_wm_latency(dev, Sprite, dev_priv-wm.spr_latency);
+ intel_print_wm_latency(dev, Cursor, dev_priv-wm.cur_latency);
+}
+
static void ilk_compute_wm_parameters(struct drm_crtc *crtc,
struct ilk_pipe_wm_parameters *p,
struct intel_wm_config *config)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [PATCH] drm/i915: Increase WM memory latency values on SNB with high pixel clock
On Fri, Mar 21, 2014 at 11:00:48AM +0200, Jani Nikula wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
On SNB the BIOS provided WM memory latency values seem insufficient to
handle high resolution displays.
In this particular case the display mode was a 2560x1440@60Hz, which
makes the pixel clock 241.5 MHz. It was empirically found that a memory
latency value if 1.2 usec is enough to avoid underruns, whereas the BIOS
provided value of 0.7 usec was clearly too low. Incidentally 1.2 usec
is what the typical BIOS provided values are on IVB systems.
Increase the WM memory latency values to 1.2 usec when encountering a
display mode with pixel clock exceeding 225 MHz. 225 MHz was chosen as
the threshold simply because that's the documented limit of SNB with
HDMI, so one might surmise that the hardware may have been tested up
to that frequency. In theory the latency shouldn't depend on the pixel
clock at all. So it may be that we should just increase the latency
values across the board for all SNB systems. But for now I'm inclined
to limit this quirk to only those cases that are proven to need it,
as doing otherwise might cause some increase in power consumption for
everyone.
Cc: Robert N crsh...@gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
I'm just relaying the patch from bugzilla to the list as it seems to fix
the bug. Don't ask me anything about it.
BR,
Jani.
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_pm.c | 33 +
3 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0b19afdfbaa7..b0ac92d8f461 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9933,6 +9933,16 @@ static int __intel_set_mode(struct drm_crtc *crtc,
*/
drm_calc_timestamping_constants(crtc,
pipe_config-adjusted_mode);
+
+
+ /*
+ * The BIOS provided WM memory latency values are often
+ * inadequate for high resolution displays. Adjust them.
+ *
+ * FIXME not sure 225MHz is a good threshold.
+ */
+ if (IS_GEN6(dev) pipe_config-adjusted_mode.crtc_clock
225000)
+ snb_wm_latency_quirk(dev);
}
/* Only after disabling all output pipelines that will be changed can we
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 60ffad376390..b1d631c9dfa5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -903,6 +903,7 @@ void intel_runtime_pm_put(struct drm_i915_private
*dev_priv);
void intel_init_runtime_pm(struct drm_i915_private *dev_priv);
void intel_fini_runtime_pm(struct drm_i915_private *dev_priv);
void ilk_wm_get_hw_state(struct drm_device *dev);
+void snb_wm_latency_quirk(struct drm_device *dev);
/* intel_sdvo.c */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 39f3238bf1c3..226750452637 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2104,6 +2104,39 @@ static void ilk_setup_wm_latency(struct drm_device
*dev)
intel_print_wm_latency(dev, Cursor, dev_priv-wm.cur_latency);
}
+static bool ilk_increase_wm_latency(struct drm_i915_private *dev_priv,
+ uint16_t wm[5], uint16_t min)
+{
+ int level, max_level = ilk_wm_max_level(dev_priv-dev);
+
+ if (wm[0] = min)
+ return false;
+
+ wm[0] = max(wm[0], min);
+ for (level = 1; level = max_level; level++)
+ wm[level] = max_t(uint16_t, wm[level], DIV_ROUND_UP(min, 5));
+
+ return true;
+}
+
+void snb_wm_latency_quirk(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ bool changed;
+
+ changed = ilk_increase_wm_latency(dev_priv, dev_priv-wm.pri_latency,
12) |
+ ilk_increase_wm_latency(dev_priv, dev_priv-wm.spr_latency, 12)
|
+ ilk_increase_wm_latency(dev_priv, dev_priv-wm.cur_latency, 12);
Unless I missed something this hereafter permanently bumps the latency
for computations.
At the 225MHz pixel clock, what are the differences in final WM values?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Increase WM memory latency values on SNB with high pixel clock
On Fri, Mar 21, 2014 at 11:00:48AM +0200, Jani Nikula wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
On SNB the BIOS provided WM memory latency values seem insufficient to
handle high resolution displays.
In this particular case the display mode was a 2560x1440@60Hz, which
makes the pixel clock 241.5 MHz. It was empirically found that a memory
latency value if 1.2 usec is enough to avoid underruns, whereas the BIOS
provided value of 0.7 usec was clearly too low. Incidentally 1.2 usec
is what the typical BIOS provided values are on IVB systems.
Increase the WM memory latency values to 1.2 usec when encountering a
display mode with pixel clock exceeding 225 MHz. 225 MHz was chosen as
the threshold simply because that's the documented limit of SNB with
HDMI, so one might surmise that the hardware may have been tested up
to that frequency. In theory the latency shouldn't depend on the pixel
clock at all. So it may be that we should just increase the latency
values across the board for all SNB systems. But for now I'm inclined
to limit this quirk to only those cases that are proven to need it,
as doing otherwise might cause some increase in power consumption for
everyone.
Cc: Robert N crsh...@gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
I think we should just unconditionally increase the memory latency. ivb
has a rather similar memory subsystem compared to snb, so just increasing
it always to this limits sounds ok. For lower resolutions we might simply
get away because there's more excess bandwidth available.
Maybe Art can shed some light on this.
-Daniel
---
I'm just relaying the patch from bugzilla to the list as it seems to fix
the bug. Don't ask me anything about it.
BR,
Jani.
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_pm.c | 33 +
3 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0b19afdfbaa7..b0ac92d8f461 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9933,6 +9933,16 @@ static int __intel_set_mode(struct drm_crtc *crtc,
*/
drm_calc_timestamping_constants(crtc,
pipe_config-adjusted_mode);
+
+
+ /*
+ * The BIOS provided WM memory latency values are often
+ * inadequate for high resolution displays. Adjust them.
+ *
+ * FIXME not sure 225MHz is a good threshold.
+ */
+ if (IS_GEN6(dev) pipe_config-adjusted_mode.crtc_clock 225000)
+ snb_wm_latency_quirk(dev);
}
/* Only after disabling all output pipelines that will be changed can we
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 60ffad376390..b1d631c9dfa5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -903,6 +903,7 @@ void intel_runtime_pm_put(struct drm_i915_private
*dev_priv);
void intel_init_runtime_pm(struct drm_i915_private *dev_priv);
void intel_fini_runtime_pm(struct drm_i915_private *dev_priv);
void ilk_wm_get_hw_state(struct drm_device *dev);
+void snb_wm_latency_quirk(struct drm_device *dev);
/* intel_sdvo.c */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 39f3238bf1c3..226750452637 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2104,6 +2104,39 @@ static void ilk_setup_wm_latency(struct drm_device
*dev)
intel_print_wm_latency(dev, Cursor, dev_priv-wm.cur_latency);
}
+static bool ilk_increase_wm_latency(struct drm_i915_private *dev_priv,
+uint16_t wm[5], uint16_t min)
+{
+ int level, max_level = ilk_wm_max_level(dev_priv-dev);
+
+ if (wm[0] = min)
+ return false;
+
+ wm[0] = max(wm[0], min);
+ for (level = 1; level = max_level; level++)
+ wm[level] = max_t(uint16_t, wm[level], DIV_ROUND_UP(min, 5));
+
+ return true;
+}
+
+void snb_wm_latency_quirk(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ bool changed;
+
+ changed = ilk_increase_wm_latency(dev_priv, dev_priv-wm.pri_latency, 12) |
+ ilk_increase_wm_latency(dev_priv, dev_priv-wm.spr_latency, 12) |
+ ilk_increase_wm_latency(dev_priv, dev_priv-wm.cur_latency, 12);
+
+ if (!changed)
+ return;
+
+ DRM_DEBUG_KMS(WM latency values increased due to high pixel clock\n);
+ intel_print_wm_latency(dev, Primary, dev_priv-wm.pri_latency);
+ intel_print_wm_latency(dev, Sprite, dev_priv-wm.spr_latency);
+ intel_print_wm_latency(dev, Cursor, dev_priv-wm.cur_latency);
+}
+
static void ilk_compute_wm_parameters(struct drm_crtc *crtc,
struct ilk_pipe_wm_parameters *p,
struct intel_wm_config *config)
--
1.7.9.5
___
Intel-gfx mailing list
Re: [Intel-gfx] [PATCH] drm/i915: Increase WM memory latency values on SNB with high pixel clock
Please check the DRAM configuration for the systems that fail. The higher
latency is more likely with higher tRFC which is mainly found with 8 Gbit
components.
-Original Message-
From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
Daniel Vetter
Sent: Friday, March 21, 2014 3:19 AM
To: Nikula, Jani; Runyan, Arthur J; Syrjala, Ville
Cc: intel-gfx
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Increase WM memory latency values
on SNB with
high pixel clock
On Fri, Mar 21, 2014 at 11:00:48AM +0200, Jani Nikula wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
On SNB the BIOS provided WM memory latency values seem insufficient to
handle high resolution displays.
In this particular case the display mode was a 2560x1440@60Hz, which
makes the pixel clock 241.5 MHz. It was empirically found that a memory
latency value if 1.2 usec is enough to avoid underruns, whereas the BIOS
provided value of 0.7 usec was clearly too low. Incidentally 1.2 usec
is what the typical BIOS provided values are on IVB systems.
Increase the WM memory latency values to 1.2 usec when encountering a
display mode with pixel clock exceeding 225 MHz. 225 MHz was chosen as
the threshold simply because that's the documented limit of SNB with
HDMI, so one might surmise that the hardware may have been tested up
to that frequency. In theory the latency shouldn't depend on the pixel
clock at all. So it may be that we should just increase the latency
values across the board for all SNB systems. But for now I'm inclined
to limit this quirk to only those cases that are proven to need it,
as doing otherwise might cause some increase in power consumption for
everyone.
Cc: Robert N crsh...@gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
I think we should just unconditionally increase the memory latency. ivb
has a rather similar memory subsystem compared to snb, so just increasing
it always to this limits sounds ok. For lower resolutions we might simply
get away because there's more excess bandwidth available.
Maybe Art can shed some light on this.
-Daniel
---
I'm just relaying the patch from bugzilla to the list as it seems to fix
the bug. Don't ask me anything about it.
BR,
Jani.
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_pm.c | 33
+
3 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0b19afdfbaa7..b0ac92d8f461 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9933,6 +9933,16 @@ static int __intel_set_mode(struct drm_crtc *crtc,
*/
drm_calc_timestamping_constants(crtc,
pipe_config-adjusted_mode);
+
+
+ /*
+ * The BIOS provided WM memory latency values are often
+ * inadequate for high resolution displays. Adjust them.
+ *
+ * FIXME not sure 225MHz is a good threshold.
+ */
+ if (IS_GEN6(dev) pipe_config-adjusted_mode.crtc_clock 225000)
+ snb_wm_latency_quirk(dev);
}
/* Only after disabling all output pipelines that will be changed can we
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 60ffad376390..b1d631c9dfa5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -903,6 +903,7 @@ void intel_runtime_pm_put(struct drm_i915_private
*dev_priv);
void intel_init_runtime_pm(struct drm_i915_private *dev_priv);
void intel_fini_runtime_pm(struct drm_i915_private *dev_priv);
void ilk_wm_get_hw_state(struct drm_device *dev);
+void snb_wm_latency_quirk(struct drm_device *dev);
/* intel_sdvo.c */
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 39f3238bf1c3..226750452637 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2104,6 +2104,39 @@ static void ilk_setup_wm_latency(struct drm_device
*dev)
intel_print_wm_latency(dev, Cursor, dev_priv-wm.cur_latency);
}
+static bool ilk_increase_wm_latency(struct drm_i915_private *dev_priv,
+uint16_t wm[5], uint16_t min)
+{
+ int level, max_level = ilk_wm_max_level(dev_priv-dev);
+
+ if (wm[0] = min)
+ return false;
+
+ wm[0] = max(wm[0], min);
+ for (level = 1; level = max_level; level++)
+ wm[level] = max_t(uint16_t, wm[level], DIV_ROUND_UP(min, 5));
+
+ return true;
+}
+
+void snb_wm_latency_quirk(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ bool changed;
+
+ changed = ilk_increase_wm_latency(dev_priv, dev_priv-wm.pri_latency, 12) |
+ ilk_increase_wm_latency(dev_priv, dev_priv-wm.spr_latency, 12) |
+ ilk_increase_wm_latency(dev_priv, dev_priv-wm.cur_latency, 12);
+
+ if (!changed)
+ return;
+
+ DRM_DEBUG_KMS(WM latency values
