Display panel does not work occasionally

[cinit]

The SPX SQ1 display panel could not work correctly after a reboot.
The display never shows back up again during system startup when switching from the efi framebuffer to drm/msm after a reboot.

This only happens after a reboot. For a cold startup, the display panel works well in msm drm mode.

Tested on the latest kernel Linux 6.15.3-1-surface+.

After a reboot, the panel-simple-dp-aux complains about failing to read EDID of the display panel in dmesg:

[    9.213236] panel-simple-dp-aux aux-ae9a000.displayport-controller: Couldn't read EDID for ID; using conservative timings
[    9.216775] msm_dpu ae01000.mdp: bound ae9a000.displayport-controller (ops msm_dp_display_comp_ops [msm])
...
[    9.731211] panel-simple-dp-aux aux-ae9a000.displayport-controller: No display modes
[    9.797642] [drm:msm_dp_panel_read_sink_caps [msm]] *ERROR* panel edid read failed

For a cold startup, the panel-simple-dp-aux is able to detect the EDID correctly:

[    9.098128] panel-simple-dp-aux aux-ae9a000.displayport-controller: Detected LGD LP129WT112684 (0x0555)
[    9.099579] msm_dpu ae01000.mdp: bound ae9a000.displayport-controller (ops msm_dp_display_comp_ops [msm])

The dmesg of a cold boot: 20250705-dmesg-cold-startup-1.txt

The dmesg after a reboot: 20250705-dmesg-after-reboot-1.txt

[cinit]

Update: just find something more weird.
If I add "loglevel=8" to the kernel cmdline, the eDP panel is more likely[^1] to work (after a reboot).
If I use any other loglevel (e.g. 3 or 7), the panel-simple-dp-aux driver fails to read the EDID (after a reboot).
The kernel is compiled with CONFIG_DYNAMIC_DEBUG=y.

^1: sometimes eDP fails with max v_level reached, link training #1 failed.

[    7.066072] panel-simple-dp-aux aux-ae9a000.displayport-controller: Detected LGD LP129WT112684 (0x0555)
[    7.070776] msm_dpu ae01000.mdp: bound ae9a000.displayport-controller (ops msm_dp_display_comp_ops [msm])
[    7.075468] adreno 2c00000.gpu: supply vdd not found, using dummy regulator
[    7.076169] adreno 2c00000.gpu: supply vddcx not found, using dummy regulator
[    7.079208] msm_dpu ae01000.mdp: bound 2c00000.gpu (ops a3xx_ops [msm])
[    7.081156] Console: switching to colour dummy device 80x25
[    7.081445] [drm:dpu_kms_hw_init:1173] dpu hardware revision:0x50010001
[    7.083856] [drm] Initialized msm 1.12.0 for ae01000.mdp on minor 0
[    7.084319] msm_dpu ae01000.mdp: [drm:adreno_request_fw [msm]] loaded qcom/a680_sqe.fw from new location
[    7.084996] msm_dpu ae01000.mdp: [drm:adreno_request_fw [msm]] loaded qcom/a680_gmu.bin from new location
[    7.086803] [drm] Loaded GMU firmware v2.2.264
[    7.299103] Bluetooth: hci0: QCA Downloading qca/crnv01.bin
[    7.368636] remoteproc remoteproc0: remote processor modem is now up
[    7.414348] tun: Universal TUN/TAP device driver, 1.6
[    7.440145] Bluetooth: hci0: QCA setup on UART is completed
[    7.441311] [drm:msm_dp_ctrl_link_train [msm]] *ERROR* max v_level reached
[    7.441429] [drm:msm_dp_ctrl_link_train [msm]] *ERROR* link training #1 failed. ret=-11
[    7.463128] [drm:msm_dp_aux_isr [msm]] *ERROR* Unexpected DP AUX IRQ 0x01000000 when not busy
[    7.463282] [drm:msm_dp_aux_isr [msm]] *ERROR* Unexpected DP AUX IRQ 0x01000000 when not busy

[cinit]

Update:
If I comment out the GPIO 130 in the DTS, the problem appears to be gone, no more occasional panel disfunction, no more screen tear when switching from framebuffer mode to msm drm mode during boot.
Since GPIO 130 is SOC_VDD_PANEL_EN, I guess that the problem may be caused by an unexpected transient loss of power of the display panel when switching from framebuffer mode to msm drm mode.

diff --git a/arch/arm64/boot/dts/qcom/sc8180x-surface-pro-x.dts b/arch/arm64/boot/dts/qcom/sc818
0x-surface-pro-x.dts
index f615edc5ffcf..1d6ba41f563c 100644
--- a/arch/arm64/boot/dts/qcom/sc8180x-surface-pro-x.dts
+++ b/arch/arm64/boot/dts/qcom/sc8180x-surface-pro-x.dts
@@ -943,10 +943,10 @@ panel {
                        compatible = "edp-panel";
                        no-hpd;
 
-                       enable-gpios = <&tlmm 130 GPIO_ACTIVE_HIGH>;
+                       //enable-gpios = <&tlmm 130 GPIO_ACTIVE_HIGH>;
 
-                       pinctrl-names = "default";
-                       pinctrl-0 = <&panel_vdd_en_default_state>;
+                       //pinctrl-names = "default";
+                       //pinctrl-0 = <&panel_vdd_en_default_state>;
 
                        backlight = <&backlight>;
 

[qzed]

I'm wondering what kind of effect this has on power consumption during suspend. Without the enable GPIO, the panel would probably be on all the time. So I think ideally we find some different way to fix this.

[valpackett]

Just got my SPX, debugging all the things… This seems to be caused by:

------------[ cut here ]------------
mdss_gdsc status stuck at 'off'
WARNING: drivers/clk/qcom/gdsc.c:178 at gdsc_toggle_logic+0x140/0x160, CPU#3: (udev-worker)/559
Modules linked in: panel_edp(+) spi_hid_of qrtr surface_aggregator_registry ecdh_generic spi_hid ecc qcom_q6v5_pas rfkill qcom_pil_info crc16 surface_aggregator qcom_q6v5 leds_qcom_lpg qco>
CPU: 3 UID: 0 PID: 559 Comm: (udev-worker) Not tainted 7.0.0-rc2-next-20260302-00105-g44b717cc8d06-dirty #40 PREEMPT(full)
Hardware name: Microsoft Corporation Surface Pro X/Surface Pro X, BIOS 11.258.140 12/16/2024
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : gdsc_toggle_logic+0x140/0x160
lr : gdsc_toggle_logic+0x140/0x160
sp : ffff8000843535b0
[…]
Call trace:
 gdsc_toggle_logic+0x140/0x160 (P)
 gdsc_enable+0x68/0x290
 _genpd_power_on+0xa0/0x1b8
 genpd_power_on+0xdc/0x210
 genpd_runtime_resume+0xc8/0x2b8
 __rpm_callback+0x50/0x220
 rpm_callback+0x7c/0x90
 rpm_resume+0x554/0x750
 rpm_resume+0x294/0x750
 __pm_runtime_resume+0x60/0xd0
 __driver_probe_device+0x68/0x170
 driver_probe_device+0x48/0x130
 __driver_attach+0x10c/0x260
 bus_for_each_dev+0x84/0xf0
 driver_attach+0x2c/0x40
 bus_add_driver+0x124/0x258
 driver_register+0x70/0x138
 __dp_aux_dp_driver_register+0x28/0x40 [drm_dp_aux_bus]
 panel_edp_init+0x48/0xff8 [panel_edp]

Something something shared rcg…? That code has long been merged and the same mdss clocks that use shared_ops in sc7180 do so in sm8250— exceeeept for the vsync one actually, let's see if that helps