On Wed, Mar 18, 2026 at 09:45:23AM +0100, Luca Weiss wrote:
> On Tue Mar 17, 2026 at 6:45 PM CET, Dmitry Baryshkov wrote:
> > 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
>
> Is this helpful?
>
> Broken:
> [ 1.247165] dsi_calc_pclk:649 DBG pclk=111546490, bclk=83659867
> [ 1.490559] dpu_encoder_helper_get_3d_blend_mode:309 DBG BLEND_3D_H_ROW_INT
> [ 1.491008] dpu_encoder_prep_dsc:2061 DBG dsc_common_mode=0 initial_lines=1
>
> Working:
> [ 0.998043] dsi_calc_pclk:649 DBG pclk=111546490, bclk=83659867
> [ 1.233836] dpu_encoder_helper_get_3d_blend_mode:313 DBG BLEND_3D_NONE
> [ 1.234277] dpu_encoder_prep_dsc:2061 DBG dsc_common_mode=0 initial_lines=1
>
> Or do you need some more things? There's a lot of data being passed into
> dpu_encoder_dsc_pipe_cfg() for example so I'm not sure which values are
> relevant for this.
It looks sane up. I will try asking internally. But for now the posted
patch should be good to go.
--
With best wishes
Dmitry
