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

[Mahadevan P <mahadevan.p@oss.qualcomm.com>]

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@oss.qualcomm.com>
>> ---
>>   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