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>,
"Pekka Paalanen" <pekka.paalanen@collabora.co.uk>,
"Simon Ser" <contact@emersion.fr>,
stable <stable@vger.kernel.org>,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Daniel Vetter" <daniel.vetter@intel.com>
Subject: Re: [PATCH] drm: document and enforce rules around "spurious" EBUSY from atomic_commit
Date: Tue, 22 Sep 2020 20:22:28 +0100 [thread overview]
Message-ID: <CAPj87rP1uBqhhBfJ0phSaOfoAptauTmeOkk_uD-N2kCCnH=_tw@mail.gmail.com> (raw)
In-Reply-To: <20200922181834.2913552-1-daniel.vetter@ffwll.ch>
Hi,
On Tue, 22 Sep 2020 at 19:18, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> + 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
> + * this 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) {
> + /* adding other CRTC is only allowed for modeset commits */
> + WARN_ON(!state->allow_modeset);
> + }
> +
Can we please add a DRM_DEBUG() here, regardless of the WARN_ON(), to
let people know what's happening?
With that, R-b me.
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>,
stable <stable@vger.kernel.org>,
DRI Development <dri-devel@lists.freedesktop.org>,
Daniel Vetter <daniel.vetter@intel.com>,
Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Subject: Re: [PATCH] drm: document and enforce rules around "spurious" EBUSY from atomic_commit
Date: Tue, 22 Sep 2020 20:22:28 +0100 [thread overview]
Message-ID: <CAPj87rP1uBqhhBfJ0phSaOfoAptauTmeOkk_uD-N2kCCnH=_tw@mail.gmail.com> (raw)
In-Reply-To: <20200922181834.2913552-1-daniel.vetter@ffwll.ch>
Hi,
On Tue, 22 Sep 2020 at 19:18, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> + 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
> + * this 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) {
> + /* adding other CRTC is only allowed for modeset commits */
> + WARN_ON(!state->allow_modeset);
> + }
> +
Can we please add a DRM_DEBUG() here, regardless of the WARN_ON(), to
let people know what's happening?
With that, R-b me.
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: Simon Ser <contact@emersion.fr>,
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>,
Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Subject: Re: [Intel-gfx] [PATCH] drm: document and enforce rules around "spurious" EBUSY from atomic_commit
Date: Tue, 22 Sep 2020 20:22:28 +0100 [thread overview]
Message-ID: <CAPj87rP1uBqhhBfJ0phSaOfoAptauTmeOkk_uD-N2kCCnH=_tw@mail.gmail.com> (raw)
In-Reply-To: <20200922181834.2913552-1-daniel.vetter@ffwll.ch>
Hi,
On Tue, 22 Sep 2020 at 19:18, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> + 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
> + * this 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) {
> + /* adding other CRTC is only allowed for modeset commits */
> + WARN_ON(!state->allow_modeset);
> + }
> +
Can we please add a DRM_DEBUG() here, regardless of the WARN_ON(), to
let people know what's happening?
With that, R-b me.
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 19:22 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-22 18:18 [PATCH] drm: document and enforce rules around "spurious" EBUSY from atomic_commit Daniel Vetter
2020-09-22 18:18 ` [Intel-gfx] " Daniel Vetter
2020-09-22 18:18 ` Daniel Vetter
2020-09-22 18:57 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2020-09-22 19:22 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-09-22 19:22 ` Daniel Stone [this message]
2020-09-22 19:22 ` [Intel-gfx] [PATCH] " Daniel Stone
2020-09-22 19:22 ` Daniel Stone
2020-09-22 22:27 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for " Patchwork
2020-09-23 8:17 ` [PATCH] " Pekka Paalanen
2020-09-23 8:17 ` [Intel-gfx] " Pekka Paalanen
2020-09-23 8:17 ` Pekka Paalanen
2020-09-23 9:16 ` Daniel Vetter
2020-09-23 9:16 ` [Intel-gfx] " Daniel Vetter
2020-09-23 9:16 ` Daniel Vetter
2020-09-23 9:21 ` Daniel Vetter
2020-09-23 9:21 ` [Intel-gfx] " Daniel Vetter
2020-09-23 9:21 ` Daniel Vetter
2020-09-23 9:26 ` Daniel Vetter
2020-09-23 9:26 ` [Intel-gfx] " Daniel Vetter
2020-09-23 9:26 ` Daniel Vetter
2020-09-23 9:55 ` Pekka Paalanen
2020-09-23 9:55 ` [Intel-gfx] " Pekka Paalanen
2020-09-23 9:55 ` Pekka Paalanen
2020-09-23 10:31 ` Ville Syrjälä
2020-09-23 10:31 ` [Intel-gfx] " Ville Syrjälä
2020-09-23 10:37 ` Daniel Vetter
2020-09-23 10:37 ` [Intel-gfx] " Daniel Vetter
2020-09-23 10:37 ` 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='CAPj87rP1uBqhhBfJ0phSaOfoAptauTmeOkk_uD-N2kCCnH=_tw@mail.gmail.com' \
--to=daniel@fooishbar.org \
--cc=contact@emersion.fr \
--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 \
--cc=ville.syrjala@linux.intel.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 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.