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 <[email protected]> > --- > 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
