From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Daniel Stone <daniel@fooishbar.org>
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 18:01:47 +0200 [thread overview]
Message-ID: <CAKMK7uEyt0d0LidUCQL4oHZRYZdDEFhy=DnRF7WwD1S1+ackFQ@mail.gmail.com> (raw)
In-Reply-To: <CAPj87rNLzFjn7xyePmEBEY8teL7TnL-HrQHXbp7C1tXDdWgeUA@mail.gmail.com>
On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone <daniel@fooishbar.org> wrote:
>
> 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.
Ok so the hang-up last time around iirc was that I broke igt by making
a few things more synchronous. Let's hope I'm not also breaking stuff
with the WARN_ON ...
New plan:
- make this patch here only document existing behaviour and enforce it
with the WARN_ON
- new uapi would be behind a flag or something, with userspace and
everything hanging off it.
Thoughts?
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Daniel Stone <daniel@fooishbar.org>
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 18:01:47 +0200 [thread overview]
Message-ID: <CAKMK7uEyt0d0LidUCQL4oHZRYZdDEFhy=DnRF7WwD1S1+ackFQ@mail.gmail.com> (raw)
In-Reply-To: <CAPj87rNLzFjn7xyePmEBEY8teL7TnL-HrQHXbp7C1tXDdWgeUA@mail.gmail.com>
On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone <daniel@fooishbar.org> wrote:
>
> 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.
Ok so the hang-up last time around iirc was that I broke igt by making
a few things more synchronous. Let's hope I'm not also breaking stuff
with the WARN_ON ...
New plan:
- make this patch here only document existing behaviour and enforce it
with the WARN_ON
- new uapi would be behind a flag or something, with userspace and
everything hanging off it.
Thoughts?
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
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 Vetter <daniel.vetter@ffwll.ch>
To: Daniel Stone <daniel@fooishbar.org>
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 18:01:47 +0200 [thread overview]
Message-ID: <CAKMK7uEyt0d0LidUCQL4oHZRYZdDEFhy=DnRF7WwD1S1+ackFQ@mail.gmail.com> (raw)
In-Reply-To: <CAPj87rNLzFjn7xyePmEBEY8teL7TnL-HrQHXbp7C1tXDdWgeUA@mail.gmail.com>
On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone <daniel@fooishbar.org> wrote:
>
> 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.
Ok so the hang-up last time around iirc was that I broke igt by making
a few things more synchronous. Let's hope I'm not also breaking stuff
with the WARN_ON ...
New plan:
- make this patch here only document existing behaviour and enforce it
with the WARN_ON
- new uapi would be behind a flag or something, with userspace and
everything hanging off it.
Thoughts?
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
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 16:02 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
2020-09-22 14:14 ` [Intel-gfx] " Daniel Stone
2020-09-22 14:14 ` Daniel Stone
2020-09-22 16:01 ` Daniel Vetter [this message]
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='CAKMK7uEyt0d0LidUCQL4oHZRYZdDEFhy=DnRF7WwD1S1+ackFQ@mail.gmail.com' \
--to=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=daniel@fooishbar.org \
--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.