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

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>;
>  

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

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

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