Let's talk about one reason why Asahi Linux doesn't have DisplayPort Alt Mode support yet.

I just spent the past 2 days trying to get the Apple Type-C PHY to work properly in the various alternate modes, including DisplayPort and USB3 host and device.

It's a painful mess. If you touch one part of the code, another part of the code breaks.

Here's the thing: Linux likes to abstract out hardware interfaces. Sometimes this works well, with stuff like I²C and SPI controllers.

Sometimes this doesn't work well, like the Linux mailbox subsystem, which is a poor excuse for abstracting out the concept of a hardware mailbox. Hardware mailboxes are not standards like I²C and SPI, it's a vague concept of similarly-designed hardware. There is no "cross-compatibility" between mailbox "controllers" and consumers. The subsystem exists only because someone decided to abstract out some common code (like queuing and polling/waiting for completion), but got the approach all wrong. When you want to abstract out common code, you want to do it as pluggable functions. The DRM subsystem does this well with its multiple components. What mailbox did is try to define a common interface around the hardware, abstracting out all possible variations through one common interface. That doesn't work.

We tried using mailbox for Asahi Linux, and after a bunch of time wasted in attempts to hack on the code and mailing list reviews, we gave up. I made the executive decision to drop mailbox. We now have an internal interface for Apple mailboxes, which only have Apple-specific consumer drivers anyway. It works much better, is overall less code than trying to work around the impedance mismatches of the mailbox subsystem, is more maintainable, and won't break when someone else touches the common code.

The story now repeats, but it's much, much worse. The players are the Linux Type-C subsystem, the PHY subsystem, DRM, USB, and more. This time there are actually semi-common drivers like dwc3 (the driver for the DesignWare USB3 host/device controller that Apple licensed) and tipd (the driver for the Texas Instruments Type-C port controller that Apple modified and commissioned a variant of), plus our own display/DCP drivers and Apple Type-C PHY drivers.

And the challenge is getting all these drivers to work together and drive the hardware in the right sequence to work, including complex/sudden hotplug cycles, mode switches, data role changes, live changes between USB and USB3+DP mode, the list goes on.

Here's how I spent the past hour:

- USB3 host + DP mode works on boot
- Hotplug doesn't work because my USB3 hub transiently starts up with the data role backwards (as if it were a host), and device/gadget mode is broken.
- Let's fix gadget mode. I need to change the USB3 PIPEHANDLER initialization, but right now it happens in usb3phy->power_on(), which is too early to know if we're device or host mode
- Let's move it to usb3phy->set_mode()
- After fixing some other stuff related to USB2, now SuperSpeed gadget mode works
- Try the hub coldplug again. It's completely broken in host mode.
- Turns out this broke because the dwc driver calls usb3phy->set_mode() twice with different but equivalent arguments for some bizarre reason
- Okay, add a flag so we only listen to the first call
- Now USB3 host mode works, but there's a 5-second delay in enumeration, so the PHY starts up in a bad state
- Diff register traces to see what happened
- Turns out usb3phy->set_mode() happens too late, after host controller soft-reset, and that's too late to work well.
- But usb3phy->power_on() is too early to know the mode, we're screwed
- ...but usb2phy->set_mode() is early enough for some reason

So now I have PIPEHANDLER setup (a USB3-relevant configuration) happening in the "USB2" PHY callback (which goes to the same shared Apple Type-C PHY driver anyway), just to make it work.

This is just the last debugging mess. It's all like this. Yesterday I found out a previous version of the code was only working due to a race between "mux configuration" and dwc3 initialization in a workqueue, synchronized by an accidentally load-bearing msleep(20) in dwc3. Yes, really. The fix for that is changing the tipd driver to do the mux set before setting up the Type-C data role (which is what triggers dwc3 init). tipd is its own hacky mess, since the hardware is too high-level for the Linux Type-C subsystem's design.

What makes this worse is that this setup is all reverse-engineered, so we have no documentation on what is supposed to work and what isn't. All we have is register traces from how macOS does it. But it's actually completely impractical to replicate them 1:1 in Linux, because the Linux cross-driver sync points are nowhere near enough for that. So we're left guessing and trying different interleaving orders and hoping that if something works, it's reliable, even though it's different to what macOS does.

(continued)