Thank you for the USB4 display and sleep work

[nekolyanich]

Hi all,

I just wanted to say thank you. I spent this week reverse-engineering DisplayPort over USB4 on my MacBook Pro 16" M2 Pro (j416s, t6020) under NixOS, and every time I hit a dead end, it turned out you already had the answer in aurora-silicon/linux.

My setup: the laptop runs NixOS on Asahi, with a Dell U2725QE on Thunderbolt as the main monitor. For the hard parts I used an m1n1 hypervisor bench: a second Linux laptop on the USB-C debug port, tracing macOS 13 and Linux on the same hardware side by side. It went from a dark monitor at the start of the week to daily use: mode switches with DSC up to 4K@120, every USB-C port,
two displays, the monitor's hub and Ethernet, and suspend and resume with the monitor attached. Sound over DisplayPort and HDMI is what I'm on now: it plays on both the monitor and an HDMI TV, and I'm chasing the TV's remaining connect quirks against macOS traces.

In particular:

• Christian Bartels (@cb2206), for the Thunderbolt display work in Thunderbolt display on M1 Pro/Max (t600x), stacked on #8 #64. The DP tunnel pixel clock in the ATC PHY was the piece I had been missing for days. Once I had it, my Dell lit up at 4K@120 with DSC. And for drm/apple: audio: open the DCP PCM without a sink, and release data_lock on a DMA error #169, the PCM that opens without a sink.
• Chris Kearney (@iconidentify), for keeping the routers awake through suspend-to-idle, keeping tunnels up across sleep, and releasing the host DP state before the adapter teardown. Those changes are the core of how my machine now sleeps and wakes with a USB4 monitor attached. Also for the DCP audio and AFK fixes.
• @DjDeveloperr, for keeping a connected dwc3 and the ACIO power domains out of system sleep, for re-arming the display route for a new DP tunnel, and for the live USB3 bandwidth accounting.
• Oliver Lukschander (@oegv), for reusing torn-down AFK service slots, which I picked up while chasing DCP replugs.

I'm on a different base (the Asahi fairydust branch with a backport of the USB4 series), so I ported the ideas rather than the code. Your commit messages explain the hardware behaviour really well, and that helped as much as the code.

The one regret: we were clearly working on the same things at the same time. While #8 was coming together, I was trying on my own to get a picture onto my Thunderbolt monitor, and on the audio side I fixed the reply buffer leak and the PCM open without a sink for PipeWire's probe, only to find #169 and Chris's fixes already in aurora-wip. A few times I meant to send you what I
had, but I couldn't test it on your tree: aurora-wip with my bench config waits forever in deferred_probe_initcall under the m1n1 hypervisor, and by the time I'd have got past that, you had got there yourselves. How do you split the work between you, and where would be the right place to say what I'm on, so that next time I pick up where you are instead of next to you? I'd
rather keep it on GitHub: is a thread here or a draft PR the right place?

My tree is at https://github.com/nekolyanich/linux/tree/tanabota/j416s-dp, in case any of it is useful: fairydust with the USB4 backport, DP tunnels, and the DCP audio work in progress (HACK commits included, so read it as a lab notebook rather than a PR).

Thank you so much, and good luck with everything you're bringing up!

nekolyanich

(I used an LLM assistant, Claude, for this work and for this note.)

[nekolyanich]

Quick follow-up: the deferred_probe_initcall hang I mentioned was my bench, not your tree. m1n1 keeps atc0 for the hypervisor's USB link, and your DT routes the DCPs through that port. With atc0 left out of the DCP routes (a bench-only DT change), aurora-wip boots fine under the m1n1 hypervisor, and that's how I tested #276.