To support high-resolution cases that exceed the width limitation of
a pair of SSPPs, or scenarios that surpass the maximum MDP clock rate,
additional pipes are necessary to enable parallel data processing
within the SSPP width constraints and MDP clock rate.
Request 4 mixers and 4 DSCs for high-resolution cases where both DSC
and dual interfaces are enabled. 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>
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 27 +++++++++++++++++------
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 6 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 28 ++++++++----------------
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, 35 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index e925d93b38feac0594d735fdc2c5b9fd5ae83e6a..7a88a26d04b46c7df86eebec27c7cda28725f6ea 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;
@@ -1328,6 +1328,7 @@ 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;
+ 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,
@@ -1341,11 +1342,14 @@ static struct msm_display_topology dpu_crtc_get_topology(
* Dual display
* 2 LM, 2 INTF ( Split display using 2 interfaces)
*
+ * If DSC is enabled, try to use 4:4:2 topology if there is enough
+ * resource. Otherwise, use 2:2:2 topology.
+ *
* 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:2:1 topology
*
* Add dspps to the reservation requirements if ctm is requested
*
@@ -1357,14 +1361,23 @@ static struct msm_display_topology dpu_crtc_get_topology(
* (mode->hdisplay > MAX_HDISPLAY_SPLIT) check.
*/
- if (topology.num_intf == 2 && !topology.cwb_enabled)
- topology.num_lm = 2;
- else if (topology.num_dsc == 2)
+ num_rt_intf = topology.num_intf;
+ if (topology.cwb_enabled)
+ num_rt_intf--;
+
+ if (topology.num_dsc) {
+ if (dpu_kms->catalog->dsc_count >= num_rt_intf * 2)
+ topology.num_dsc = num_rt_intf * 2;
+ else
+ topology.num_dsc = num_rt_intf;
+ topology.num_lm = topology.num_dsc;
+ } else if (num_rt_intf == 2) {
topology.num_lm = 2;
- else if (dpu_kms->catalog->caps->has_3d_merge)
+ } else if (dpu_kms->catalog->caps->has_3d_merge) {
topology.num_lm = (mode->hdisplay > MAX_HDISPLAY_SPLIT) ? 2 : 1;
- else
+ } else {
topology.num_lm = 1;
+ }
if (crtc_state->ctm)
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 6eaba5696e8e6bd1246a9895c4c8714ca6589b10..455073c7025b0bcb970d8817f197d9bcacc6dca5 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 55b83ba6102d38a9ec97bc4d12ad31810e4b261a..3dd202e0ce94eaecfc7e401e1c9e1fe43106dc9e 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
@@ -675,22 +675,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)
@@ -2181,8 +2171,8 @@ static void dpu_encoder_helper_reset_mixers(struct dpu_encoder_phys *phys_enc)
struct dpu_hw_mixer_cfg mixer;
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;
memset(&mixer, 0, sizeof(mixer));
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 61b22d9494546885db609efa156222792af73d2a..09395d7910ac87c035b65cf476350bf6c9619612 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 f0768f54e9b3d5a3f5a7bec4b66127f2e2284cfd..21c980f8e2e3e8469055ff6bfbba1afdbb88bfbc 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 e4875a1f638db6f1983d9c51cb399319d27675e9..5cedcda285273a46cd6e11da63cde92cab94b9f4 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
--
2.34.1On 2025-09-18 21:29:02, Jun Nie wrote: > To support high-resolution cases that exceed the width limitation of > a pair of SSPPs, or scenarios that surpass the maximum MDP clock rate, > additional pipes are necessary to enable parallel data processing > within the SSPP width constraints and MDP clock rate. > > Request 4 mixers and 4 DSCs for high-resolution cases where both DSC > and dual interfaces are enabled. 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> > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 27 +++++++++++++++++------ > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 6 ++--- > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 28 ++++++++---------------- > 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, 35 insertions(+), 32 deletions(-) With this patch applied, I get the following crash on the Sony Xperia 1 III, a dual-DSI dual-DSC device: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000012d4e1000 [0000000000000020] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: msm drm_client_lib ubwc_config drm_dp_aux_bus gpu_sched drm_gpuvm drm_exec CPU: 5 UID: 0 PID: 3081 Comm: (sd-close) Tainted: G U 6.18.0-rc7-next-20251127-SoMainline-12422-g10b6db5b056d-dirty #21 NONE Tainted: [U]=USER Hardware name: Sony Xperia 1 III (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : dpu_plane_atomic_check_sspp.isra.0+0x88/0x3f4 [msm] lr : dpu_plane_atomic_check_sspp.isra.0+0x84/0x3f4 [msm] sp : ffff800081e23940 x29: ffff800081e23950 x28: ffff0000bf2700d0 x27: 0000000000000a00 x26: ffff0000bf270000 x25: 0000000000000a00 x24: ffff0000bd0e5c18 x23: ffff000087a6c080 x22: 0000000000000224 x21: ffff00008ce88080 x20: 0000000000000002 x19: ffff0000bf270138 x18: ffff8000818350b0 x17: 000000040044ffff x16: ffffc488ae2e37e0 x15: 0000000000000005 x14: 0000000000000a00 x13: 0000000000000000 x12: 0000000000000138 x11: 0000000000000000 x10: 0000000000000012 x9 : 0000000000000000 x8 : 0000000000000a00 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000002 x4 : 0000000000000000 x3 : ffffc48897741db0 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: dpu_plane_atomic_check_sspp.isra.0+0x88/0x3f4 [msm] (P) dpu_plane_atomic_check+0x100/0x1a0 [msm] drm_atomic_helper_check_planes+0xd8/0x224 drm_atomic_helper_check+0x50/0xb4 msm_atomic_check+0xd0/0xe0 [msm] drm_atomic_check_only+0x4e0/0x928 drm_atomic_commit+0x50/0xd4 drm_client_modeset_commit_atomic+0x200/0x260 drm_client_modeset_commit_locked+0x64/0x180 drm_client_modeset_commit+0x30/0x60 drm_fb_helper_lastclose+0x60/0xb0 drm_fbdev_client_restore+0x18/0x38 [drm_client_lib] drm_client_dev_restore+0xac/0xf8 drm_release+0x124/0x158 __fput+0xd4/0x2e4 fput_close_sync+0x3c/0xe0 __arm64_sys_close+0x3c/0x84 invoke_syscall.constprop.0+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe4 do_el0_svc+0x20/0x3c el0_svc+0x38/0x110 el0t_64_sync_handler+0xa8/0xec el0t_64_sync+0x1a0/0x1a4 Code: 2a1403e5 52800082 94008e28 f9400380 (f940101b) ---[ end trace 0000000000000000 ]--- pstore: backend (ramoops) writing error (-28) [drm:dpu_encoder_frame_done_timeout:2726] [dpu error]enc33 frame done timeout I don't see any thought given to it in the extremely terse patch description, but this patch seems to unconditionally select 4 DSCs and 4 LMs on this device because the underlying SM8350 SoC has 4 available in its catalog - while it was previously affixed to 2:2:2 matching the downstream and known-working configuration of this device - and I can only imagine things are rolling downhill from there. faddr2line seems to be failing for me, but this is the line `dpu_plane_atomic_check_sspp.isra.0+0x88` seems to be referring to: aarch64-linux-gnu-objdump .output/drivers/gpu/drm/msm/msm.ko -dS | grep dpu_plane_atomic_check_sspp.isra.0\> -A80 00000000000671ac <dpu_plane_atomic_check_sspp.isra.0>: static int dpu_plane_atomic_check_sspp(struct drm_plane *plane, ... 67234: f940101b ldr x27, [x0, #32] if (!(sblk->scaler_blk.len && pipe->sspp->ops.setup_scaler) && Please help resolve this issue, as I am not understanding the thought process behind this patch and unsure how to solve this issue short of just reverting it. Looking forward to some assistance, thanks; - Marijn
On Sat, Nov 29, 2025 at 05:37:43PM +0100, Marijn Suijten wrote:
> On 2025-09-18 21:29:02, Jun Nie wrote:
> > To support high-resolution cases that exceed the width limitation of
> > a pair of SSPPs, or scenarios that surpass the maximum MDP clock rate,
> > additional pipes are necessary to enable parallel data processing
> > within the SSPP width constraints and MDP clock rate.
> >
> > Request 4 mixers and 4 DSCs for high-resolution cases where both DSC
> > and dual interfaces are enabled. 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>
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 27 +++++++++++++++++------
> > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 6 ++---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 28 ++++++++----------------
> > 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, 35 insertions(+), 32 deletions(-)
>
> With this patch applied, I get the following crash on the Sony Xperia 1 III, a
> dual-DSI dual-DSC device:
>
> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
> Mem abort info:
> ESR = 0x0000000096000004
> EC = 0x25: DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> FSC = 0x04: level 0 translation fault
> Data abort info:
> ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> user pgtable: 4k pages, 48-bit VAs, pgdp=000000012d4e1000
> [0000000000000020] pgd=0000000000000000, p4d=0000000000000000
> Internal error: Oops: 0000000096000004 [#1] SMP
> Modules linked in: msm drm_client_lib ubwc_config drm_dp_aux_bus gpu_sched drm_gpuvm drm_exec
> CPU: 5 UID: 0 PID: 3081 Comm: (sd-close) Tainted: G U 6.18.0-rc7-next-20251127-SoMainline-12422-g10b6db5b056d-dirty #21 NONE
> Tainted: [U]=USER
> Hardware name: Sony Xperia 1 III (DT)
> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : dpu_plane_atomic_check_sspp.isra.0+0x88/0x3f4 [msm]
> lr : dpu_plane_atomic_check_sspp.isra.0+0x84/0x3f4 [msm]
> sp : ffff800081e23940
> x29: ffff800081e23950 x28: ffff0000bf2700d0 x27: 0000000000000a00
> x26: ffff0000bf270000 x25: 0000000000000a00 x24: ffff0000bd0e5c18
> x23: ffff000087a6c080 x22: 0000000000000224 x21: ffff00008ce88080
> x20: 0000000000000002 x19: ffff0000bf270138 x18: ffff8000818350b0
> x17: 000000040044ffff x16: ffffc488ae2e37e0 x15: 0000000000000005
> x14: 0000000000000a00 x13: 0000000000000000 x12: 0000000000000138
> x11: 0000000000000000 x10: 0000000000000012 x9 : 0000000000000000
> x8 : 0000000000000a00 x7 : 0000000000000000 x6 : 0000000000000000
> x5 : 0000000000000002 x4 : 0000000000000000 x3 : ffffc48897741db0
> x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
> Call trace:
> dpu_plane_atomic_check_sspp.isra.0+0x88/0x3f4 [msm] (P)
> dpu_plane_atomic_check+0x100/0x1a0 [msm]
> drm_atomic_helper_check_planes+0xd8/0x224
> drm_atomic_helper_check+0x50/0xb4
> msm_atomic_check+0xd0/0xe0 [msm]
> drm_atomic_check_only+0x4e0/0x928
> drm_atomic_commit+0x50/0xd4
> drm_client_modeset_commit_atomic+0x200/0x260
> drm_client_modeset_commit_locked+0x64/0x180
> drm_client_modeset_commit+0x30/0x60
> drm_fb_helper_lastclose+0x60/0xb0
> drm_fbdev_client_restore+0x18/0x38 [drm_client_lib]
> drm_client_dev_restore+0xac/0xf8
> drm_release+0x124/0x158
> __fput+0xd4/0x2e4
> fput_close_sync+0x3c/0xe0
> __arm64_sys_close+0x3c/0x84
> invoke_syscall.constprop.0+0x44/0x100
> el0_svc_common.constprop.0+0x3c/0xe4
> do_el0_svc+0x20/0x3c
> el0_svc+0x38/0x110
> el0t_64_sync_handler+0xa8/0xec
> el0t_64_sync+0x1a0/0x1a4
> Code: 2a1403e5 52800082 94008e28 f9400380 (f940101b)
> ---[ end trace 0000000000000000 ]---
> pstore: backend (ramoops) writing error (-28)
> [drm:dpu_encoder_frame_done_timeout:2726] [dpu error]enc33 frame done timeout
>
> I don't see any thought given to it in the extremely terse patch description,
> but this patch seems to unconditionally select 4 DSCs and 4 LMs on this device
> because the underlying SM8350 SoC has 4 available in its catalog - while it
> was previously affixed to 2:2:2 matching the downstream and known-working
> configuration of this device - and I can only imagine things are rolling
> downhill from there.
>
> faddr2line seems to be failing for me, but this is the line
> `dpu_plane_atomic_check_sspp.isra.0+0x88` seems to be referring to:
>
> aarch64-linux-gnu-objdump .output/drivers/gpu/drm/msm/msm.ko -dS | grep dpu_plane_atomic_check_sspp.isra.0\> -A80
> 00000000000671ac <dpu_plane_atomic_check_sspp.isra.0>:
> static int dpu_plane_atomic_check_sspp(struct drm_plane *plane,
> ...
> 67234: f940101b ldr x27, [x0, #32]
> if (!(sblk->scaler_blk.len && pipe->sspp->ops.setup_scaler) &&
I think it is:
pipe_hw_caps = pipe->sspp->cap;
14bc: f9401018 ldr x24, [x0, #32]
So, please check why pipe->sspp becomes NULL (or where do we miss the
NULL check for pipe->sspp).
--
With best wishes
Dmitry
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2025年12月11日周四 03:30写道：
>
> On Sat, Nov 29, 2025 at 05:37:43PM +0100, Marijn Suijten wrote:
> > On 2025-09-18 21:29:02, Jun Nie wrote:
> > > To support high-resolution cases that exceed the width limitation of
> > > a pair of SSPPs, or scenarios that surpass the maximum MDP clock rate,
> > > additional pipes are necessary to enable parallel data processing
> > > within the SSPP width constraints and MDP clock rate.
> > >
> > > Request 4 mixers and 4 DSCs for high-resolution cases where both DSC
> > > and dual interfaces are enabled. 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>
> > > ---
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 27 +++++++++++++++++------
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 6 ++---
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 28 ++++++++----------------
> > > 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, 35 insertions(+), 32 deletions(-)
> >
> > With this patch applied, I get the following crash on the Sony Xperia 1 III, a
> > dual-DSI dual-DSC device:
> >
> > Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
> > Mem abort info:
> > ESR = 0x0000000096000004
> > EC = 0x25: DABT (current EL), IL = 32 bits
> > SET = 0, FnV = 0
> > EA = 0, S1PTW = 0
> > FSC = 0x04: level 0 translation fault
> > Data abort info:
> > ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> > CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> > GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> > user pgtable: 4k pages, 48-bit VAs, pgdp=000000012d4e1000
> > [0000000000000020] pgd=0000000000000000, p4d=0000000000000000
> > Internal error: Oops: 0000000096000004 [#1] SMP
> > Modules linked in: msm drm_client_lib ubwc_config drm_dp_aux_bus gpu_sched drm_gpuvm drm_exec
> > CPU: 5 UID: 0 PID: 3081 Comm: (sd-close) Tainted: G U 6.18.0-rc7-next-20251127-SoMainline-12422-g10b6db5b056d-dirty #21 NONE
> > Tainted: [U]=USER
> > Hardware name: Sony Xperia 1 III (DT)
> > pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > pc : dpu_plane_atomic_check_sspp.isra.0+0x88/0x3f4 [msm]
> > lr : dpu_plane_atomic_check_sspp.isra.0+0x84/0x3f4 [msm]
> > sp : ffff800081e23940
> > x29: ffff800081e23950 x28: ffff0000bf2700d0 x27: 0000000000000a00
> > x26: ffff0000bf270000 x25: 0000000000000a00 x24: ffff0000bd0e5c18
> > x23: ffff000087a6c080 x22: 0000000000000224 x21: ffff00008ce88080
> > x20: 0000000000000002 x19: ffff0000bf270138 x18: ffff8000818350b0
> > x17: 000000040044ffff x16: ffffc488ae2e37e0 x15: 0000000000000005
> > x14: 0000000000000a00 x13: 0000000000000000 x12: 0000000000000138
> > x11: 0000000000000000 x10: 0000000000000012 x9 : 0000000000000000
> > x8 : 0000000000000a00 x7 : 0000000000000000 x6 : 0000000000000000
> > x5 : 0000000000000002 x4 : 0000000000000000 x3 : ffffc48897741db0
> > x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
> > Call trace:
> > dpu_plane_atomic_check_sspp.isra.0+0x88/0x3f4 [msm] (P)
> > dpu_plane_atomic_check+0x100/0x1a0 [msm]
> > drm_atomic_helper_check_planes+0xd8/0x224
> > drm_atomic_helper_check+0x50/0xb4
> > msm_atomic_check+0xd0/0xe0 [msm]
> > drm_atomic_check_only+0x4e0/0x928
> > drm_atomic_commit+0x50/0xd4
> > drm_client_modeset_commit_atomic+0x200/0x260
> > drm_client_modeset_commit_locked+0x64/0x180
> > drm_client_modeset_commit+0x30/0x60
> > drm_fb_helper_lastclose+0x60/0xb0
> > drm_fbdev_client_restore+0x18/0x38 [drm_client_lib]
> > drm_client_dev_restore+0xac/0xf8
> > drm_release+0x124/0x158
> > __fput+0xd4/0x2e4
> > fput_close_sync+0x3c/0xe0
> > __arm64_sys_close+0x3c/0x84
> > invoke_syscall.constprop.0+0x44/0x100
> > el0_svc_common.constprop.0+0x3c/0xe4
> > do_el0_svc+0x20/0x3c
> > el0_svc+0x38/0x110
> > el0t_64_sync_handler+0xa8/0xec
> > el0t_64_sync+0x1a0/0x1a4
> > Code: 2a1403e5 52800082 94008e28 f9400380 (f940101b)
> > ---[ end trace 0000000000000000 ]---
> > pstore: backend (ramoops) writing error (-28)
> > [drm:dpu_encoder_frame_done_timeout:2726] [dpu error]enc33 frame done timeout
> >
> > I don't see any thought given to it in the extremely terse patch description,
> > but this patch seems to unconditionally select 4 DSCs and 4 LMs on this device
> > because the underlying SM8350 SoC has 4 available in its catalog - while it
> > was previously affixed to 2:2:2 matching the downstream and known-working
> > configuration of this device - and I can only imagine things are rolling
> > downhill from there.
> >
> > faddr2line seems to be failing for me, but this is the line
> > `dpu_plane_atomic_check_sspp.isra.0+0x88` seems to be referring to:
> >
> > aarch64-linux-gnu-objdump .output/drivers/gpu/drm/msm/msm.ko -dS | grep dpu_plane_atomic_check_sspp.isra.0\> -A80
> > 00000000000671ac <dpu_plane_atomic_check_sspp.isra.0>:
> > static int dpu_plane_atomic_check_sspp(struct drm_plane *plane,
> > ...
> > 67234: f940101b ldr x27, [x0, #32]
> > if (!(sblk->scaler_blk.len && pipe->sspp->ops.setup_scaler) &&
>
> I think it is:
>
> pipe_hw_caps = pipe->sspp->cap;
> 14bc: f9401018 ldr x24, [x0, #32]
>
>
> So, please check why pipe->sspp becomes NULL (or where do we miss the
> NULL check for pipe->sspp).
Yeah, per panic log and objdump, it should be due to this line. But no
clue is found
with code analysis.
Did you reproduce it? If so, what's the platform and git commit id? I
tested with
HDK8650 dual-DSI HDMI bridged monitor, but kernel does not panic.
resource mapping:
pingpong=104 104 # # # # - - # # # # -
mixer=104 104 # # # # - -
ctl=104 # # # # # - -
dspp=# # # # - - - -
dsc=# # # # # # - -
cdm=#
sspp=# # # # - - - - 104 # # # # # - -
cwb=# # # #
Hi Marijn,
Could you help collect debug info with this change? Thanks!
BTW: my irc id: niej
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index d07a6ab6e7ee1..fc61c2fbb0699 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -886,6 +886,7 @@ static int dpu_plane_atomic_check_nosspp(struct
drm_plane *plane,
new_plane_state->fb->width, new_plane_state->fb->height,
new_plane_state->rotation);
+ memset(&pstate->pipe_cfg[0], 0, PIPES_PER_PLANE *
sizeof(struct dpu_sw_pipe_cfg));
/*
* We have 1 mixer pair cfg for 1:1:1 and 2:2:1 topology, 2 mixer pair
* configs for left and right half screen in case of 4:4:2 topology.
@@ -1055,6 +1056,13 @@ static int dpu_plane_atomic_check_sspp(struct
drm_plane *plane,
if (!drm_rect_width(&pipe_cfg->src_rect))
continue;
DPU_DEBUG_PLANE(pdpu, "pipe %d is in use, validate it\n", i);
+ if(!pipe->sspp) {
+ WARN(1, "%svirtual plane pipe %d is null with
width %d height %d!!\n",
+ dpu_use_virtual_planes ? " " : "non-",
+ i,
+ drm_rect_width(&pipe_cfg->src_rect),
+ drm_rect_height(&pipe_cfg->src_rect));
+ }
ret = dpu_plane_atomic_check_pipe(pdpu, pipe, pipe_cfg,
&crtc_state->adjusted_mode,
new_plane_state);
>
>
> --
> With best wishes
> Dmitry
On 2025-12-11 23:53:00, Jun Nie wrote:
> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> ???2025???12???11????????? 03:30?????????
> >
> > On Sat, Nov 29, 2025 at 05:37:43PM +0100, Marijn Suijten wrote:
> > > On 2025-09-18 21:29:02, Jun Nie wrote:
> > > > To support high-resolution cases that exceed the width limitation of
> > > > a pair of SSPPs, or scenarios that surpass the maximum MDP clock rate,
> > > > additional pipes are necessary to enable parallel data processing
> > > > within the SSPP width constraints and MDP clock rate.
> > > >
> > > > Request 4 mixers and 4 DSCs for high-resolution cases where both DSC
> > > > and dual interfaces are enabled. 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>
> > > > ---
> > > > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 27 +++++++++++++++++------
> > > > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 6 ++---
> > > > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 28 ++++++++----------------
> > > > 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, 35 insertions(+), 32 deletions(-)
> > >
> > > With this patch applied, I get the following crash on the Sony Xperia 1 III, a
> > > dual-DSI dual-DSC device:
> > >
> > > Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
> > > Mem abort info:
> > > ESR = 0x0000000096000004
> > > EC = 0x25: DABT (current EL), IL = 32 bits
> > > SET = 0, FnV = 0
> > > EA = 0, S1PTW = 0
> > > FSC = 0x04: level 0 translation fault
> > > Data abort info:
> > > ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> > > CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> > > GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> > > user pgtable: 4k pages, 48-bit VAs, pgdp=000000012d4e1000
> > > [0000000000000020] pgd=0000000000000000, p4d=0000000000000000
> > > Internal error: Oops: 0000000096000004 [#1] SMP
> > > Modules linked in: msm drm_client_lib ubwc_config drm_dp_aux_bus gpu_sched drm_gpuvm drm_exec
> > > CPU: 5 UID: 0 PID: 3081 Comm: (sd-close) Tainted: G U 6.18.0-rc7-next-20251127-SoMainline-12422-g10b6db5b056d-dirty #21 NONE
> > > Tainted: [U]=USER
> > > Hardware name: Sony Xperia 1 III (DT)
> > > pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > pc : dpu_plane_atomic_check_sspp.isra.0+0x88/0x3f4 [msm]
> > > lr : dpu_plane_atomic_check_sspp.isra.0+0x84/0x3f4 [msm]
> > > sp : ffff800081e23940
> > > x29: ffff800081e23950 x28: ffff0000bf2700d0 x27: 0000000000000a00
> > > x26: ffff0000bf270000 x25: 0000000000000a00 x24: ffff0000bd0e5c18
> > > x23: ffff000087a6c080 x22: 0000000000000224 x21: ffff00008ce88080
> > > x20: 0000000000000002 x19: ffff0000bf270138 x18: ffff8000818350b0
> > > x17: 000000040044ffff x16: ffffc488ae2e37e0 x15: 0000000000000005
> > > x14: 0000000000000a00 x13: 0000000000000000 x12: 0000000000000138
> > > x11: 0000000000000000 x10: 0000000000000012 x9 : 0000000000000000
> > > x8 : 0000000000000a00 x7 : 0000000000000000 x6 : 0000000000000000
> > > x5 : 0000000000000002 x4 : 0000000000000000 x3 : ffffc48897741db0
> > > x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
> > > Call trace:
> > > dpu_plane_atomic_check_sspp.isra.0+0x88/0x3f4 [msm] (P)
> > > dpu_plane_atomic_check+0x100/0x1a0 [msm]
> > > drm_atomic_helper_check_planes+0xd8/0x224
> > > drm_atomic_helper_check+0x50/0xb4
> > > msm_atomic_check+0xd0/0xe0 [msm]
> > > drm_atomic_check_only+0x4e0/0x928
> > > drm_atomic_commit+0x50/0xd4
> > > drm_client_modeset_commit_atomic+0x200/0x260
> > > drm_client_modeset_commit_locked+0x64/0x180
> > > drm_client_modeset_commit+0x30/0x60
> > > drm_fb_helper_lastclose+0x60/0xb0
> > > drm_fbdev_client_restore+0x18/0x38 [drm_client_lib]
> > > drm_client_dev_restore+0xac/0xf8
> > > drm_release+0x124/0x158
> > > __fput+0xd4/0x2e4
> > > fput_close_sync+0x3c/0xe0
> > > __arm64_sys_close+0x3c/0x84
> > > invoke_syscall.constprop.0+0x44/0x100
> > > el0_svc_common.constprop.0+0x3c/0xe4
> > > do_el0_svc+0x20/0x3c
> > > el0_svc+0x38/0x110
> > > el0t_64_sync_handler+0xa8/0xec
> > > el0t_64_sync+0x1a0/0x1a4
> > > Code: 2a1403e5 52800082 94008e28 f9400380 (f940101b)
> > > ---[ end trace 0000000000000000 ]---
> > > pstore: backend (ramoops) writing error (-28)
> > > [drm:dpu_encoder_frame_done_timeout:2726] [dpu error]enc33 frame done timeout
> > >
> > > I don't see any thought given to it in the extremely terse patch description,
> > > but this patch seems to unconditionally select 4 DSCs and 4 LMs on this device
> > > because the underlying SM8350 SoC has 4 available in its catalog - while it
> > > was previously affixed to 2:2:2 matching the downstream and known-working
> > > configuration of this device - and I can only imagine things are rolling
> > > downhill from there.
> > >
> > > faddr2line seems to be failing for me, but this is the line
> > > `dpu_plane_atomic_check_sspp.isra.0+0x88` seems to be referring to:
> > >
> > > aarch64-linux-gnu-objdump .output/drivers/gpu/drm/msm/msm.ko -dS | grep dpu_plane_atomic_check_sspp.isra.0\> -A80
> > > 00000000000671ac <dpu_plane_atomic_check_sspp.isra.0>:
> > > static int dpu_plane_atomic_check_sspp(struct drm_plane *plane,
> > > ...
> > > 67234: f940101b ldr x27, [x0, #32]
> > > if (!(sblk->scaler_blk.len && pipe->sspp->ops.setup_scaler) &&
> >
> > I think it is:
> >
> > pipe_hw_caps = pipe->sspp->cap;
> > 14bc: f9401018 ldr x24, [x0, #32]
> >
> >
> > So, please check why pipe->sspp becomes NULL (or where do we miss the
> > NULL check for pipe->sspp).
>
> Yeah, per panic log and objdump, it should be due to this line. But no
> clue is found
> with code analysis.
> Did you reproduce it? If so, what's the platform and git commit id? I
> tested with
> HDK8650 dual-DSI HDMI bridged monitor, but kernel does not panic.
>
> resource mapping:
> pingpong=104 104 # # # # - - # # # # -
> mixer=104 104 # # # # - -
> ctl=104 # # # # # - -
> dspp=# # # # - - - -
> dsc=# # # # # # - -
This series, and specifically this patch I am replying to applies modifications
to DSC topology requests. your test setup however does not seem to be using any
DSC encoders at all and is hence not going into this strange block of code that
I am concerned about:
if (topology.num_dsc) {
if (dpu_kms->catalog->dsc_count >= num_rt_intf * 2)
topology.num_dsc = num_rt_intf * 2;
else
topology.num_dsc = num_rt_intf;
topology.num_lm = topology.num_dsc;
For DSC-enabled setups with 2:2:2 topology (the device I mentioned in the
main report) this is bumping the number of DSC encoders **and layer mixers**
to **four** if available in the catalog; it is not even checked against the
currently allocated resources in the case of "hotpluggable" panels.
Unrelated to this bug, but as a relevant context-comment on this series:
We discussed scenarios in the past where DSC-merge might be used (for example
in a 2:2:1 or 4:4:2 topology) for improved power consumption, but should modeset
back to lower DSC usage (1:1:1 or 2:2:2) if a second display is plugged in that
also requires a DSC encoder to be driven at some refresh rate - and only 2 or 4
encoders are available.
- Marijn
> cdm=#
> sspp=# # # # - - - - 104 # # # # # - -
> cwb=# # # #
>
>
> Hi Marijn,
> Could you help collect debug info with this change? Thanks!
> BTW: my irc id: niej
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> index d07a6ab6e7ee1..fc61c2fbb0699 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> @@ -886,6 +886,7 @@ static int dpu_plane_atomic_check_nosspp(struct
> drm_plane *plane,
> new_plane_state->fb->width, new_plane_state->fb->height,
> new_plane_state->rotation);
>
> + memset(&pstate->pipe_cfg[0], 0, PIPES_PER_PLANE *
> sizeof(struct dpu_sw_pipe_cfg));
> /*
> * We have 1 mixer pair cfg for 1:1:1 and 2:2:1 topology, 2 mixer pair
> * configs for left and right half screen in case of 4:4:2 topology.
> @@ -1055,6 +1056,13 @@ static int dpu_plane_atomic_check_sspp(struct
> drm_plane *plane,
> if (!drm_rect_width(&pipe_cfg->src_rect))
> continue;
> DPU_DEBUG_PLANE(pdpu, "pipe %d is in use, validate it\n", i);
> + if(!pipe->sspp) {
> + WARN(1, "%svirtual plane pipe %d is null with
> width %d height %d!!\n",
> + dpu_use_virtual_planes ? " " : "non-",
> + i,
> + drm_rect_width(&pipe_cfg->src_rect),
> + drm_rect_height(&pipe_cfg->src_rect));
> + }
> ret = dpu_plane_atomic_check_pipe(pdpu, pipe, pipe_cfg,
> &crtc_state->adjusted_mode,
> new_plane_state);
> >
> >
> > --
> > With best wishes
> > Dmitry
Marijn Suijten <marijn.suijten@somainline.org> 于2025年11月30日周日 00:37写道： > > On 2025-09-18 21:29:02, Jun Nie wrote: > > To support high-resolution cases that exceed the width limitation of > > a pair of SSPPs, or scenarios that surpass the maximum MDP clock rate, > > additional pipes are necessary to enable parallel data processing > > within the SSPP width constraints and MDP clock rate. > > > > Request 4 mixers and 4 DSCs for high-resolution cases where both DSC > > and dual interfaces are enabled. 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> > > --- > > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 27 +++++++++++++++++------ > > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 6 ++--- > > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 28 ++++++++---------------- > > 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, 35 insertions(+), 32 deletions(-) > > With this patch applied, I get the following crash on the Sony Xperia 1 III, a > dual-DSI dual-DSC device: > > Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 > Mem abort info: > ESR = 0x0000000096000004 > EC = 0x25: DABT (current EL), IL = 32 bits > SET = 0, FnV = 0 > EA = 0, S1PTW = 0 > FSC = 0x04: level 0 translation fault > Data abort info: > ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 > CM = 0, WnR = 0, TnD = 0, TagAccess = 0 > GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 > user pgtable: 4k pages, 48-bit VAs, pgdp=000000012d4e1000 > [0000000000000020] pgd=0000000000000000, p4d=0000000000000000 > Internal error: Oops: 0000000096000004 [#1] SMP > Modules linked in: msm drm_client_lib ubwc_config drm_dp_aux_bus gpu_sched drm_gpuvm drm_exec > CPU: 5 UID: 0 PID: 3081 Comm: (sd-close) Tainted: G U 6.18.0-rc7-next-20251127-SoMainline-12422-g10b6db5b056d-dirty #21 NONE > Tainted: [U]=USER > Hardware name: Sony Xperia 1 III (DT) > pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > pc : dpu_plane_atomic_check_sspp.isra.0+0x88/0x3f4 [msm] > lr : dpu_plane_atomic_check_sspp.isra.0+0x84/0x3f4 [msm] > sp : ffff800081e23940 > x29: ffff800081e23950 x28: ffff0000bf2700d0 x27: 0000000000000a00 > x26: ffff0000bf270000 x25: 0000000000000a00 x24: ffff0000bd0e5c18 > x23: ffff000087a6c080 x22: 0000000000000224 x21: ffff00008ce88080 > x20: 0000000000000002 x19: ffff0000bf270138 x18: ffff8000818350b0 > x17: 000000040044ffff x16: ffffc488ae2e37e0 x15: 0000000000000005 > x14: 0000000000000a00 x13: 0000000000000000 x12: 0000000000000138 > x11: 0000000000000000 x10: 0000000000000012 x9 : 0000000000000000 > x8 : 0000000000000a00 x7 : 0000000000000000 x6 : 0000000000000000 > x5 : 0000000000000002 x4 : 0000000000000000 x3 : ffffc48897741db0 > x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 > Call trace: > dpu_plane_atomic_check_sspp.isra.0+0x88/0x3f4 [msm] (P) > dpu_plane_atomic_check+0x100/0x1a0 [msm] > drm_atomic_helper_check_planes+0xd8/0x224 > drm_atomic_helper_check+0x50/0xb4 > msm_atomic_check+0xd0/0xe0 [msm] > drm_atomic_check_only+0x4e0/0x928 > drm_atomic_commit+0x50/0xd4 > drm_client_modeset_commit_atomic+0x200/0x260 > drm_client_modeset_commit_locked+0x64/0x180 > drm_client_modeset_commit+0x30/0x60 > drm_fb_helper_lastclose+0x60/0xb0 > drm_fbdev_client_restore+0x18/0x38 [drm_client_lib] > drm_client_dev_restore+0xac/0xf8 > drm_release+0x124/0x158 > __fput+0xd4/0x2e4 > fput_close_sync+0x3c/0xe0 > __arm64_sys_close+0x3c/0x84 > invoke_syscall.constprop.0+0x44/0x100 > el0_svc_common.constprop.0+0x3c/0xe4 > do_el0_svc+0x20/0x3c > el0_svc+0x38/0x110 > el0t_64_sync_handler+0xa8/0xec > el0t_64_sync+0x1a0/0x1a4 > Code: 2a1403e5 52800082 94008e28 f9400380 (f940101b) > ---[ end trace 0000000000000000 ]--- > pstore: backend (ramoops) writing error (-28) > [drm:dpu_encoder_frame_done_timeout:2726] [dpu error]enc33 frame done timeout > > I don't see any thought given to it in the extremely terse patch description, > but this patch seems to unconditionally select 4 DSCs and 4 LMs on this device > because the underlying SM8350 SoC has 4 available in its catalog - while it > was previously affixed to 2:2:2 matching the downstream and known-working > configuration of this device - and I can only imagine things are rolling > downhill from there. This patch expands pipe array size from 2 to 4, and changes the topology decision making. There is an assumption that 2 stages(4LMs) should be allocated in case of 2 interfaces with DSC enabled, because it is a very high resolution use case. This fails for your 2:2:2 use case. But I still expect there are only 2 pipes info filled for your case, and the later 2 pipes shall be bypassed in dpu_plane_atomic_check_sspp() and does not introduce panic. So there is bug in SSPP handling. What's your IRC ID and timezone? IRC shall be much more efficient, if you want to discuss more detail and debug support. > > faddr2line seems to be failing for me, but this is the line > `dpu_plane_atomic_check_sspp.isra.0+0x88` seems to be referring to: > > aarch64-linux-gnu-objdump .output/drivers/gpu/drm/msm/msm.ko -dS | grep dpu_plane_atomic_check_sspp.isra.0\> -A80 > 00000000000671ac <dpu_plane_atomic_check_sspp.isra.0>: > static int dpu_plane_atomic_check_sspp(struct drm_plane *plane, > ... > 67234: f940101b ldr x27, [x0, #32] > if (!(sblk->scaler_blk.len && pipe->sspp->ops.setup_scaler) && > > Please help resolve this issue, as I am not understanding the thought process > behind this patch and unsure how to solve this issue short of just reverting it. > > Looking forward to some assistance, thanks; > - Marijn
On Thu, Sep 18, 2025 at 09:29:02PM +0800, Jun Nie wrote: > To support high-resolution cases that exceed the width limitation of > a pair of SSPPs, or scenarios that surpass the maximum MDP clock rate, > additional pipes are necessary to enable parallel data processing > within the SSPP width constraints and MDP clock rate. > > Request 4 mixers and 4 DSCs for high-resolution cases where both DSC > and dual interfaces are enabled. 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> > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 27 +++++++++++++++++------ > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 6 ++--- > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 28 ++++++++---------------- > 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, 35 insertions(+), 32 deletions(-) > Please fix the LKP report. -- With best wishes Dmitry
© 2016 - 2026 Red Hat, Inc.