From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Imre Deak <imre.deak@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix fastsets on TypeC ports following a non-blocking modeset
Date: Fri, 12 Nov 2021 23:14:52 +0200 [thread overview]
Message-ID: <YY7ZTAMj/VKorHJH@intel.com> (raw)
In-Reply-To: <20211112190904.62920-1-imre.deak@intel.com>
On Fri, Nov 12, 2021 at 09:09:04PM +0200, Imre Deak wrote:
> After a non-blocking modeset on a TypeC port's CRTC - possibly blocked
> later in drm_atomic_helper_wait_for_dependencies() - a fastset on the
> same CRTC may copy the state of CRTC before this gets updated to reflect
> the up-to-date DP-alt vs. TBT-alt TypeC mode DPLL used for the CRTC. In
> this case after the first (non-blocking) commit completes enabling the
> DPLL required for the up-to-date TypeC mode the following fastset will
> update the CRTC state pointing to the wrong DPLL. A subsequent disabling
> modeset will try to disable the wrong PLL, triggering a state checker
> WARN (and leaving the DPLL which is actually used active for good).
>
> Fix the above race by copying the DPLL state for fastset CRTCs from the
> old CRTC state at the point where it's guaranteed to be up-to-date
> already. This could be handled in the encoder's update_prepare() hook as
> well, but that's a bigger change, which is better done as a follow-up.
>
> Testcase: igt/kms_busy/extended-modeset-hang-newfb-with-reset
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4308
> Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> Signed-off-by: Imre Deak <imre.deak@intel.com>
This is getting a bit unpleasant. Maybe we should just get rid of
shared_dpll entirely and track the currently active pll entirely
elsewhere, I guess maybe in intel_crtc? That would at least make it
a bit more clear that it's no longer your normal pre-computed state
thing. Though that would have some implications for state readout,
so might turn a bit hairy as well. Dunno.
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 25 ++++++++++++++++----
> 1 file changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index 0ceee8ac66717..76ebb3c91a75b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1572,10 +1572,24 @@ intel_connector_primary_encoder(struct intel_connector *connector)
>
> static void intel_encoders_update_prepare(struct intel_atomic_state *state)
> {
> + struct intel_crtc_state *new_crtc_state, *old_crtc_state;
> + struct intel_crtc *crtc;
> struct drm_connector_state *new_conn_state;
> struct drm_connector *connector;
> int i;
>
> + /*
> + * Make sure the DPLL state is up-to-date for fastset TypeC ports after non-blocking commits.
> + * TODO: Update the DPLL state for all cases in the encoder->update_prepare() hook.
> + */
> + for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state, new_crtc_state, i) {
> + if (!intel_crtc_needs_modeset(new_crtc_state))
> + new_crtc_state->shared_dpll = old_crtc_state->shared_dpll;
> + }
Don't we want to copy the pll state as well?
> +
> + if (!state->modeset)
> + return;
> +
> for_each_new_connector_in_state(&state->base, connector, new_conn_state,
> i) {
> struct intel_connector *intel_connector;
> @@ -1602,6 +1616,9 @@ static void intel_encoders_update_complete(struct intel_atomic_state *state)
> struct drm_connector *connector;
> int i;
>
> + if (!state->modeset)
> + return;
> +
> for_each_new_connector_in_state(&state->base, connector, new_conn_state,
> i) {
> struct intel_connector *intel_connector;
> @@ -8670,8 +8687,7 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
> }
> }
>
> - if (state->modeset)
> - intel_encoders_update_prepare(state);
> + intel_encoders_update_prepare(state);
>
> intel_dbuf_pre_plane_update(state);
>
> @@ -8683,11 +8699,10 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
> /* Now enable the clocks, plane, pipe, and connectors that we set up. */
> dev_priv->display->commit_modeset_enables(state);
>
> - if (state->modeset) {
> - intel_encoders_update_complete(state);
> + intel_encoders_update_complete(state);
>
> + if (state->modeset)
> intel_set_cdclk_post_plane_update(state);
> - }
>
> intel_wait_for_vblank_workers(state);
>
> --
> 2.27.0
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2021-11-12 21:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-12 19:09 [Intel-gfx] [PATCH] drm/i915: Fix fastsets on TypeC ports following a non-blocking modeset Imre Deak
2021-11-12 20:05 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2021-11-12 20:10 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2021-11-12 20:37 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-11-12 21:14 ` Ville Syrjälä [this message]
2021-11-15 12:45 ` [Intel-gfx] [PATCH] " Imre Deak
2021-11-15 15:38 ` Ville Syrjälä
2021-11-15 17:26 ` Imre Deak
2021-11-15 17:33 ` Ville Syrjälä
2021-11-15 17:39 ` Imre Deak
2021-11-12 22:32 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for " Patchwork
2021-11-15 18:11 ` [Intel-gfx] [PATCH v2] " Imre Deak
2021-11-16 12:29 ` Kahola, Mika
2021-11-15 18:28 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Fix fastsets on TypeC ports following a non-blocking modeset (rev2) Patchwork
2021-11-15 18:32 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2021-11-15 18:58 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-11-15 20:31 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-11-16 12:47 ` Imre Deak
2021-11-16 18:43 ` Vudum, Lakshminarayana
2021-11-16 17:57 ` [Intel-gfx] ✓ Fi.CI.IGT: success " Patchwork
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=YY7ZTAMj/VKorHJH@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.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.