Skip to content

T8132: DisplayPort alt mode on the J604's USB-C ports - #1678

Merged
RyanTheTide merged 4 commits into
aurora-silicon:integration/aurorafrom
aeries0x:j604-dp-altmode
Nov 12, 2026
Merged

RyanTheTide merged 4 commits into
aurora-silicon:integration/aurorafrom
aeries0x:j604-dp-altmode

Conversation

@aeries0x

@aeries0x aeries0x commented Nov 12, 2026 •

Copy link
Copy Markdown
Contributor

External displays on the J604 (MacBook Pro 14", M4) over USB-C in DisplayPort alt mode, as asked about in #1518.
Today the T8132 PHY refuses DP outside USB4/TBT, so a USB-C monitor or a USB-C to HDMI hub gets no picture.

Four commits:

  1. phy: apple: atc: DisplayPort alt mode on T8132 — on a port marked apple,dp-alt-mode, 4-lane DP and
    USB3+DP run the PHY's own DP transmitter: the DP lanes and AUX sit in the core window at the offsets the T8122
    helpers use, and the T8122 AUX and main-link sequences bring them up. set_mode(DP) accepts any submode (the
    crossbar picks the DCP), the DCP's link rate goes to the T8122 link start, drive requests leave the lanes at their
    start level (no dp-training-table on these PHYs). Ports without the property behave as before. The binding
    gets the property; the host-test fixtures that compile the touched functions get the new field and helper, and
    atc-usb3-tests a T8132 target-mode case.
  2. drm: apple: fabric — a T8132 dcpext route counts as "no DP alt mode" only when its PHY lacks the property;
    a routed dcpext connects on HPD from the Type-C reconnect work, and its direct crossbar output gets its link up
    as on T6030. A dcpext stays no appledrm pipeline either way: appledrm keeps skipping its ports and they take no
    tiles. Fixture updates for tiled-split-tests and the apple-dcp transaction harness.
  3. arm64: dts: t8132-j604 — both dcpext pipes with routes to all three USB-C ports (left ports as on the
    J713, right port on ATC3 with its crossbar) and the three PHYs marked. HDMI (ATC2) is not part of this.
  4. phy: apple: atc: T8132 DP lane start — the T8132 lane start differs from the T8122 one in three points
    (start drive preset on both blocks, RX VREF filter held over both DTVREG stages, no LDOCLK1 bypass at HBR3);
    passed as flags to the shared lane start, T8122 callers unchanged. It is separate so it can be dropped on its own:
    in my tests both starts trained (below).

The enable comes from the board DT only; no module parameter. As on the J713, a pipe is only used when aura hands
it over (chosen.asahi,j713-dcpext=1), and the internal display still needs the DCP opt-in.

Tested on the J604 with these four commits on integration/aurora 2b4523c plus #1483, #1543 and two local
test-only commits (RTC read-only, a GPU counter):

  • All three USB-C ports (right, rear-left, front-left), Dell S2722QC over USB-C: 3840x2160@60.
  • Right port, UGREEN CM512 hub (pin D) to a Dell's HDMI input: 1920x1080@60, both plug orientations.
  • The internal display stays on appledrm throughout.

Earlier, the first version of this PR (the same commits except the two appledrm/tile checks in commit 2) on
integration/aurora 716670b, with a local runtime switch to compare the lane start of commit 4 against the plain
T8122 one:

  • Right port, Dell S2722QC over USB-C: 4 lanes at HBR2, 3840x2160@60, both plug orientations, with both lane starts.
  • Right port, the same hub: HBR3, 1920x1080@60, with USB 3 at 5 Gb/s on the same port (hub, Ethernet adapter, card
    reader, stick), with both lane starts.
  • Rear-left port, Dell over USB-C: 4 lanes at HBR2, 3840x2160@60.

Not tested: suspend/resume with a monitor attached, two monitors at once.

Assisted-by: LLM

The T8132 path refuses DisplayPort outside USB4/TBT: 4-lane DP falls
back to USB2, set_mode and the link rate return -EOPNOTSUPP, and AUX is
never powered. On T8132 the DP lanes and AUX sit in the core window at
the offsets the T8122 helpers use, and the T8122 sequences bring them up.

On a port the board marks with apple,dp-alt-mode:

- 4-lane DP keeps its mode. The PHY is powered up as for USB3, without
  the USB lane tunables, with lane mode and crossbar from atcphy_modes[],
  the common block started and the usb3-dp (AUX_TOP) calibration applied.
- After RCAL, DP and USB3+DP power AUX up; the main link and AUX go
  down again before the PHY leaves a DP mode.
- set_mode(DP) succeeds in DP and USB3+DP whatever the submode: the
  submode is the DCP index, and on an ATC the display crossbar selects
  the DCP. The DCP answers its ACTIVATE only once this succeeds.
- The DCP's link rate runs the T8122 main link start on the mode's DP
  lane pairs. Drive requests leave the lanes at their start level: these
  PHYs have no dp-training-table to map a request to.

Ports without the property behave as before.

Assisted-by: LLM
Signed-off-by: Friedrich <261542475+aeries0x@users.noreply.github.com>
Every Type-C route of a T8132 dcpext is treated as having no DP alt
mode, so a monitor in DP alt mode is never routed. Treat a route that
way only when its PHY lacks apple,dp-alt-mode.

A routed T8132 dcpext has no connector of its own: on HPD it connects
from the Type-C reconnect work, as it does for a tunnel. Its crossbar
behaves as T6030's, where selecting an output only routes it, so a
direct (non-tunnel) output gets its link brought up as there.

Either way a T8132 dcpext is no apple_crtc pipeline: appledrm keeps
skipping its ports and they take no tiles, so those two checks ask for
the dcpext rather than for a route without DP alt mode.

Assisted-by: LLM
Signed-off-by: Friedrich <261542475+aeries0x@users.noreply.github.com>
Describe both external display pipes (dcpext0/1) and their routes to
all three USB-C ports: the left ports on ATC0/ATC1 as on the J713, the
right port on ATC3 with its display crossbar. Mark the three ATC PHYs
for DisplayPort alt mode. The HDMI port (ATC2) is not part of this.

As on the J713, a pipe is used only when the boot loader handed it
over (chosen.asahi,j713-dcpext=1).

Assisted-by: LLM
Signed-off-by: Friedrich <261542475+aeries0x@users.noreply.github.com>
The T8132 lane start differs from the T8122 sequence in three points:

- both blocks of a pair start at the full swing 0 / pre-emphasis 0
  drive preset, where the T8122 start writes only the swing field and
  a de-emphasis code of 0 to the TX block;
- the RX block's VREF filter adjust is 3 rather than 1 and is cleared
  only after both DTVREG stages are enabled, with 500 ns after each;
- at HBR3 the TX start leaves the LDOCLK1 small/big bypass clear.

Pass these as flags to the shared lane start; T8122 callers pass none
and keep their sequence.

Assisted-by: LLM
Signed-off-by: Friedrich <261542475+aeries0x@users.noreply.github.com>
@aeries0x

Copy link
Copy Markdown
Contributor Author

Force-pushed: rebased onto integration/aurora 2b4523c, with a fix in commit 2. The first version changed dcp_typec_route_no_dp_alt(), which dcp_typec_port_unusable() and dcp_typec_port_untileable() also use in the sense "a T8132 dcpext". With a DP alt mode PHY on a port, appledrm then looked for a pipeline of its own for that port, found none and did not bind ("Type-C port 0 has no display pipeline", -ENODEV), so the internal display stayed on simpledrm. On the old base appledrm happened to bind before the dcpext routes were registered, so I did not see it; on the new base it no longer does. Both checks now use dcp_is_t8132_ext(). Retested on 2b4523c; the description has the details.

On the boot-logo stop mentioned in the first version: #1616 and #1617 enabled the T8132 scaler and JPEG DARTs without power-domains. A bisect on the J604 landed on those two merges, and #1668 (654fad4) already fixed it, so the new base boots.

@RyanTheTide RyanTheTide left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The T8122 helpers keep their old sequence for every non-T8132 caller (flags 0), and the fabric changes are all T8132-dcpext gated. The J604 results across the three ports cover it. Looks good.

@RyanTheTide
RyanTheTide merged commit a7f1bec into aurora-silicon:integration/aurora Nov 12, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants