Skip to content

Studio Display: DCP firmware sends unhandled DPTX_APCALL_INACTIVE_SINK_DETECTED (call 20); driver acks blindly and link tears down (fairydust) #579

New issue
New issue
Open
Open
Studio Display: DCP firmware sends unhandled DPTX_APCALL_INACTIVE_SINK_DETECTED (call 20); driver acks blindly and link tears down (fairydust)#579

Description

@pulsebrowser
pulsebrowser
opened on Aug 24, 2026

Summary

On the fairydust experimental branch, plugging an Apple Studio Display into a
MacBook Pro (13-inch, M2, 2022) brings up the whole display path — Type-C PHY
mode switch, OOB hotplug delivery to dcpext, DPTX bring-up — until the DCP
firmware issues AP call 20 (DPTX_APCALL_INACTIVE_SINK_DETECTED). The
constant is defined in dptxep.h but dptxport_call() has no case for it, so
it falls into the default "ack and hope for the best" branch
(dptxep.c:558). Immediately after the blind ack the firmware gives up and
the driver logs dcp_dptx_disconnect(port=0); the DP-1 connector never
leaves disconnected.

The Studio Display presumably needs a sink wake/activation sequence at this
point (its internal computer is still asleep), which explains why displays
without such a sink-side processor work while the Studio Display does not.

Environment
Machine Apple MacBook Pro (13-inch, M2, 2022) — apple,j493 / apple,t8112
Kernel linux-asahi-fairydust 7.1.6.fairydust.g96775a0 (AsahiLinux/linux commit 96775a0e72995e79e13b93755d456cb128dcdc81)
uname 7.1.9-1-1-ARCH #1 SMP PREEMPT_DYNAMIC aarch64
Display Apple Studio Display (USB hub 05ac:101d, bcdDevice 52.12)
Distro Arch Linux ARM (Omarchy), GRUB boot, Hyprland/Wayland desktop

Steps to reproduce

  1. Boot the fairydust kernel. card3-DP-1 (dcpext) appears, disconnected.
  2. modprobe typec_thunderbolt (see note 1 below — it does not autoload).
  3. Plug an Apple Studio Display into either Type-C port.

Result

The same terminal sequence on both ports (each attempt, no retraining):

kernel: #### oob_hotplug status:0x2 ####
kernel: apple-dcp 271c00000.dcp: DPTXPort: acking unhandled call 20
kernel: apple-dcp 271c00000.dcp: dcp_dptx_disconnect(port=0)

/sys/class/drm/card3-DP-1/status stays disconnected; no modes are ever
reported (dcp_hotplug() connected:0 valid_mode:0 nr_modes:0 at boot, no
hotplug event after plugging).

Port-specific detail:

  • Port at 503000000.phy: clean run of the sequence above, twice per
    plug, no other errors. The display's internal USB hub enumerates fine
    beforehand ("Apple USB2 Hub", 4 ports), then xhci tears down for the mode
    switch as expected.

  • Port at 383000000.phy: the same unhandled call 20 → dptx disconnect sequence, followed ~3 s later by:

    kernel: phy-apple-atc 383000000.phy: Pipehandler lock not acked.
kernel: phy-apple-atc 383000000.phy: Failed to lock pipehandler

    This looks like fallout of the aborted DPTX bring-up rather than an
    independent failure, since the call-20 sequence precedes it.

Analysis

In drivers/gpu/drm/apple/dptxep.h:

DPTX_APCALL_INACTIVE_SINK_DETECTED = 20,

In drivers/gpu/drm/apple/dptxport_call() (dptxep.c), call 20 has no case
and lands in:

default:
        /* just try to ACK and hope for the best... */
        dev_info(service->ep->dcp->dev, "DPTXPort: acking unhandled call %u\n", idx);
        fallthrough;

The zeroed-retcode ack is apparently not what the firmware expects for an
inactive sink: it disconnects the DPTX port right after. I'd guess the
expected response involves waking/activating the sink (the Studio Display's
internal SoC) before link training can proceed, but I don't have m1n1 traces
of what macOS does at this point.

Happy to test patches, capture fuller logs, or run instrumented builds — the
machine and display are available.

Notes

  1. typec_thunderbolt.ko is built but does not autoload on this
    configuration; without it the plug event only ever enumerates the
    display's USB2 hub and no mode switch is attempted. If that is not
    expected I can file it separately.
  2. Full dmesg of the boot and both plug attempts available on request.

Activity

  1. thejamescollins commented on Aug 26, 2026

    @thejamescollins
    thejamescollins
    on Aug 26, 2026

    I tried this on a 2021 16-inch MacBook Pro with an M1 Max (apple,j316c / apple,t6001). I'm using the same fairydust commit: 96775a0e72995e79e13b93755d456cb128dcdc81.

    I loaded typec_thunderbolt and typec_displayport, then plugged the Studio Display into the front-left port. I got the same sequence:

    #### oob_hotplug status:0x2 ####
apple-dcp 28cc00000.dcp: DPTXPort: acking unhandled call 20
apple-dcp 28cc00000.dcp: dcp_dptx_disconnect(port=0)

    I tried booting with the display connected as well, but that made no difference. It still hit call 20 and disconnected. DP-1 stayed disconnected with no modes.

    The only difference I noticed is that the Studio Display's USB hub didn't enumerate here, so I didn't get its audio device either. I also didn't see the pipehandler errors. I can test patches or grab more logs if useful.

    Thanks,

    James

  2. chadmed commented on Aug 29, 2026

    @chadmed
    chadmed
    on Aug 29, 2026
    Member

    Please try with a non-Thunderbolt full-spec USB-C cable. Do not try to use a Thunderbolt cable or a cheap/charging-only USB-C cable.

  3. thejamescollins commented on Sep 3, 2026

    @thejamescollins
    thejamescollins
    on Sep 3, 2026

    A correction to my earlier note about USB enumeration: I tried an Apple USB-C charging cable as a USB 2 control test. I know this is not the full-spec non-Thunderbolt cable you requested, so it does not test DP Alt Mode properly.

    It still produced the same oob_hotplug → unhandled call 20 → dcp_dptx_disconnect sequence, with DP-1 remaining disconnected. This time the Studio Display's USB2 hub (05ac:101d) and main device (05ac:1114) enumerated; UVC and USB audio loaded, and the speakers worked. No pipehandler errors occurred.

    Unfortunately I don't have a full-spec non-Thunderbolt USB-C cable available, so I'm unable to run the requested test at the moment.

    Thanks

  4. thejamescollins commented on Sep 4, 2026

    @thejamescollins
    thejamescollins
    on Sep 4, 2026

    I ran another control test on the same M1 Max (apple,j316c). The running kernel was 7.1.9-fairydust-1-ARCH, from package linux-asahi-fairydust 7.1.9.fairydust.g96775a0-1.

    Immediately before this boot I rebuilt m1n1 using the fairydust DTBs. The embedded t6001-j316c.dtb matches the one installed by the fairydust package.

    I plugged an Apple USB-C Digital AV Multiport Adapter (05ac:1463, bcdDevice 45.14) into the front-left port, with HDMI from the adapter to a Samsung TV. It connected as DP-1 and worked in Hyprland at 4096x2160/60.

    On the initial plug, I got this sequence twice:

    #### oob_hotplug status:0x2 ####
DPTXPort: acking unhandled call 20
dcp_dptx_disconnect(port=0)

    After the second one, the kernel also printed a warning from atcphy_mux_set. It then recovered and followed this path:

    #### oob_hotplug status:0x1 ####
dcp_dptx_connect(port=0)
...
DPTXPort: acking unhandled call 21
...
display HPD asserted
dcp_hotplug() connected:1 valid_mode:0 nr_modes:48
...
set_digital_out_mode(...) "4096x2160": 60
#### oob_hotplug status:0x1 ####
dcp_dptx_connect(port=0)
...
4096x2160@60 Hz link: 1

    So the call 20/disconnect pair can occur on a connection that later succeeds, at least through this DP-to-HDMI adapter. That doesn't tell us whether the current acknowledgement is correct for the Studio Display.

    In my captured Studio Display attempts, I never saw the later status 0x1, reconnect, HPD assertion or mode list.

    This still isn't the direct test with a full-spec, non-Thunderbolt USB-C cable that you requested. I don't have one yet.

    Thanks

  5. philtim commented on Oct 29, 2026

    @philtim
    philtim
    on Oct 29, 2026

    I think that I got a bit further as the Studio Display fires up, finally. I've asked claude to gather the interesting data points for this comment and hope that it helps a bit.

    Data point with a non-Thunderbolt full-featured USB-C cable, as asked above: on a base M2 (same T8112 as the original report) the Studio Display comes up at 5120x2880@60, 10 bit over DP alt mode. Call 20 still fires, but here it is followed by HPD-high and a successful dcp_dptx_connect.

    Environment
    Machine Apple MacBook Air (13-inch, M2, 2022) — apple,j413 / apple,t8112
    Kernel linux-asahi 7.2.12.asahi3-1 (7.2.12-3-1-ARCH), m1n1 1.9.9, plus the fairydust Type-C display pieces backported (below)
    Display Apple Studio Display — hub 05ac:101d bcdDevice 52.12, device 05ac:1114 bcdDevice 02.01
    Cable a full-featured USB-C data cable, not the display's bundled Thunderbolt cable (it must carry the SuperSpeed pairs, since 4-lane DP at 5K works and the hub drops to 480 Mbps)
    Port USB-C Left-front (usb-pd@3f, atcphy1)

    Backported from fairydust onto the 7.2.12 package, nothing else changed:

    • DT: the ENABLE_DCPEXT_TYPEC block of t8112-jxxx.dtsi (dcpext on atcphy1, mux-index = <2>, displayport = <&dcpext> on typec1, the dcpext alias, dispext0/dcpext DARTs, ps_atc1_common always-on), with the 5-cell iommus on display-subsystem as in fairydust.
    • tipd: the cd321x HPD forwarding (data_status_changed + drm_connector_oob_hotplug_event()), which applies cleanly to 7.2.12 and is then identical to fairydust's core.c / tps6598x.h.

    Sequence on plug

    15:31:39.759 #### oob_hotplug status:0x2 ####
15:31:39.759 apple-dcp 271c00000.dcp: DPTXPort: acking unhandled call 20
15:31:39.759 apple-dcp 271c00000.dcp: dcp_dptx_disconnect(port=0)
15:31:43.567 #### oob_hotplug status:0x2 ####
15:31:43.567 apple-dcp 271c00000.dcp: DPTXPort: acking unhandled call 20
15:31:43.568 apple-dcp 271c00000.dcp: dcp_dptx_disconnect(port=0)
15:31:44.183 #### oob_hotplug status:0x2 ####
15:31:44.183 apple-dcp 271c00000.dcp: DPTXPort: acking unhandled call 20
15:31:44.184 apple-dcp 271c00000.dcp: dcp_dptx_disconnect(port=0)
15:31:44.184 #### oob_hotplug status:0x1 ####
15:31:44.184 apple-dcp 271c00000.dcp: dcp_dptx_connect(port=0)
...
apple-dcp 271c00000.dcp: dcp_hotplug() connected:1 valid_mode:0 nr_modes:5
apple-dcp 271c00000.dcp: set_digital_out_mode(color:48 timing:43) "5120x2880": 60 936000 5120 5128 5160 5200 2880 2986 2994 3000 0x48 0x0
apple-dcp 271c00000.dcp: set_digital_out_mode() color mode depth:10 format:0 colorimetry:16 eotf:0 range:0 vrr:0

    Modes: 5120x2880, 3840x2160, 2560x2880, 2560x1440, 1920x1080, all @60. Camera, speakers, microphone and the HID interfaces bind on the display's hub. Same result on every plug across two boots (5 successful 5K modesets).

    So this is the recovery @thejamescollins saw through the DP-to-HDMI adapter, now with the Studio Display: the blind call-20 ACK doesn't seem to be fatal by itself.

    Differences from the failing reports above, in case one of them is what matters:

    • 7.2.12 instead of the 7.1.6 / 7.1.9 fairydust builds
    • typec_thunderbolt was not loaded (it isn't built in this kernel at all); the earlier reports modprobed it before plugging
    • typec_displayport was not loaded either; the cd321x firmware entered DP alt mode on its own
    • the cable above, instead of Thunderbolt / charging cables

    On 2026-10-05 the same machine on stock linux-asahi 7.1.13 (no fairydust pieces) with the bundled Thunderbolt cable and with a Dell USB-C cable showed the original failure: call 20, disconnect, never status:0x1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions