[Intel-gfx] [PATCH v4 0/6] Check pixel clock when setting mode
Daniel Vetter
daniel at ffwll.ch
Thu Feb 11 09:20:44 UTC 2016
On Tue, Feb 02, 2016 at 03:16:37PM +0200, Mika Kahola wrote:
> From EDID we can read and request higher pixel clock than
> our HW can support. This set of patches add checks if
> requested pixel clock is lower than the one supported by the HW.
> The requested mode is discarded if we cannot support the requested
> pixel clock. For example for Cherryview
>
> 'cvt 2560 1600 60' gives
>
> # 2560x1600 59.99 Hz (CVT 4.10MA) hsync: 99.46 kHz; pclk: 348.50 MHz
> Modeline "2560x1600_60.00" 348.50 2560 2760 3032 3504 1600 1603 1609 1658 -hsync +vsync
>
> where pixel clock 348.50 MHz is higher than the supported 304 MHz.
>
> The missing mode validity checks for DisplayPort, HDMI, DP-MST, SDVO, CRT, and TV.
>
> V2:
> - The maximum DOT clock frequency is added to debugfs i915_frequency_info.
> - max dotclock cached in dev_priv structure
> - moved computation of max dotclock to 'intel_display.c'
>
> V3:
> - intel_update_max_dotclk() renamed as intel_compute_max_dotclk()
> - for GEN9 and above the max dotclock frequency is equal to CD clock
> frequency
> - for older generations the dot clock frequency is limited to 90% of the
> CD clock frequency
> - For Cherryview the dot clock is limited to 95% of CD clock frequency
> - for GEN2/3 the maximum dot clock frequency is limited to 90% of the
> 2X CD clock frequency as we have on option to use double wide mode
> - cleanup
>
> V4:
> - renaming of max_dotclk as max_dotclk_freq in dev_priv (i915_drv.h)
> caused changes to all patches in my series even though some of them has
> been r-b'd by Ville
> - for consistency the max_pixclk variable is renamed as max_dotclk throughout
> the whole series
>
> Mika Kahola (6):
> drm/i915: DisplayPort pixel clock check
> drm/i915: HDMI pixel clock check
> drm/i915: DisplayPort-MST pixel clock check
> drm/i915: SDVO pixel clock check
> drm/i915: CRT pixel clock check
> drm/i915: TV pixel clock check
Note that the title of your series is wrong I think - mode_valid is _only_
called at probe time, to filter the list of modes userspace can see.
Userspace can still try to set a mode not in that list which would be
above that dotclk. From a quick look around I don't see that addressed
anywhere.
If that's true then I think we also need an igt which exercises this code
by trying to set a dotclock that's way too high (but for a resolution that
the display actually supports).
-Daniel
>
> drivers/gpu/drm/i915/intel_crt.c | 4 ++++
> drivers/gpu/drm/i915/intel_dp.c | 3 ++-
> drivers/gpu/drm/i915/intel_dp_mst.c | 5 +++++
> drivers/gpu/drm/i915/intel_hdmi.c | 8 ++++++++
> drivers/gpu/drm/i915/intel_sdvo.c | 4 ++++
> drivers/gpu/drm/i915/intel_tv.c | 4 ++++
> 6 files changed, 27 insertions(+), 1 deletion(-)
>
> --
> 1.9.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the Intel-gfx
mailing list