drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 50 ++++++++++++++++-------- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 6 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 29 +++++--------- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 +- 6 files changed, 48 insertions(+), 43 deletions(-)
To support high-resolution cases that exceed the width constrain
or scenarios that surpass the maximum MDP clock rate, additional
pipes are necessary to enable parallel data processing within
the width constraints and MDP clock rate.
Expand pipe array size to 4. Request 4 mixers and 4 DSCs for
high-resolution cases where dual interfaces are enabled for virtual
plane case. More use cases can be incorporated later if quad-pipe
capabilities are required.
Signed-off-by: Jun Nie <jun.nie@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/675418/
Link: https://lore.kernel.org/r/20250918-v6-16-rc2-quad-pipe-upstream-4-v16-10-ff6232e3472f@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
2 or more SSPPs and dual-DSI interface are need for super wide panel.
And 4 DSC are preferred for power optimal in this case due to width
limitation of SSPP and MDP clock rate constrain. This patch set
extends number of pipes to 4 and revise related mixer blending logic
to support quad pipe. All these changes depends on the virtual plane
feature to split a super wide drm plane horizontally into 2 or more sub
clip. Thus DMA of multiple SSPPs can share the effort of fetching the
whole drm plane.
The first pipe pair co-work with the first mixer pair to cover the left
half of screen and 2nd pair of pipes and mixers are for the right half
of screen. If a plane is only for the right half of screen, only one
or two of pipes in the 2nd pipe pair are valid, and no SSPP or mixer is
assinged for invalid pipe.
For those panel that does not require quad-pipe, only 1 or 2 pipes in
the 1st pipe pair will be used. There is no concept of right half of
screen.
For legacy non virtual plane mode, the first 1 or 2 pipes are used for
the single SSPP and its multi-rect mode.
This patch set drop the merged heading 8 patches of v16, only the last
2 are revised and split into 4 patches here.
Changes in v20:
- Rebase to latest msm-next to add single DSC case into topology revison.
- Link to v19: https://lore.kernel.org/r/20260312-msm-next-quad-pipe-split-v19-0-4ffa2b06c996@linaro.org
Changes in v19:
- Refine the plane resource assignment to avoid unnecessary argument
and operation for non-virtual plane case.
- Fix wording in comments.
- Link to v18: https://lore.kernel.org/r/20260213-msm-next-quad-pipe-split-v18-0-5815158d3635@linaro.org
Changes in v18:
- Revise the deferring of SSPP handling and comments to distinguish
assignment of non-virtual plane case and allocation of virtual plane case.
- Always assume 1 stage in non-virtual plane case when splitting and
mapping plane to pipes.
- Revise topology decision making and comments to fix possible
regression.
- Link to v17: https://lore.kernel.org/r/20260121-msm-next-quad-pipe-split-v17-0-6eb6d8675ca2@linaro.org
Changes in v17:
- Fix iommu warning on Hamoa.
- Extract plane splitting into a dedicated function.
- Defer plan splitting and SSPP allocation until CRTC check
so that topology information is available.
- Add virtual plane condition to quad-pipe topology so that
legacy devices are not impacted.
- Drop the merged 8 patches of v16, only the last 2 is revised
and sent here.
- Link to v16: https://lore.kernel.org/linux-arm-msm/20250918-v6-16-rc2-quad-pipe-upstream-4-v16-0-ff6232e3472f@linaro.org
Changes in v16:
- Rebase to latest branch msm-next-lumag.
- Fix IGT test failures.
- Drop patches that have been merged.
- Link to v15: https://lore.kernel.org/r/20250819-v6-16-rc2-quad-pipe-upstream-v15-0-2c7a85089db8@linaro.org
Changes in v15:
- Polish logic in sspp check and assignment.
- Link to v14: https://lore.kernel.org/r/20250801-v6-16-rc2-quad-pipe-upstream-v14-0-b626236f4c31@linaro.org
Changes in v14:
- Add patch to fix null pointer bug SSPP sharing, which is missed in
the last version.
- Polish single pipe check with removing loop.
- Polish logic of SSPP sharing test in dpu_plane_virtual_assign_resources()
- Polish argument of dpu_plane_virtual_assign_resources().
- Link to v13: https://lore.kernel.org/r/20250728-v6-16-rc2-quad-pipe-upstream-v13-0-954e4917fe4f@linaro.org
Changes in v13:
- Modify the SSPP assignment patch for sharing SSPP among planes in
quad-pipe case.
- Link to v12: https://lore.kernel.org/r/20250707-v6-16-rc2-quad-pipe-upstream-v12-0-67e3721e7d83@linaro.org
Changes in v12:
- Polish single pipe case detection in a plane. Add stage index check when
sharing SSPP with multi-rect mode in 2 planes.
- Abstract SSPP assignment in a stage into a function.
- Rebase to latest msm/msm-next.
- Link to v11: https://lore.kernel.org/r/20250603-v6-15-quad-pipe-upstream-v11-0-c3af7190613d@linaro.org
Changes in v11:
- Change function name from dpu_plane_check_single_pipe to
dpu_plane_get_single_pipe.
- Abstract SSPP assignment in stage into a function.
- Link to v10: https://lore.kernel.org/r/20250526-v6-15-quad-pipe-upstream-v10-0-5fed4f8897c4@linaro.org
Changes in v10:
- Drop changes in drm helper side, because num_lm == 0 does not lead to
any issue in the first call to dpu_plane_atomic_check_nosspp() with
latest repo. It is initialized properly right after the call in
drm_atomic_helper_check_planes(), thus the later plane splitting works
as expected.
- Rebase to latest msm-next branch.
- Fix PIPES_PER_STAGE to PIPES_PER_PLANE where handling all pipes, instead
of stages.
- Link to v9: https://lore.kernel.org/r/20250506-quad-pipe-upstream-v9-0-f7b273a8cc80@linaro.org
Changes in v9:
- Rebase to latest mainline and drop 3 patches as mainline already cover
the logic.
"Do not fix number of DSC"
"configure DSC per number in use"
"switch RM to use crtc_id rather than enc_id for allocation"
- Add a patch to check crtc before checking plane in drm framework.
- Add a patch to use dedicated WB number in an encoder to avoid regression.
- Revise the condition to decide quad-pipe topology.
- Link to v8: https://lore.kernel.org/r/20250303-sm8650-v6-14-hmd-deckard-mdss-quad-upstream-oldbootwrapper-36-prep-v8-0-eb5df105c807@linaro.org
Changes in v8:
- Fix looping pipes of a plane in _dpu_plane_color_fill()
- Improve pipe assignment with deleting pipes loop in stage.
- Define PIPES_PER_PLANE properly when it appears fisrt.
- rename lms_in_pair to lms_in_stage to avoid confusion.
- Add review tags.
- Link to v7: https://lore.kernel.org/r/20250226-sm8650-v6-14-hmd-deckard-mdss-quad-upstream-oldbootwrapper-36-prep-v7-0-8d5f5f426eb2@linaro.org
Changes in v7:
- Improve pipe assignment to avoid point to invalid memory.
- Define STAGES_PER_PLANE as 2 only when quad-pipe is introduced.
- Polish LM number when blending pipes with min() and pull up to caller func.
- Add review tags.
- Link to v6: https://lore.kernel.org/r/20250217-sm8650-v6-14-hmd-deckard-mdss-quad-upstream-oldbootwrapper-36-prep-v6-0-c11402574367@linaro.org
Changes in v6:
- Replace LM number with PP number to calculate PP number per encoder.
- Rebase to Linux v6.14-rc2.
- Add review tags.
- Link to v5: https://lore.kernel.org/r/20250118-sm8650-v6-13-hmd-deckard-mdss-quad-upstream-33-v5-0-9701a16340da@linaro.org
Changes in v5:
- Iterate SSPP flushing within the required mixer pair, instead of all
active mixers or specific mixer.
- Limit qaud-pipe usage case to SoC with 4 or more DSC engines and 2
interfaces case.
- Remove valid flag and use width for pipe validation.
- Polish commit messages and code comments.
- Link to v4: https://lore.kernel.org/r/20250116-sm8650-v6-13-hmd-deckard-mdss-quad-upstream-33-v4-0-74749c6eba33@linaro.org
Changes in v4:
- Restrict SSPP flushing to the required mixer, instead of all active mixers.
- Polish commit messages and code comments.
- Rebase to latest msm/drm-next branch.
- Move pipe checking patch to the top of patch set.
- Link to v3: https://lore.kernel.org/dri-devel/20241219-sm8650-v6-13-hmd-deckard-mdss-quad-upstream-32-v3-0-92c7c0a228e3@linaro.org
Changes in v3:
- Split change in trace into a separate patch.
- Rebase to latest msm-next branch.
- Reorder patch sequence to make sure valid flag is set in earlier patch
- Rectify rewrite patch to move logic change into other patch
- Polish commit messages and code comments.
- Link to v2: https://lore.kernel.org/dri-devel/20241009-sm8650-v6-11-hmd-pocf-mdss-quad-upstream-21-v2-0-76d4f5d413bf@linaro.org
Changes in v2:
- Revise the patch sequence with changing to 2 pipes topology first. Then
prepare for quad-pipe setup, then enable quad-pipe at last.
- Split DSI patches into other patch set.
- Link to v1: https://lore.kernel.org/all/20240829-sm8650-v6-11-hmd-pocf-mdss-quad-upstream-8-v1-0-bdb05b4b5a2e@linaro.org
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 50 ++++++++++++++++--------
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 6 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 29 +++++---------
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 +-
6 files changed, 48 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index bd0e720b484fd..8ef44163cd18e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -200,7 +200,7 @@ static int dpu_crtc_get_lm_crc(struct drm_crtc *crtc,
struct dpu_crtc_state *crtc_state)
{
struct dpu_crtc_mixer *m;
- u32 crcs[CRTC_DUAL_MIXERS];
+ u32 crcs[CRTC_QUAD_MIXERS];
int rc = 0;
int i;
@@ -1384,6 +1384,9 @@ static struct msm_display_topology dpu_crtc_get_topology(
struct drm_display_mode *mode = &crtc_state->adjusted_mode;
struct msm_display_topology topology = {0};
struct drm_encoder *drm_enc;
+ struct msm_drm_private *priv = crtc->dev->dev_private;
+ struct dpu_kms *kms = to_dpu_kms(priv->kms);
+ u32 num_rt_intf;
drm_for_each_encoder_mask(drm_enc, crtc->dev, crtc_state->encoder_mask)
dpu_encoder_update_topology(drm_enc, &topology, crtc_state->state,
@@ -1396,32 +1399,45 @@ static struct msm_display_topology dpu_crtc_get_topology(
*
* Dual display
* 2 LM, 2 INTF ( Split display using 2 interfaces)
+ * 4 LM, 2 INTF ( Split display using 2 interfaces and stream merge
+ to support high resolution interfaces if virtual
+ plane is enabled)
+ * If DSC is enabled, use 2:2:2 for 2 LMs case, and 4:4:2 for 4 LMs
+ * case.
*
* Single display
* 1 LM, 1 INTF
* 2 LM, 1 INTF (stream merge to support high resolution interfaces)
*
- * If DSC is enabled, use 2 LMs for 2:2:1 topology
+ * If DSC is enabled, use 2 LMs for 2:2:1 topology for single display
+ * to support legacy devices that use this topology. Use 1:1:1 topology
+ * if there is only one DSC engine in SoC.
*
* Add dspps to the reservation requirements if ctm or gamma_lut are requested
- *
- * Only hardcode num_lm to 2 for cases where num_intf == 2 and CWB is not
- * enabled. This is because in cases where CWB is enabled, num_intf will
- * count both the WB and real-time phys encoders.
- *
- * For non-DSC CWB usecases, have the num_lm be decided by the
- * (mode->hdisplay > MAX_HDISPLAY_SPLIT) check.
*/
- if (topology.num_intf == 2 && !topology.cwb_enabled)
- topology.num_lm = 2;
- else if (topology.num_dsc == 2)
- topology.num_lm = 2;
- else if (dpu_kms->catalog->caps->has_3d_merge &&
- topology.num_dsc == 0)
- topology.num_lm = (mode->hdisplay > MAX_HDISPLAY_SPLIT) ? 2 : 1;
+ num_rt_intf = topology.num_intf;
+ if (topology.cwb_enabled)
+ num_rt_intf--;
+
+ if ((mode->hdisplay > (MAX_HDISPLAY_SPLIT * num_rt_intf)) ||
+ ((u64)mode->hdisplay * mode->vtotal * drm_mode_vrefresh(mode) >
+ kms->perf.max_core_clk_rate))
+ topology.num_lm = num_rt_intf * 2;
else
- topology.num_lm = 1;
+ topology.num_lm = num_rt_intf;
+
+ if (!dpu_use_virtual_planes)
+ topology.num_lm = min(2, topology.num_lm);
+
+ if (!dpu_kms->catalog->caps->has_3d_merge)
+ topology.num_lm = min(num_rt_intf, topology.num_lm);
+
+ if (topology.num_dsc) {
+ if (num_rt_intf == 1)
+ topology.num_lm = min(2, dpu_kms->catalog->dsc_count);
+ topology.num_dsc = topology.num_lm;
+ }
if (crtc_state->ctm || crtc_state->gamma_lut)
topology.num_dspp = topology.num_lm;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index 6eaba5696e8e6..455073c7025b0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -210,7 +210,7 @@ struct dpu_crtc_state {
bool bw_control;
bool bw_split_vote;
- struct drm_rect lm_bounds[CRTC_DUAL_MIXERS];
+ struct drm_rect lm_bounds[CRTC_QUAD_MIXERS];
uint64_t input_fence_timeout_ns;
@@ -218,10 +218,10 @@ struct dpu_crtc_state {
/* HW Resources reserved for the crtc */
u32 num_mixers;
- struct dpu_crtc_mixer mixers[CRTC_DUAL_MIXERS];
+ struct dpu_crtc_mixer mixers[CRTC_QUAD_MIXERS];
u32 num_ctls;
- struct dpu_hw_ctl *hw_ctls[CRTC_DUAL_MIXERS];
+ struct dpu_hw_ctl *hw_ctls[CRTC_QUAD_MIXERS];
enum dpu_crtc_crc_source crc_source;
int crc_frame_skip_count;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index eba1d52211f68..058a7c8727f7c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -55,7 +55,7 @@
#define MAX_PHYS_ENCODERS_PER_VIRTUAL \
(MAX_H_TILES_PER_DISPLAY * NUM_PHYS_ENCODER_TYPES)
-#define MAX_CHANNELS_PER_ENC 2
+#define MAX_CHANNELS_PER_ENC 4
#define MAX_CWB_PER_ENC 2
#define IDLE_SHORT_TIMEOUT 1
@@ -661,7 +661,6 @@ void dpu_encoder_update_topology(struct drm_encoder *drm_enc,
struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(drm_enc);
struct msm_drm_private *priv = dpu_enc->base.dev->dev_private;
struct msm_display_info *disp_info = &dpu_enc->disp_info;
- struct dpu_kms *dpu_kms = to_dpu_kms(priv->kms);
struct drm_connector *connector;
struct drm_connector_state *conn_state;
struct drm_framebuffer *fb;
@@ -675,22 +674,12 @@ void dpu_encoder_update_topology(struct drm_encoder *drm_enc,
dsc = dpu_encoder_get_dsc_config(drm_enc);
- /* We only support 2 DSC mode (with 2 LM and 1 INTF) */
- if (dsc) {
- /*
- * Use 2 DSC encoders, 2 layer mixers and 1 or 2 interfaces
- * when Display Stream Compression (DSC) is enabled,
- * and when enough DSC blocks are available.
- * This is power-optimal and can drive up to (including) 4k
- * screens.
- */
- WARN(topology->num_intf > 2,
- "DSC topology cannot support more than 2 interfaces\n");
- if (topology->num_intf >= 2 || dpu_kms->catalog->dsc_count >= 2)
- topology->num_dsc = 2;
- else
- topology->num_dsc = 1;
- }
+ /*
+ * Set DSC number as 1 to mark the enabled status, will be adjusted
+ * in dpu_crtc_get_topology()
+ */
+ if (dsc)
+ topology->num_dsc = 1;
connector = drm_atomic_get_new_connector_for_encoder(state, drm_enc);
if (!connector)
@@ -2180,8 +2169,8 @@ static void dpu_encoder_helper_reset_mixers(struct dpu_encoder_phys *phys_enc)
{
int i, num_lm;
struct dpu_global_state *global_state;
- struct dpu_hw_blk *hw_lm[2];
- struct dpu_hw_mixer *hw_mixer[2];
+ struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_ENC];
+ struct dpu_hw_mixer *hw_mixer[MAX_CHANNELS_PER_ENC];
struct dpu_hw_ctl *ctl = phys_enc->hw_ctl;
/* reset all mixers for this encoder */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index 61b22d9494546..09395d7910ac8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -302,7 +302,7 @@ static inline enum dpu_3d_blend_mode dpu_encoder_helper_get_3d_blend_mode(
/* Use merge_3d unless DSC MERGE topology is used */
if (phys_enc->split_role == ENC_ROLE_SOLO &&
- dpu_cstate->num_mixers == CRTC_DUAL_MIXERS &&
+ (dpu_cstate->num_mixers != 1) &&
!dpu_encoder_use_dsc_merge(phys_enc->parent))
return BLEND_3D_H_ROW_INT;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index ba04ac24d5a9e..b1ac84c0b52db 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -24,7 +24,7 @@
#define DPU_MAX_IMG_WIDTH 0x3fff
#define DPU_MAX_IMG_HEIGHT 0x3fff
-#define CRTC_DUAL_MIXERS 2
+#define CRTC_QUAD_MIXERS 4
#define MAX_XIN_COUNT 16
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
index 0e65bf5ddc4a6..fd1f3e7982062 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
@@ -34,7 +34,7 @@
#define DPU_MAX_PLANES 4
#endif
-#define STAGES_PER_PLANE 1
+#define STAGES_PER_PLANE 2
#define PIPES_PER_STAGE 2
#define PIPES_PER_PLANE (PIPES_PER_STAGE * STAGES_PER_PLANE)
#ifndef DPU_MAX_DE_CURVES
---
base-commit: a913d08e5ea9a491b806e64a24410f6722ddc9b3
change-id: 20260121-msm-next-quad-pipe-split-ab95b6e3ffd3
Best regards,
--
Jun Nie <jun.nie@linaro.org>On Wed, 15 Apr 2026 11:15:11 +0800, Jun Nie wrote:
> To support high-resolution cases that exceed the width constrain
> or scenarios that surpass the maximum MDP clock rate, additional
> pipes are necessary to enable parallel data processing within
> the width constraints and MDP clock rate.
>
> Expand pipe array size to 4. Request 4 mixers and 4 DSCs for
> high-resolution cases where dual interfaces are enabled for virtual
> plane case. More use cases can be incorporated later if quad-pipe
> capabilities are required.
>
> [...]
Applied to msm-next, thanks!
[1/1] drm/msm/dpu: Enable quad-pipe for DSC and dual-DSI case
https://gitlab.freedesktop.org/lumag/msm/-/commit/218eb06a72bf
Best regards,
--
With best wishes
Dmitry
On Wed, May 20, 2026 at 04:41:29PM +0300, Dmitry Baryshkov wrote:
> On Wed, 15 Apr 2026 11:15:11 +0800, Jun Nie wrote:
> > To support high-resolution cases that exceed the width constrain
> > or scenarios that surpass the maximum MDP clock rate, additional
> > pipes are necessary to enable parallel data processing within
> > the width constraints and MDP clock rate.
> >
> > Expand pipe array size to 4. Request 4 mixers and 4 DSCs for
> > high-resolution cases where dual interfaces are enabled for virtual
> > plane case. More use cases can be incorporated later if quad-pipe
> > capabilities are required.
> >
> > [...]
>
> Applied to msm-next, thanks!
>
> [1/1] drm/msm/dpu: Enable quad-pipe for DSC and dual-DSI case
> https://gitlab.freedesktop.org/lumag/msm/-/commit/218eb06a72bf
And I'm going to drop it again.
I tested on the SDM845, it tried enabling QUAD_PIPE for the follwing
mode, which then broke the display.
mode: "3840x2160": 30 297000 3840 4016 4104 4400 2160 2168 2178 2250 0x40 0x5
--
With best wishes
Dmitry
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年5月21日周四 01:41写道： > > On Wed, May 20, 2026 at 04:41:29PM +0300, Dmitry Baryshkov wrote: > > On Wed, 15 Apr 2026 11:15:11 +0800, Jun Nie wrote: > > > To support high-resolution cases that exceed the width constrain > > > or scenarios that surpass the maximum MDP clock rate, additional > > > pipes are necessary to enable parallel data processing within > > > the width constraints and MDP clock rate. > > > > > > Expand pipe array size to 4. Request 4 mixers and 4 DSCs for > > > high-resolution cases where dual interfaces are enabled for virtual > > > plane case. More use cases can be incorporated later if quad-pipe > > > capabilities are required. > > > > > > [...] > > > > Applied to msm-next, thanks! > > > > [1/1] drm/msm/dpu: Enable quad-pipe for DSC and dual-DSI case > > https://gitlab.freedesktop.org/lumag/msm/-/commit/218eb06a72bf > > And I'm going to drop it again. > > I tested on the SDM845, it tried enabling QUAD_PIPE for the follwing > mode, which then broke the display. > > mode: "3840x2160": 30 297000 3840 4016 4104 4400 2160 2168 2178 2250 0x40 0x5 > What's the platform? To enable QUAD_PIPE, both virtual plane feature and 2 real time RT interfaces are needed besides width exceeding the constrain. If all conditions in the dpu_crtc_get_topology() are met, why QUAD_PIPE cannot be enabled on this platform, any other condition shall be added? Regards, Jun
On Thu, May 21, 2026 at 05:15:18PM +0800, Jun Nie wrote: > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年5月21日周四 01:41写道： > > > > On Wed, May 20, 2026 at 04:41:29PM +0300, Dmitry Baryshkov wrote: > > > On Wed, 15 Apr 2026 11:15:11 +0800, Jun Nie wrote: > > > > To support high-resolution cases that exceed the width constrain > > > > or scenarios that surpass the maximum MDP clock rate, additional > > > > pipes are necessary to enable parallel data processing within > > > > the width constraints and MDP clock rate. > > > > > > > > Expand pipe array size to 4. Request 4 mixers and 4 DSCs for > > > > high-resolution cases where dual interfaces are enabled for virtual > > > > plane case. More use cases can be incorporated later if quad-pipe > > > > capabilities are required. > > > > > > > > [...] > > > > > > Applied to msm-next, thanks! > > > > > > [1/1] drm/msm/dpu: Enable quad-pipe for DSC and dual-DSI case > > > https://gitlab.freedesktop.org/lumag/msm/-/commit/218eb06a72bf > > > > And I'm going to drop it again. > > > > I tested on the SDM845, it tried enabling QUAD_PIPE for the follwing > > mode, which then broke the display. > > > > mode: "3840x2160": 30 297000 3840 4016 4104 4400 2160 2168 2178 2250 0x40 0x5 > > > What's the platform? To enable QUAD_PIPE, both virtual plane feature and 2 > real time RT interfaces are needed besides width exceeding the constrain. > If all conditions in the dpu_crtc_get_topology() are met, why QUAD_PIPE > cannot be enabled on this platform, any other condition shall be added? The platform is SDM845 HDK, it should also be reproducible on the RB3 platform, which uses the same chip. I assume the difference is related to the active vs non-active CTL (which means that QUAD PIPE needs to be disabled for all platforms before 5.x). I've asked my colleagues to test quad pipe on other platforms, I'll report on it later. But it also surprised me that the code selects 4 LMs for the 4k@30 mode. It should be prefectly working with just 2LMs and 2 rectangles. > > Regards, > Jun -- With best wishes Dmitry
© 2016 - 2026 Red Hat, Inc.