Hi Dmitry,
before the technical part: this reply is drafted with an AI assistant and
edited by me. I am the author of the series; the content, the measurements
and the decisions are mine.
1) Why change it. Upstream's bonded DSI is clock/PHY only: dsi.xml defines
CMD_DMA_CTRL.BROADCAST_EN, dsi_host.c never sets it, so no path sends one
command over both links -- which is what this panel needs (first DCS ff 20
fails with -22, the DMA engine hangs; slave-first/master-last fixes it).
This series is the data half of proposing that path; behaviour unchanged.
[E1][E2][E3]
2) 1/5. Both style points accepted: v2 moves dsi_bonded_cmd_lock into
msm_dsim_glb next to the flag (today DEFINE_MUTEX at dsi_manager.c:40, flag
at :41) and reflows the comment to a leading "/*" on its own line. On the
base: 0f1fb1c9c1 is not public -- it is v7.3-rc7 plus one local squashed
payload commit, so the definitions you miss do not exist upstream. [E4][E5]
3) 2/5. I have SM8750 values only, so I cannot claim they differ per
platform; that is why they are data in a table, and if a second SoC turns
out identical the entry collapses. On every other SoC cfg->bonded is NULL
and the old path is taken. You are also right that SM8750 data must not
hang off the sm8650 entry: both report DSI 6G v2.9, so v2 selects it per
compatible. [E6]
4) 4/5. My commit message was wrong: IDs are not assigned by probe order
and the master is not derived from it either, it comes from the DT. The
corrected paragraph is
drm/msm/dsi: take bonded DSI master cfg from per-SoC config
The bonded master link is selected by the device tree: dsi_mgr_parse_of()
sets msm_dsim_glb.master_dsi_link_id from "qcom,master-dsi", and the link
ids are the DSI host indices, not the probe order. The DT stays the
authority for the role; the per-SoC entry only records which link this
board's panel sits on, so a bonded transfer issued from the non-master
link can be rejected with a warning instead of failing later as -EINVAL
during panel init. On this board the recorded id equals the DT-selected
one, so behaviour is unchanged.
So in v2 I will not take the master from the table: the DT keeps deciding it
and the entry only backs the "caller must be the master link" check. I will
recut the series on top of current torvalds master, so it applies for you
without the local payload, and resend it as a new series. I am not sending
patches in this thread.
Evidence
[E1] v7.3-rc7 (24a19b953e) as exported from this tree:
grep -n BROADCAST_EN drivers/gpu/drm/msm/registers/display/dsi.xml
-> 190: <bitfield name="BROADCAST_EN" pos="31" type="boolean"/>
grep -c BROADCAST_EN drivers/gpu/drm/msm/dsi/dsi_host.c
-> 0
[E2] Panel init on this board when the bonded command path is absent or
mis-ordered: reports/b5-step4-master-from-cfg-20261027.md:35-41
panel-novatek-nt36536 ae94000.dsi.0: sending dcs data ff 20 failed: -22
... attempt 1/2/3 failed ... Failed to initialize panel: -22
msm_dsi ae96000.dsi: panel is not prepared; refusing video enable
same file, section 0: with the path in place the seven error counters
(command DMA timeout, vblank timeout, reset failure, panel not
prepared, ...) stay at 0 across 10 blank/wake cycles.
[E3] Command DMA engine state with the two links armed independently:
patches/upstream/m6-b5-p4-rfc-20261027/RFC-SCOPE.md:12-15
STATUS0=0x20003, TRIG_DMA=0x1 (self-clearing never happens), panel
shows backlight only; symptom disappears after slave-first /
master-last ordering with the completion IRQ on the master alone.
[E4] Lock and flag as sent (both file-scoped today):
linux/drivers/gpu/drm/msm/dsi/dsi_manager.c:40
static DEFINE_MUTEX(dsi_bonded_cmd_lock);
linux/drivers/gpu/drm/msm/dsi/dsi_manager.c:41
static bool dsi_bonded_cmd_failed;
[E5] The base really is v7.3-rc7 + one squashed local commit:
git -C build/m3v2-7.3rc7 rev-parse 0f1fb1c9c1^ -> 24a19b953e (v7.3-rc7)
git -C build/m3v2-7.3rc7 show --stat 0f1fb1c9c1 -> 148 files changed,
15513 insertions(+), 700 deletions(-)
and the DSI part of it: dsi_host.c +578, dsi_manager.c +249, dsi.h +19.
Consequence measured earlier: on pristine v7.3-rc7 the series does not
apply (0/6; only 0002 is clean) -- reports/b5-preflight-20261029.md
section 1.2. That is what v2 has to fix, not something I can talk away.
[E6] The SM8750 bonded data is attached to the sm8650 entry in the sent
patch: patches/local/b5-resoc-20261027/0002-dsi-per-soc-bonded-cfg.patch:72
+ .bonded = &sm8750_dsi_bonded_cfg,
on sm8650_dsi_cfg; the only thing distinguishing the two SoCs is the
compatible (7 uses of "qcom,sm8750-dsi-ctrl" in dsi_host.c), since both
report DSI 6G v2.9.
[E7] Master is a DT property on this board too:
linux/arch/arm64/boot/dts/qcom/sm8750-lenovo-elden.dts:1658
qcom,master-dsi; (inside &mdss_dsi0, the node with the panel)
parsed at linux/drivers/gpu/drm/msm/dsi/dsi_manager.c:80-81.
Thanks for the review.
Qianhui Xu
