[PATCH v2 0/3] drm/msm/mdss: reset all MDSS block resets described in DT

[PATCH v2 0/3] drm/msm/mdss: reset all MDSS block resets described in DT

[Qianhui Xu]

This is the replacement for the RFC sent on 2026-10-22, which Taniya Das
correctly rejected: the MDSS block resets do not belong to the clock driver,
and resetting the whole block from dispcc probe would also take the PLLs down.

The problem the RFC tried to solve is real.  On a board that enters Linux
with the display block already running, the kernel later sees command DMA
timeouts on the first DPMS enable and the panel never comes up; resetting the
MDSS blocks before touching them fixes it, and it has to happen before the
first commit, not in the middle of one.

This version therefore leaves the clock driver completely alone and moves
the resets to the display side, where they already live:

1/3 describes three block resets on the MDSS node instead of one.  minItems
    is 1, so every existing device tree that describes only the core reset
    keeps validating; the example in the SM8750 binding now shows all three.
2/3 makes msm_mdss_reset() drive the whole array described in DT instead of
    the first reset only.  Platforms with a single reset behave exactly as
    before, which is why this is not gated on any board compatible.
3/3 describes the three resets on the SM8750 MDSS node.

The reset is still held for 20 ms, the value upstream uses today, and the
PLLs are untouched by it, so no flicker from reconfiguring them.

Scope and status, stated plainly: this was built with W=1 and the binding was
validated with dt-doc-validate, dt-validate (both with three resets and with
one, to prove the old shapes still pass) and dt-check-style.  It has *not*
yet been run on hardware, and the ordering is the one point where I would
value review most: in the arm that was measured as good, the reset happened
before the dispcc PLLs were programmed, whereas here it happens after, because
mdss consumes dispcc clocks and must probe later.  I could not find a way to
get the display side to probe earlier without reintroducing the clock-driver
problem, and resetting only the block resets (not the PLLs themselves) is the
part that I believe makes the later point harmless.  If you think that is not
sound, say so and I will drop it rather than argue.

Only SM8750 is changed here; sc7180/sc7280/sc8280xp/sm6350/sm8150 also have an
RSCC reset described in their dtsi, and sm8650 has the same three, but whether
they want the same treatment is for their maintainers to decide.

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 all MDSS block resets

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

-- 
2.53.0

[PATCH v2 1/3] dt-bindings: display: msm: mdss-common: describe additional block resets

[Qianhui Xu]

Some platforms provide more than one reset for the MDSS hardware block:
beside the MDSS core reset, the SM8750 display clock controller also
exposes block resets for the MDSS core INT2 interrupt controller and
for the MDSS RSC (resource state controller).

Allow the resets property to list up to three resets, keeping the MDSS
core reset as the first entry so that existing device trees describing
a single reset remain valid.

Signed-off-by: Qianhui Xu <xiaqinghuan@mail.ustc.edu.cn>
---
 .../devicetree/bindings/display/msm/mdss-common.yaml         | 5 ++++-
 .../devicetree/bindings/display/msm/qcom,sm8750-mdss.yaml    | 4 +++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
index c6305a6e03..7c0ac90511 100644
--- a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
+++ b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
@@ -84,8 +84,11 @@ properties:
           - const: cpu-cfg
 
   resets:
+    minItems: 1
     items:
-      - description: MDSS_CORE reset
+      - description: MDSS core reset
+      - description: MDSS core INT2 interrupt controller reset
+      - description: MDSS RSC (resource state controller) reset
 
   memory-region:
     maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8750-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8750-mdss.yaml
index 46dc0d28da..5408b48135 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm8750-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8750-mdss.yaml
@@ -101,7 +101,9 @@ examples:
             interconnect-names = "mdp0-mem",
                                  "cpu-cfg";
 
-            resets = <&disp_cc_mdss_core_bcr>;
+            resets = <&disp_cc_mdss_core_bcr>,
+                     <&disp_cc_mdss_core_int2_bcr>,
+                     <&disp_cc_mdss_rscc_bcr>;
 
             power-domains = <&mdss_gdsc>;
 
-- 
2.53.0

Re: [PATCH v2 1/3] dt-bindings: display: msm: mdss-common: describe additional block resets

[Konrad Dybcio]

On 10/29/26 1:32 PM, Qianhui Xu wrote:
> Some platforms provide more than one reset for the MDSS hardware block:
> beside the MDSS core reset, the SM8750 display clock controller also
> exposes block resets for the MDSS core INT2 interrupt controller and
> for the MDSS RSC (resource state controller).
> 
> Allow the resets property to list up to three resets, keeping the MDSS
> core reset as the first entry so that existing device trees describing
> a single reset remain valid.
> 
> Signed-off-by: Qianhui Xu <xiaqinghuan@mail.ustc.edu.cn>
> ---
>  .../devicetree/bindings/display/msm/mdss-common.yaml         | 5 ++++-
>  .../devicetree/bindings/display/msm/qcom,sm8750-mdss.yaml    | 4 +++-
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
> index c6305a6e03..7c0ac90511 100644
> --- a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
> @@ -84,8 +84,11 @@ properties:
>            - const: cpu-cfg
>  
>    resets:
> +    minItems: 1
>      items:
> -      - description: MDSS_CORE reset
> +      - description: MDSS core reset
> +      - description: MDSS core INT2 interrupt controller reset
> +      - description: MDSS RSC (resource state controller) reset

MDSS RSC is not part of MDSS itself

Konrad

Re: [PATCH v2 1/3] dt-bindings: display: msm: mdss-common: describe additional block resets

[Qianhui Xu]

Hi Konrad,

One note on how this mail was written, since it matters for how you read
it: I work on this board alone and my English is not good enough to
write upstream mail unaided, so I draft with an AI assistant and edit it
myself. The content, the measurements and every decision in it are mine.

you are right, and I will drop it.

MDSS RSC is not part of the MDSS block: the RSC sits in its own node
(apps_rsc at 0x16500000 on SM8750), and the only reason I pulled
DISP_CC_MDSS_RSCC_BCR into the mdss resets list is that the reset bit
happens to be generated inside dispcc. That is a register-map argument, not
a block-ownership argument, and the block-ownership one is the one that
decides which node owns a reset.

What v3 will look like, so nobody has to guess:

 - mdss-common.yaml: resets keeps "minItems: 1" with two array entries,
   MDSS core and MDSS core INT2. The RSC entry goes away, and the
   commit message says why.
 - qcom,sm8750-mdss.yaml and sm8750.dtsi: resets drops to CORE and
   CORE_INT2.
 - drm/msm/mdss: unchanged, it still drives the whole array from DT.

One thing I would like to flag rather than paper over: the reason RSCC was
in the list at all is empirical. This board is handed over with the display
block running, and on the vendor stack both a warm reset and a cold boot can
end in the same panel-init failure (command DMA timeout, L1/L2 error
counters non-zero). Resetting MDSS core + core INT2 + RSC is what makes the
failure go away on that stack, and I have not yet isolated which of the
three is load-bearing; I have only ever measured them together. So after
dropping RSCC from the binding I will re-measure with CORE + INT2 alone. If
that turns out not to be enough, the RSC reset will be driven from the RSC
device, where you are saying it belongs, and not from mdss - I am not
proposing to add it back here.

Note also that the reset ordering caveat from the cover letter stands
independently of this: mdss consumes dispcc clocks, so dispcc has to have
programmed the PLLs before msm_mdss_reset() runs. I have no measurement for
"block reset after the PLLs are up does not disturb them" beyond the vendor
stack behaviour; that is still the open point, and if you think it should be
answered before this series goes anywhere, say so and I will hold it.

Thanks,
Qianhui Xu

[PATCH v2 2/3] drm/msm/mdss: reset all block resets described in DT

[Qianhui Xu]

msm_mdss_reset() acquires only the first reset listed in the MDSS
device node.  Platforms can describe additional MDSS block resets: the
SM8750 display clock controller provides resets for the MDSS core INT2
interrupt controller and for the MDSS RSC, which can be left out of
reset together with the MDSS core when the bootloader hands over with
the display block still running.

Switch to the reset control array API so that every reset listed in the
device node is asserted and released as one group.  Devices without a
reset in DT are unaffected, and for devices describing a single reset
the assert/deassert sequence is unchanged.

The resets are driven from the display driver rather than from the
display clock controller: the clock controller supplies the MDSS clocks
and power domain, so it probes first and has already programmed its
PLLs when MDSS probes.  The block resets do not touch the PLL registers
and no display pipeline is running yet, so the PLL configuration
survives the reset.

Signed-off-by: Qianhui Xu <xiaqinghuan@mail.ustc.edu.cn>
---
 drivers/gpu/drm/msm/msm_mdss.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 9087c4b290..59343987bc 100644
--- a/drivers/gpu/drm/msm/msm_mdss.c
+++ b/drivers/gpu/drm/msm/msm_mdss.c
@@ -306,11 +306,22 @@ static void msm_mdss_destroy(struct msm_mdss *msm_mdss)
 	irq_set_chained_handler_and_data(irq, NULL, NULL);
 }
 
+/*
+ * The MDSS block resets are driven from the display driver, not from the
+ * display clock controller: the clock controller supplies the MDSS clocks
+ * and power domain, so it probes first and has already programmed its PLLs
+ * when MDSS probes.  The block resets do not touch the PLL registers and no
+ * display pipeline is running yet, so the PLL configuration survives the
+ * reset and nothing visible can glitch.  Bootloaders that hand over with
+ * the display block still running (PLLs locked, blocks out of reset) are
+ * returned to a known-zero state before any display hardware is programmed.
+ */
 static int msm_mdss_reset(struct device *dev)
 {
 	struct reset_control *reset;
 
-	reset = reset_control_get_optional_exclusive(dev, NULL);
+	reset = devm_reset_control_array_get(dev,
+					     RESET_CONTROL_OPTIONAL_EXCLUSIVE);
 	if (!reset) {
 		/* Optional reset not specified */
 		return 0;
@@ -327,8 +338,6 @@ static int msm_mdss_reset(struct device *dev)
 	msleep(20);
 	reset_control_deassert(reset);
 
-	reset_control_put(reset);
-
 	return 0;
 }
 
-- 
2.53.0

[PATCH v2 3/3] arm64: dts: qcom: sm8750: describe all MDSS block resets

[Qianhui Xu]

The SM8750 display clock controller provides, beside the MDSS core
reset, block resets for the MDSS core INT2 interrupt controller and for
the MDSS RSC.  On devices whose bootloader hands over with the display
block still active (PLLs locked, MDSS core / INT2 / RSC out of reset),
the kernel so far reset only the MDSS core and left the INT2 and RSC
blocks in the state left behind by the bootloader; command-mode panel
initialisation then fails with command DMA timeouts and the display
comes up as backlight only, without a DRM device.

Describe all three block resets so that the MDSS reset returns the
whole display subsystem to a known state before any display hardware is
programmed.

The reset runs after the display clock controller has programmed its
PLLs (the clock controller supplies the MDSS clocks and power domain,
so it always probes first).  The block resets do not touch the PLL
registers and no display pipeline is active at this point, so the PLL
configuration survives the reset and nothing visible can glitch.

Signed-off-by: Qianhui Xu <xiaqinghuan@mail.ustc.edu.cn>
---
 arch/arm64/boot/dts/qcom/sm8750.dtsi | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
index dd738d13df..950c528bc4 100644
--- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
@@ -3071,7 +3071,9 @@ mdss: display-subsystem@ae00000 {
 				 <&gcc GCC_DISP_HF_AXI_CLK>,
 				 <&dispcc DISP_CC_MDSS_MDP_CLK>;
 
-			resets = <&dispcc DISP_CC_MDSS_CORE_BCR>;
+			resets = <&dispcc DISP_CC_MDSS_CORE_BCR>,
+				 <&dispcc DISP_CC_MDSS_CORE_INT2_BCR>,
+				 <&dispcc DISP_CC_MDSS_RSCC_BCR>;
 
 			interconnects = <&mmss_noc MASTER_MDP QCOM_ICC_TAG_ALWAYS
 					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
-- 
2.53.0