Devicetree
 help / color / mirror / Atom feed
* [PATCH v5 0/3] drm/msm/mdss: reset all block resets described in DT
@ 2026-11-13 15:56 Qianhui Xu
  2026-11-13 15:56 ` [PATCH 1/3] dt-bindings: display: msm: mdss-common: describe additional block resets Qianhui Xu
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Qianhui Xu @ 2026-11-13 15:56 UTC (permalink / raw)
  To: linux-arm-msm, dri-devel
  Cc: devicetree, linux-kernel, Konrad Dybcio, Dmitry Baryshkov,
	Abel Vesa, Bjorn Andersson

*** AI-assistance disclosure ***
This cover letter and the three patches were prepared with the help of an
LLM coding assistant.  The author reviewed every line, checked every
statement against the tree and his own logs, and takes full responsibility
for the content.

This is v5 of the MDSS block-reset series.  It supersedes v4
(<cover.1794558882.git.xiaqinghuan@mail.ustc.edu.cn>) and changes only the
last commit message, in response to the review of v4 3/3
(<8a0c75949fcf428a2163a2e63b27fcf08d3b4f9c.1794558882.git.xiaqinghuan@mail.ustc.edu.cn>).

1/3 and 2/3 are unchanged from v4.  3/3 keeps a byte-identical diff; only its
commit message is rewritten.

v4 said that dispcc provides "a block reset for the MDSS core INT2 interrupt
controller" and that INT2 "is part of the same block, not a separate
device".  Review pointed out that 0xa000 is described by dispcc as its own
domain: it has its own GDSC (mdss_int2_gdsc) and its own clock family
(disp_cc_mdss_mdp1_clk, disp_cc_mdss_ahb1_clk, ...), and the mdss node does
not attach that domain (power-domains is MDSS_GDSC only, and the clocks list
has no mdp1 entries).  That reading of the code is correct, so v5 no longer
calls this an interrupt controller reset and no longer claims it is the same
block.

What v5 states instead is only what is observable:

  - dispcc provides two block resets for the MDSS core area (0x8000 and
    0xa000), and the second one belongs to a domain dispcc describes
    separately;
  - firmware hands over with the display hardware still running, so the MDSS
    reset returns the group to a known state before display hardware is
    programmed;
  - on this board, resetting only DISP_CC_MDSS_CORE_BCR leaves the display
    intermittently broken at cold boot (command DMA timeouts followed by a
    panel init failure, 5 of 9 cold PORs), while asserting the group gave 15
    clean boots out of 15.

The message also records the limits of that measurement: the 15/15 figure
came from the three-reset shape that still included RSCC, it has not been
repeated for this two-reset shape, and the second reset was not isolated as a
single variable.  There is no datasheet-level confirmation that the INTR2
group and the 0xa000 domain are the same hardware block; the evidence for
that is naming (dispcc's ..._CORE_INT2_BCR, MDSS_INT2_GDSC; MDP TOP's INTR2)
plus structure (same MDSS core, separate BCR/GDSC inside it).

All three Reviewed-by tags are carried over: Abel Vesa, Dmitry Baryshkov, and
Konrad Dybcio (the last one received on v4 3/3).

If the un-attached-domain concern is considered disqualifying, the
alternative is to drop 3/3 and keep only 2/3 -- the array-API change, which is
uncontroversial.  I kept 3/3 because the failing cold boot is reproducible on
this hardware and the group is what tracks with it, but I am happy to send a
v6 without it if that is preferred.

Gates: pristine v7.3-rc7 (24a19b953e) git am 3/3 clean; checkpatch --strict
3/3 at 0 errors, 0 warnings, 0 checks; code and DT diffs are identical to v4,
so v4's dt_binding_check and W=1 results carry over unchanged.

Qianhui Xu (3):
  dt-bindings: display: msm: mdss-common: describe additional block
    resets
  drm/msm/mdss: reset all block resets described in DT
  arm64: dts: qcom: sm8750: describe the second MDSS block reset

 .../devicetree/bindings/display/msm/mdss-common.yaml         | 4 +++-
 .../devicetree/bindings/display/msm/qcom,sm8750-mdss.yaml    | 3 ++-
 arch/arm64/boot/dts/qcom/sm8750.dtsi                         | 3 ++-
 drivers/gpu/drm/msm/msm_mdss.c                               | 5 ++---
 4 files changed, 9 insertions(+), 6 deletions(-)

-- 
2.53.0


^ permalink raw reply	[flat|nested] 9+ messages in thread
* [PATCH v5 0/3] drm/msm/mdss: reset all block resets described in DT
@ 2026-11-13 15:56 Qianhui Xu
  2026-11-13 15:56 ` [PATCH 3/3] arm64: dts: qcom: sm8750: describe the second MDSS block reset Qianhui Xu
  0 siblings, 1 reply; 9+ messages in thread
From: Qianhui Xu @ 2026-11-13 15:56 UTC (permalink / raw)
  To: linux-arm-msm, dri-devel
  Cc: devicetree, linux-kernel, Konrad Dybcio, Dmitry Baryshkov,
	Abel Vesa, Bjorn Andersson

*** AI-assistance disclosure ***
This cover letter and the three patches were prepared with the help of an
LLM coding assistant.  The author reviewed every line, checked every
statement against the tree and his own logs, and takes full responsibility
for the content.

This is v5 of the MDSS block-reset series.  It supersedes v4
(<cover.1794558882.git.xiaqinghuan@mail.ustc.edu.cn>) and changes only the
last commit message, in response to the review of v4 3/3
(<8a0c75949fcf428a2163a2e63b27fcf08d3b4f9c.1794558882.git.xiaqinghuan@mail.ustc.edu.cn>).

1/3 and 2/3 are unchanged from v4.  3/3 keeps a byte-identical diff; only its
commit message is rewritten.

v4 said that dispcc provides "a block reset for the MDSS core INT2 interrupt
controller" and that INT2 "is part of the same block, not a separate
device".  Review pointed out that 0xa000 is described by dispcc as its own
domain: it has its own GDSC (mdss_int2_gdsc) and its own clock family
(disp_cc_mdss_mdp1_clk, disp_cc_mdss_ahb1_clk, ...), and the mdss node does
not attach that domain (power-domains is MDSS_GDSC only, and the clocks list
has no mdp1 entries).  That reading of the code is correct, so v5 no longer
calls this an interrupt controller reset and no longer claims it is the same
block.

What v5 states instead is only what is observable:

  - dispcc provides two block resets for the MDSS core area (0x8000 and
    0xa000), and the second one belongs to a domain dispcc describes
    separately;
  - firmware hands over with the display hardware still running, so the MDSS
    reset returns the group to a known state before display hardware is
    programmed;
  - on this board, resetting only DISP_CC_MDSS_CORE_BCR leaves the display
    intermittently broken at cold boot (command DMA timeouts followed by a
    panel init failure, 5 of 9 cold PORs), while asserting the group gave 15
    clean boots out of 15.

The message also records the limits of that measurement: the 15/15 figure
came from the three-reset shape that still included RSCC, it has not been
repeated for this two-reset shape, and the second reset was not isolated as a
single variable.  There is no datasheet-level confirmation that the INTR2
group and the 0xa000 domain are the same hardware block; the evidence for
that is naming (dispcc's ..._CORE_INT2_BCR, MDSS_INT2_GDSC; MDP TOP's INTR2)
plus structure (same MDSS core, separate BCR/GDSC inside it).

All three Reviewed-by tags are carried over: Abel Vesa, Dmitry Baryshkov, and
Konrad Dybcio (the last one received on v4 3/3).

If the un-attached-domain concern is considered disqualifying, the
alternative is to drop 3/3 and keep only 2/3 -- the array-API change, which is
uncontroversial.  I kept 3/3 because the failing cold boot is reproducible on
this hardware and the group is what tracks with it, but I am happy to send a
v6 without it if that is preferred.

Gates: pristine v7.3-rc7 (24a19b953e) git am 3/3 clean; checkpatch --strict
3/3 at 0 errors, 0 warnings, 0 checks; code and DT diffs are identical to v4,
so v4's dt_binding_check and W=1 results carry over unchanged.

Qianhui Xu (3):
  dt-bindings: display: msm: mdss-common: describe additional block
    resets
  drm/msm/mdss: reset all block resets described in DT
  arm64: dts: qcom: sm8750: describe the second MDSS block reset

 .../devicetree/bindings/display/msm/mdss-common.yaml         | 4 +++-
 .../devicetree/bindings/display/msm/qcom,sm8750-mdss.yaml    | 3 ++-
 arch/arm64/boot/dts/qcom/sm8750.dtsi                         | 3 ++-
 drivers/gpu/drm/msm/msm_mdss.c                               | 5 ++---
 4 files changed, 9 insertions(+), 6 deletions(-)

-- 
2.53.0


^ permalink raw reply	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2026-11-13 16:10 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-13 15:56 [PATCH v5 0/3] drm/msm/mdss: reset all block resets described in DT Qianhui Xu
2026-11-13 15:56 ` [PATCH 1/3] dt-bindings: display: msm: mdss-common: describe additional block resets Qianhui Xu
2026-11-13 16:10   ` sashiko-bot
2026-11-13 15:56 ` [PATCH 2/3] drm/msm/mdss: reset all block resets described in DT Qianhui Xu
2026-11-13 16:08   ` sashiko-bot
2026-11-13 15:56 ` [PATCH 3/3] arm64: dts: qcom: sm8750: describe the second MDSS block reset Qianhui Xu
2026-11-13 16:03   ` sashiko-bot
  -- strict thread matches above, loose matches on Subject: below --
2026-11-13 15:56 [PATCH v5 0/3] drm/msm/mdss: reset all block resets described in DT Qianhui Xu
2026-11-13 15:56 ` [PATCH 3/3] arm64: dts: qcom: sm8750: describe the second MDSS block reset Qianhui Xu
2026-11-13 16:05   ` sashiko-bot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox