From: Daniel Stone <daniel@fooishbar.org>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
stable@vger.kernel.org,
DRI Development <dri-devel@lists.freedesktop.org>,
Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
Date: Fri, 31 Jan 2020 07:34:00 +0000 [thread overview]
Message-ID: <CAPj87rN48S8+pLd0ksOX4pdCTqtO=bDgjhkPxpWr_AnpVvgaSQ@mail.gmail.com> (raw)
In-Reply-To: <20180705102121.5091-1-daniel.vetter@ffwll.ch>
On Thu, 5 Jul 2018 at 11:21, Daniel Vetter <daniel.vetter@ffwll.ch> 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).
>
> But in nonblocking mode userspace has then no idea this happened,
> which can lead to spurious EBUSY calls, both:
> - when that other CRTC is currently busy doing a page_flip the
> ALLOW_MODESET commit can fail with an EBUSY
> - on the other CRTC a normal atomic flip can fail with EBUSY because
> of the additional commit inserted by the kernel without userspace's
> knowledge
>
> For blocking commits this isn't a problem, because everyone else will
> just block until all the CRTC are reconfigured. Only thing userspace
> can notice is the dropped frames without any reason for why frames got
> dropped.
>
> Consensus is that we need new uapi to handle this properly, but no one
> has any idea what exactly the new uapi should look like. As a stop-gap
> plug this problem by demoting nonblocking commits which might cause
> issues by including CRTCs not in the original request to blocking
> commits.
Thanks for writing this up Daniel, and for reminding me about it some
time later as well ...
Reviewed-by: Daniel Stone <daniels@collabora.com>
Cheers,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-01-31 7:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-05 10:10 [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets Daniel Vetter
2018-07-05 10:21 ` Daniel Vetter
2020-01-31 7:34 ` Daniel Stone [this message]
2020-09-22 13:36 ` Marius Vlad
2020-09-22 14:04 ` Daniel Vetter
2020-09-22 14:14 ` Daniel Stone
2020-09-22 16:01 ` Daniel Vetter
2020-09-22 19:02 ` Daniel Stone
2020-09-23 10:58 ` Daniel Vetter
2020-09-23 11:14 ` Marius Vlad
2020-09-23 11:16 ` Daniel Vetter
2020-09-23 11:31 ` Marius Vlad
2020-02-25 11:50 Daniel Vetter
2020-04-08 16:24 Daniel Vetter
2020-05-14 6:40 ` Daniel Stone
2020-05-14 7:08 ` Daniel Vetter
2020-05-14 7:16 ` Daniel Stone
2020-05-14 7:25 ` Daniel Vetter
2020-05-14 7:40 ` Daniel Stone
2020-05-14 12:32 ` Daniel Vetter
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='CAPj87rN48S8+pLd0ksOX4pdCTqtO=bDgjhkPxpWr_AnpVvgaSQ@mail.gmail.com' \
--to=daniel@fooishbar.org \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=pekka.paalanen@collabora.co.uk \
--cc=stable@vger.kernel.org \
/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).