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

[Daniel Stone]

On Wed, 10 Feb 2021 at 15:07, Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
> On Wed, Feb 10, 2021 at 01:38:45PM +0000, Simon Ser wrote:
> > The WARN_ON only happens if allow_modeset == false. If allow_modeset == true,
> > then the driver is allowed to steal an unrelated pipe.
> >
> > Maybe i915 is stealing a pipe without allow_modeset?
>
> No. All page flips etc. will have to get split up internally
> between multiple crtcs.

I think this is the salient point.

> So I think there's basically three options:
> a) massive rewrite of i915 to bypass even more of drm_atomic stuff
> b) allow i915 to silence that warning, which opens up the question
>    whether the warn is doing any good if it can just be bypassed
> c) nuke the warning entirely
>
> a) is not going to happen, and it would any way allow i915 to
> do things any which way it wants without tripping the warn,
> rendering the warn entirely toothless.
>
> Hmm. Maybe there is a d) which would be to ignore all crtcs
> that are not logically enabled in the warn? Not sure if that
> could allow something to slit through that people want it to
> catch?

So from what I understand, if I enable CRTC 44 and the driver
magically decides to split it up as a 'big-joiner' output, it will
also steal CRTC 50 to work as the other half of the output. Then if I
attach plane 47 to CRTC 44, posting a FB to plane 47 will result in me
getting atomic completion events for both CRTC 44 and CRTC 50?

That's not OK from a userspace perspective. If you want to do magic to
create the illusion of a single CRTC, then that magic needs to be
consistent. At the moment it's the worst kind of magic: it does
implicit things under the hood for you, but then leaks all of the
behind-the-scenes detail into userspace.

Continuing with that would force us all to just ignore whatever events
we see, because we can't reason about what they may be or why they're
generated. Which doesn't allow for any kind of best practice in
userspace.

Cheers,
Daniel