[PATCH] drm/msm/dsi: Restore widebus calculation for CMDMode panels

[PATCH] drm/msm/dsi: Restore widebus calculation for CMDMode panels

[Marijn Suijten]

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 <marijn.suijten@somainline.org>
---
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?

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?).
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c
index e8e83ee61eb0..168e37e38fc7 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1029,10 +1029,14 @@ static void dsi_timing_setup(struct msm_dsi_host *msm_host, bool is_bonded_dsi)
 		 * unused anyway.
 		 */
 		h_total -= hdisplay;
-		if (wide_bus_enabled)
-			bits_per_pclk = mipi_dsi_pixel_format_to_bpp(msm_host->format);
-		else
+		if (wide_bus_enabled) {
+			if (msm_host->mode_flags & MIPI_DSI_MODE_VIDEO)
+				bits_per_pclk = mipi_dsi_pixel_format_to_bpp(msm_host->format);
+			else
+				bits_per_pclk = 48;
+		} else {
 			bits_per_pclk = 24;
+		}
 
 		hdisplay = DIV_ROUND_UP(msm_dsc_get_bytes_per_line(msm_host->dsc) * 8, bits_per_pclk);
 

---
base-commit: 3fa5e5702a82d259897bd7e209469bc06368bf31
change-id: 20260311-dsi-dsc-regresses-again-4be27dfc4001

Best regards,
-- 
Marijn Suijten <marijn.suijten@somainline.org>

Re: [PATCH] drm/msm/dsi: Restore widebus calculation for CMDMode panels

[Pengyu Luo]

On Thu, Mar 12, 2026 at 6:31 AM Marijn Suijten
<marijn.suijten@somainline.org> 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 <marijn.suijten@somainline.org>
> ---

Apologies, I messed up, I had sent the same fixes days ago.
https://lore.kernel.org/linux-arm-msm/20260307111250.105772-2-mitltlatltl@gmail.com/

> 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/20260307111250.105772-1-mitltlatltl@gmail.com/

> 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

Re: [PATCH] drm/msm/dsi: Restore widebus calculation for CMDMode panels

[Dmitry Baryshkov]

On Thu, Mar 12, 2026 at 01:10:07PM +0800, Pengyu Luo wrote:
> On Thu, Mar 12, 2026 at 6:31 AM Marijn Suijten
> <marijn.suijten@somainline.org> 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 <marijn.suijten@somainline.org>
> > ---
> 
> Apologies, I messed up, I had sent the same fixes days ago.
> https://lore.kernel.org/linux-arm-msm/20260307111250.105772-2-mitltlatltl@gmail.com/
> 
> > 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/20260307111250.105772-1-mitltlatltl@gmail.com/

I'm really torn between your two patchsets here.

Marijn, Pengyu, what are your testing platforms and are you testing
video or command mode panels?

> > 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.

I think this comment more or less matches what I see in the docs.

-- 
With best wishes
Dmitry

Re: [PATCH] drm/msm/dsi: Restore widebus calculation for CMDMode panels

[Pengyu Luo]

On Fri, Mar 20, 2026 at 9:59 AM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> On Thu, Mar 12, 2026 at 01:10:07PM +0800, Pengyu Luo wrote:
> > On Thu, Mar 12, 2026 at 6:31 AM Marijn Suijten
> > <marijn.suijten@somainline.org> 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 <marijn.suijten@somainline.org>
> > > ---
> >
> > Apologies, I messed up, I had sent the same fixes days ago.
> > https://lore.kernel.org/linux-arm-msm/20260307111250.105772-2-mitltlatltl@gmail.com/
> >
> > > 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/20260307111250.105772-1-mitltlatltl@gmail.com/
>
> I'm really torn between your two patchsets here.
>
> Marijn, Pengyu, what are your testing platforms and are you testing
> video or command mode panels?
>

SM8750, I am testing on a native 10-bit video mode panel.

My thoughts are we should restore 6 for the cmd panel, and we should
fix video mode too.
As I mentioned, I overlooked something, I thought the cmd panel didn't
use the value, which
made the value for the cmd panel wrong. So we can restore it for the
cmd panel (though I can't say why 6).

Best wishes,
Pengyu

Re: [PATCH] drm/msm/dsi: Restore widebus calculation for CMDMode panels

[Dmitry Baryshkov]

On Fri, Mar 20, 2026 at 07:26:22PM +0800, Pengyu Luo wrote:
> On Fri, Mar 20, 2026 at 9:59 AM Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> wrote:
> >
> > On Thu, Mar 12, 2026 at 01:10:07PM +0800, Pengyu Luo wrote:
> > > On Thu, Mar 12, 2026 at 6:31 AM Marijn Suijten
> > > <marijn.suijten@somainline.org> 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 <marijn.suijten@somainline.org>
> > > > ---
> > >
> > > Apologies, I messed up, I had sent the same fixes days ago.
> > > https://lore.kernel.org/linux-arm-msm/20260307111250.105772-2-mitltlatltl@gmail.com/
> > >
> > > > 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/20260307111250.105772-1-mitltlatltl@gmail.com/
> >
> > I'm really torn between your two patchsets here.
> >
> > Marijn, Pengyu, what are your testing platforms and are you testing
> > video or command mode panels?
> >
> 
> SM8750, I am testing on a native 10-bit video mode panel.

Is the framerate correct for you?

> 
> My thoughts are we should restore 6 for the cmd panel, and we should
> fix video mode too.
> As I mentioned, I overlooked something, I thought the cmd panel didn't
> use the value, which
> made the value for the cmd panel wrong. So we can restore it for the
> cmd panel (though I can't say why 6).

2 (wide) x 24 (normal bus) / 8 (byte)

-- 
With best wishes
Dmitry

Re: [PATCH] drm/msm/dsi: Restore widebus calculation for CMDMode panels

[Pengyu Luo]

On Fri, Mar 20, 2026 at 9:06 PM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> On Fri, Mar 20, 2026 at 07:26:22PM +0800, Pengyu Luo wrote:
> > On Fri, Mar 20, 2026 at 9:59 AM Dmitry Baryshkov
> > <dmitry.baryshkov@oss.qualcomm.com> wrote:
> > >
> > > On Thu, Mar 12, 2026 at 01:10:07PM +0800, Pengyu Luo wrote:
> > > > On Thu, Mar 12, 2026 at 6:31 AM Marijn Suijten
> > > > <marijn.suijten@somainline.org> 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 <marijn.suijten@somainline.org>
> > > > > ---
> > > >
> > > > Apologies, I messed up, I had sent the same fixes days ago.
> > > > https://lore.kernel.org/linux-arm-msm/20260307111250.105772-2-mitltlatltl@gmail.com/
> > > >
> > > > > 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/20260307111250.105772-1-mitltlatltl@gmail.com/
> > >
> > > I'm really torn between your two patchsets here.
> > >
> > > Marijn, Pengyu, what are your testing platforms and are you testing
> > > video or command mode panels?
> > >
> >
> > SM8750, I am testing on a native 10-bit video mode panel.
>
> Is the framerate correct for you?
>

30, 60, 90, 120, 144, 165 work for me, in 24 dst bpp, 30 src bpp.

It failed to set pclk clk rate when I set 30 dst bpp, 30 src bpp, but
172992000 is right and works for 24 dst bpp, 30 src bpp.

Mar 20 20:46:00 qcom kernel: dsi_mgr_bridge_mode_set: set mode:
"1904x3040": 120 915552 1904 2180 2212 2244 3040 3066 3070 3400 0x48
 0x0
Mar 20 20:46:00 qcom kernel: dsi_mgr_bridge_pre_enable: id=0
Mar 20 20:46:00 qcom kernel: dsi_mgr_bridge_power_on: id=0
Mar 20 20:46:00 qcom kernel: msm_dsi_host_reset_phy:
Mar 20 20:46:00 qcom kernel: msm_dsi_host_reset_phy:
Mar 20 20:46:00 qcom kernel: dsi_calc_pclk: pclk=172992000, bclk=108120000
Mar 20 20:46:00 qcom kernel: dsi_calc_pclk: pclk=172992000, bclk=108120000
Mar 20 20:46:00 qcom kernel: dsi_link_clk_set_rate_6g: Set clk rates:
pclk=172992000, byteclk=108120000
Mar 20 20:46:00 qcom kernel: dsi_link_clk_set_rate_6g: Failed to set
rate pixel clk, -22
Mar 20 20:46:00 qcom kernel: msm_dsi_host_power_on: failed to enable
link clocks. ret=-22
Mar 20 20:46:00 qcom kernel: dsi_mgr_bridge_power_on: power on host 0
failed, -22
Mar 20 20:46:00 qcom kernel: msm_dsi ae94000.dsi: Power on failed: -22

Best wishes,
Pengyu
> >
> > My thoughts are we should restore 6 for the cmd panel, and we should
> > fix video mode too.
> > As I mentioned, I overlooked something, I thought the cmd panel didn't
> > use the value, which
> > made the value for the cmd panel wrong. So we can restore it for the
> > cmd panel (though I can't say why 6).
>
> 2 (wide) x 24 (normal bus) / 8 (byte)
>
> --
> With best wishes
> Dmitry

Re: [PATCH] drm/msm/dsi: Restore widebus calculation for CMDMode panels

[AngeloGioacchino Del Regno]

Il 11/03/26 23:31, Marijn Suijten ha scritto:
> 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 <marijn.suijten@somainline.org>
> ---
> 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?
> 
> 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?).
> ---
>   drivers/gpu/drm/msm/dsi/dsi_host.c | 10 +++++++---
>   1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index e8e83ee61eb0..168e37e38fc7 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -1029,10 +1029,14 @@ static void dsi_timing_setup(struct msm_dsi_host *msm_host, bool is_bonded_dsi)
>   		 * unused anyway.
>   		 */
>   		h_total -= hdisplay;
> -		if (wide_bus_enabled)
> -			bits_per_pclk = mipi_dsi_pixel_format_to_bpp(msm_host->format);
> -		else
> +		if (wide_bus_enabled) {
> +			if (msm_host->mode_flags & MIPI_DSI_MODE_VIDEO)
> +				bits_per_pclk = mipi_dsi_pixel_format_to_bpp(msm_host->format);
> +			else
> +				bits_per_pclk = 48;
> +		} else {
>   			bits_per_pclk = 24;
> +		}

Marijn et al,

I don't really know this hardware specifically, but I had a very fast look
at this patch, and I believe that however you put it, this looks like being
either plain wrong or very weird.

I think this should be, instead....

	/* (don't add this comment) assuming RGB888/666, this will be 24 for both Command 
and Video modes */
	bits_per_pclk = mipi_dsi_pixel_format_to_bpp(msm_host->format);

	/* Can send twice the bits per clock if WideBus with Video Mode */
	if (wide_bus_enabled && msm_host->mode_flags & MIPI_DSI_MODE_VIDEO)
		bits_per_pclk *= 2;

...because, unless there's a hardware quirk (and that should be really clarified
with a big comment stating that), I don't see why command mode should always be
24 bits per clock, and I also don't see why a widebus case would do 48 bits per
clock even in the RGB666_PACKED and RGB565 cases (which may not even be possible
but *meh*).

Just my two cents.

Reminding you all again that I don't know this HW, so I may have said something
wrong here.

Cheers!
Angelo

>   
>   		hdisplay = DIV_ROUND_UP(msm_dsc_get_bytes_per_line(msm_host->dsc) * 8, bits_per_pclk);
>   
> 
> ---
> base-commit: 3fa5e5702a82d259897bd7e209469bc06368bf31
> change-id: 20260311-dsi-dsc-regresses-again-4be27dfc4001
> 
> Best regards,

Re: [PATCH] drm/msm/dsi: Restore widebus calculation for CMDMode panels

[Marijn Suijten]

On 2026-03-12 14:18:43, AngeloGioacchino Del Regno wrote:
...
> Marijn et al,
> 
> I don't really know this hardware specifically, but I had a very fast look
> at this patch, and I believe that however you put it, this looks like being
> either plain wrong or very weird.

I would say I also don't know the hardware here very well, and which parameters
apply when and were.  Most importantly, just be aware that the code we're
looking at is for **DSC**, i.e. when we're no longer transfering single pixels
per pclk, but compressed slices of a given number of bytes that can loosely be
converted back to a "number of pixels".

> I think this should be, instead....
> 
> 	/* (don't add this comment) assuming RGB888/666, this will be 24 for both Command 
> and Video modes */
> 	bits_per_pclk = mipi_dsi_pixel_format_to_bpp(msm_host->format);

That would make sense, if it weren't for DSC.  The older downstream kernel I'm
looking at -for at least CMD mode- disregards the format entirely, and just
divides the "width" (computed like msm_dsc_get_bytes_per_line()) by 3 or 6
depending on widebus.

In other words that's clearly demonstrating that input/output "bits per
component" (in uncompressed space) are irrelevant when we're transmitting
compressed pixels.

> 	/* Can send twice the bits per clock if WideBus with Video Mode */
> 	if (wide_bus_enabled && msm_host->mode_flags & MIPI_DSI_MODE_VIDEO)
> 		bits_per_pclk *= 2;

And this is where the original patch got things wrong too; widebus isn't limited
to VIDEO mode, in fact we were specifically only allowing CMD mode to use it
thus far.  That comment and condition should be inverted.

In this old downstream, widebus also doesn't seem to affect the pclk rate for
VIDEO mode, only the ratio between bits per component and the chroma format
(making up the total size of the pixel) and the configured "bits per pixel"
value are taken into account; that ratio is generally 3.

> ...because, unless there's a hardware quirk (and that should be really clarified
> with a big comment stating that), I don't see why command mode should always be
> 24 bits per clock, and I also don't see why a widebus case would do 48 bits per
> clock even in the RGB666_PACKED and RGB565 cases (which may not even be possible
> but *meh*).
> 
> Just my two cents.
> 
> Reminding you all again that I don't know this HW, so I may have said something
> wrong here.
>
> Cheers!
> Angelo

Kind regards,
Marijn