Panel initialisation race condition on SDM845

Since ~v6.5 there is a random 60% chance that the display panel will fail to initialise during boot (with FBDEV_EMULATION), instead it will just be a black screen. The issue can be entirely mitigated by introducing some delay (adding console=ttyMSM0,115200 to the kernel cmdline is enough).

It happens on the OnePlus 6 and likely with other devices too. I have been able to reproduce it on upstream 6.5 with a small patch enabling prepare_prev_first in the panel driver.

Poking via modetest or blanking the display do nothing, and there is no additional messages printed via dmesg.

Cc: @lumag

I can confirm this issue. It happens in my Poco F1 (SDM845) too. The workaround suggested by Caleb doesn't consistently work though in my phone. it still fails like half the times.

This sounds awfully similar to what I reported in #42 (comment 2155962), manifesting itself between next-20231006 and next-20231009. On one device the looks like DSC corruption, some others have a black screen most of the time. Strangely SDM845 wasn't affected back then so maybe this is a new/different issue?

Also, if you can, please address the typo in the title (and resulting notifications ).

The console=ttyMSM0,115200 workaround, of course, only works with a sufficiently high loglevel

changed title from Panel initialisation race condtiion on SDM845 to Panel initialisation race condition on SDM845

Something I found out recently on sm6350 is that the mdss_gdsc needs to be off (turned off normally by genpd_power_off_unused) before mdss probe, otherwise the display will be stuck on black. So with DRM_MSM=y it won't really work since genpd_power_off_unused is called too late, but with DRM_MSM=m it seems to be work reliably with my setup.

I didn't figure out yet a better way to solve this, potentially a reset inside dispcc is somewhere that can be used to properly reset it to avoid this race condition there.

So might be something worth checking if also on sdm845 something similar could be the case...

@lucaweiss

There is an optional mdss reset, DISP_CC_MDSS_CORE_BCR see sm8350/sm8450/sm8550. Could you please check if adding it fixed the CONFIG_DRM_MSM=y vs CONFIG_DRM_MSM=m issue for you?

Wonder if there is a DISP_CC_MDSS_CORE_BCR reset in the case of SDM845? I don't find any reference for it downstream. So I guess it's not there?

I think there should be one at 0x2000.

I did a quick testing with the following patch to add the DISP_CC_MDSS_CORE_BCR reset. If i specified it as 0x2000, then the entire device doesn't boot up for most of the time and get's stuck in a black screen. It rarely boots up, but when it does, it works correctly. I also tried specifying 0x1000, 0x3000, 0x4000 , in all 3 cases, it behaved the same way as reported in the MR. So, I think 0x2000 is maybe valid? and there is a bug somewhere else. Sadly, I don't have a device with UART serial debugging enabled. So I couldn't get any logs.

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 1c9d0268128f..5fc154593eb2 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -4458,6 +4458,7 @@ mdss: display-subsystem@ae00000 {
reg-names = "mdss";
power-domains = <&dispcc MDSS_GDSC>;
+			resets = <&dispcc DISP_CC_MDSS_CORE_BCR>;
clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
<&dispcc DISP_CC_MDSS_MDP_CLK>;
diff --git a/drivers/clk/qcom/dispcc-sdm845.c b/drivers/clk/qcom/dispcc-sdm845.c
index 735adfefc379..c900f9497497 100644
--- a/drivers/clk/qcom/dispcc-sdm845.c
+++ b/drivers/clk/qcom/dispcc-sdm845.c
@@ -814,6 +814,7 @@ static struct clk_regmap *disp_cc_sdm845_clocks[] = {
static const struct qcom_reset_map disp_cc_sdm845_resets[] = {
[DISP_CC_MDSS_RSCC_BCR] = { 0x5000 },
+	[DISP_CC_MDSS_CORE_BCR] = { 0x2000 },
};
static struct gdsc *disp_cc_sdm845_gdscs[] = {
diff --git a/include/dt-bindings/clock/qcom,dispcc-sdm845.h b/include/dt-bindings/clock/qcom,dispcc-sdm845.h
index 4016fd1d5b46..f3e088b450ba 100644
--- a/include/dt-bindings/clock/qcom,dispcc-sdm845.h
+++ b/include/dt-bindings/clock/qcom,dispcc-sdm845.h
@@ -49,6 +49,7 @@
/* DISP_CC Reset */
#define DISP_CC_MDSS_RSCC_BCR					0
+#define DISP_CC_MDSS_CORE_BCR					1
/* DISP_CC GDSCR */
#define MDSS_GDSC						0

I tried adding this reset on the OnePlus 6 and it resulted in a crashdump on every single boot.

Assuming that this register isn't protected, my guess would be that doing a proper reset of the mdss block is somehow more involved.

I wonder if perhaps downstream Linux is missing some parts of the hardware init because it relies on the bootloader having done this initialisation beforehand? Like with the "continuous splash" feature.

I tried comparing the output of "debugcc" when the display works vs when it doesn't and there is no difference.

@calebccff would it be possible to compare a devcoredump to see what registers might be changing/missing?

For one active CTL setup isn't complete, but that's only a thing since DPU 5.0 (8150 and above).

Regarding sdm845 MDSS reset: https://git.codelinaro.org/clo/la/kernel/msm-4.9/-/commit/77c171780bd7b82991b2a65bb93e8b3bd14c59a6

@calebccff could you please try removing the dsi->mode_flags |= MIPI_DSI_MODE_LPM from sofef00_panel_on()?