Skip to content

m4pro batch 2 review fixups: keep T8140 ISP and G13/G14 queue priority unchanged - #399

Merged
RyanTheTide merged 2 commits into
integration/aurorafrom
m4pro/batch2-review-fixups-20261023
Oct 23, 2026
Merged

RyanTheTide merged 2 commits into
integration/aurorafrom
m4pro/batch2-review-fixups-20261023

Conversation

@RyanTheTide

Copy link
Copy Markdown

Two follow-ups from reviewing jgoyvaerts' M4 Pro batch (#383 to #387, #391), all merged now. Both keep shared paths on our existing machines where they were until someone tests them there.

Tested in the 73m kernel (Fedora base plus asahi.config, the same resolved config as 73r) with all of batch 2:

  • Builds clean.
  • W=1 is clean on the 27 objects batch 2 and its fixups touch.
  • KUnit: asahi 67/67, rust_drm_sched 3/3, touched drivers 155/155.
  • Host selftests 57/57.
  • One-shot boot of 73m on the MacBook Neo, then back to 73r:
    • No WARN, BUG or Oops.
    • GPU, display, Wi-Fi, Bluetooth, Touch ID and the trackpad all came up. Speaker and mic streams ran with speakerguardd on.
    • vkcube and glmark2 ran fine.
    • A 30 s s2idle resumed cleanly, and Wi-Fi reassociated within about 11 s.

🤖 Generated with Claude Code

…aths

Two changes in the T6040 series also act on the T8140 (MacBook Neo),
which runs the same H17 firmware interface:

- Commit ed7b2a4 ("media: apple: isp: Zero the lens shading strides
  of H17 setfiles") rewrites the lens shading records of every setfile
  loaded on H17 firmware. It was only seen to matter on T6040, and the
  T8140 camera streams with its setfiles unchanged.
- Commit 3161362 ("media: apple: isp: Add T6040 support") reads a
  "data" memory-region for every SoC, maps zeroed pages above it, and
  fails the probe when it does not fit the heap. The T8140 regions come
  from the bootloader, and nothing has checked how that would behave
  there.

Limit both to ISP_GEN_T6040, so the T8140 boot and capture paths stay
as they were until they are tested on that machine.

Assisted-by: LLM
Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Commit 2321a1b ("drm/asahi: allow HIGH queue priority with
CAP_SYS_NICE or DRM master") makes queue_create accept HIGH on every
GPU, and its message says the G13 and G14 priority-1 pipes it then
reaches are untested. Those are the M1 and M2 Macs, which run Asahi's
firmware tables, and a Mesa that starts asking for HIGH would move
compositor work onto them.

Accept HIGH only on G17, where it was run, and keep EINVAL elsewhere,
as before.

Assisted-by: LLM
Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
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.

1 participant