| Message ID | 1395392448-6337-1-git-send-email-jani.nikula@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Mar 21, 2014 at 11:00:48AM +0200, Jani Nikula wrote: > From: Ville Syrjälä <ville.syrjala@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 <crshman@gmail.com> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254 > Signed-off-by: Ville Syrjälä <ville.syrjala@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
On Fri, Mar 21, 2014 at 11:00:48AM +0200, Jani Nikula wrote: > From: Ville Syrjälä <ville.syrjala@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 <crshman@gmail.com> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254 > Signed-off-by: Ville Syrjälä <ville.syrjala@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 > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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.vetter@ffwll.ch [mailto:daniel.vetter@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.syrjala@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 <crshman@gmail.com> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254 >> Signed-off-by: Ville Syrjälä <ville.syrjala@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 >> Intel-gfx@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx > >-- >Daniel Vetter >Software Engineer, Intel Corporation >+41 (0) 79 365 57 48 - http://blog.ffwll.ch
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?
On Mon, Mar 31, 2014 at 06:29:51PM +0000, 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 base 0.125 ns Maximum module speed 1333 MHz (PC3-10600) Size 4096 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 ivb and snb machines however. Also I must admit that I've never tried plugging in a 25x14 monitor to these machines, and in fact with the dell xps I can't since it doesn't even have a DP connector.
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)