Skip to content

Commit 35d2e4b

Browse files
committed
drm/i915/ddi: start distinguishing 128b/132b SST and MST at state readout
We'll want to distinguish 128b/132b SST and MST modes at state readout. There's a catch, though. From the hardware perspective, 128b/132b SST and MST programming are pretty much the same. And we can't really ask the sink at this point. If we have more than one transcoder in 128b/132b mode associated with the port, we can safely assume it's MST. But for MST with only a single stream enabled, we are pretty much out of luck. Let's fall back to looking at the software state, i.e. intel_dp->is_mst. It should be fine for the state checker, but for hardware takeover at probe, we'll have to trust the GOP has only enabled SST. TODO: Not sure how this *or* our current code handles 128b/132b enabled by GOP. Cc: Imre Deak <[email protected]> Cc: Ville Syrjälä <[email protected]> Reviewed-by: Imre Deak <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/119a773a0d4d74ad204435e462f8d12cb0ea4128.1735912293.git.jani.nikula@intel.com
1 parent 591b917 commit 35d2e4b

File tree

1 file changed

+23
-6
lines changed

1 file changed

+23
-6
lines changed

drivers/gpu/drm/i915/display/intel_ddi.c

Lines changed: 23 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -787,7 +787,7 @@ static void intel_ddi_get_encoder_pipes(struct intel_encoder *encoder,
787787
intel_wakeref_t wakeref;
788788
enum pipe p;
789789
u32 tmp;
790-
u8 mst_pipe_mask;
790+
u8 mst_pipe_mask = 0, dp128b132b_pipe_mask = 0;
791791

792792
*pipe_mask = 0;
793793
*is_dp_mst = false;
@@ -824,7 +824,6 @@ static void intel_ddi_get_encoder_pipes(struct intel_encoder *encoder,
824824
goto out;
825825
}
826826

827-
mst_pipe_mask = 0;
828827
for_each_pipe(dev_priv, p) {
829828
enum transcoder cpu_transcoder = (enum transcoder)p;
830829
u32 port_mask, ddi_select, ddi_mode;
@@ -853,9 +852,10 @@ static void intel_ddi_get_encoder_pipes(struct intel_encoder *encoder,
853852

854853
ddi_mode = tmp & TRANS_DDI_MODE_SELECT_MASK;
855854

856-
if (ddi_mode == TRANS_DDI_MODE_SELECT_DP_MST ||
857-
(ddi_mode == TRANS_DDI_MODE_SELECT_FDI_OR_128B132B && HAS_DP20(display)))
855+
if (ddi_mode == TRANS_DDI_MODE_SELECT_DP_MST)
858856
mst_pipe_mask |= BIT(p);
857+
else if (ddi_mode == TRANS_DDI_MODE_SELECT_FDI_OR_128B132B && HAS_DP20(display))
858+
dp128b132b_pipe_mask |= BIT(p);
859859

860860
*pipe_mask |= BIT(p);
861861
}
@@ -865,6 +865,23 @@ static void intel_ddi_get_encoder_pipes(struct intel_encoder *encoder,
865865
"No pipe for [ENCODER:%d:%s] found\n",
866866
encoder->base.base.id, encoder->base.name);
867867

868+
if (!mst_pipe_mask && dp128b132b_pipe_mask) {
869+
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
870+
871+
/*
872+
* If we don't have 8b/10b MST, but have more than one
873+
* transcoder in 128b/132b mode, we know it must be 128b/132b
874+
* MST.
875+
*
876+
* Otherwise, we fall back to checking the current MST
877+
* state. It's not accurate for hardware takeover at probe, but
878+
* we don't expect MST to have been enabled at that point, and
879+
* can assume it's SST.
880+
*/
881+
if (hweight8(dp128b132b_pipe_mask) > 1 || intel_dp->is_mst)
882+
mst_pipe_mask = dp128b132b_pipe_mask;
883+
}
884+
868885
if (!mst_pipe_mask && hweight8(*pipe_mask) > 1) {
869886
drm_dbg_kms(&dev_priv->drm,
870887
"Multiple pipes for [ENCODER:%d:%s] (pipe_mask %02x)\n",
@@ -875,9 +892,9 @@ static void intel_ddi_get_encoder_pipes(struct intel_encoder *encoder,
875892

876893
if (mst_pipe_mask && mst_pipe_mask != *pipe_mask)
877894
drm_dbg_kms(&dev_priv->drm,
878-
"Conflicting MST and non-MST state for [ENCODER:%d:%s] (pipe_mask %02x mst_pipe_mask %02x)\n",
895+
"Conflicting MST and non-MST state for [ENCODER:%d:%s] (pipe masks: all %02x, MST %02x, 128b/132b %02x)\n",
879896
encoder->base.base.id, encoder->base.name,
880-
*pipe_mask, mst_pipe_mask);
897+
*pipe_mask, mst_pipe_mask, dp128b132b_pipe_mask);
881898
else
882899
*is_dp_mst = mst_pipe_mask;
883900

0 commit comments

Comments
 (0)