[erykwieliczko]

Problem

Since #265, a stereo DP/HDMI audio link is held between streams, because the sink mutes a link that stops and starts again with the same format until the DP link retrains. The hold_link module parameter limited this to the HDMI port by default (hold_link=1) until the Type-C ports had been tested with it.

So with the default, audio on USB-C is still affected by the same mute: every stream starts a new link with an unchanged format, and after the first stream the TV stays silent. On a fresh Omarchy install of linux-aurora 7.2.11.aurora11 (J514S, TV on USB-C), Chromium played into the USB-C sink with the PCM running and its DMA advancing, but nothing was audible. The log showed three link setups within 20 s, and Chromium's stream was the third.

Fix

Hold the link on every port and remove hold_link. Nothing needs to turn the hold off, and the only effect of the parameter's other values is silent audio. Streams with more than two channels still get a link of their own, as before.

dcp_audiosrv_typec() only existed for this check and goes too, along with the KUnit case for the old Type-C default.

Testing

J514S (M3 Pro), same TV on the HDMI port and on USB-C.

• With the hold on USB-C (hold_link=2, the behaviour this makes the default):
  • tonight, on the setup above: Chromium audio on USB-C plays, checked by ear;
  • earlier (2026-10-28, M3 Pro: keep HDMI audio working across pause, rate changes and output switches; add USB-C DisplayPort audio #265 testing): Chromium stop/start 5/5, pw-play runs including a PipeWire restart 5/5, direct restarts and screen off/on 10/10. Held links survived 90 s idle and sleep.
• HDMI port: unchanged; it already held the link by default.
• run-kunit.py: 144 suites, 1734 cases: 1731 pass, 0 fail, 3 skip (the expected ones), no splats. apple-dcpaud-release-link passes 11/11.
• check-commits.py and checkpatch.pl --strict: clean.

After this, users no longer need appledrm.hold_link=2 for USB-C audio. appledrm.hdmi_audio=1 is still needed to enable DP/HDMI audio at all; that's a separate question.

🤖 Generated with Claude Code

[chriskearney]

Reviewed exact head 653176d. No source blocker found. The native T6030 external-audio path now behaves as the previous hold_link=2: open-time rate/format pinning and period cap, first-start settling, and stereo silence DMA between streams apply to USB-C as well as HDMI. The four changed files merge cleanly; the removed symbols have no remaining references in the driver or host suites. Exact-head compile, KUnit, host tests, package and QEMU boot CI are green; current-base merge-queue CI is still required.

The change remains behind appledrm.hdmi_audio=1; the shipped default is off. M1/M2 use different PCM ops. Removing hold_link also removes the 0 opt-out; existing settings produce an ignored-parameter warning. Holding the link has a power cost while connected. The stereo rate/format pin also applies to multichannel opens.

Our combined #298 build (#295 + this head on 31748f0) supplied a J516S built-in-HDMI regression/control observation, not a direct test of the changed USB-C default: HDMI already held under hold_link=1. At 3840×2160@120 Hz with DSC, attach and re-plug completed, the DCP card/jack tracked the connection, and the held link used S24_LE/48 kHz. Eight explicitly targeted playbacks plus one requested repeat returned success; tones were heard, without confirming the exact count or cleanliness. A 6-channel open was cleanly refused by this sink's 2-channel capability.

The corrected audio job remains failed because final unplug occurred after its timeout; those observations do not rescore it. The earlier audio attempt sent no tones due to our script's resolver. The latest return restored the original audio state without a recovery reboot. Across the campaign, two of four returns to the regular kernel had AOP initialization crashes, recovered by one ordinary reboot each; their cause remains unidentified and is neither attributed to nor cleared by this review.

USB-C evidence remains the author's J514S hold_link=2 runs, to which this source is equivalent. No new dock, other-board, suspend, packaging or global-default qualification is claimed. Approval is for this opt-in kernel change; #83's default-enable decision remains separate.