From: Daniel Stone <daniel@fooishbar.org>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Marius Vlad <marius.vlad@collabora.com>,
Pekka Paalanen <pekka.paalanen@collabora.co.uk>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
stable <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: Tue, 22 Sep 2020 15:14:11 +0100 [thread overview]
Message-ID: <CAPj87rNLzFjn7xyePmEBEY8teL7TnL-HrQHXbp7C1tXDdWgeUA@mail.gmail.com> (raw)
In-Reply-To: <CAKMK7uHCeFan4+agMn0sr-z9UDyZwEJv0_dL-K-gA1n0=m+A2w@mail.gmail.com>
On Tue, 22 Sep 2020 at 15:04, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad <marius.vlad@collabora.com> wrote:
> > Gentle ping. I've tried out Linus's master tree and, and like Pekka,
> > I've noticed this isn't integrated/added.
>
> Defacto the uapi we have now is that userspace needs to ignore "spurious" EBUSY.
This really, really, really, bites.
I think we need a guarantee that this never happens if ALLOW_MODESET
is always used in blocking mode, plus in future a cap we can use to
detect that we won't be getting spurious EBUSY events.
I really don't want to ever paper over this, because it's one of the
clearest indications that userspace has its timing/signalling wrong.
Cheers,
Daniel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Stone <daniel@fooishbar.org>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
DRI Development <dri-devel@lists.freedesktop.org>,
stable <stable@vger.kernel.org>,
Daniel Vetter <daniel.vetter@intel.com>,
Pekka Paalanen <pekka.paalanen@collabora.co.uk>,
Marius Vlad <marius.vlad@collabora.com>
Subject: Re: [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
Date: Tue, 22 Sep 2020 15:14:11 +0100 [thread overview]
Message-ID: <CAPj87rNLzFjn7xyePmEBEY8teL7TnL-HrQHXbp7C1tXDdWgeUA@mail.gmail.com> (raw)
In-Reply-To: <CAKMK7uHCeFan4+agMn0sr-z9UDyZwEJv0_dL-K-gA1n0=m+A2w@mail.gmail.com>
On Tue, 22 Sep 2020 at 15:04, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad <marius.vlad@collabora.com> wrote:
> > Gentle ping. I've tried out Linus's master tree and, and like Pekka,
> > I've noticed this isn't integrated/added.
>
> Defacto the uapi we have now is that userspace needs to ignore "spurious" EBUSY.
This really, really, really, bites.
I think we need a guarantee that this never happens if ALLOW_MODESET
is always used in blocking mode, plus in future a cap we can use to
detect that we won't be getting spurious EBUSY events.
I really don't want to ever paper over this, because it's one of the
clearest indications that userspace has its timing/signalling wrong.
Cheers,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Stone <daniel@fooishbar.org>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
DRI Development <dri-devel@lists.freedesktop.org>,
stable <stable@vger.kernel.org>,
Daniel Vetter <daniel.vetter@intel.com>,
Pekka Paalanen <pekka.paalanen@collabora.co.uk>,
Marius Vlad <marius.vlad@collabora.com>
Subject: Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
Date: Tue, 22 Sep 2020 15:14:11 +0100 [thread overview]
Message-ID: <CAPj87rNLzFjn7xyePmEBEY8teL7TnL-HrQHXbp7C1tXDdWgeUA@mail.gmail.com> (raw)
In-Reply-To: <CAKMK7uHCeFan4+agMn0sr-z9UDyZwEJv0_dL-K-gA1n0=m+A2w@mail.gmail.com>
On Tue, 22 Sep 2020 at 15:04, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad <marius.vlad@collabora.com> wrote:
> > Gentle ping. I've tried out Linus's master tree and, and like Pekka,
> > I've noticed this isn't integrated/added.
>
> Defacto the uapi we have now is that userspace needs to ignore "spurious" EBUSY.
This really, really, really, bites.
I think we need a guarantee that this never happens if ALLOW_MODESET
is always used in blocking mode, plus in future a cap we can use to
detect that we won't be getting spurious EBUSY events.
I really don't want to ever paper over this, because it's one of the
clearest indications that userspace has its timing/signalling wrong.
Cheers,
Daniel
_______________________________________________
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-22 14:14 UTC|newest]
Thread overview: 54+ 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:10 ` Daniel Vetter
2018-07-05 10:21 ` Daniel Vetter
2020-01-31 7:34 ` Daniel Stone
2020-01-31 7:34 ` [Intel-gfx] " Daniel Stone
2020-01-31 7:34 ` Daniel Stone
2020-09-22 13:36 ` Marius Vlad
2020-09-22 13:36 ` [Intel-gfx] " Marius Vlad
2020-09-22 13:36 ` Marius Vlad
2020-09-22 14:04 ` Daniel Vetter
2020-09-22 14:04 ` [Intel-gfx] " Daniel Vetter
2020-09-22 14:04 ` Daniel Vetter
2020-09-22 14:14 ` Daniel Stone [this message]
2020-09-22 14:14 ` [Intel-gfx] " Daniel Stone
2020-09-22 14:14 ` Daniel Stone
2020-09-22 16:01 ` Daniel Vetter
2020-09-22 16:01 ` [Intel-gfx] " Daniel Vetter
2020-09-22 16:01 ` Daniel Vetter
2020-09-22 19:02 ` Daniel Stone
2020-09-22 19:02 ` [Intel-gfx] " Daniel Stone
2020-09-22 19:02 ` Daniel Stone
2020-09-23 10:58 ` Daniel Vetter
2020-09-23 10:58 ` [Intel-gfx] " Daniel Vetter
2020-09-23 10:58 ` Daniel Vetter
2020-09-23 11:14 ` Marius Vlad
2020-09-23 11:14 ` [Intel-gfx] " Marius Vlad
2020-09-23 11:14 ` Marius Vlad
2020-09-23 11:16 ` Daniel Vetter
2020-09-23 11:16 ` [Intel-gfx] " Daniel Vetter
2020-09-23 11:16 ` Daniel Vetter
2020-09-23 11:31 ` Marius Vlad
2020-09-23 11:31 ` [Intel-gfx] " Marius Vlad
2020-09-23 11:31 ` Marius Vlad
2018-07-05 10:25 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2018-07-05 10:41 ` ✓ Fi.CI.BAT: success " Patchwork
2018-07-05 10:45 ` ✗ Fi.CI.CHECKPATCH: warning for drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev2) Patchwork
2018-07-05 11:01 ` ✓ Fi.CI.BAT: success " Patchwork
2018-07-05 12:23 ` ✗ Fi.CI.IGT: failure " Patchwork
2020-02-25 11:50 [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets Daniel Vetter
2020-02-25 11:50 ` Daniel Vetter
2020-04-08 16:24 Daniel Vetter
2020-04-08 16:24 ` Daniel Vetter
2020-05-14 6:40 ` Daniel Stone
2020-05-14 6:40 ` Daniel Stone
2020-05-14 7:08 ` Daniel Vetter
2020-05-14 7:08 ` Daniel Vetter
2020-05-14 7:16 ` Daniel Stone
2020-05-14 7:16 ` Daniel Stone
2020-05-14 7:25 ` Daniel Vetter
2020-05-14 7:25 ` Daniel Vetter
2020-05-14 7:40 ` Daniel Stone
2020-05-14 7:40 ` Daniel Stone
2020-05-14 12:32 ` Daniel Vetter
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=CAPj87rNLzFjn7xyePmEBEY8teL7TnL-HrQHXbp7C1tXDdWgeUA@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=marius.vlad@collabora.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.