Re: [PATCH] drm/msm/dpu: advertise linear-only modifiers on platforms without UBWC

[Mahadevan P]

On 8/24/2026 1:01 PM, Nabige Aala wrote:
> On 8/19/2026 4:53 PM, Mahadevan P wrote:
> > Certain Qualcomm targets like QCM2290 and Shikra do not have UBWC
> > support. On such targets, advertising DRM_FORMAT_MOD_QCOM_COMPRESSED
> > in the supported modifier list causes userspace to attempt UBWC
> > allocations that the kernel rejects:
> >
> >    msm_dpu: [drm] *ERROR* unsupported format modifier 500000000000003
> >    msm_dpu: [drm] *ERROR* unsupported pixel format: AR24 little-endian
> >
> > On platforms without UBWC, only advertise DRM_FORMAT_MOD_LINEAR to
> > avoid exposing formats that the hardware cannot handle.
> >
> > Fixes: 71c5c23be874 ("drm/msm/dpu: check ubwc support before adding 
> > compressed formats")
> > Signed-off-by: Mahadevan P <mahadevan.p@xxxxxxxxxxxxxxxx>
> > ---
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 10 +++++++++-
> >   1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c b/drivers/gpu/ 
> > drm/msm/disp/dpu1/dpu_plane.c
> > index 7b92082d35a6..c8bd034690cb 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > @@ -94,6 +94,11 @@ static const uint64_t supported_format_modifiers[] = {
> >       DRM_FORMAT_MOD_INVALID
> >   };
> > +static const uint64_t supported_format_modifiers_no_ubwc[] = {
> > +    DRM_FORMAT_MOD_LINEAR,
> > +    DRM_FORMAT_MOD_INVALID
> > +};
> > +
> >   #define to_dpu_plane(x) container_of(x, struct dpu_plane, base)
> >   static struct dpu_kms *_dpu_plane_get_kms(struct drm_plane *plane)
> > @@ -1836,7 +1841,10 @@ static struct drm_plane 
> > *dpu_plane_init_common(struct drm_device *dev,
> >       pdpu = drmm_universal_plane_alloc(dev, struct dpu_plane, base,
> >                   0xff, &dpu_plane_funcs,
> >                   format_list, num_formats,
> > -                supported_format_modifiers, type, NULL);
> > +                (kms->mdss->ubwc_enc_version == 0) ?
> > +                    supported_format_modifiers_no_ubwc :
> > +                    supported_format_modifiers,
>
> Can we just pass the NULL here in case no ubwc modifer are supported 
> instead of "supported_format_modifier_no_ubwc"?
>
> would not it automatically handled in this function 
> __drm_universal_plane_init as default_modifier?


Thanks for the review. Please drop this patch - it is not needed.

The commit message was wrong. The modifier in the log I quoted,
0x500000000000003, is DRM_FORMAT_MOD_QCOM_TILED3, not
DRM_FORMAT_MOD_QCOM_COMPRESSED (0x500000000000001). DPU does not
advertise TILED3 anywhere, so this patch could neither have caused nor
fixed that error. I pasted that log here by mistake; it came from an
unrelated experiment.

Having re-checked the current code, there is nothing left to fix:

   - 71c5c23be874 already makes dpu_plane_format_mod_supported() return
     false for QCOM_COMPRESSED when ubwc_enc_version == 0, and
     drm_plane_has_format() consults that callback in preference to
     plane->modifiers[]. UBWC commits are therefore already rejected on
     QCM2290 and Shikra.

   - create_in_format_blob() runs the same callback for every
     (format, modifier) pair, so the QCOM_COMPRESSED entry in IN_FORMATS
     already carries an all-zero format bitmask.

So the patch's only observable effect was to stop a zero-format
modifier entry from being enumerated in the IN_FORMATS blob. That is
cosmetic, and certainly not a Fixes: for 71c5c23be874.

To answer your question: you were right, NULL is equivalent.
__drm_universal_plane_init() substitutes { DRM_FORMAT_MOD_LINEAR } 
when format_modifiers is NULL, and this is documented in the
drm_universal_plane_init() kernel-doc.

Please mark this as Not Applicable. Sorry for the noise.

> Thanks,
>
> Nabige
>
> > +                type, NULL);
> >       if (IS_ERR(pdpu))
> >           return ERR_CAST(pdpu);
> >
> > ---
> > base-commit: e6664f2b33db9b6811eb4cec109f06cb2b4f458d
> > change-id: 20260819-remove_ubwc-0180dfb2908c
> >
> > Best regards,

Thanks,
Mahadevan