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

[Rob Clark]

On Fri, Nov 9, 2012 at 3:20 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> 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].

hmm, how does this not break weston compositor-drm (and modetest w/
vsync'd flipping.. although I suppose that is a less important
use-case)

>> 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.

yeah, not quite sure how the backwards-compat should work.. you'd have
to somehow only dynamically reassign crtcs if you could tell that
userspace is new enough to cope..

BR,
-R

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