From: Pekka Paalanen <ppaalanen@gmail.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Marius Vlad <marius.vlad@collabora.com>,
DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
Date: Thu, 24 Sep 2020 10:41:01 +0300 [thread overview]
Message-ID: <20200924104101.63be1c13@eldfell> (raw)
In-Reply-To: <CAKMK7uH0WiEPP1H1DZPdE4mJdStTTtnZJQN5rjnkG_6va_1Tdg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3028 bytes --]
On Wed, 23 Sep 2020 22:01:25 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Wed, Sep 23, 2020 at 9:17 PM Marius Vlad <marius.vlad@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);
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-09-24 7:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-23 10:57 [Intel-gfx] [PATCH 1/2] drm/atomic: document and enforce rules around "spurious" EBUSY Daniel Vetter
2020-09-23 10:57 ` [Intel-gfx] [PATCH 2/2] drm/atomic: debug output for EBUSY Daniel Vetter
2020-09-25 8:27 ` Pekka Paalanen
2020-09-23 11:03 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/atomic: document and enforce rules around "spurious" EBUSY Patchwork
2020-09-23 11:28 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-09-23 14:33 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2020-09-23 15:18 ` [Intel-gfx] [PATCH] " Daniel Vetter
2020-09-23 19:17 ` Marius Vlad
2020-09-23 20:01 ` Daniel Vetter
2020-09-24 7:41 ` Pekka Paalanen [this message]
2020-09-24 8:04 ` Daniel Vetter
2020-09-24 10:10 ` Pekka Paalanen
2020-09-24 11:01 ` Ville Syrjälä
2020-09-24 11:13 ` Daniel Vetter
2020-09-24 11:32 ` Ville Syrjälä
2020-09-25 8:24 ` Pekka Paalanen
2020-09-25 8:45 ` Daniel Vetter
2020-09-23 15:47 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with drm/atomic: document and enforce rules around "spurious" EBUSY (rev2) Patchwork
2020-09-23 16:16 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200924104101.63be1c13@eldfell \
--to=ppaalanen@gmail.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=marius.vlad@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).