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

[Daniel Vetter]

On Wed, Nov 07, 2012 at 02:29:45PM -0600, Rob Clark wrote:
> On Thu, Nov 1, 2012 at 5:39 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> > On Thu, Nov 01, 2012 at 10:12:21AM -0700, Jesse Barnes wrote:
> >> On Thu, 1 Nov 2012 19:07:02 +0200
> >> Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> >>
> >> > On Thu, Nov 01, 2012 at 07:39:12AM -0700, Jesse Barnes wrote:
> >> > > On Thu, 1 Nov 2012 12:12:35 +0100
> >> > > Daniel Vetter <daniel at ffwll.ch> wrote:
> >> > >
> >> > > > 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.
> 
> I don't know if it is possible, but it would be nice to try to clean
> up crtc<->pipe stuff..  userspace, at least modetest, assumes crtc ==
> crtc_list[pipe].  But I haven't noticed yet anywhere that this
> relationship is documented.  And if you are thinking about doing what
> I think you are thinking about doing, then this assumption would no
> longer hold for i915.

This relationship does already no longer hold on i915 - on gen3 at least
we sometimes switch the crtc->pipe assignement (to make fbc more useful),
which means even with todays code userspace cannot assume (when running on
i915), that the vblank pipe satisfies crtc == crtc_list[pipe].

> How frequently do you emit waits for scanline?  Places where the pipe
> # ends up in cmdstream, would it be too crazy to handle that like a
> reloc where the kernel goes and fixes up the actual value in the
> cmdstream as it does it's GEM reloc pass?  If you did this then you
> could virtualize pipe as well as crtc.

Every dri2 copyregion or Xv upload to the frontbuffer on pre-gen6 will use
it. And we need old userspace to keep on working - presumably the fb layer
will switch to using the new atomic modeset stuff (if available) to figure
out an optimal config, so this is relevant.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch