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

[Ville Syrjälä]

On Thu, Feb 11, 2021 at 04:14:02PM +0000, Daniel Stone wrote:
> 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.

You should only get externally visibile events for stuff in your
request. Or at least if that's not the case then the atomic
code is already bork regardless of bigjoiner.

-- 
Ville Syrjälä
Intel