Repository navigation
J616s g5: test integration of external display series #451 - #515
Closed
RyanTheTide wants to merge 17 commits into
Closed
RyanTheTide wants to merge 17 commits into
RyanTheTide wants to merge 17 commits into
Conversation
The dcpext of a T6041 listed the DP PHY and crossbar of every Type-C port and picked the port whose PHY had entered DP alt mode at connect time. The display fabric already routes the T602x, T6030 and J700 Type-C ports: a typec-routes node under the DCP, one mode switch per port, driven by the port controller. Use it for desktop 26.x as well and drop the private route (apple,dptx-phys, dp-phyN/dp-xbarN, apple_t6040_phy_dp_alt()). Three things differ from the other fabric users: - The T6040 DP PHY must be powered when the display connects, not when a route is claimed. The port controller calls the PHY's and the route's mode switch in connector order, and the PHY has to have seen DP alt mode and the plug orientation before its lanes are programmed. - The compact DPTX of desktop 26.x takes the crossbar link down and up around a link configuration through dcp->xbar, while the fabric's own direct-link helper is T6030 only. The route sets dcp->xbar for the time it is active; without it the link never trains. - There is a single Type-C pipeline. A port in DP alt mode without a sink (a dock, or a pin assignment the PHY cannot drive) must not hold it against the port that has a display: claim it on HPD only. Tested on a J616s (Mac16,7) with a USB-C display on one port: attach at boot, rebind of the port controller (replug) and a device suspend test (pm_test=devices). The other ports and a second display are not tested. Signed-off-by: František Balázsy <frantisekbalazsy@gmail.com>
…lers The H17P callbacks are checked against the record sizes the firmware sends; the desktop 26.6 ones were not. The u16 offset keeps a record inside the shared memory, but a handler could still read past a short request or write past a short reply into the next record. Give every desktop 26.6 handler the request and reply size it reads and writes, and refuse a callback whose record is shorter, or whose lengths do not fit the message, the way H17P refuses a malformed one. Longer records stay accepted. Signed-off-by: František Balázsy <frantisekbalazsy@gmail.com>
t6040_dp_power_on() shuts the USB3 side down, but t6040_dp_power_off() only cleared dp_up, and t6040_usb3_power_on() could re-initialise the PHY under a live DP mode. Once a Type-C DP session ended with the plug still in, USB3 on that port stayed down until dwc3 power cycled the PHY. Track whether dwc3 holds the USB3 phy on and asked for the PIPE switch. USB3 bring-up now waits while DP mode is programmed, and when DP mode ends and the port has left DP alt mode, from the DP power-off or the mode switch, whichever comes last, USB3 is brought up again and the PIPE goes back to the PHY. On an unplug or a DP mode change tipd drops the USB role first, dwc3 powers the USB3 phy off, and nothing changes there. Signed-off-by: František Balázsy <frantisekbalazsy@gmail.com>
The comment in dcp_is_typec_output() still described the private route the previous commit removed. Desktop 26.x now takes its Type-C route from the fabric and only drives the link through its own compact DPTX connect. Signed-off-by: František Balázsy <frantisekbalazsy@gmail.com>
…peline with the sink Review of the Type-C fabric series found four holes on the T6041 path. dcp_typec_phy_on() looked at the active route under hpd_mutex only, while the deactivate powers the PHY off and releases the crossbar under tb_lock. A connect racing a release could power the PHY after the crossbar was deselected and leave phy_powered set. Take tb_lock around the check and the power-on, and refuse a route whose crossbar is already released. The start-up gate in dcp_start_desktop() is again satisfied by a Type-C route, so a restart after an unplug (dcp->phy is NULL then) still brings the DPTX services up, and the start-up link is only connected when a fixed PHY or an active route exists: an idle pipeline has no powered PHY and no crossbar selection to connect on. When HPD drops while the port stays in DP alt mode, the route, its crossbar and the PHY were kept. Release them with the sink, as a mode change does, so a display on another port is not refused as busy; the route is claimed again when HPD returns. Check that a desktop callback record lies inside the shared buffer before its header is read, and access dcp->xbar with READ_ONCE()/WRITE_ONCE() as it is read by the DPTX worker without a lock. Signed-off-by: František Balázsy <frantisekbalazsy@gmail.com>
The fabric extraction now reaches dcp_typec_route_phy_off() and the DCP_FIRMWARE_V_26_6_DESKTOP tests, and the dispatcher extraction the desktop callback check. Add the define and, as for the other desktop paths, a stub that asserts if a non-desktop scenario reaches the check; the PHY power-off is a no-op there as the real one returns for an unpowered PHY. Seven of the eight units that stopped compiling build and pass again; mux-release-stages needs -Wno-unused-but-set-global with clang 23. Signed-off-by: František Balázsy <frantisekbalazsy@gmail.com>
…tput session A desktop 26.x Type-C display took its route from the fabric but was connected by dcp_desktop_dptx_connect(), outside the session the other SoCs use: no attach and detach bookkeeping (cable flag, generation, firmware metadata, unplug count), no relink, no reconnect retry and none of the IRQ_HPD handling the fabric already dispatches to it. dcp_is_typec_output() is no longer false for the desktop firmware, and dcp_dptx_connect(), dcp_dptx_connect_oob() and dcp_dptx_disconnect_oob() take the common path for it. What compact DPTX does differently stays where it differs: - the connection validation call does not exist, so it is skipped; - the PHY is powered when the display connects, before the DPTX connect; - a link configuration that has not arrived when the wait ends is not an error, it comes once a sink arrives; - a disconnect marks the external pipe as shut down by the firmware. The fixed HDMI output (dcpext0) has no Type-C session and keeps dcp_desktop_dptx_connect(). Signed-off-by: František Balázsy <frantisekbalazsy@gmail.com>
dcp_dptx_connect_raw() now asks the DPTX endpoint whether it is compact and has the route power the PHY. This scenario's endpoint is the classic one and its PHY needs no route: report not compact and stub the PHY power-on. Signed-off-by: František Balázsy <frantisekbalazsy@gmail.com>
apple,irq-safe on a PMP report entry marks an entry that parents the IRQ-safe PMGR power states of a coprocessor: genpd requires the parent of an IRQ-safe subdomain to be IRQ safe as well. Signed-off-by: František Balázsy <frantisekbalazsy@gmail.com>
A PMP device-state entry that parents PMGR power states (which are IRQ safe) must be IRQ safe too, or genpd refuses the subdomain. Setting the state takes a spinlock and polls the acknowledgment atomically, so the entry may run with interrupts disabled. Opt in with apple,irq-safe. Tested on a MacBook Pro M4 Pro (J616s): the DISPEXT0 and DISPEXT1 device-state entries parent the dispext0/1 PMGR chains that power the HDMI and USB-C DisplayPort controllers. Signed-off-by: František Balázsy <frantisekbalazsy@gmail.com>
The M4 Pro (T6041) external display processors use the generic dcpext fallback like the other dcpext variants; the driver already matches apple,t6041-dcpext. Signed-off-by: František Balázsy <frantisekbalazsy@gmail.com>
Describe the J616s external display chain, all disabled: dcpext0 behind the HDMI port (atc3 display crossbar, atcphy3, the DP-to-HDMI converter), dcpext1 behind the three Type-C ports (display fabric routes, atc0..2 crossbars), their DISPEXT power domains with the PMP acknowledgement entries, the display DARTs and mailboxes, and the dcpext firmware memory as disabled placeholders that the boot loader fills from the ADT. Nothing is enabled by the device tree: powering the DISPEXT chain without the PMP acknowledgement hangs the machine before root, and a boot loader that does not provide the firmware memory leaves the placeholders disabled. A gate enables the chain (next commit). Signed-off-by: František Balázsy <frantisekbalazsy@gmail.com>
Extend the T6041 display gate to the external displays. When both external display processors have their firmware memory (the memory-region nodes of the dcpext are available: the boot loader filled the placeholders), enable the chain after the PMP firmware is bound: the Type-C routes before any device exists (so the port controllers wait for dcpext1's mode switches) with the display subsystem held back, then the HDMI chain, the Type-C chain, and last both processors and the display subsystem together, so the display master is created once with every DART in its iommus. The port controllers are probed again once dcpext1 is bound, as the Type-C core treats a mode switch below a disabled node as absent at their first probe. If the PMP does not come within 20 s, or a step fails, the routes are withdrawn and only the internal panel stays. The processors are enabled only once the infrastructure devices have their drivers (the crossbar and PHY are modules), as a processor that finds one missing is given up for good. Without the firmware memory, with nomodeset, or on another machine, nothing changes. Tested on a J616s with m4-loader rev19-j616s-1 (which fills the memory from the ADT): HDMI and USB-C DisplayPort from boot, eDP unchanged. Signed-off-by: František Balázsy <frantisekbalazsy@gmail.com>
A J616s with 26.6.2 boot firmware (25G83, iBoot mBoot-18000.161.10) can load a third normalized T6040 TEXT identity: TEXT 0x60000, DATA 0x138000, the same entropy offsets, sha256 d725264d4831b95a5b8a375abf2fb5cdfbd6d7cbc7f1baa2cc8b37ee5d6e5e98. Without it the GPU probe stops with "GPU firmware image not admitted" and the device has no render node. Add the digest to the 26.6.2 T6040 image list next to the two existing identities and to the KUnit test that exercises every listed image through the lookup used by identify(). Signed-off-by: František Balázsy <frantisekbalazsy@gmail.com>
The g5 line already has the internal-panel adaptive-sync policy and failure fallback that overlap the last two commits of #451. Keep that panel path, admit VRR advertised by external sink modes, and program the desktop sync parameter when an external pipe enters or leaves VRR. Ported from the external-display intent of fbalazsy's #451 while preserving its preceding commits. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The g5 lifecycle fixture already extracts the real desktop 26.6 callback checker. The #451 fixture follow-up adds an assert stub for its older base, which makes three g5 host scenarios fail to compile with a duplicate symbol. Keep the extracted checker and remove only that redundant stub. The original #451 commits remain attributed to František Balázsy. This is a g5 integration fixup. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The g5 line already validates exact record lengths for its desktop 26.6 callbacks. #451 adds a minimum-length table for the full handler set, so a straight replay defines the checker twice and fails the WERROR build. Keep the g5 exact checks as a helper, fill the four g5 handlers absent from the new table, then require both checks. The table now covers every registered desktop handler. Point the synthetic desktop fixtures at the exact helper; production dispatch uses the combined checker. The original #451 commits remain attributed to František Balázsy. This is a g5 integration fixup. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
This was referenced Oct 27, 2026
Contributor
Author
|
Landed in integration/aurora through #533 (J616s consolidation, 2026-10-28). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
J616s g5 test integration of #451
This draft stacks the 17-commit #451 head
562eb4cnamed for this task from #451 on the public g5 tip (1214a925). Fourteen non-merge commits keep František Balázsy as author. The contributor's integration merge is not replayed because this branch uses g5 as its base.#451 has since advanced with three commits for 7680-pixel two-pipe displays. Its latest commit adds a
typec_hybrid_firstmodule parameter. Those later commits are outside this pinned single-pipe boot candidate and the task's no-new-kernel-parameter constraint; they need separate review and qualification.The last two #451 adaptive-sync commits overlap g5's newer internal-panel policy. They are omitted from this replay. Separate Ryan-authored fixups carry their external VRR intent through g5's existing policy and fallback, remove a duplicate host fixture stub, and combine g5's exact desktop callback shapes with #451's minimum-size table. The combined table covers all 62 registered handlers.
The #451 chain includes the IRQ-safe PMP entries, both disabled external DCPs, HDMI over ATC3, the three USB-C DP routes, and the staged T6041 display gate. Do not power DISPEXT without the PMP acknowledgement: the contributor reports a pre-root hang when that order is reversed.
This g5 test branch does not contain draft #506. The two series directly overlap in
apple,dcp.yaml,t6040-j616s.dtsandt6040.dtsi, and share external DCP/ATC3 resources. Reconcile them on a separate combined branch before any merge; concatenating the DT additions could duplicate nodes or break the staged gate.Loader and hardware gate
The current J616s m1n1 guest #52 only hands off the internal DCP. It does not fill dcpext0/1 firmware-memory placeholders from the ADT, so the #451 gate leaves external display disabled with that guest. m4-loader #5 implements an ADT-derived placeholder fill and was folded into open m4-loader #4; neither is part of this boot set. The boot set can qualify a safe baseline on the current guest; HDMI/USB-C hotplug tests require a separately accepted J616s-native loader that satisfies this contract.
The J616s controller device is not registered in the current inventory. No hardware request or direct target access has been made. Do not merge this draft until review, attribution, the universal gate, and a policy-approved J616s hardware run have passed. No force push to the contributor's branch and no new kernel parameter.
Offline evidence
CONFIG_WERROR=y) Image/modules/dtbs build: pass; 5,863 installed modules. Source identity stable at48fe30da9842007954558d215edae084c90ee1ff, tree5be422f623d359b6689202e71497ca4260b1ecd6.dtbs_checkand generated tether DTB schema validation: pass. The focused new bindings check is clean. W=1 DTC records 13 disabled-placeholder/existing-node warnings, and the broader binding run reports seven diagnostics in an older Type-C example; neither is a new-node schema error.7.3.0-aurora-j616s-display451:SHA256SUMSandMANIFEST.sha256pass, 5,863 module binaries and 5,881 archive files verified, final/initstarts after 298 zero bytes on a 512-byte boundary. Boot plan and MEASURE note are included with the artifact. This is not a live external-display qualification on Ryan's J616s.J616s batch1 hardware update (2026-10-27)
The orchestrator's J616s run paired batch1 (which includes this #451 series) with m1n1 #56 dcpext-only Stage 2. Both external firmware memories were filled, the PMP display gate completed, built-in HDMI enumerated as HDMI-A-1 (no cable/HPD), and eDP/GUI stayed working with zero WARN and DART faults. USB-C dock HDMI did not enumerate. The dock negotiated DP pin assignment D, and
drivers/phy/apple/t6040-usb2.cexplicitly rejected D: it only implements four-lane C/E. Do not map D through that C/E routine while the dock uses USB3. A proper two-DP-lane plus USB3 mode is still needed; the USB-C path has not passed on this machine.The same run logged missing T6040 GPU calibration because the Stage 2 lacked m1n1 #52. Draft m1n1 #56 now includes those GPU commits at
1bf9ec57; an offline Stage 2 candidate is published asstage2-dcpext-1bf9ec57-r2with MEASURE and SHA256SUMS. The panel and both external DCPs intentionally map the same immutable TEXT image, validated equal by m1n1. Their three reservation nodes produce overlap warnings; DATA and HEAP are distinct. This is a shared-memory description cleanup, not evidence of overlapping writable DCP buffers.The new Stage 2 has not been hardware tested. The batch1 D pin assignment remains unsupported. Do not count the earlier display451 boot set or the new Stage 2 as a dock HDMI pass.
Pin D follow-up and paired candidate (2026-10-27)
Draft #516 adds the missing
two-DP-lane pin D mode to the T6040 ATC PHY while retaining dock USB3.
It is batch1-based, has no DT edit or new kernel parameter, and is separate
from this g5 #451 integration. Final source head:
31340abccfcc3f7f9669fa327d8771a3cadd4f3f.The verified tether kernel is
candidates/boot-7.3.0-aurora-j616s-dp2-u2, paired withstage2-dcpext-1bf9ec57-r2for dcpext0/1 memory and GPU calibration.Its boot plan uses
--extra user4k=on. WERROR Image/modules/DTBs,J616s target DTB and T6040 ATC binding checks pass; payload and manifest
SHA256SUMS pass. Seven pre-existing T6020 Type-C example diagnostics remain
in the broader binding run. No J616s hardware result is claimed for the pair.
Ryan's acceptance is EDID-named 1920x1080@180 Hz, a visible mode set,
correct full-range RGB colours against Neo, and dock USB3/Ethernet retained.
The batch1 DCP policy requires a current matching EDID and trained HBR3
with two lanes for its 414.09 MHz RGB8 timing: 9.93816 Gbit/s fits HBR3
×2 (12.96 Gbit/s) but not HBR2 ×2 (8.64 Gbit/s). The kernel candidate's
MEASURE note requires the orchestrator's J616s agent to check actual EDID,
monitor name in desktop settings, configured link, monitor OSD, colour
pattern, built-in HDMI, eDP/GUI and zero WARN/DART faults. The candidate
hashes and final PR head were handed to t-3369 for the batch2 tip build.
Dock identity correction and direct HDMI qualification (2026-10-28)
The J616s dock in the hardware run enumerates as
17e9:6011Plugable UD-ULTC4K, a hybrid dock. Plugable documents DISPLAY 1 as native DP Alt Mode and DISPLAY 2/3 as DisplayLink USB graphics. Its USB ID alone does not identify which HDMI jack holds the monitor. Therefore the absence of Type-C partner altmodes in the dp2-u2 run does not qualify or refute #516 pin D; the earlier statement that this dock negotiated pin D was incorrect. No further T6040 altmode work is being done for this task, and #516 is unchanged.The new J616s test separates DisplayLink graphics, packaged outside the kernel tree, from the M4 Pro's built-in HDMI-A-1. The latter already enumerated under the display gate while disconnected; a direct HDMI cable/EDID test is pending. The test must establish the real EDID mode list, visible 1920x1080@180 Hz if offered, monitor name, full-range RGB colour, eDP/GUI continuity and zero WARN/DART faults. No HDMI hotplug or 180 Hz pass is claimed from the disconnected run.