Re: [PATCH 2/5] drm/msm/dsi: add per-SoC bonded command-path config

[Dmitry Baryshkov]

On Sat, Oct 31, 2026 at 11:03:02PM +0800, Qianhui Xu wrote:
> The bonded command path carried its constants inline: the error-mask bits
> in dsi_cmd_error_prepare()/dsi_cmd_error_cleanup(), the CMD_DMA_CTRL bits
> staged before a broadcast and the peer poll budget. Those are controller
> facts, so they belong in the existing per-SoC table next to the regulator
> and bus-clock data rather than in the driver body.

Do they differ from platform to platform?

> 
> Add struct msm_dsi_bonded_cfg and hang it off struct msm_dsi_config.
> SM8750 reports DSI 6G v2.9, which selects the sm8650 cfg entry, so the
> bonded data is attached there with values copied verbatim from the
> current code. Use remains gated on the sm8750 compatible, so behaviour is
> unchanged.

What happens on the other platforms?

> 
> Signed-off-by: Qianhui Xu <xiaqinghuan@xxxxxxxxxxxxxxxx>
> ---
>  drivers/gpu/drm/msm/dsi/dsi_cfg.c  | 26 ++++++++++++++++++++++++++
>  drivers/gpu/drm/msm/dsi/dsi_cfg.h  | 22 ++++++++++++++++++++++
>  drivers/gpu/drm/msm/dsi/dsi_host.c | 22 +++++++++++++++-------
>  3 files changed, 63 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
> index da3fe68244..640ebe8244 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
> @@ -4,6 +4,7 @@
>   */
>  
>  #include "dsi_cfg.h"
> +#include "dsi.xml.h"
>  
>  static const char * const dsi_v2_bus_clk_names[] = {
>  	"core_mmss", "iface", "bus",
> @@ -194,6 +195,24 @@ static const struct regulator_bulk_data sm8650_dsi_regulators[] = {
>  	{ .supply = "vdda", .init_load_uA = 16600 },	/* 1.2 V */
>  };
>  
> +/*
> + * Bonded command-path data. Values are copied verbatim from the vendor-derived
> + * in-tree code; the SM8750 compatible check in dsi_host.c/dsi_manager.c still
> + * gates every use until the master link moves into this table as well.
> + * TODO(doc): err_clear_bits/err_cleanup_bits touch bits that dsi.xml does not
> + * describe (see reports/b5-per-soc-cfg-design-20261027.md, RFC-SCOPE R1).
> + */
> +static const struct msm_dsi_bonded_cfg sm8750_dsi_bonded_cfg = {
> +	.master_link_id = DSI_0,
> +	.cmd_dma_ctrl = DSI_CMD_DMA_CTRL_BROADCAST_EN |
> +			DSI_CMD_DMA_CTRL_FROM_FRAME_BUFFER,
> +	.err_clear_bits = 0x001f0200,
> +	.err_cleanup_bits = 0x44440400,
> +	.poll_timeout_us = 5000,	/* 500 polls, 10 us apart */
> +	.needs_link_clk_bump = true,
> +	.needs_sw_reset = true,
> +};
> +
>  static const struct msm_dsi_config sm8650_dsi_cfg = {
>  	.io_offset = DSI_6G_REG_SHIFT,
>  	.regulator_data = sm8650_dsi_regulators,
> @@ -203,6 +222,13 @@ static const struct msm_dsi_config sm8650_dsi_cfg = {
>  	.io_start = {
>  		{ 0xae94000, 0xae96000 },
>  	},
> +	/*
> +	 * SM8750 reports DSI 6G v2.9, i.e. it selects this very table entry, so
> +	 * the bonded data has to hang off it. Its use is still gated on the
> +	 * "qcom,sm8750-dsi-ctrl" compatible, so an actual SM8650 keeps taking
> +	 * the regular command path.
> +	 */

Huh?

> +	.bonded = &sm8750_dsi_bonded_cfg,

If it's a sm8650 struct all the fields should be sm8650 too.

>  };
>  
>  static const struct msm_dsi_config kaanapali_dsi_cfg = {

-- 
With best wishes
Dmitry