[PATCH 46/51] drm/i915: Add support for atomic modesetting completion events

[Daniel Vetter]

On Thu, Oct 25, 2012 at 8:05 PM,  <ville.syrjala at linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
>
> Send completion events when the atomic modesetting operations has
> finished succesfully.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>

I have to admit I'm not on top of the latest ioctl/interface
discussion, but one new requirement for the modeset (not the pageflip
part) of the all this atomic stuff I've discovered is that the kernel
needs to be able to select the crtcs for each output completely
unrestricted. I think userspace should simply pass in abstract crtc
ids (e.g. 0, 1, 2, ...) and the kernel then passes back the actual
crtcs it has selected.

We can't do that remapping internally because the crtc abstraction is leaky:
- wait_for_vblank requires the pipe id, which could then change on every modeset
- similarly userspace doing MI_WAIT for scanlines needs to know the
actual hw pipe in use by a crtc.
And current userspace presumes that the mapping between crtc->pipe
doesn't change.

An example why the kernel needs to pick the crtc for userspace:
- on ivb only pipe A has a 7x5 panel fitter, so usually you want to
put the panel on the first crtc
- but if you run in a 3 pipe configuration and have an eDP panel, it's
better to put the eDP output on pipe C, since then pipes A&B will have
full 4-lane fdi links to the pch ports (instead of otherwise only 2
lanes each on links B&C)
- similarly when we have a 3 pipe configuration with all encoders on
the pch, we need to move the mode with the highest dotclock to pipe A
(since that's the only one which will have 4 lanes, pipe B&C will only
have 2 each).
- afaik these kind of asymmetric constraints won't disappear anytime
soon, haswell definitely still has some.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch