Repository navigation
J616s external displays: carry #451 with a FORTIFY build fix and selftest fixtures - #526
Merged
RyanTheTide merged 32 commits intoOct 27, 2026
Merged
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 desktop 26.6 mode set (get_mode_info, then set_digital_out_mode) never sent IOMFBParameter 14, so VRR on the J616s ProMotion panel was offered by nobody and the panel stayed at a fixed rate; the VRR modes were hidden because enabling them that way left swaps uncompleted. Send adaptive sync (minimum rate in 16.16 Hz, 0 when VRR_ENABLED is off) before the mode is selected, as the firmware wants it applied with a mode set, and turn a VRR_ENABLED change into a mode set. Offer VRR on the internal panel only; external pipes do not program it here. On the J616s (T6041, DCP firmware 26.6.2) the firmware logs "IOMFBParameter_adaptive_sync Req minRR = 0x180000" and "3456x2234@120 Hz DSC=NO VRR=YES"; swaps keep completing, VRR on/off toggles and DPMS cycles are clean. Signed-off-by: František Balázsy <frantisekbalazsy@gmail.com>
The desktop 26.6 mode set programs adaptive sync the same way on the external pipes (dcpext) as on the internal panel. Send IOMFBParameter 14 for every VRR mode and stop hiding the VRR range of external displays. Signed-off-by: František Balázsy <frantisekbalazsy@gmail.com>
…utes on dcpext0 The desktop 26.6 firmware names the display pipes by their display index (endpoint 0 the internal panel, 1 dcpext0, 2 dcpext1) when two of them drive one display: apple,dcp-endpoint records it, separate from apple,dcp-index, which the driver also uses for the doorbell and the PHY mode. The two external pipes merge upwards only, so a display wider than one pipe (the Samsung Odyssey G95NC, 7680x2160) needs dcpext0 as the primary. dcpext0 therefore also gets a route to every Type-C port next to its fixed HDMI path (a hybrid pipeline, as the T6030 J514s): crossbar state 0 on atcphy0..2 (the ADT's dp-switch-dfp-endpoint 0 = dispext0, as its HDMI route on atcphy3), the connectors' port@3 with an endpoint per pipe. The routes are disabled with the rest of the chain; the display gate enables them in the HDMI stage.
…pipes
One DISPEXT pipe of the desktop 26.6 firmware drives modes up to 6720 px
wide ("IOMFB removing mode: 7680 x 2160, max width: 6720"); a 7680x2160
sink lost its native mode. The firmware supports a two-pipe display: the
primary pipe and a peer merge their frame timing generators and each
encodes half of the line, as the T6050 firmware-27 peer (#485) does.
The primary answers the display allocation in SET_TILED_DISPLAY_HINTS
with its own and the peer's endpoint IDs when the sink is wider than one
pipe and an idle pipe above it exists (apple,dcp-endpoint; the pipes
merge upwards only: dcpext0 is the primary, dcpext1 its peer; its sinkless
HDMI link does not make dcpext0 busy, that link is released before the
pair comes up). With the pair reserved the hotplug record is echoed as
on firmware 27, so both pipes know each other's display ID.
A DRM mode set wider than one pipe then runs the merge on both pipes:
the primary's video data (A364) is split into a half-width derived mode
inserted on both (A365, A366), both pipes are powered as a pair (A473),
their master swap IDs aligned (A360/A361), and the paired mode set
(A413) run with the tiling rendezvous the firmware drives through D115
(read) and D116 (write): membership, phase, display IDs, offsets; the
DSC capabilities, bits per pixel and slice hints are copied from the
primary to the peer in between (A367..A373). The same mode set again
keeps the pair (DRM repeats it right after the connector came up, and
the merged pipe no longer resolves the original timing).
Each frame is the primary's swap: its left tile stays in the swap, the
right tile goes to the peer as its own swap_start/swap_submit chain with
the primary's swap ID (the firmware does not use the IOMFB transaction
queue on this firmware); the peer's completion is not a DRM event. A
merged pair is stopped as a pair before the primary's power-off or sleep:
the single-pipe power-off of a merged primary timed out and the peer's
firmware looped.
Adaptive sync follows the CRTC on the pair: IOMFBParameter 14 goes to
both pipes with the same minimum rate before the paired mode set. A pipe
keeps the parameter across a replug, so a peer that last ran a VRR mode
alone merged with VRR on while the primary ran without it, and its
firmware crashed. A changed rate (VRR switched on or off) stops the pair
and installs it again, as the mode set applies it on one pipe.
The hybrid pipeline (a fixed output plus Type-C routes, dcpext0 on the J616s) scores last for a Type-C port, kept for the fixed display. On the J616s it is also the only pipe that can be the primary of a two-pipe display, so a 7680 px sink on USB-C can only be driven through it. appledrm.typec_hybrid_first drops that penalty: a Type-C port is planned onto the hybrid pipeline first and dcpext1 stays free as its peer. The HDMI display then has no pipe while the Type-C display is up; the default keeps today's order.
A pair's peer stayed marked as its owner's peer after the owner's display was gone: after system sleep, or a cable change, the port could move to the peer pipe, and the peer then ran its own display with the owner recorded. dcp_peer_swap_complete_26_6() takes the swaps of a reserved peer for the pair's and discarded the display's own swaps: the picture stuttered and the CRTC retrained in a loop. The reservation is released when the primary disconnects its DPTX link (a merged pair is stopped first by the power-off, and a pair that still runs is kept); the next allocation reserves a peer again. A peer's swap is only taken for the pair's while the peer has no route of its own. A pipe that was unbound is no longer refused as a peer after it binds again.
…he DT, no debounce without a sink apple,typec-hybrid-first on dcpext0 (the J616s: the only pipe that can be the primary of a display wider than one pipe) makes the fabric plan a Type-C port onto the hybrid pipeline first, as appledrm.typec_hybrid_first does, so a 7680 px sink on USB-C is paired at boot without a module parameter. The pipeline is only available while its fixed output has no sink, so an HDMI display plugged in first keeps it. The HDMI presence debounce (ten seconds) delayed a sample that finds no sink where there was none before, at start-up and after system sleep. The pipeline still counted as taken when the port was planned at start-up, or re-planned after the sink dropped its link in sleep, and the port went to the other pipe (a flattened 3840x2160, and after sleep no pair). Such a sample now stays absent; a sample after a real unplug is debounced as before.
…lug finds no mode A Type-C display that wakes from system sleep may list only its base modes at first: its EDID is not ready yet. The retrain after that hotplug then finds no mode for the active CRTC (the sink's 7680x2160 is not listed), and nothing reads the EDID again until the next HPD event, which can be a minute away; the compositor stays at a fallback mode (a 3840x2160 picture stretched over a 7680x2160 monitor). Disconnect and connect the link again, as a replug does, two seconds after such a retrain failed, unless a mode set completed in between; at most four times per resume. The work goes with the other Type-C works: disabled at probe, while unbound and across system sleep, so that nothing arms it behind a cancel.
The pair was installed first with adaptive sync off, because the CRTC still had VRR disabled, and the compositor then switched VRR on: that stopped the pair and installed it again. When the sink drops its link in between (a monitor waking up or switching its input layout), the second install fails (set_digital_out_mode 0x6) and the display stays dark until the next replug. Install the pair with the mode's minimum refresh rate from the start, whatever the CRTC asks. A VRR toggle then finds the pair with the same timing, colour and rate and keeps it. Swaps on a VRR mode carry their timestamps either way, so the compositor still paces the frames.
…m its Type-C route's On desktop 26.x a Type-C route sets dcp->xbar to its own crossbar control, for the compact DPTX link configuration. dcp->xbar was also the fixed HDMI output's control, so on the hybrid dcpext0 every later use for HDMI went to the Type-C port's control instead: when the route was let go with an HDMI display present, handing the pipeline back to HDMI selected the Type-C port's control with the HDMI index. The next route of that port, on dcpext1, then waited in mux_control_select() for good, holding the fabric lock, with the port controller's update work and interrupt thread stuck behind it (seen with a G95NC on USB-C and HDMI, switching its picture-by-picture layout). Keep the fixed output's control in dcp->fixed_xbar and select, release and check the fixed route with it only; dcp->xbar stays the control a link configuration takes up and down, and points at the fixed one again when the pipeline is handed back to HDMI. A Type-C route's control is taken with mux_control_try_select(): only a route of the same port can hold it, and that one lets it go under the fabric lock held here, so a wait could never end.
…ps HPD When the sink of a desktop 26.x Type-C route drops HPD, the route gives its pipeline back and the freed pipeline goes to a port left waiting. The port's own DP state still said HPD at that point, so it was taken as waiting itself and routed again at once, onto the same pipeline or, with an HDMI display on the hybrid, onto the other one, and its connection was replayed against a sink without HPD. Clear the port's HPD before the pipeline is freed (the pairing pass still sees what it counted before), connect a live HDMI display the hybrid has gone back to, as the DP-exit path does, and leave a parked hybrid without a link crossbar: the released route's control may now belong to the other pipeline. The error path that restores the fixed route points the link crossbar at it again.
…splay onto the freed hybrid On a desktop 26.x processor the HDMI HPD handler left disconnects to the firmware. The J616s's DP-to-HDMI converter (a Parade DP855) keeps its DP link up without a sink, so the firmware never reports an unplug: the HDMI connector stayed connected and the hybrid pipeline busy until the next plug. Debounce both edges for 500 ms; when HPD stays low, report the unplug as a CRTC power-off with HPD low does, and start the HDMI presence hold, which frees the hybrid when it expires. A Type-C display wider than one pipe that came while HDMI held the hybrid sits on the Type-C-only pipeline, which pairs with nothing above it. When the hybrid becomes free again, move such a display onto it, as a replug does, so that it gets both pipes. While the hybrid drives a Type-C display, an HDMI plug only waits: the cold-plug HPD pulse would have hit the Type-C display's link.
…e-C display A monitor on both the HDMI port and a USB-C port of a J616s (a Samsung G95NC at 7680x2160) can have both display pipes on one input only: the hybrid dcpext0 is the HDMI output's pipeline and the only primary of a pair. The monitor does not tell which input it shows: both keep HPD up, and the unselected DP input still answers for its EDID. So typec_hybrid_first says who gets the hybrid: -1 follows the device tree (the default), 0 puts an HDMI display first, 1 a Type-C display. A write applies at once, so that the desktop can follow the monitor's input. - Type-C first: a Type-C display that asked for two pipes and found no peer takes the hybrid. The HDMI display is reported gone, its link released (retried while the firmware is busy with a link nobody answers) and it waits; it gets the hybrid back when the Type-C display sets a mode within one pipe (picture by picture) or leaves. - HDMI first: an HDMI display keeps the hybrid. One wider than one pipe also takes the other pipe from a Type-C display, which waits, routed nowhere, until the HDMI display fits one pipe or leaves. A hand-over is an unplug and replug: at most one per ten seconds, and no more than two failed takes until the next plug. Peer reservations that outlived their pair are dropped: when a Type-C route takes a pipeline reserved as another display's peer, and when a display asks for a pair while the pipe it reserved, or the pipe it is reserved for, drives a display of its own.
dcp_peer_hints_26_6() clears the 32-byte allocation block of the display hints (primary and peer endpoint IDs, extra pipe count, flags and the reserved bytes) with memset(&r->primary_id, 0, 32). FORTIFY_SOURCE sees a write of 32 bytes into the 4-byte primary_id field and fails the build with -Werror (__write_overflow_field), so dcp.o does not compile with the Fedora-based release configuration. Group the allocation fields with struct_group_attr(), keeping the packed layout, and clear the group by its size. The offsets are unchanged and a new static_assert pins the group at 32 bytes. Fixes: e3e7131 ("drm/apple: drive a display wider than one pipe with two desktop 26.6 pipes") Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Desktop 26.6 now takes adaptive sync with a mode set. 562eb4c removed dcp_mode_vrr_supported(), which the publication fixture extracted unconditionally. 6477da6 made dcp_crtc_atomic_check() turn a VRR_ENABLED change on that firmware into a mode set, through drm_atomic_get_old_crtc_state() and crtc_state->mode_changed, which the VRR admission fixture did not model. So publication-hpd failed to build its unit and vrr-rejection did not compile. Extract the VRR filter only where the source still has it. Give the VRR fixture the desktop firmware value, mode_changed and an old-state lookup that counts its calls. The existing 72 admission cases run unchanged and now also check that no other firmware looks at the old state or forces a mode set. Where the source has the desktop path, 12 more cases pin it: an enabled CRTC whose VRR_ENABLED differs from its old state gets mode_changed, and nothing else does (a disabled CRTC, an unchanged VRR_ENABLED, no old state). Fixes: 562eb4c ("drm/apple: enable adaptive sync on desktop 26.6 external displays") Fixes: 6477da6 ("drm/apple: enable adaptive sync on the desktop 26.6 internal panel") Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The actual-DCP route fixtures compile the real dcp_typec_route_set(), dcp_typec_route_deactivate() and dcp_typec_route_available(). The J616s series added hybrid hand-over state to them. Deactivation now clears peer_starved and typec_narrow, releases a desktop 26.6 peer and restores the fixed output through its own fixed_xbar. A port leaving DP clears typec_yielded and dcp_hybrid_fails and hands every yielded hybrid on the port's routes back to HDMI. Availability asks dcp_typec_hybrid_first(). The mock struct apple_dcp and port had none of this, so seven units no longer compiled. Add the fields and a counter. Extract the real dcp_typec_hybrid_first() over the production defaults (module parameter -1, no DT opt-in), so the policy is as before. Stub the peer release to assert, since no scenario is on desktop 26.6. Let the single-port list walk yield the port's one route when it walks routes. Probe now records the fixed output's crossbar in fixed_xbar as well as xbar (7b99095), and deactivation restores the fixed route through fixed_xbar. The mux-release-stages fixed-restore case set only xbar, so set both as probe does. Its assertions are unchanged: the restore is retried once after its failure and the deselect stays balanced. Fixes: 7b99095 ("drm/apple: fabric: keep the hybrid pipeline's HDMI crossbar apart from its Type-C route's") Fixes: 0d43a7f ("drm/apple: fabric: hand the hybrid between an HDMI and a two-pipe Type-C display") Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
erikwb
pushed a commit
to erikwb/linux
that referenced
this pull request
Oct 28, 2026
Brings the J616s batch5 kernel (the tree running on the M4 Pro) up to the current integration/aurora, which adds aurora-silicon#524 (J713 T8132 energy model), aurora-silicon#526 (the T6041 display fabric carry, whose peer allocation field group batch5 already has) and aurora-silicon#529 (J713 USB-C idle power). Conflict resolution: - selftests apple-dcp rate.py: keep batch5's version. Its fixtures follow aurora-silicon#451's desktop adaptive sync and the T6041 external EDID. The integration/aurora side only changed how the lookup_mode() definition is found; its line-start pattern also matches the indented "lookup_mode(dcp, ..." call that batch5's iomfb.c has before the definition, while batch5's 'bool lookup_mode(' marker finds the definition in either form. aurora-silicon#529's ATC and dwc3 changes merge cleanly beside aurora-silicon#516's two-lane DP pin D. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.
This carries #451 by František Balázsy (J616s external displays through the display fabric, the T6041 display gate, HDMI, two-pipe and hybrid HDMI/Type-C handling, adaptive sync and the third T6040 GPU image) onto the current integration/aurora, plus three fixes found while testing it. His 28 commits are unchanged and keep his authorship.
What this adds on top of #451
drm/apple: clear the desktop 26.6 peer allocation as one field group. WithCONFIG_FORTIFY_SOURCE=y(the Fedora-based release config)dcp.odid not compile.dcp_peer_hints_26_6()clears the 32-byte allocation block withmemset(&r->primary_id, 0, 32), and FORTIFY rejects a 32-byte write into a 4-byte field (__write_overflow_field, an error under-Werror). The fields are now astruct_group_attr(allocation, __packed, ...)and the group is cleared by its size. The layout is unchanged and pinned by a newstatic_assert.selftests: apple-dcp: follow adaptive sync on desktop 26.6andselftests: apple-dcp: follow the hybrid hand-over in the route fixtures. The apple-dcp host selftests went from 63/63 to 54/63 with J616s (M4 Pro): external displays (Type-C through the display fabric, HDMI and USB-C DisplayPort behind the T6041 display gate) and the third loaded GPU image #451 merged. All nine failures were fixtures that had not caught up with J616s (M4 Pro): external displays (Type-C through the display fabric, HDMI and USB-C DisplayPort behind the T6041 display gate) and the third loaded GPU image #451 (the removeddcp_mode_vrr_supported(), the VRR mode-set rule, the new hybrid hand-over fields andfixed_xbar). No assertion was removed or weakened, and the same fixtures still pass 63/63 on integration/aurora without J616s (M4 Pro): external displays (Type-C through the display fabric, HDMI and USB-C DisplayPort behind the T6041 display gate) and the third loaded GPU image #451.Testing
run.py) on this branchdrivers/gpu/drm/apple,soc/apple,phy/appleat W=1, Fedora-based release config with FORTIFYNot covered here: s2idle, a physical replug, HDMI and USB-C monitors on the J616s, an external display on the Neo, and #451's VRR mode-set change on hardware (the J616s test kernel carries its own adaptive-sync code). Those rely on František's hardware results in #451. The EDID still does not reach userspace on the dock (a 0-byte EDID, so GNOME shows "Unknown"), which is a separate driver gap.
Supersedes #451.
🤖 Generated with Claude Code