On Mon, Mar 16, 2026 at 10:08:47AM +0100, Luca Weiss wrote:
> Hi Dmitry,
>
> On Fri Mar 13, 2026 at 6:14 PM CET, Dmitry Baryshkov wrote:
> > On Fri, Mar 13, 2026 at 09:33:18AM +0100, Luca Weiss wrote:
> >> Hi Mahadevan,
> >>
> >> On Thu Jan 1, 2026 at 6:04 AM CET, Mahadevan P wrote:
> >> > On SC7280 targets, display modes with a width greater than the
> >> > max_mixer_width (2400) are rejected during mode validation when
> >> > merge3d is disabled. This limitation exists because, without a
> >> > 3D merge block, two layer mixers cannot be combined(non-DSC interface),
> >> > preventing large layers from being split across mixers. As a result,
> >> > higher resolution modes cannot be supported.
> >> >
> >> > Enable merge3d support on SC7280 to allow combining streams from
> >> > two layer mixers into a single non-DSC interface. This capability
> >> > removes the width restriction and enables buffer sizes beyond the
> >> > 2400-pixel limit.
> >> >
> >> > Fixes: 591e34a091d1 ("drm/msm/disp/dpu1: add support for display for
> >> > SC7280 target")
> >> > Signed-off-by: Mahadevan P <[email protected]>
> >>
> >> This patch is causing display regression on QCM6490 fairphone-fp5.
> >>
> >> With this patch in 7.0-rc3 (or 6.18.16) there's just pink noise on the
> >> screen. When reverting this patch everything becomes working again.
> >>
> >> See also
> >> https://salsa.debian.org/Mobian-team/devices/kernels/qcom-linux/-/issues/41
> >>
> >> @Dmitry: Can we revert this for later 7.0-rc, in case it's not fixed
> >> quickly?
> >
> > Could you please provide the resource allocation parts of
> > debugfs/dri/0/state for both working and non-working cases?
>
> Working (patch reverted)
>
> resource mapping:
> pingpong=# # 68 # - - - - - - - - -
> mixer=# - 68 # - - - -
> ctl=68 # # # - - - -
> dspp=# - - - - - - -
> dsc=68 - - - - - - -
> cdm=#
> sspp=# - - - - - - - # # # - - - - -
> cwb=- - - -
>
>
> Broken (with the patch)
>
> resource mapping:
> pingpong=# # 68 68 - - - - - - - - -
> mixer=# - 68 68 - - - -
> ctl=68 # # # - - - -
> dspp=# - - - - - - -
> dsc=68 - - - - - - -
> cdm=#
> sspp=# - - - - - - - # # # - - - - -
> cwb=- - - -
As we have identified that the issue is what downstream calls
DUALPIPE_3DMERGE_DSC topology, could you please also check several
things (with the broken kernel):
- What is being returned by dpu_encoder_helper_get_3d_blend_mode() (in
the broken config)?
- If there is any difference in working and broken configs between
values being passed to (and programmed to the DSC) in
dpu_encoder_prep_dsc() ?
- The same question for pclk calculation in dsi_host.c
--
With best wishes
Dmitry
