Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Phase 3: external DP over Type-C works (2026-11-03)

Attempt 2026-11-03-6. Image 713bf8d219796e5b, kernel #6 (2026-11-03 2:23 PM ET, unchanged from attempt -5), commits 91c5aa6, 2cda0fd. Sources: the netlog dumps/firstboot/2026-11-03-netlog.txt and the AP console log dumps/firstboot/2026-11-03-ap.log (both gitignored), plus the owner looking at the monitor.

Why

In attempt 2026-11-03-5 the DP chain had already bound: msm_dpu bound all three DP controllers (ae90000, ae98000, aea0000), card2-DP-1 and card2-DP-2 existed, and the aux_bridge … failed to acquire drm_bridge error from usb-2026-11-02.md was gone. Both DP connectors read disconnected because nothing was plugged in. The kernel already builds in every link of the path (a804c57 .config):

  • QCOM_PMIC_GLINK=y, which builds pmic_glink_altmode.o (drivers/soc/qcom/Makefile:14)
  • TYPEC_MUX_PS883X=y (retimers), PHY_QCOM_QMP_COMBO=y, DRM_AUX_HPD_BRIDGE=y

pmic_glink_altmode.c sets the mux and retimer (typec_mux_set, typec_retimer_set) and reports HPD through drm_aux_hpd_bridge_notify (lines 196-377), so TYPEC_DP_ALTMODE=m plays no part. The DTS already matched the 9345: link-frequencies on mdss_dp0_out/dp1_out as in x1e80100-dell-xps13-9345.dts:891, :899, and data-lanes = <0 1 2 3> from hamoa.dtsi:5714, :5803. The test needed only a sink and a capture.

Changes

  • /init (91c5aa6, 2cda0fd): after the eDP block, it polls card*-DP-*/status for up to 60 s. At 10 s with nothing connected, it prints plug in (or replug) the monitor now on the panel. Then it reports each DP connector with its modes and EDID identity (the existing edid_id), the Type-C altmodes and a dp-dmesg capture.
  • attempt.sh watch (d63d869) shows those lines.
  • No kernel, DTS or firmware change.

Setup

The SuzyQ stayed in the left port. The boot stick went in the right port as usual. The initramfs runs from RAM, so at the prompt the owner pulled the stick (usb 4-1: USB disconnect at 66.8 s) and plugged a USB-C monitor into the right port.

Result: pass

  • DP connected: dp-wait=25s, then dp-conn=card2-DP-2 status=connected enabled=enabled modes=1920x720 1920x540 1280x720 1280x720 1280x720.
  • Monitor identity: dp-id=card2-DP-2 mfr=BSL product=9826 name="K3". Its USB side names itself ROYUAN K3 and BJYP-K3, with keyboard and mouse HID interfaces behind a USB hub.
  • The owner saw the console text on the monitor.
  • USB through the same port: the monitor’s hub enumerated at 70.3 s on a800000.usb (usb_1_ss1), at high speed on bus 3 and SuperSpeed on bus 4, so DP and USB 3 run together on the port (inference: 2-lane DP).
  • Altmodes: typec-altmode=port0.0 svid=ff01 mode=1 active=yes and port1.0 svid=ff01 mode=1 active=yes (the ports’ own DP altmodes; the partner directories stay empty, as ucsi_glink leaves partner fields blank).
  • Everything else unchanged from attempt -5: eDP-1 at 2560x1600, backlight 2048/4095, GPU firmware and GMU loaded (Loaded GMU firmware v4.3.17), Wi-Fi on 6 GHz with a DHCP lease and netlog sent.
  • Shutdown: reboot: Restarting system at 146.5 s (about 3:21 PM ET). The stick was already out, so stock booted.
  • Deferred at the end: only arm-scmi (mailbox 17430000).

Which port is which

Three readings put the 9345’s side labels the other way round on mica:

  1. SuzyQ, left port: typec port0 sinks power (source [sink]), as in every earlier boot.
  2. Stick, right port: typec port1 sources power, and in usb-2026-11-02.md the stick enumerated on usb_1_ss1.
  3. Monitor, right port: it came up as DP-2, its USB on a800000.usb (usb_1_ss1).

Inference: typec portN is pmic-glink connector@N, and DP-2 is mdss_dp1 (the second DP connector registered). So connector@0 (retimer on i2c3, usb_1_ss0, mdss_dp0) is the left port and connector@1 (i2c7, usb_1_ss1, mdss_dp1) the right one. DP working on the right port supports this directly: pmic_glink_altmode indexes its ports by each connector’s reg (pmic_glink_altmode.c:597, :615), so it programmed the connector@1 chain (i2c7 retimer, usb_1_ss1 PHY) for the right port. Had the index pointed at connector@0, the i2c3 retimer would have been set and mdss_dp1 would not have linked (inference from the code path, not traced per message). The DTS comments now say so (dts/x1e80100-google-mica.dts); the DTB itself is unchanged.

qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with supplier 5-0008 for /pmic-glink/connector@1 appears on every boot. At a804c57:

  • 0x180 is DL_FLAG_SYNC_STATE_ONLY | DL_FLAG_INFERRED (include/linux/device.h:444-445). fw_devlink makes the link from fw_devlink_create_devlink() (drivers/base/core.c:2219-2245).
  • A sync-state-only link only orders sync_state() callbacks. device_link_add() returns NULL for one if the supplier is not yet registered with PM, or if the consumer has already probed.

Inference, not traced further: the i2c7 retimer registered after pmic-glink had probed. Either way, DP and SuperSpeed both work on connector@1, so the warning blocks nothing.

Next

  • Test the left port (connector@0, mdss_dp0), which needs the SuzyQ out, so netlog only.
  • A panel-edp entry for LGD 0x0804. CDSP. The SCMI mailbox.