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

[Jesse Barnes]

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.
> > > 
> > > 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.
> > 
> > Yeah that's a good point... adding a virtual crtc layer would solve
> > this and let us preserve the existing ABI.
> 
> How would the state handling work? I mean if drm_crtc X currently has
> some state, drm_crtc Y has some other state, and then we do a modeset
> which would require swapping the roles of the crtcs, what would happen
> to the bits of state that we didn't specify?
> 
> If we'd do the remapping below the drm crtc layer, the state would
> always be tied to the drm crtc. But that would definitely require
> mostly uniform hardware "crtcs" so that the capabilities of the
> drm_crtcs wouldn't keep changing whenever the remap happens.
> 
> Well, I suppose we could tie the state to the virtual crtc instead,
> and doing an operation on a real drm_crtc would also change the
> state of the currently bound virtual crtc. And then changing the
> virtual<->real mapping would just copy the state over from the virtual
> crtc to the real drm_crtc.
> 
> And if we do it for crtcs, then we'd need to do it for planes as well,
> because the plane<->crtc mapping can be fixed or otherwise limited
> in some fashion.
> 
> Either way it sounds rather messy to me.
> 
> Another option would be just leave it up to userspace to make the
> correct choice between crtcs and planes. But then user space needs
> to be equipped with more hardware specific knowledge, so it's not
> a very appealing idea either.

Yeah it gets ugly one way or another.  From a userspace perspective,
keeping the ugliness in the kernel is nice, and if we have to do it
somewhere I guess I'd prefer that.

However, we can't always hide hw details like that in the kernel
through generic interfaces (e.g. for sprites and all their
restrictions) so userspace will have to have some knowledge one way or
another, and maybe it's not that bad to push some of the other
limitation knowledge into our userspace code.

Ambivalent.

-- 
Jesse Barnes, Intel Open Source Technology Center