On Thu, Mar 12, 2026 at 6:31 AM Marijn Suijten
<[email protected]> wrote:
>
> Commit ac47870fd795 ("drm/msm/dsi: fix hdisplay calculation when
> programming dsi registers") makes a false and ungrounded statement that
> "Since CMD mode does not use this, we can remove !(msm_host->mode_flags
> & MIPI_DSI_MODE_VIDEO) safely." which isn't the case at all.
> dsi_timing_setup() affects both command mode and video mode panels, and
> by no longer having any path that sets bits_per_pclk = 48 (contrary to
> the updated code-comment) all DSI DSC panels on SM8350 and above (i.e.
> with widebus support) regress thanks to this patch.
>
> The entire reason that video mode was originally omitted from this code
> path is because it was never tested before; any change that enables
> widebus for video mode panels should not regress the command mode path.
>
> Thus add back the path allows 6 bytes or 48 bits to be sent per pclk
> on command mode DSI panels with widebus, restoring the panel on devices
> like the Sony Xperia 1 III and upwards.
>
> Fixes: ac47870fd795 ("drm/msm/dsi: fix hdisplay calculation when programming 
> dsi registers")
> Signed-off-by: Marijn Suijten <[email protected]>
> ---

Apologies, I messed up, I had sent the same fixes days ago.
https://lore.kernel.org/linux-arm-msm/[email protected]/

> In addition I can't say I understand the original commit message
> at all; it mentions a BPC=10 mode however the highest format that
> mipi_dsi_pixel_format_to_bpp supports is RGB888 thus it won't
> ever return anything above 24, which is the original amount the
> non-command-mode path defaulted to (regardless of widebus)...  Was that
> patch doing anything for video mode at all?
>

RGB888 is the dst bpc, which is tied to qcom,mdss-dsi-bpp in the downstream.

Actually, we should use src bpc here, another fixe
https://lore.kernel.org/linux-arm-msm/[email protected]/

> It feels like the conditional introduced here is only making things more
> confusing, but I don't have enough input to confirm what the video-mode
> path should be doing in widebus mode (multiply BPC by the number of
> components and by 2 in case of widebus?).

I left a comment. For CMD mode, it consumes 6 bytes, for Video mode,

  * DPU sends 3 bytes per pclk cycle to DSI. If widebus is
- * enabled, bus width is extended to 6 bytes.
+ * enabled, 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.



Best wishes,
Pengyu Luo

Reply via email to