[Intel-gfx] [PATCH 2/3] drm/i915: Check timings against hardware maximums

[Ville Syrjälä]

On Fri, Jun 15, 2018 at 09:02:52PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-06-15 20:48:49)
> > On Fri, Jun 15, 2018 at 07:44:08PM +0100, Chris Wilson wrote:
> > > Quoting Ville Syrjala (2018-06-15 18:44:05)
> > > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > 
> > > > Validate that all display timings fit within the number of bits
> > > > we have in the transcoder timing registers.
> > > > 
> > > > The limits are:
> > > > hsw+:
> > > >  4k: vdisplay, vblank_start
> > > >  8k: everything else
> > > > gen3+:
> > > >  4k: h/vdisplay, h/vblank_start
> > > >  8k: everything else
> > > > gen2:
> > > >  2k: h/vdisplay, h/vblank_start
> > > >  4k: everything else
> > > > 
> > > > Also document the fact that the mode_config.max_width/height limits
> > > > refer to just the max framebuffer dimensions we support. Which may
> > > > be larger than the max hdisplay/vdisplay.
> > > 
> > > In the ddx, I used them to filter max hdisplay/vdisplay... And
> > > completely ignored them wrt to framebuffer.
> > 
> > Whatever works :)
> 
> Yeah, and this doesn't break -intel afaict, since ultimately validation
> is done by the kernel and we/the client just keeps on trying something
> until it works (or more often until they just give up).

Yeah. The main issue is the user being presented with a pile of modes
that can never actually work. It shouldn't be fatal but at least it's
annoying to the user.

I think we might want a new ioctl to have the kernel validate user
modes as well. I guess we could try to ressurect the old ioctls to
add/remove modes to the other list, but I'm thinking we might just want
something that takes the connector ID and a pile of modes and returns a
good/bad status for each (could snatch one of the mode type or flag bits
for that I suppose).

-- 
Ville Syrjälä
Intel