All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Imre Deak <imre.deak@intel.com>,
	intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/dp_mst: Fix encoder HW state readout for UHBR MST
Date: Mon, 24 Feb 2025 12:34:36 +0200	[thread overview]
Message-ID: <8734g38wcj.fsf@intel.com> (raw)
In-Reply-To: <20250224093242.1859583-1-imre.deak@intel.com>

On Mon, 24 Feb 2025, Imre Deak <imre.deak@intel.com> wrote:
> The encoder HW/SW state verification should use a SW state which stays
> unchanged while the encoder/output is active. The intel_dp::is_mst flag
> used during state computation to choose between the DP SST/MST modes can
> change while the output is active, if the sink gets disconnected or the
> MST topology is removed for another reason. A subsequent state
> verification using intel_dp::is_mst leads then to a mismatch if the
> output is disabled/re-enabled without recomputing its state.
>
> Use the encoder's active MST link count instead, which will be always
> non-zero for an active MST output and will be zero for SST.
>
> Fixes: 35d2e4b75649 ("drm/i915/ddi: start distinguishing 128b/132b SST and MST at state readout")
> Fixes: 40d489fac0e8 ("drm/i915/ddi: handle 128b/132b SST in intel_ddi_read_func_ctl()")
> Cc: Jani Nikula <jani.nikula@intel.com>
> Signed-off-by: Imre Deak <imre.deak@intel.com>

Do we have a bug for this?

> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 7937f4de66cb4..8c8b53414da67 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -890,7 +890,7 @@ static void intel_ddi_get_encoder_pipes(struct intel_encoder *encoder,
>  			    encoder->base.base.id, encoder->base.name);
>  
>  	if (!mst_pipe_mask && dp128b132b_pipe_mask) {
> -		struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +		struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
>  
>  		/*
>  		 * If we don't have 8b/10b MST, but have more than one
> @@ -902,7 +902,8 @@ static void intel_ddi_get_encoder_pipes(struct intel_encoder *encoder,
>  		 * we don't expect MST to have been enabled at that point, and
>  		 * can assume it's SST.
>  		 */
> -		if (hweight8(dp128b132b_pipe_mask) > 1 || intel_dp->is_mst)
> +		if (hweight8(dp128b132b_pipe_mask) > 1 ||
> +		    intel_dp_mst_encoder_active_links(dig_port))

I think the reasoning here is valid, but I think we should probably do
something about the intel_dp_mst_encoder_active_links() naming as
follow-up. This is confusing. What is an "mst encoder"? The above
expects the primary digital port, i.e. it assumes enc_to_dig_port()
already did the right thing. It's all really subtle. Also wrt which
encoders the intel_ddi_get_encoder_pipes() gets called on.

Maybe we need s/intel_dp_mst_encoder/intel_dp_mst_primary/ for this and
some other functions? They're not about the "fake" mst stream encoders.

Anyway,

Reviewed-by: Jani Nikula <jani.nikula@intel.com>


>  			mst_pipe_mask = dp128b132b_pipe_mask;
>  	}
>  
> @@ -4131,13 +4132,13 @@ static void intel_ddi_read_func_ctl(struct intel_encoder *encoder,
>  	} else if (ddi_mode == TRANS_DDI_MODE_SELECT_DP_MST) {
>  		intel_ddi_read_func_ctl_dp_mst(encoder, pipe_config, ddi_func_ctl);
>  	} else if (ddi_mode == TRANS_DDI_MODE_SELECT_FDI_OR_128B132B && HAS_DP20(display)) {
> -		struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +		struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
>  
>  		/*
>  		 * If this is true, we know we're being called from mst stream
>  		 * encoder's ->get_config().
>  		 */
> -		if (intel_dp->is_mst)
> +		if (intel_dp_mst_encoder_active_links(dig_port))
>  			intel_ddi_read_func_ctl_dp_mst(encoder, pipe_config, ddi_func_ctl);
>  		else
>  			intel_ddi_read_func_ctl_dp_sst(encoder, pipe_config, ddi_func_ctl);

-- 
Jani Nikula, Intel

  reply	other threads:[~2025-02-24 13:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-24  9:32 [PATCH] drm/i915/dp_mst: Fix encoder HW state readout for UHBR MST Imre Deak
2025-02-24 10:34 ` Jani Nikula [this message]
2025-02-24 12:13   ` Imre Deak
2025-02-24 16:21 ` ✓ i915.CI.BAT: success for " Patchwork
2025-02-24 18:28 ` ✗ i915.CI.Full: failure " Patchwork
2025-02-25 14:11   ` Imre Deak
2025-02-24 19:43 ` ✓ CI.Patch_applied: success " Patchwork
2025-02-24 19:44 ` ✓ CI.checkpatch: " Patchwork
2025-02-24 19:45 ` ✓ CI.KUnit: " Patchwork
2025-02-24 20:01 ` ✓ CI.Build: " Patchwork
2025-02-24 20:04 ` ✓ CI.Hooks: " Patchwork
2025-02-24 20:05 ` ✓ CI.checksparse: " Patchwork
2025-02-24 20:26 ` ✓ Xe.CI.BAT: " Patchwork
2025-02-24 21:21 ` ✗ Xe.CI.Full: failure " 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=8734g38wcj.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@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.