Re: [PATCH v3 4/4] drm/msm/dpu: fix video mode DSC INTF timing width calculation

[Jonathan Marek <jonathan@marek.ca>]

On 3/19/26 9:45 PM, Dmitry Baryshkov wrote:
> On Thu, Mar 19, 2026 at 01:23:03PM -0400, Jonathan Marek wrote:
...
>>
>> That's not how it works. INTF (which feeds DSI) is after DSC compression.
>>
>> INTF timings are always in RGB888 (24-bit) units. Ignoring widebus details,
>> the INTF timing should match what is programmed on the DSI side (hdisplay,
>> which is calculated as bytes per line / 3).
>>
>> (fwiw, the current "timing->width = ..." calculation here blames to me, but
>> what I wrote originally was just "timing->width = timing->width / 3" with a
>> comment about being incomplete.)
>>
> Okay. After reading the docs (sorry, it took a while).
> 
> - When widebus is not enabled, the transfer is always 24 bit of
>    compressed data. Thus if it is not in play, pclk and timing->width
>    should be scaled by source_pixel_depth / compression_ratio / 24. In
>    case of the code it is 'drm_dsc_get_bpp_int(dsc) / 24'.
> 
>    For RGB101010 / 8bpp DSC this should result in the PCLK being lowered
>    by the factor of 3 (= 24 / (30 / 3.75))
> 
> - When widebus is in play (MDSS 6.x+, DSI 2.4+), the transfer takes
>    more than 24 bits. In this case the PCLK and timing->width should be
>    scaled exactly by the DSC compression ratio, which is
>    'drm_dsc_get_bpp_int(dsc) / (3 * dsc->bits_per_component).
> 
> So, this piece of code needs to be adjusted to check for the widebus
> being enabled or not.
> 

The widebus adjustment on the MDP/INTF side is already in 
dpu_hw_intf_setup_timing_engine: the "data width" is divided by 2 for 
48-bit widebus instead of 24-bit. there shouldn't be any other 
adjustment (downstream doesn't have any other adjustment).

a relevant downstream comment: "In DATABUS-WIDEN mode, MDP always sends 
out 48-bit compressed data per pclk and on average, DSI consumes an 
amount of compressed data equivalent to the uncompressed pixel depth per 
pclk."

Based on that comment, this patch is correct, and the 
''drm_dsc_get_bpp_int(dsc) / (3 * dsc->bits_per_component)' adjustment 
only applies to DSI. (note: newer downstream looks like it would divide 
by 3.75 here, which doesn't make sense. older downstream would divide by 
3 here. I guess downstream is broken now and video mode + 10-bit dsc 
doesn't get tested?)

on DSI side, "uncompressed pixel depth" shouldn't matter either: DSI 
only sees the compressed data. But based on that comment, when widebus 
is enabled, by setting DSI_VID_CFG0_DST_FORMAT(?) to 30bpp, then the DSI 
pclk is in 30-bit units instead of 24-bits. And with this series DSI 
side ends up with the right result if 30bpp format and widebus is enabled.