Repository navigation
drm/apple: enable J516M built-in panel brightness - #416
Draft
DanielLemky wants to merge 26 commits into
Draft
DanielLemky wants to merge 26 commits into
DanielLemky wants to merge 26 commits into
Conversation
The T6031 (M3 Max) G15 GPU is powered by its PMGR domain alone, with no RTKit vote, and nothing sets its PTD power request. PMP then ignores the GPU's bandwidth demand and memory stays at its idle floor. Port the T6030 report (9bb7476) to T6031: AGX is the acknowledged soc-device ID 14 (record 13) of the J516C table, on the T6031 report apertures. Set it after firmware and backend setup, clearing it first, since an earlier request is acknowledged without enabling bandwidth scaling. A failure only warns and clears the request, which is how the GPU ran before. The session and the request stay until reboot. With Mesa unchanged, compute-copy bandwidth (test-backend-ops perf -o CPY, Vulkan) goes from 75 to 316 GB/s for 1.5 GB f32 copies and from 56 to 200 GB/s for 768 MB f16/bf16 copies. Tested on an M3 Max J516C, on top of local patches (HDMI, panel brightness, AVD AV1, in-flight cap); the panel, HDMI, brightness and AVD keep working. Generated-by: LLM Signed-off-by: Samuel Carreño <soyminero11yt@gmail.com>
…th g15_max_inflight On the T6031 (J516C) a browser submits one render per job. With only two prefixes in flight and ~612 us of host/firmware turnaround per flight while the GPU work per render is ~88 us (asahi-g15/stats span vs busy), the engine held publication on the in-flight cap ~3 times per job (stats hold[0]) and the GPU idled ~85% of every flight: at 120 Hz Chrome's ~2.7k renders/s hit the ~3.3k/s ceiling and frames queued up as stutter. Power (17-24 W) and a resolution-scaling test (1322 -> 1276 fps for 4x pixels) showed the GPU was starved, not busy; pstate was already 8/8. Raise FLIGHTS and MAX_INFLIGHT to 8 and add g15_max_inflight (0: tuned value, 1..8) so it can be lowered without a rebuild. Later flights still have to be of the same VM; pass slots (16) and CT buffers bound the rest, and publish_prefix_into already backs off with EAGAIN when they are held. Generated-by: LLM Signed-off-by: Samuel Carreño <soyminero11yt@gmail.com>
…ssbars Add the M3 Max's four external display processors, their mailboxes and firmware DARTs, all disabled, at the addresses, interrupts and power states of the J516C ADT (dcpextN, dart-dcpextN), translated through /arm-io ranges. The internal DCP's ADT values translate to exactly what t6031-dcp.dtsi already has, which checks the translation. dcpext0 0x3_06c00000 mbox IRQ 1068..1071 DART 0x3_0530c000 IRQ 1047 dcpext1 0x4_4ac00000 mbox IRQ 1104..1107 DART 0x4_4930c000 IRQ 1083 dcpext2 0x4_4ec00000 mbox IRQ 1140..1143 DART 0x4_4d30c000 IRQ 1119 dcpext3 0x2_cac00000 mbox IRQ 1176..1179 DART 0x2_c930c000 IRQ 1155 Each processor's ADT power gate is DISPEXTn-CPU-V, whose parents are DISPEXTn_CPU and DISPEXTn_FE, as DISP-CPU-V is the internal DCP's. So each sits on ps_dispextN_fe, as the internal DCP sits on ps_disp_fe. The node shape is T6030's dcpext: Type-C routes to ATC0..2, disabled until the display gate enables their processor. The compatible keeps apple,t6030-dcpext as a fallback so the display driver takes its T6030 external path. apple,typec-mux-indices is N for dcpextN because the ADT's display-crossbar0 lists its upstream ports as dispext0..7 in order; this is not yet confirmed on hardware. Add the three ATC display crossbars (ADT atcN-dpxbar, atc-dpxbar,t602x) at the T6030 addresses. With the t6020 compatible their probe writes no register. Give the PMP's pmp-dispext0..3 requests apple,always-on and apple,defer-startup-ack, as T6030's. They stay disabled, and the report driver seeds only available entries, so nothing changes until the gate enables one. Add the J514C/J516C Type-C port@3 endpoints for all four processors. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: DB <rafal+claudeai@digitalbrew.io>
Enable the dcpext gate on T6031 behind its own switch, apple_t6031_display.dcpext=1, which is off by default. Without it, or without the boot loader's handoff markers, every processor and its Type-C routes stay disabled. The gate's dcpext path assumed T6030's power order: the processor on dispextN_cpu, the child of dispextN_fe. On T6031 the processor is on dispextN_fe, the child of dispextN_cpu. Resolve the chain in the SoC's order, and check the mailbox, firmware DART and display DART against the processor's own power state, which also gets the active floor (its parents follow it). The boot loader's markers stay the T6030 ones (apple,t6030-dcpext-memory-ready, apple,t6030-dispext-handoff), so the display driver's checks need no change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: DB <rafal+claudeai@digitalbrew.io>
A T6031 dcpext loads the same DCP image as its internal DCP (F493F03E-CC40-3D89-9A08-5F259BA2B246, per the J516C ADT's iop nubs). Accept that image on apple,t6031-dcpext nodes only; every other external processor still needs the T6030 image. Also give T6031 the T6030 display-crossbar programming. Both use the same dispext pipes and the same t602x crossbar, and the T6030 path handles dispext bits 0..3. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: DB <rafal+claudeai@digitalbrew.io>
The display gate needs the pmp-dispextN report entry to have a phandle, and dtc emits one only for referenced nodes. Name the entry in apple,pmp-report, as T8122 does; the gate sets the same value. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: DB <rafal+claudeai@digitalbrew.io>
dcp_t6030_ext_native() looked only for apple,t6030-display-subsystem, so a T6031 dcpext the gate had handed its display DART fell back to the manual diagnostic path and never joined the DRM device. Look up the subsystem of the processor's own SoC. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: DB <rafal+claudeai@digitalbrew.io>
dcpext_check_power() required the processor's power domain to be dispext<N>_cpu, as on T6030. On T6031 the dcpext sits on dispext<N>_fe, whose parent is the CPU domain, and the display gate puts the active floor there, so startup was refused with -EINVAL on attach. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: DB <rafal+claudeai@digitalbrew.io>
A T6031 dispext<N>_fe power state does not hold the PMGR minimum-state field: with apple,min-state written it still reads 0xff, as the internal display's FE state does, while the CPU states keep it. Floor the CPU domain in the display gate (the same node as before on T6030), and have the driver check the floor there, reached through the FE domain the T6031 dcpext sits on. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: DB <rafal+claudeai@digitalbrew.io>
The J516C 14.7 firmware on a T6031 external processor publishes every timing with an empty ColorModes array; the display's color modes are only in ColorElements, and each timing names the ones it excludes in UnsafeColorElementIDs and DSCRequiredColorElementIDs. Every timing so had no color mode, parse_mode() rejected all of them, and the connector stayed disconnected with HPD asserted. When an external timing has no color mode of its own, select one from the published ColorElements, less its excluded IDs, with the external SDR ranking (full-range SDR RGB, 8 or 10 bits). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: DB <rafal+claudeai@digitalbrew.io>
The display crossbar runs T6031 in its T6030 mode (t6030_dpin): a route
is selected on activate, and its clocks come up only from the DCP's
DidChangeLinkConfiguration call, through dcp_direct_crossbar_link().
That function returned early on anything but apple,t6030, so on T6031
the direct DP PHY output stayed unclocked ('T602X route 0, clocks
disabled'), and every mode set failed in the firmware with
'IOAVVideoInterface prepareLink() failed'.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: DB <rafal+claudeai@digitalbrew.io>
T6031 (M3 Max) has the T6030 (M3 Pro) display fabric: T8122-generation
ATC PHYs, a crossbar in t6030_dpin mode and dcpext processors bound as
apple,t6030-dcpext. Its DP IN tunnel path was still disabled, though:
- the Thunderbolt driver leaves DP IN off on SoCs missing from
apple_dpin_qualified_soc, and the T6031 ACIO matched only the t8103
fallback (M1 DP IN policy);
- the DCP fabric and the ATC PHY pick the T6030 DP IN pixel clock path
and its source map on of_machine_is_compatible("apple,t6030") alone.
Qualify T6031, give its ACIO the T6030 DP IN policy while it keeps the
t8103 boot sequence (its DT node has no MxWrap region), and take the
T6030 clock path on T6031 too. The T6030 source map (crossbar sources
0 and 2 feed DP IN0/1) is assumed to hold on T6031; untested.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: DB <rafal+claudeai@digitalbrew.io>
The T6031 (M3 Max) DCP DPTX firmware drives a DP tunnel like a plain DP link: it never requests bandwidth through the DP IN adapter's allocation registers. With allocation mode enabled the tunnel reported "consumed bandwidth 0/12960 Mb/s", the mode set completed and the sink (a DisplayPort monitor behind a USB4 dock, DP OUT x2 HBR3) dropped the stream about 1.5 s later (DPTX INACTIVE_SINK_DETECTED). The same setup works with thunderbolt.bw_alloc_mode=0. Add a TB_HOST_DP_NO_BW_ALLOC host policy that takes the bw_alloc_mode=0 path for that host's tunnels only, and give T6031 its own policy: the T6030 flow plus the new flag. T6030 keeps its current behaviour. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: DB <rafal+claudeai@digitalbrew.io>
The J516C's HDMI port is ATC3 used as a DisplayPort-only PHY behind display-crossbar0, feeding an on-board DP-to-HDMI converter, as on the J514S/J516S (t603x-j514s-j516s-hdmi.dtsi). The T6031 tree described only ATC0..2, so the port had no connector. From the J516C ADT: - atc-phy3 and atc3-dpxbar sit where the T6030's do (0x1303000000, 0x130304c000); - dp2hdmi-gpio0: hdmi_pwr_en and dp2hdmi_pwr_en are SMC gP0f and gP1a, the J514S/J516S pins; - atc3-hdmi: function-hdmi_hpd is AOP GPIO 42 (47 on the J514S/J516S). dcpext0 takes the fixed route and stays a hybrid pipeline, lent to a USB-C port while no HDMI display is attached. The atcphy3 alias lets m1n1 copy the ADT's atc-phy3 calibration; without it the PHY reports "Calibration tunables missing, DisplayPort disabled". HDMI audio (DPA1 over the SIO) is not described yet. Signed-off-by: DB <rafal+claudeai@digitalbrew.io> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On the J516C only dcpext0 brings up an external display. dcpext1..3 time out in the DPTX remote port on USB-C (HPD assert, link configuration) and dcpext3 does the same on the HDMI route: AppleDCPDPTXRemotePort (chan:1) command type 0xc0 tag 0x0300 timed out after 1000 ms dcp_dptx_connect: failed to assert Type-C HPD: -110 DPTXPort: firmware reports link fault 22 on target 0:3 With the HDMI route on dcpext0, the allocator offers a hybrid pipeline to USB-C last, so a USB-C display always landed on a broken processor. Mark dcpext1..3 "fail": the display gate enables only processors left "disabled", and the DRM device waits only for available ones, so dcpext0 serves USB-C and HDMI alike. This is a stopgap that limits the J516C to one external display until dcpext1..3 are fixed; drop it then. Signed-off-by: DB <rafal+claudeai@digitalbrew.io> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A T6031 external processor's timings take their colors from ColorElements, but dcp_v14_external_published() built the mode catalog only on a TimingElements publication. Timings published before their colors so gave no mode until republished, replaced colors (ID 7 by 11) left the catalog on the old ID, and withdrawn colors left an admitted catalog naming color IDs that were gone. The fallback also applied to every native v14.7 external processor, beyond the T6031 opt-in. Opt the T6031 dcpext in explicitly (shared_colors), and on it rebuild the catalog from the published timings and the colors published now whenever either is published, replaced or withdrawn, in either order. A color change that leaves the timings no mode withdraws the catalog (dcp_modes_withdraw(): no longer admitted, kept for snapshot readers) and the timings' part of the description, and reports the display withdrawn once: the firmware withdraws ColorElements before TimingElements on an unplug, and a second report would release a connector kept connected through the withdrawal. A removal has no transfer and applies to the current attachment; a transfer begun before it is still refused as stale. The dcp_v14_shared_colors KUnit suite runs the production callback through both publication orders, replacement, unsafe-ID exclusion, withdrawal in both orders (one report each), republication, stale generations, and a processor without the opt-in. With the rebuild on a color change disabled, six of its eight cases fail. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WHu9VBxYcBYR8voXKiSV65 Signed-off-by: DB <rafal+claudeai@digitalbrew.io>
A T6031 external session whose first mode was fast hung on its first swap: with 3840x2560@60 (DSC) on the J516C 14.7 image, the firmware dropped swap ID 1 and its A407 never completed, ending the session until reboot: IOMFB: swap_submit_dcp: swallowed swap ID 1 as timinsg are not enabled for External Display DCP call 0x41343037 failed: -110; recovery requires a reboot The firmware starts a display's timings in a deferred run mode change after A472(1) and then sets the boolean property NormalModeActive (D104) to 1; A472(1) sets it to 0 first. With a slow mode (2560x1600@60) the change ends within A472, NormalModeActive already 1 when it replies. With the DSC mode it ends about 20 ms after A472 replied, and the swap sent meanwhile is dropped. Later swaps sent early are held instead, so only a session's first mode failed. Logged on a J516C: 8.597 A472(1) 8.599 D104 NormalModeActive = 0 8.613 A472 replied; A406, A407 sent 8.614 swallowed swap ID 1 as timings are not enabled 8.633 switch to normal mode succeeded; D104 NormalModeActive = 1 After A472(1), wait under the RPC lock for NormalModeActive (service 0) to be 1, handling the queued callbacks as dcp_v14_idle() does, for up to 500 ms. A timeout fails the mode set into the retry path; a failed callback stops the session; a firmware that never reported the property is not waited for. Every power-on is waited for, about 20 ms for the first DSC mode and 10 ms for later ones. On the J516C with a 3840x2560 display (DP over USB-C), six boots (reboot, power cycle, replug) set 3840x2560@60 first and showed its first swap in 18 ms; 14 later mode sets, 3840x2560@120 included, all succeeded. Without the wait, 5 of 5 boots lost the session. The dcp_v14_normal_mode KUnit suite runs the wait and the production D104 handler with a scripted link pump. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WHu9VCTrUXYgBxj2gKTGrp Signed-off-by: DB <rafal+claudeai@digitalbrew.io>
Assisted-by: Codex:GPT-6 Signed-off-by: Daniel Lemky <daniel@quantumfirelabs.com> # Conflicts: # drivers/gpu/drm/apple/iomfb_v14_7.c
Assisted-by: Codex:GPT-6 Signed-off-by: Daniel Lemky <daniel@quantumfirelabs.com>
Assisted-by: Codex:GPT-6 Signed-off-by: Daniel Lemky <daniel@quantumfirelabs.com>
The in-flight T6034 display profile includes t6031-dcp.dtsi, whose external routes reference the Type-C endpoints. Include the same endpoint definitions already used by J514C to resolve the twelve undefined phandles when combining PR372 with the current display base. This supplies graph endpoints without enabling a processor. Keep this integration correction separate from the J516M board work. Assisted-by: Codex:GPT-6 Signed-off-by: Daniel Lemky <daniel@quantumfirelabs.com>
Reuse the ADT-confirmed T6031 display layout on the J516M/T6034, with its exact board/SoC and pinned 14.7 DCP image. Retain the working T6031 handoff namespace separately from J514M and require explicit display and dcpext owner choices. Only dcpext0 is qualified. Enable the existing swap timestamp behavior for the 120 Hz internal panel and carry the J516M panel admission cases into the existing host fixture. Other boards and their default policy are unchanged. Assisted-by: Codex:GPT-6 Signed-off-by: Daniel Lemky <daniel@quantumfirelabs.com>
Share the existing six-channel T6034 G15C hardware layout while keeping J516M machine and full firmware admission independent of J514M. Require the measured 30-core fused identity 0x7b5ed7f5fd and retain strict refusal of the generic firmware-prefix override. Link J516M GPU startup to its T6031 display supplier; keep J514M on its separate T6034 supplier. Extend the existing profile and display order fixtures with the prior J516M admission cases. Inherited J516C power/reference values remain thermally unqualified. Assisted-by: Codex:GPT-6 Signed-off-by: Daniel Lemky <daniel@quantumfirelabs.com>
Extend the T6031 GFX bandwidth helper to the exact J516M/T6034 root pair. This board uses the same report layout and the existing GFX request/ack protocol. Keep other T6034 boards outside this guard and retain the existing supplier readiness and timeout behavior. Assisted-by: Codex:GPT-6 Signed-off-by: Daniel Lemky <daniel@quantumfirelabs.com>
J516M uses the T6031 PMP report layout, whose fallback tells users to boot with apple_t6031_display.enable=0 after startup fails. Its display gate only honors apple_t6034_display.enable, so that advice can leave a retained T6034 enable active and retry the failed startup. Select apple_t6034_display.enable=0 for the exact J516M/T6034 machine pair. Keep other report profiles' recovery switches and the nomodeset alternative unchanged. No PMP startup or report protocol changes. Fixes: 727efc7 ("drm/apple: add opt-in J516M native panel and HDMI admission") Assisted-by: Codex:GPT-6 Signed-off-by: Daniel Lemky <daniel@quantumfirelabs.com>
The J516M record already pins the J516C 14.7 image and J516 panel geometry. Admit this board to the existing nits backlight path, retaining the 500-nit bound, lifecycle and external-display exclusion. No protocol, raw register or boot-brightness changes are required. The original working kernel was physically qualified: apple-panel-bl registers and the brightness keys visibly dim and brighten the panel. The rebased branch has not been booted; suspend, DPMS cycles, the full range and photometric accuracy remain unqualified. Link: omacom#259 Assisted-by: Codex:GPT-6 Signed-off-by: Daniel Lemky <daniel@quantumfirelabs.com>
|
The J514M (14-inch M3 Max, T6034) works with the same change: |
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.
Depends on #415 (J516M native graphics and its listed dependencies), with companion loader omacom/m1n1#41. Target:
integration/aurora.Enable the existing bounded nits backlight path for the J516M board record and exact machine admission. Preserve the pinned DCP image, J516 geometry, 500-nit cap, lifecycle checks and other supported models. No brightness protocol/encoding or raw register changes; external-monitor brightness remains excluded.
The topic delta relative to #415 is one file, four insertions and two deletions. This draft initially carries that kernel stack because it targets
integration/aurora; rebase when #415 merges to reduce the diff to the brightness change.Validation: the exact rebased brightness source tree, unchanged by human DCO sign-off, booted with the prepared native graphics stack and corrected loader.
apple-panel-blregisters with maximum 500; both brightness keys visibly dim/brighten the built-in panel while native GPU rendering and 120 Hz scanout remain active. Existing backlight callback and panel-admission checks and the full Image/modules/DTBs build passed. Independent technical review found no actionable findings. No new tests were authored.Full-range, photometric, suspend and DPMS qualification remain unclaimed. Firmware, boot-image packaging and graphical-unlock configuration are excluded.
Assisted-by: Codex:GPT-6