All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marius Vlad <marius.vlad@collabora.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Stone <daniel@fooishbar.org>,
	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: Wed, 23 Sep 2020 14:14:43 +0300	[thread overview]
Message-ID: <20200923111443.GA8478@xpredator> (raw)
In-Reply-To: <CAKMK7uHr3dKu8o4e3hoSe3S5MfVtZ92nLk1VGZTqSuDsH6kphg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2451 bytes --]

On Wed, Sep 23, 2020 at 12:58:30PM +0200, Daniel Vetter wrote:
> On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad <marius.vlad@collabora.com> wrote:
> >
> > On Fri, Jan 31, 2020 at 07:34:00AM +0000, Daniel Stone wrote:
> > > 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.
> > Gentle ping. I've tried out Linus's master tree and, and like Pekka,
> > I've noticed this isn't integrated/added.
> >
> > Noticed this is fixing (also) DPMS when multiple outputs are in use.
> > Wondering if we can just use a _ONCE() variant instead of WARN_ON(). I'm seeing
> > the warning quite often.
> 
> On which driver/chip does this happen?
I've tried it out on i915.
> -Daniel
> 
> >
> > >
> > > 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
> 
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Marius Vlad <marius.vlad@collabora.com>
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>
Subject: Re: [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
Date: Wed, 23 Sep 2020 14:14:43 +0300	[thread overview]
Message-ID: <20200923111443.GA8478@xpredator> (raw)
In-Reply-To: <CAKMK7uHr3dKu8o4e3hoSe3S5MfVtZ92nLk1VGZTqSuDsH6kphg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2451 bytes --]

On Wed, Sep 23, 2020 at 12:58:30PM +0200, Daniel Vetter wrote:
> On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad <marius.vlad@collabora.com> wrote:
> >
> > On Fri, Jan 31, 2020 at 07:34:00AM +0000, Daniel Stone wrote:
> > > 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.
> > Gentle ping. I've tried out Linus's master tree and, and like Pekka,
> > I've noticed this isn't integrated/added.
> >
> > Noticed this is fixing (also) DPMS when multiple outputs are in use.
> > Wondering if we can just use a _ONCE() variant instead of WARN_ON(). I'm seeing
> > the warning quite often.
> 
> On which driver/chip does this happen?
I've tried it out on i915.
> -Daniel
> 
> >
> > >
> > > 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
> 
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
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: Marius Vlad <marius.vlad@collabora.com>
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>
Subject: Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
Date: Wed, 23 Sep 2020 14:14:43 +0300	[thread overview]
Message-ID: <20200923111443.GA8478@xpredator> (raw)
In-Reply-To: <CAKMK7uHr3dKu8o4e3hoSe3S5MfVtZ92nLk1VGZTqSuDsH6kphg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2451 bytes --]

On Wed, Sep 23, 2020 at 12:58:30PM +0200, Daniel Vetter wrote:
> On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad <marius.vlad@collabora.com> wrote:
> >
> > On Fri, Jan 31, 2020 at 07:34:00AM +0000, Daniel Stone wrote:
> > > 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.
> > Gentle ping. I've tried out Linus's master tree and, and like Pekka,
> > I've noticed this isn't integrated/added.
> >
> > Noticed this is fixing (also) DPMS when multiple outputs are in use.
> > Wondering if we can just use a _ONCE() variant instead of WARN_ON(). I'm seeing
> > the warning quite often.
> 
> On which driver/chip does this happen?
I've tried it out on i915.
> -Daniel
> 
> >
> > >
> > > 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
> 
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

[-- Attachment #1.2: signature.asc --]
[-- 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

  reply	other threads:[~2020-09-23 11: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
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 [this message]
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=20200923111443.GA8478@xpredator \
    --to=marius.vlad@collabora.com \
    --cc=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=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.