[PATCH 0/3] arm64: dts: qcom: msm8916/39: Add missing MDSS/SDCC resets

[PATCH 0/3] arm64: dts: qcom: msm8916/39: Add missing MDSS/SDCC resets

[Stephan Gerhold]

Add the missing resets for MDSS and SDCC on MSM8916 and MSM8939 to ensure
that we don't run into issues with the hardware configured by the
bootloader. On v6.17, the MDSS reset is necessary to have working display
when the bootloader has already initialized it for the boot splash screen.
MSM8939 has the SDCC resets specified already, so that commit is omitted.

Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
---
Stephan Gerhold (3):
      arm64: dts: qcom: msm8916: Add missing MDSS reset
      arm64: dts: qcom: msm8939: Add missing MDSS reset
      arm64: dts: qcom: msm8916: Add SDCC resets

 arch/arm64/boot/dts/qcom/msm8916.dtsi | 4 ++++
 arch/arm64/boot/dts/qcom/msm8939.dtsi | 2 ++
 2 files changed, 6 insertions(+)
---
base-commit: 62a9be0b3388d1026117de536f6c81e09ba219fe
change-id: 20250915-msm8916-resets-52f2e52602b7

Best regards,
-- 
Stephan Gerhold <stephan.gerhold@linaro.org>

[PATCH 1/3] arm64: dts: qcom: msm8916: Add missing MDSS reset

[Stephan Gerhold]

On most MSM8916 devices (aside from the DragonBoard 410c), the bootloader
already initializes the display to show the boot splash screen. In this
situation, MDSS is already configured and left running when starting Linux.
To avoid side effects from the bootloader configuration, the MDSS reset can
be specified in the device tree to start again with a clean hardware state.

The reset for MDSS is currently missing in msm8916.dtsi, which causes
errors when the MDSS driver tries to re-initialize the registers:

 dsi_err_worker: status=6
 dsi_err_worker: status=6
 dsi_err_worker: status=6
 ...

It turns out that we have always indirectly worked around this by building
the MDSS driver as a module. Before v6.17, the power domain was temporarily
turned off until the module was loaded, long enough to clear the register
contents. In v6.17, power domains are not turned off during boot until
sync_state() happens, so this is no longer working. Even before v6.17 this
resulted in broken behavior, but notably only when the MDSS driver was
built-in instead of a module.

Cc: stable@vger.kernel.org
Fixes: 305410ffd1b2 ("arm64: dts: msm8916: Add display support")
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index b50c7e6e0bfcd35ab4f8b84aeabe214fd60e8d7c..de0c10b54c86c7795b7a0d1ecd80652e60e117b6 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -1562,6 +1562,8 @@ mdss: display-subsystem@1a00000 {
 
 			interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
 
+			resets = <&gcc GCC_MDSS_BCR>;
+
 			interrupt-controller;
 			#interrupt-cells = <1>;
 

-- 
2.50.1

[PATCH 2/3] arm64: dts: qcom: msm8939: Add missing MDSS reset

[Stephan Gerhold]

On most MSM8939 devices, the bootloader already initializes the display to
show the boot splash screen. In this situation, MDSS is already configured
and left running when starting Linux. To avoid side effects from the
bootloader configuration, the MDSS reset can be specified in the device
tree to start again with a clean hardware state.

The reset for MDSS is currently missing in msm8939.dtsi, which causes
errors when the MDSS driver tries to re-initialize the registers:

 dsi_err_worker: status=6
 dsi_err_worker: status=6
 dsi_err_worker: status=6
 ...

It turns out that we have always indirectly worked around this by building
the MDSS driver as a module. Before v6.17, the power domain was temporarily
turned off until the module was loaded, long enough to clear the register
contents. In v6.17, power domains are not turned off during boot until
sync_state() happens, so this is no longer working. Even before v6.17 this
resulted in broken behavior, but notably only when the MDSS driver was
built-in instead of a module.

Cc: stable@vger.kernel.org
Fixes: 61550c6c156c ("arm64: dts: qcom: Add msm8939 SoC")
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8939.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8939.dtsi b/arch/arm64/boot/dts/qcom/msm8939.dtsi
index 68b92fdb996c26e7a1aadedf0f52e1afca85c4ab..eb64ec35e7f0e1c63b0b96f68d30006c2e440998 100644
--- a/arch/arm64/boot/dts/qcom/msm8939.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8939.dtsi
@@ -1249,6 +1249,8 @@ mdss: display-subsystem@1a00000 {
 
 			power-domains = <&gcc MDSS_GDSC>;
 
+			resets = <&gcc GCC_MDSS_BCR>;
+
 			#address-cells = <1>;
 			#size-cells = <1>;
 			#interrupt-cells = <1>;

-- 
2.50.1

[PATCH 3/3] arm64: dts: qcom: msm8916: Add SDCC resets

[Stephan Gerhold]

Add the missing resets for the two SDCC controllers to allow fully
resetting previous hardware state from the bootloader.

Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
---
Unlike the previous two commits with the MDSS resets, this is more
"cleanup" than "fix", so I omitted the Fixes tag and Cc stable here.
There are no reported issues with the reset omitted.
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index de0c10b54c86c7795b7a0d1ecd80652e60e117b6..d3a25a837488c940f7f9dd08d0aa4054aeed014c 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -2127,6 +2127,7 @@ sdhc_1: mmc@7824900 {
 				 <&gcc GCC_SDCC1_APPS_CLK>,
 				 <&xo_board>;
 			clock-names = "iface", "core", "xo";
+			resets = <&gcc GCC_SDCC1_BCR>;
 			pinctrl-0 = <&sdc1_default>;
 			pinctrl-1 = <&sdc1_sleep>;
 			pinctrl-names = "default", "sleep";
@@ -2148,6 +2149,7 @@ sdhc_2: mmc@7864900 {
 				 <&gcc GCC_SDCC2_APPS_CLK>,
 				 <&xo_board>;
 			clock-names = "iface", "core", "xo";
+			resets = <&gcc GCC_SDCC2_BCR>;
 			pinctrl-0 = <&sdc2_default>;
 			pinctrl-1 = <&sdc2_sleep>;
 			pinctrl-names = "default", "sleep";

-- 
2.50.1

Re: [PATCH 1/3] arm64: dts: qcom: msm8916: Add missing MDSS reset

[Konrad Dybcio]

On 9/15/25 3:28 PM, Stephan Gerhold wrote:
> On most MSM8916 devices (aside from the DragonBoard 410c), the bootloader
> already initializes the display to show the boot splash screen. In this
> situation, MDSS is already configured and left running when starting Linux.
> To avoid side effects from the bootloader configuration, the MDSS reset can
> be specified in the device tree to start again with a clean hardware state.

This is really just Linux behavior and not necessarily the effect
of specifying the reset in the DT, but w/e
> 
> The reset for MDSS is currently missing in msm8916.dtsi, which causes
> errors when the MDSS driver tries to re-initialize the registers:
> 
>  dsi_err_worker: status=6
>  dsi_err_worker: status=6
>  dsi_err_worker: status=6
>  ...
> 
> It turns out that we have always indirectly worked around this by building
> the MDSS driver as a module. Before v6.17, the power domain was temporarily
> turned off until the module was loaded, long enough to clear the register
> contents. In v6.17, power domains are not turned off during boot until
> sync_state() happens, so this is no longer working. Even before v6.17 this
> resulted in broken behavior, but notably only when the MDSS driver was
> built-in instead of a module.
> 
> Cc: stable@vger.kernel.org
> Fixes: 305410ffd1b2 ("arm64: dts: msm8916: Add display support")
> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH 2/3] arm64: dts: qcom: msm8939: Add missing MDSS reset

[Konrad Dybcio]

On 9/15/25 3:28 PM, Stephan Gerhold wrote:
> On most MSM8939 devices, the bootloader already initializes the display to
> show the boot splash screen. In this situation, MDSS is already configured
> and left running when starting Linux. To avoid side effects from the
> bootloader configuration, the MDSS reset can be specified in the device
> tree to start again with a clean hardware state.
> 
> The reset for MDSS is currently missing in msm8939.dtsi, which causes
> errors when the MDSS driver tries to re-initialize the registers:
> 
>  dsi_err_worker: status=6
>  dsi_err_worker: status=6
>  dsi_err_worker: status=6
>  ...
> 
> It turns out that we have always indirectly worked around this by building
> the MDSS driver as a module. Before v6.17, the power domain was temporarily
> turned off until the module was loaded, long enough to clear the register
> contents. In v6.17, power domains are not turned off during boot until
> sync_state() happens, so this is no longer working. Even before v6.17 this
> resulted in broken behavior, but notably only when the MDSS driver was
> built-in instead of a module.
> 
> Cc: stable@vger.kernel.org
> Fixes: 61550c6c156c ("arm64: dts: qcom: Add msm8939 SoC")
> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH 3/3] arm64: dts: qcom: msm8916: Add SDCC resets

[Konrad Dybcio]

On 9/15/25 3:28 PM, Stephan Gerhold wrote:
> Add the missing resets for the two SDCC controllers to allow fully
> resetting previous hardware state from the bootloader.
> 
> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH 1/3] arm64: dts: qcom: msm8916: Add missing MDSS reset

[Dmitry Baryshkov]

On Mon, Sep 15, 2025 at 03:28:30PM +0200, Stephan Gerhold wrote:
> On most MSM8916 devices (aside from the DragonBoard 410c), the bootloader
> already initializes the display to show the boot splash screen. In this
> situation, MDSS is already configured and left running when starting Linux.
> To avoid side effects from the bootloader configuration, the MDSS reset can
> be specified in the device tree to start again with a clean hardware state.
> 
> The reset for MDSS is currently missing in msm8916.dtsi, which causes
> errors when the MDSS driver tries to re-initialize the registers:
> 
>  dsi_err_worker: status=6
>  dsi_err_worker: status=6
>  dsi_err_worker: status=6
>  ...
> 
> It turns out that we have always indirectly worked around this by building
> the MDSS driver as a module. Before v6.17, the power domain was temporarily
> turned off until the module was loaded, long enough to clear the register
> contents. In v6.17, power domains are not turned off during boot until
> sync_state() happens, so this is no longer working. Even before v6.17 this
> resulted in broken behavior, but notably only when the MDSS driver was
> built-in instead of a module.
> 
> Cc: stable@vger.kernel.org
> Fixes: 305410ffd1b2 ("arm64: dts: msm8916: Add display support")
> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
> ---
>  arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 ++
>  1 file changed, 2 insertions(+)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

Re: [PATCH 2/3] arm64: dts: qcom: msm8939: Add missing MDSS reset

[Dmitry Baryshkov]

On Mon, Sep 15, 2025 at 03:28:31PM +0200, Stephan Gerhold wrote:
> On most MSM8939 devices, the bootloader already initializes the display to
> show the boot splash screen. In this situation, MDSS is already configured
> and left running when starting Linux. To avoid side effects from the
> bootloader configuration, the MDSS reset can be specified in the device
> tree to start again with a clean hardware state.
> 
> The reset for MDSS is currently missing in msm8939.dtsi, which causes
> errors when the MDSS driver tries to re-initialize the registers:
> 
>  dsi_err_worker: status=6
>  dsi_err_worker: status=6
>  dsi_err_worker: status=6
>  ...
> 
> It turns out that we have always indirectly worked around this by building
> the MDSS driver as a module. Before v6.17, the power domain was temporarily
> turned off until the module was loaded, long enough to clear the register
> contents. In v6.17, power domains are not turned off during boot until
> sync_state() happens, so this is no longer working. Even before v6.17 this
> resulted in broken behavior, but notably only when the MDSS driver was
> built-in instead of a module.
> 
> Cc: stable@vger.kernel.org
> Fixes: 61550c6c156c ("arm64: dts: qcom: Add msm8939 SoC")
> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
> ---
>  arch/arm64/boot/dts/qcom/msm8939.dtsi | 2 ++
>  1 file changed, 2 insertions(+)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

Re: [PATCH 0/3] arm64: dts: qcom: msm8916/39: Add missing MDSS/SDCC resets

[Bjorn Andersson]

On Mon, 15 Sep 2025 15:28:29 +0200, Stephan Gerhold wrote:
> Add the missing resets for MDSS and SDCC on MSM8916 and MSM8939 to ensure
> that we don't run into issues with the hardware configured by the
> bootloader. On v6.17, the MDSS reset is necessary to have working display
> when the bootloader has already initialized it for the boot splash screen.
> MSM8939 has the SDCC resets specified already, so that commit is omitted.
> 
> 
> [...]

Applied, thanks!

[1/3] arm64: dts: qcom: msm8916: Add missing MDSS reset
      commit: 99b78773c2ae55dcc01025f94eae8ce9700ae985
[2/3] arm64: dts: qcom: msm8939: Add missing MDSS reset
      commit: f73c82c855e186e9b67125e3eee743960320e43c
[3/3] arm64: dts: qcom: msm8916: Add SDCC resets
      commit: 456dcaf570043e60978352da9b2a55d067fd290b

Best regards,
-- 
Bjorn Andersson <andersson@kernel.org>

Re: [PATCH 1/3] arm64: dts: qcom: msm8916: Add missing MDSS reset

[Luca Weiss]

Hi Stephan,

On Mon Sep 15, 2025 at 3:28 PM CEST, Stephan Gerhold wrote:
> On most MSM8916 devices (aside from the DragonBoard 410c), the bootloader
> already initializes the display to show the boot splash screen. In this
> situation, MDSS is already configured and left running when starting Linux.
> To avoid side effects from the bootloader configuration, the MDSS reset can
> be specified in the device tree to start again with a clean hardware state.
>
> The reset for MDSS is currently missing in msm8916.dtsi, which causes
> errors when the MDSS driver tries to re-initialize the registers:
>
>  dsi_err_worker: status=6
>  dsi_err_worker: status=6
>  dsi_err_worker: status=6
>  ...
>
> It turns out that we have always indirectly worked around this by building
> the MDSS driver as a module. Before v6.17, the power domain was temporarily
> turned off until the module was loaded, long enough to clear the register
> contents. In v6.17, power domains are not turned off during boot until
> sync_state() happens, so this is no longer working. Even before v6.17 this
> resulted in broken behavior, but notably only when the MDSS driver was
> built-in instead of a module.

Do you have a link to the patch that causes this behavior? I've tried
looking through the git log for drivers/gpu/drm/msm/ but couldn't find
anything that looks relevant.

FWIW a similar change to this was also necessary for sc7280 (as done by
Bjorn) and for sm6350 (will send the patches very soon).

And happily enough for me, with v6.17 and that reset, a long-standing
issue on sm7225-fairphone-fp4 has been resolved that the display init
seems to somehow fail the first time after bootup, with the screen
needing to be turned off once and back on to work. I traced this back
to some power domain behavior as well back then.

> "mdss_gdsc needs to be off before mdss/dpu probe, this can happen with
> genpd_power_off_unused but not guaranteed"

Anyways, I'm hoping this is not just a coincidence it works now but
will stay working on my device. Just the reset in the past didn't seem
to affect anything.

Regards
Luca

>
> Cc: stable@vger.kernel.org
> Fixes: 305410ffd1b2 ("arm64: dts: msm8916: Add display support")
> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
> ---
>  arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index b50c7e6e0bfcd35ab4f8b84aeabe214fd60e8d7c..de0c10b54c86c7795b7a0d1ecd80652e60e117b6 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -1562,6 +1562,8 @@ mdss: display-subsystem@1a00000 {
>  
>  			interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
>  
> +			resets = <&gcc GCC_MDSS_BCR>;
> +
>  			interrupt-controller;
>  			#interrupt-cells = <1>;
>  

Re: [PATCH 1/3] arm64: dts: qcom: msm8916: Add missing MDSS reset

[Stephan Gerhold]

On Fri, Sep 19, 2025 at 11:49:20AM +0200, Luca Weiss wrote:
> On Mon Sep 15, 2025 at 3:28 PM CEST, Stephan Gerhold wrote:
> > On most MSM8916 devices (aside from the DragonBoard 410c), the bootloader
> > already initializes the display to show the boot splash screen. In this
> > situation, MDSS is already configured and left running when starting Linux.
> > To avoid side effects from the bootloader configuration, the MDSS reset can
> > be specified in the device tree to start again with a clean hardware state.
> >
> > The reset for MDSS is currently missing in msm8916.dtsi, which causes
> > errors when the MDSS driver tries to re-initialize the registers:
> >
> >  dsi_err_worker: status=6
> >  dsi_err_worker: status=6
> >  dsi_err_worker: status=6
> >  ...
> >
> > It turns out that we have always indirectly worked around this by building
> > the MDSS driver as a module. Before v6.17, the power domain was temporarily
> > turned off until the module was loaded, long enough to clear the register
> > contents. In v6.17, power domains are not turned off during boot until
> > sync_state() happens, so this is no longer working. Even before v6.17 this
> > resulted in broken behavior, but notably only when the MDSS driver was
> > built-in instead of a module.
> 
> Do you have a link to the patch that causes this behavior? I've tried
> looking through the git log for drivers/gpu/drm/msm/ but couldn't find
> anything that looks relevant.

It's not a drm/msm change, the change was done in the pmdomain core:
https://lore.kernel.org/r/20250701114733.636510-1-ulf.hansson@linaro.org/

> 
> FWIW a similar change to this was also necessary for sc7280 (as done by
> Bjorn) and for sm6350 (will send the patches very soon).
> 
> And happily enough for me, with v6.17 and that reset, a long-standing
> issue on sm7225-fairphone-fp4 has been resolved that the display init
> seems to somehow fail the first time after bootup, with the screen
> needing to be turned off once and back on to work. I traced this back
> to some power domain behavior as well back then.
> 
> > "mdss_gdsc needs to be off before mdss/dpu probe, this can happen with
> > genpd_power_off_unused but not guaranteed"
> 
> Anyways, I'm hoping this is not just a coincidence it works now but
> will stay working on my device. Just the reset in the past didn't seem
> to affect anything.

You might have had multiple different problems in the past. Perhaps
keeping on the power domain during boot actually helps ensure a clean
shutdown of the MDSS/DPU and then the reset is enough to bring it into a
clean state for the new configuration. But that's just guessing.

Thanks,
Stephan