Re: [RFC PATCH] drm: Add plane event

[Daniel Vetter <daniel@ffwll.ch>]

On Wed, Apr 18, 2012 at 09:19:42PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 18, 2012 at 07:06:10PM +0300, Ville Syrjälä wrote:
> > On Wed, Apr 18, 2012 at 05:27:57PM +0200, Daniel Vetter wrote:
> > > Also, I'm toying around with ideas to split up the big modeset lock such
> > > that operations that only touch the crtc (like pageflip, plane changes and
> > > cursor changes) do not take the big modeset lock but only a per-crtc
> > > mutex.
> > 
> > Plane operations might well involve multiple CRTCs (when moving the
> > planes between pipes for example). You have to be careful with the
> > locking order when doing stuff like that. One option would be to
> > always take the per-CRTC locks in the same order (based on the
> > object ID for example).
> 
> Multiple locks will also cause problems for the atomic mode set. The
> full device state may be needed to evaluate whether a certain change
> is allowed, which means any change happening in parallel can screw
> things up.

Imo we can simply demand that any operation which touches more than 1 crtc
needs the big modeset lock. So atomic modeset would still take this look,
but modeset is a really rare operation, so no point to optimize for it.
The only issue I see is with switching a sprite from one crtc to another,
with that design this would also require the big modeset look. But
Kristian just brought up the idea of a prepare_sprite ioctl, so we could
do the crtc switch there, and userspace could run this ioctl asynchronous
in a separate thread to avoid stalls (e.g. on the old gen2 intel overlay a
crtc switch takes 2 full vblanks to disable and 1 full vblank to set up on
the new crtc, then another vblank to show anything). The nuclear pageflip
would then only touch one single crtc, so never get stalled by other
modeset operations.
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48