[fairydust] DP Alt Mode: sink's swing/pre-emphasis requests are never applied to atcphy (set_drive_settings only stored; atcphy rejects set_voltages) — M1 Pro + Samsung G95NC trains and modesets but panel stays black

[Isaac-b-ux]

Hardware / software

• Machine: MacBook Pro 14" 2021, M1 Pro — apple,j314s / apple,t6000
• Distro / kernel: Omarchy (Arch Linux ARM), stock linux-asahi 7.1.6 (asahi-7.1.6-1, 16K pages), with the fairydust tipd change applied as an out-of-tree module (details below)
• Cable: Cable Matters USB-C → DisplayPort cable (Realtek billboard 0bda:5452), no hub/dock
• Monitor: Samsung Odyssey G95NC (57", EDID preferred 3840x2160@60 / 5120x1440@60 on DP), DisplayPort input, PBP off
• Same cable + monitor work on this machine under macOS.

Setup notes (so nothing is hidden)

• I could not get a fairydust build (ce9f2eb) to boot on this machine (hung before console; not investigated further), so I ran stock asahi-7.1.6-1 and built drivers/usb/typec/tipd from that tag plus the fairydust cd321x OOB-hotplug change (CD321X_DATA_STATUS_HPD_LEVEL → drm_connector_oob_hotplug_event on the displayport fwnode) as an out-of-tree module. For everything below (dcp.c, dptxep.c, atc.c) stock and fairydust head ce9f2eb are identical.
• The display is on the port the DT calls typec0 (usb-pd@38, 702280000.usb, atcphy0), because I need a USB SSD on the other port. I rebuilt the j314s DTB so dcpext1 points at atcphy0 (apple,dptx-phy = <0>, mux-index = <2>). Everything AP-side works with this wiring, so I don't think the port choice matters for what follows, but flagging it.

Summary

The whole AP-side path completes: OOB HPD → dcp_dptx_connect → AUX/EDID (28 modes) → link config HBR2 (0x14) × 4 lanes → set_digital_out_mode → switch to normal mode succeeded → swaps accepted (no more "swallowed swap"). DP-1 is connected and the compositor renders to it. With the monitor set to DP 1.2 in its OSD the link stays up indefinitely (>20 min, survives repeated modesets).

The monitor never shows a picture: black, backlight off, and its relay clicks each time the source retrains. Same at 2560x1440@60 (depth:10) and 3840x2160@60 (depth:8), and with the USB-C plug flipped 180°.

What the training log shows

Every connect/modeset produces the same four set_drive_settings calls: the sink first gets swing 0 / pre-emphasis 0, then asks for 2 / 2 three times in a row:

2901.977414 apple-dcp 28cc00000.dcp: dcp_dptx_connect(port=0)
2904.099014 apple-dcp 28cc00000.dcp: DPTXPort: acking unhandled call 21
2904.117013 apple-dcp 28cc00000.dcp: set_drive_settings: 4:0:323:0:0:0:0
2904.135034 apple-dcp 28cc00000.dcp: set_drive_settings: 4:0:325:0:2:0:2
2904.154026 apple-dcp 28cc00000.dcp: set_drive_settings: 4:0:327:0:2:0:2
2904.171023 apple-dcp 28cc00000.dcp: set_drive_settings: 4:0:329:0:2:0:2
2904.268018 apple-dcp 28cc00000.dcp: IOMFB: IOAVVideoInterface published
2904.268448 apple-dcp 28cc00000.dcp: display HPD asserted
2904.338064 apple-dcp 28cc00000.dcp: cb_hotplug() connected:1, valid_mode:0
...
3062.253775 apple-dcp 28cc00000.dcp: set_digital_out_mode(color:84 timing:74) "2560x1440": 60 241500 2560 2608 2640 2720 1440 1443 1448 1481 0x40 0x0
3062.254217 apple-dcp 28cc00000.dcp: set_digital_out_mode() color mode depth:10 format:0 colorimetry:16 eotf:0 range:0 vrr:0
3062.469064 apple-dcp 28cc00000.dcp: set_drive_settings: 4:0:343:0:0:0:0
3062.487035 apple-dcp 28cc00000.dcp: set_drive_settings: 4:0:347:0:2:0:2
3062.506349 apple-dcp 28cc00000.dcp: set_drive_settings: 4:0:349:0:2:0:2
3062.524030 apple-dcp 28cc00000.dcp: set_drive_settings: 4:0:351:0:2:0:2
3062.566012 apple-dcp 28cc00000.dcp: UnifiedPipeline::mode_set_gated(uint32_t, uint32_t): 2560x1440@59 Hz link: 1
3062.584032 apple-dcp 28cc00000.dcp: IOMFB: switch to normal mode succeeded
3062.584684 apple-dcp 28cc00000.dcp: set_digital_out_mode finished:8167

(dptxport_call_set_link_rate trace: link rate 0x14; set_active_lane_count 4.)

Why I think the picture is missing

• dptxport_call_set_drive_settings (dptxep.c:210) acks the request and stores unk5/unk7 in dptx->drive_settings[] (dptxep.c:228), but nothing ever pushes them to the PHY.
• atcphy_dpphy_configure (atc.c:2077) returns -EINVAL if opts->set_voltages is set, and I can't find any main-lane swing/pre-emphasis programming in atc.c (only LPDPTX_AUX_MARGIN_RCAL_TXSWING for AUX).
• So the main lanes run at whatever the fixed tunables give, regardless of what the sink asks for. That fits the symptom exactly: AUX works (HPD, EDID, DPCD), the sink repeatedly requests a stronger level, never locks, and stays black — while macOS (which does apply drive settings) drives the same cable and panel fine.

I realise this is probably known internally, but I couldn't find it written down in an issue, and it may explain a share of the "trains fine, no picture" / cable-dependent reports (e.g. #571 is a link-bounce with one adapter and stable with another on the same monitor).

Side observations (same logs)

1. Monitor on DP 1.4: the sink drops HPD 2.01 s after "HPD asserted" — repeatable (3/3), with or without a modeset, at 1440p60 and 4K60. In the captured case below the firmware also raised call 23 (DEVICE_BUSY_TIMEOUT) during the modeset and retrained first. Setting the G95NC to DP 1.2 in its OSD removes the drop entirely. Possibly the same class as [fairydust] M2 Air: DP Alt Mode link repeatedly bounces with VIA Labs hub adapter (PS186); stable with UGREEN CM478 #571.

   1359.462457 display HPD asserted
   1359.625048 set_digital_out_mode(color:94 timing:78) "2560x1440": 60 241500 ...
   1360.331042 DPTXPort: acking unhandled call 23
   1360.362034 set_drive_settings: 4:0:216:0:0:0:0
   1360.381041 set_drive_settings: 4:0:220:0:2:0:2
   1360.400032 set_drive_settings: 4:0:222:0:2:0:2
   1360.418026 set_drive_settings: 4:0:224:0:2:0:2
   1360.476872 set_digital_out_mode finished:7648
   1361.471045 IOMFB: IOAVVideoInterface terminated
   1361.471273 display HPD removed
   

2. Connect ordering: with this sink the firmware only starts link config after dptxport_set_hpd(true), so dcp_dptx_connect always waits the full DPTX_CONNECT_TIMEOUT (2000 ms, dcp.c:358/387) before calling set_hpd (dcp.c:399). Harmless, but every hotplug costs 2 s.
3. WARN_ON_ONCE(atcphy->pipehandler_up) (atc.c:2328) fires from atcphy_mux_set ← typec_set_mode(TYPEC_STATE_SAFE) ← tps6598x_disconnect ← tipd_remove when unloading tipd while a DP-only partner is attached (the pipehandler is still up at that point). Only relevant if you care about module unload.

Happy to help

I can test patches on this hardware (j314s, this cable, this monitor), capture m1n1/hypervisor traces if you tell me what you need, or provide the full previous-boot journalctl -k, EDID, and the type-C sysfs state.