Repository navigation
soc: apple: mailbox: receive T6050 GPU mailboxes by polling - #1601
joshuaswarren wants to merge 2 commits into
Conversation
On the 14-inch M5 Max MacBook Pro the GPU ASC interrupt never reaches the AIC, so nothing the GPU firmware sends is received. Add rx_poll_only to struct apple_mbox_hw and set it for both T6050 ASCWrap v6 hardware descriptions. apple_mbox_has_rx_poller() now also returns true for them, and probe sets up the same delayed work item the v8 mailboxes use, so the receive poller drives these mailboxes. Tested on a 14-inch M5 Max MacBook Pro: with this change the GPU firmware (macOS 27.3 build 26C5035r) completes its initdata handshake and the driver registers /dev/dri/card1 and renderD128. Signed-off-by: Joshua Warren <816217+joshuaswarren@users.noreply.github.com>
|
Thanks Joshua. Only the two T6050 v6 descriptions change, and the poller is the one the v8 mailboxes already use, so no other SoC's mailboxes move. On our M2, M1 Pro and J616s a kernel with this PR shows no mailbox or RTKit change against the base. Waiting on a J714s GPU row (the same descriptor drives its GPU) before merging. The source and kunit failures are on the base (sbio.rs log rate and pmp-report get_cpu_idle_time), not this change; a rebase picks up the fixes. |
|
J714s (M5 Pro) validation of 43c6ca8: FAIL on GPU throughput.
|
Codex Review Summary: ❌ FailedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
The account paying for this security review has reached its Codex usage limits. The payer can check the Codex usage dashboard. For personal accounts, using credits requires enabling “Use credits for security reviews” in Code review settings. If you do not manage the paying account, contact this repository's admins. |
…outstanding The poll-only T6050 GPU mailboxes receive with the delayed work poller, which wakes once per jiffy: 4 ms at HZ=250, against a 0.22 ms GPU frame, so a reply can wait for roughly eighteen frames. After every send on a rx_poll_only mailbox, arm a 25 us hrtimer that runs the same receive step as the jiffy poller (same rx_lock, same PSD and removal checks). Fast-polling continues while messages arrive and for a 1 ms grace window after the last message or send -- about four frames, to catch straggler replies -- then stops and leaves only the slow poller, so unsolicited messages are still received while idle. The recv-not-empty IRQ mode and the ASCWrap v8 mailboxes are untouched: every new code path is gated on hw->rx_poll_only. The kick writes the grace deadline and arms the timer without taking rx_lock: apple_mbox_poll_locked() runs the rx callback with rx_lock held, and a callback that sends would take tx_lock under rx_lock. Neither the RTKit receive callback nor any recv_message_early hook sends today, but the kick no longer depends on that. Both timers are cancelled where the poller already was, on stop and remove. Compile-tested only against the aurora 7.3 tree (arm64, LLVM=1, config with CONFIG_APPLE_MAILBOX=y); no hardware run yet, so the 25 us period and 1 ms grace are unproven on real firmware. Signed-off-by: Joshua Warren <816217+joshuaswarren@users.noreply.github.com>
|
[Joshua's agent] Thanks for the J714s run. glmark2 154 against 4464 and 6.4 ms against 0.22 ms per frame match a reply that waits for the next poll tick. I pushed a23755c to this branch. It adds a 25 us hrtimer poll that every send on a poll-only mailbox arms. The timer runs the same receive step as the jiffy poller. It keeps polling while messages arrive and for 1 ms after the last send or message, then stops. Idle still uses only the slow poller, so unsolicited messages are still received. The kick takes no lock, so it does not nest Limits: this builds clean (arm64, LLVM=1, Could you rerun the same glmark2-es2 30 s off-screen test on a23755c and post the score and the frame time? Please also post |
|
[Joshua's agent] Measured on a 14-inch MacBook Pro with the M5 Max (K114c), same kernel config, same Mesa, one boot per row. Only difference: this patch. Test:
That is about 5x more frames per second (roughly 1000 to 5000). vkcube exits 0 and dmesg shows no new GPU message after the run. glmark2 is not usable on the live compositor here (it falls back to llvmpipe), so this is a frame-pacing proxy, not a glmark2 score. |
The GPU on the 14-inch M5 Max MacBook Pro (K114c, T6050) never started under Linux. Its ASC interrupt does not reach the AIC, so the driver never received anything the GPU firmware sent.
This adds
rx_poll_onlytostruct apple_mbox_hw, sets it on both T6050 ASCWrap v6 descriptions, and letsapple_mbox_has_rx_poller()return true for them. Probe starts the same delayed work item the ASCWrap v8 mailboxes use, so the receive poller drives them. The v8 path and the other v6 descriptions are unchanged.Tested on a 14-inch M5 Max MacBook Pro with the macOS 27.3 (26C5035r) G17C firmware: the initdata handshake completes and the driver registers
/dev/dri/card1andrenderD128. With the Mesa from the matching branch, a Wayland triangle renders and Hyprland runs on the GPU (glmark2-es2-wayland scored 683 in a 30 second run).The GPU still needs the K114c device tree handoff and the firmware identification, which come as separate PRs. The device tree handoff merged as #1603 and the firmware identification is #1602.