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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 1 Nov 2012 12:12:35 +0100
Daniel Vetter <daniel@xxxxxxxx> wrote:

> On Thu, Oct 25, 2012 at 8:05 PM,  <ville.syrjala@xxxxxxxxxxxxxxx> wrote:
> > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> >
> > Send completion events when the atomic modesetting operations has
> > finished succesfully.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> 
> 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.

-- 
Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux