| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <i234zyh7ajsxdvbkzindyk5h6wilds226jqmh32kml4aweesav@frlk2l7zgmg4>
Date: Wed, 10 Dec 2025 21:30:20 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Marijn Suijten <marijn.suijten@...ainline.org>
Cc: Jun Nie <jun.nie@...aro.org>, Abhinav Kumar <abhinav.kumar@...ux.dev>,
Dmitry Baryshkov <lumag@...nel.org>, Sean Paul <sean@...rly.run>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Rob Clark <robin.clark@....qualcomm.com>,
Jessica Zhang <jessica.zhang@....qualcomm.com>,
linux-arm-msm@...r.kernel.org, dri-devel@...ts.freedesktop.org,
freedreno@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
Jessica Zhang <quic_jesszhan@...cinc.com>
Subject: Re: [PATCH v16 10/10] drm/msm/dpu: Enable quad-pipe for DSC and
dual-DSI case
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@...aro.org>
> > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> > Reviewed-by: Jessica Zhang <quic_jesszhan@...cinc.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
Powered by blists - more mailing lists