[Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY

[Pekka Paalanen]

On Wed, 23 Sep 2020 22:01:25 +0200
Daniel Vetter <daniel.vetter at ffwll.ch> wrote:

> On Wed, Sep 23, 2020 at 9:17 PM Marius Vlad <marius.vlad at collabora.com> wrote:
> >
> > On Wed, Sep 23, 2020 at 05:18:52PM +0200, Daniel Vetter wrote:  
> > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > pull in arbitrary other resources, including CRTCs (e.g. when
> > > reconfiguring global resources).

...

> > > @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
> > >               }
> > >       }
> > >
> > > +     for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> > > +             affected_crtc |= drm_crtc_mask(crtc);
> > > +
> > > +     /*
> > > +      * For commits that allow modesets drivers can add other CRTCs to the
> > > +      * atomic commit, e.g. when they need to reallocate global resources.
> > > +      * This can cause spurious EBUSY, which robs compositors of a very
> > > +      * effective sanity check for their drawing loop. Therefor only allow
> > > +      * drivers to add unrelated CRTC states for modeset commits.
> > > +      *
> > > +      * FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output
> > > +      * so compositors know what's going on.
> > > +      */
> > > +     if (affected_crtc != requested_crtc) {
> > > +             DRM_DEBUG_ATOMIC("driver added CRTC to commit: requested 0x%x, affected 0x%0x\n",
> > > +                              requested_crtc, affected_crtc);
> > > +             WARN(!state->allow_modeset, "adding CRTC not allowed without modesets: requested 0x%x, affected 0x%0x\n",
> > > +                  requested_crtc, affected_crtc);  
> > Previous patch had the warn on state->allow_modeset now is
> > !state->allow_modeset. Is that correct?  
> 
> We need to fire a warning when allow_modeset is _not_ set. An earlier
> version got that wrong, and yes that would have caused a _ton_ of
> warnings on any fairly new intel platform.
> 
> > I haven't followed the entire thread on this matter, but I guess the idea
> > is that somehow the kernel would pass to userspace a CRTC mask of
> > affected_crtc (somehow, we don't know how atm) and with it, userspace
> > can then issue a new commit (this commit blocking) with those?  
> 
> Either that, or just use that to track all the in-flight drm events.
> Userspace will get events for all the crtc, not just the one it asked
> to update.

Wait, does that happen already? Getting CRTC events for CRTCs userspace
didn't include in the atomic commit?

That could explain why Weston freaks out in
https://gitlab.freedesktop.org/wayland/weston/-/issues/435


Thanks,
pq


> If that's easier to do by re-issuing the commit with the
> full set of crtc, then I guess that's an option. But not required (I
> think at least, would need to test that to make sure).
> -Daniel
> 
> > > +     }
> > > +
> > >       return 0;
> > >  }
> > >  EXPORT_SYMBOL(drm_atomic_check_only);
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20200924/9faf3908/attachment.sig>