[Intel-gfx] [PATCH 0/9] drm/i915: Check pixel clock when setting mode
Chris Wilson
chris at chris-wilson.co.uk
Mon Jul 6 08:35:50 PDT 2015
On Mon, Jul 06, 2015 at 05:21:48PM +0200, Daniel Vetter wrote:
> On Fri, Jul 03, 2015 at 01:49:17PM +0100, Chris Wilson wrote:
> > On Fri, Jul 03, 2015 at 02:35:48PM +0300, 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 checks are implemented for DisplayPort, HDMI, LVDS, DVO, SDVO, DSI,
> > > CRT, TV, and DP-MST.
> >
> > Why do I get the feeling that there was a lot of duplicated code?
>
> The problem on top is that this only changes the mode_valid callback as
> used by the probe helpers. Which means userspace can still do an addmode
> of something not supported and try to trick over the code into accepting
> something it can't. That code is the stuff around compute_config.
Heh, all I meant was that we seemed to be setting the same max clock for
each GPU several times, hardcoding those values in multiple locations looks
wrong.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list