Repository navigation
Merge aurora-wip (M5 J813 / T8152 J873 bring-up, selftests) into integration/aurora - #1032
Merged
RyanTheTide merged 139 commits intoNov 6, 2026
Merged
Conversation
The G18 backend (T8152, Mac mini M6) takes this driver's command layout. Two of its abilities have no equivalent among the shared features, so they take the next free feature bits: - DRM_ASAHI_FEATURE_G18_GRAPHICS_SCRATCH (bit 31): render commands may carry struct drm_asahi_g18_render_resources, flagged with DRM_ASAHI_RENDER_G18_RESOURCES (render flag bit 25). The kernel sizes the shared TA/3D private-memory pool from it. - DRM_ASAHI_FEATURE_G18_NATIVE_TILE_SAMPLES (bit 32): single-sample renders with 32x32 utiles also accept 40-, 56- and 72-byte samples. It is a #define after enum drm_asahi_feature: a 64-bit enumerator would widen that enum to unsigned long, which bindgen maps to usize. Compute commands get two G18-only flags: DRM_ASAHI_COMPUTE_USES_TEXTURE_STATE (bit 18) selects the native texture compute mode, and DRM_ASAHI_COMPUTE_G18_RESOURCES (bit 19) adds struct drm_asahi_g18_compute_resources. The flagged payloads, struct drm_asahi_cmd_render_g18 (528 bytes) and struct drm_asahi_cmd_compute_g18 (264 bytes), are the complete render or compute command followed by its resources. Every field of the command keeps its meaning. The flag numbers leave render bits 21-24, compute bits 16-17 and feature bits 25, 27 and 30 to the M5 runtime's userspace, which uses them. No existing struct, field or value changes. G18 reports DRM_ASAHI_GPU_HAL_300; say so in its documentation.
The G18 backend maps an alias into the unmapped guard pages that trail a kernel mapping, and must give the guard back if the alias is undone. Add NodeData::split_tail(), which turns the tail of a reservation into a node of its own, and NodeData::rejoin_tail(), which merges an adjacent tail back. Both are limited to allocators without colour callbacks, allocate before they mutate, and leave both reservations unchanged on failure.
The M6 (T8152) GPU has two coprocessors, GFX and GFX1, behind ASCWrap v8 wrappers. Add an "apple,t8152-gfx-ascwrap-v8" provider: - a counted FIFO for its post-office window; - the lifecycle helpers the G18 backend uses to start and stop the coprocessors, gated on the PMGR PSD service of each role; - a receive poller. Starting or stopping a coprocessor needs apple_mailbox.ascwrap_v8_cpu_control=1. The receive interrupt is used only with apple_mailbox.ascwrap_v8_rx_irq=1; otherwise the receive side is polled. Both default to off and are read-only at runtime. Ported from our earlier out-of-tree M6 port onto this tree's mailbox core.
The G18 GPU firmware places its crash buffer in memory the GPU UAT already maps, so the RTKit core must neither allocate nor map it. Add the APPLE_RTKIT_FIRMWARE_OWNED_CRASHLOG ops flag, in the style of the existing CoreAnalytics flag, and RtKit::new_g17p() to create such a client from Rust. Based on earlier work by DjDeveloperr.
Import the G18 backend of the Mac mini M6 (J873, T8152, G18G B1) from our earlier out-of-tree M6 port, which ran it on an older copy of this driver, together with its UAT support, mmu/t8152.rs. That port passed every test of the OpenGL 4.6 CTS once on the M6. The files are unchanged apart from some comments. Nothing builds them yet: the following commits move the backend to this driver's command layout and core, and then wire it up behind its own Kconfig option. Credits: - The G17P init-data model in g18/fw/initdata.rs (InstanceRole, ChannelEntry, the UAT level descriptors, the region runs, INITDATA_VERSION_WORD and the serializers around them, about 227 lines) is DjDeveloperr's work, from his August 2026 rebuild of the G17P (T8140) init-data model. Eryk Wieliczko carried it into the port, where it was adapted for G18. It was not published before. - The rest of the backend is Acelogic's.
The earlier out-of-tree M6 interface used a 272-byte render and an 88-byte compute command. Parse this driver's instead: struct drm_asahi_cmd_render (448 bytes) and struct drm_asahi_cmd_compute (200 bytes), zero-extending shorter payloads. - prior_vdm/prior_cdm move to 320/328 (render) and 136/144 (compute). They stay trivially satisfied: G18 retires each command before the next one starts. - scs_layout moves to 128. - Words G18 does not implement and does not report must be zero: timestamp copies, ray queries, the compute auxiliary allocation and intersection tables. - With DRM_ASAHI_RENDER_G18_RESOURCES (now bit 25) or DRM_ASAHI_COMPUTE_G18_RESOURCES (now bit 19) the payload is the complete command followed by the resources, and must be complete. USES_TEXTURE_STATE is now bit 18. The translation after parsing is unchanged.
T8152's two GPU coprocessors publish their own page-table roots and never touch the handoff page. Add UatFirmware::NoPeerRoots and the hooks it needs: - refuse a live firmware peer in the handoff page; - prepare, confirm and mirror the firmware-published high roots (mmu/t8152.rs); - preflight GPUVM maps against driver-owned aliases; - per-page range TLB invalidation; - downgrade cached mappings to uncached before unmapping them, with no cache flush request; - execution-context leases on contexts 3..63 instead of the slot allocator; - guard-page mappings and guard-tail aliases, with the GEM helpers they use. T8152 uses the default UatQuirks, the policy the earlier M6 port ran this UAT with. Everything new is under CONFIG_DRM_ASAHI_G18, so other GPUs' code is unchanged. Based on the earlier out-of-tree M6 port's T8152 UAT code, adapted to this tree's UAT code.
Adapt the imported backend to this driver. - It implements gpu::Gpu and queue::Queue as they are now. It uses the tracked-submission model, which is what the earlier port's batched VM_BIND and copy-before-sync submit amounted to. - Its timestamps are the shared CPU-written timestamp buffers, published at retirement. Their CPU path is now also built for G18. - The DRM device type, the IoMem/devres, MMIO, VMap and firmware request APIs, and the module's name are updated. - Its module parameters live in g18/params.rs. They are registered the way kernel::module! registers parameters, but only when the backend is built. - The T8152 SoC entry moves to hw/t8152.rs. - The G18-only PRIME import hook is dropped: this driver already gives core-created objects their driver data.
Add CONFIG_DRM_ASAHI_G18. With it, the module registers an "aurora-g18" platform driver for "apple,agx-t8152", as G16 does for its SoC. Its probe: - first checks the G18 parameters; - maps SGX and allocates the DRM device and DMA binding; - starts the firmware session the parameters select; - at the application stage, registers the render node over it; - in a diagnostic stage, keeps the firmware owner without one. The firmware session is retained until reboot, so manual unbind is suppressed.
Describe the M6 GPU in t8152-j873-gpu.dtsi: - the "apple,agx-t8152" node with its SGX window and PSD service blocks; - its eight reserved regions; - the GFX and GFX1 ASCWrap v8 mailboxes. Include it from t8152-j873g.dts. The reserved regions and the mailboxes stay disabled. A boot loader fills them from this boot's ADT and enables them, then writes the /chosen firmware receipt the driver checks.
T8142 (M5) ANS2 behaves like T8140: separate NVMe (non-secure alias) and NVMMU windows, post-M4 queue setup, three power domains. Allow apple,t8142-nvme-ans2 with apple,t8140-nvme-ans2 as fallback and apply the three-region reg rule to the T8140 family as well. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
The T8142 (M5) SART is the coastguard SART with sart-version 3, the same layout as T6000. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
The J813 (MacBook Air 13-inch, M5) ANS2 is laid out like T8140's: LSQ NVMMU, separate NVMMU, IOQ registers, 64-deep queues and broken FUA. As on every post-M4 controller the final shutdown sends SHN. aura (the J813 boot loader) leaves the controller and its RTKit session running for Linux to adopt. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
The J813 ADT lists E-cluster levels up to 2964 MHz (8) and P-cluster levels 11-20 above the 3516 MHz this tree stopped at. Add them; level 19 (4416 MHz) is below level 18 and left out. The SoC throttles the top levels when hot. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
The T8142 PMC (AppleT8142PMC, ADT pmc-pmgr 31 + 0x700000) takes DRAM and fabric floors per voter agent: PMP 0, CLPC 1, GFX 2, AP 3. iBoot leaves every rail enable at 0, so no vote is honoured and DRAM and the fabric stay at their lowest states (CPU DRAM latency 171 ns instead of 70 ns). Describe the PMC with its static voters and the CLPC agent. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
The 13.6" 2560x1664 panel (1600 lines below the notch) with a 500 nit peak (ADT backlight known-nits). The panel node makes the connector eDP and gives the DCP a backlight to drive. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
…eset - The pmgr block is 0x14000 long (the ISP and keyboard backlight power states sit beyond 0x4000). - The QSPI NOR flash with the NVRAM partitions (asahi-nvram, asahi-bless), its 200 MHz clock and the spi_p/qspi power states. - The PMP (DRAM and fabric DVFS coprocessor, registry-v2 firmware) with its DART, mailbox, power states and the J813 tunables. - The trackpad's AFE reset line (SMC GPIO 28, active low) instead of a firmware-managed reset. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
The M5 (T8142) GPU, laid out like the A18 Pro's: the sgx block, the gfx-asc and gfx1-asc firmware CPUs with their mailboxes, and the power domain, with addresses and interrupts from the J813 ADT. aura fills the uat-* regions from iBoot's raw-boot handoff, the gfx-data regions from the firmware DATA segments iBoot loaded, and the OPPs from sgx perf-states. apple,clpc links the GPU to the CLPC so that GPU work raises the DRAM and fabric floor. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
The M5 AVD ("Hibiscus", avd-version 4, avd-fw v5 tier 2 tunables): CM3
code and SRAM, the mailbox, its DART (SIDs 0-2) and the AVD_SYS power
state, from the J813 ADT.
Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
The M5 ISP is the A18 Pro's ISP17a at another base: the ISP block and its interrupts, the ISP DART with the remapped streams, the PMGR power states the firmware does not lock, and the J813 camera presets (1280x720, 1440x1080, 1080x1080 and 1920x1080), from the J813 ADT. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
aura runs the OS at EL1 under its monitor and adds a /psci node with enable-method psci for every CPU. Its CPU_SUSPEND is a WFI at EL2 that preserves the registers WFI loses on these cores, so one retention state for both clusters replaces idle=nop. Without a /psci node (raw aura, spin-table) cpuidle-psci does not probe. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
ANS2 with its mailbox, the coastguard SART (sart-version 3) and the apcie and ANS power states, from the J813 ADT. As on T8140 the NVMe registers are used through the non-secure alias and the NVMMU through the 0x60000 window; aura leaves ANS running for Linux to adopt. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
aura trains the apcie port 0 link to the N1 (AUS5 PHY, refclk buffer, N1 reset). Linux uses the root port as a generic ECAM host with port 0's 32 MSIs (apple,t8142-pcie-msi) and owns the DART and the endpoint. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
The watchdog for restart (and as the SMC's fallback), the PMU on SPMI with the scratchpad cells the SMC uses for power off, and the SMC reboot node. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
As on J873 the AOP's audio service owns the audio fabric and runs the MCA serializers: the CS42L84 headphone jack on admac-base-ns TX2/RX2, the four SN012776 speaker amplifiers on TX0 with their V/I sense on RX0. The AOP is laid out like T8140's (ascwrap-v6, asc-mailbox-v4, setup port). Addresses are from the J813 ADT. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
…ensor mode The 1280x720, 1440x1080 and 1080x1080 presets used the IMX958's binned mode (config 10, 1520x1440). In it the ISP firmware's AWB never leaves the setfile's default white point and the picture is magenta (mean U/V 160/168 on a grey room). In the full-resolution mode (config 7, 3040x2880), which 1920x1080 already used, it converges. Scale all presets from config 7, the crops doubled. With the firmware's AWB alone the J813 streams a neutral picture at all four sizes (mean U/V 127/127, two streams each), at 30 fps. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
On H17G the system endpoint announces powerlog-service on channel 1 with only ep-has-desc-mgr and interface-id, so parse_epic_service_init() returned -ENOENT and the service carrying the mNits reports never bound. Match such announces by their name, as props-less announces are (only for the H17G method profile, so H17P is unchanged). H17G publishes no NITS property, so register the backlight device from the first powerlog report instead (140 nits at boot on the J813). H17G firmware ignores the DAC words (bl_unk/bl_value/bl_power at swap+0x32f) and takes the H17P brightness encoding in the same swap bytes (activation at +0x354, binary64 nits at +0x35e, ceiling pair at +0x36e/+0x376), which the unserialized 26.6 request already spans. Factor the H17P encoder to take the swap record and use it from the flush on a brightness update. Tested on the MacBook Air M5 (J813): apple-panel-bl 0..500 nits; writes of 100/300/140 give DCP "send_brightness" at those levels and matching actual_brightness, and the panel follows. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
…pty dict
The M5's DCP (H17G) panicked with "app NMI" one hour after every boot,
taking the display with it. Its crash log shows "OSDictionary
deserialization failed": D114 CoreAnalyticsSendEvent was answered with
trampoline_zero on H17G, so the reply starts with 0 instead of an
OSDictionary. H17P already returns an empty dictionary ('d', 0x1004
bytes); D114's sizes are the same on H17G (0x1044/0x1004), so use that
reply there too.
DJ identified the analytics callback as the one-hour trigger.
Tested on J813 (M5 MacBook Air): two boots run past one hour (3799 s,
4269 s+) without a DCP crash; before, every boot crashed at about 3600 s.
Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
On the M5 (H17G) internal panel, DPMS off stopped the DCP pipe:
setPowerState(0) times out and the following setPowerState(1) is never
answered ("wait for power timed out, connector will be broken"), so the
panel stays frozen after a lid close or a compositor's output power off.
Keep the pipe running instead, as H17P soft DPMS does: DPMS off submits
a black, surface-free clear swap that also takes the backlight to 0 nits;
DPMS on only requests a brightness update, and the next frame restores
scanout and level.
Tested on J813: fbdev blank/unblank and sway output power off/on cycles
and a lid close/open; the firmware reports brightness 0 and back to the
previous level, no timeouts.
Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
The H17G (M5) DCP firmware blends the fourth byte of an XRGB surface as alpha, and it ignores the opaque-X property as H17P does. A compositor that picks XRGB8888 leaves that byte to whatever its renderer stored: the GPU-rendered sway output on J813 showed blue and cyan text as black and grey while the pixels in memory were right. Offer the overlay formats, which all carry alpha, on the H17G primary plane, so that compositors write the byte. Treat the fbdev console the same way as on H17P: an XRGB console with X = 0 stays black. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
Vm::map_at() reserves at most one guard page after a mapping. The M5 backend maps the driver's pools at the same address in each client VM with two guard pages after each, as it does when it allocates them. Add Vm::map_at_with_guard_size() and express map_at() through it. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
The kernel range of a VM, reserved at VM_CREATE for kernel-managed objects, is only handed to GPUVM. The M5 backend places its per-client objects in that range and checks that userspace commands stay out of it. Keep the range in the Vm and add an accessor. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
The M5 (T8142) 25G76 firmware runs application work in a TTBAT context whose lower half is the client VM's root and whose upper half is an empty root of its own; the firmware's upper mappings are not shared with applications. The context is claimed when the work is set up and published explicitly once it is prepared, and a later client takes it over without giving up the context number. Add M5ExecutionContext for that, built only with the M5 backend. It claims numbers from the execution context mask, publishes and retracts under the handoff lock, and a mapping change reaches it through the existing invalidation of every context that names a VM's root. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
The native 25G76 driver sets the low bit of the GPU's PMGR boot control word (SGX + 0xe90000) before either M5 firmware instance starts; the word reads 0x30000 on J813. Add the write, for the M5 backend only, refusing any other starting value. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
Add a backend for the M5 GPU (J813, G17G) running the 25G76 firmware (RTKit-3255.160.4), as ProbeConfig::M5 for apple,agx-t8142 behind CONFIG_DRM_ASAHI_M5. It changes nothing for the other SoCs. The 25G76 firmware has two coprocessors, GFX and GFX1, as the A18 Pro has, but a HAL300 interface that differs from the 26A428 and 25G83 builds the shared G17 code runs. The backend therefore builds its own initialization graph and talks to the firmware over its own queues, while using the shared parts of the driver: - the UAT is the shared one with published roots, adopted and mirrored as on the A18 Pro, plus the M5 application contexts; - user VMs carry a status and a job lifetime, and the backend uses the tracked submission model of file.rs; - the UAPI is the shared one. The backend reports VM_STATUS and SOFT_FAULTS and one hardware command per submission. The boot loader (aura) loads the firmware, checks both TEXT images against the 25G76 build and says so in /chosen/aurora,m5-gpu-firmware-profile; the backend refuses to start without it. One render pair and one compute queue serve all clients and are handed from client VM to client VM; a submission is polled to retirement before the ioctl returns. Renders and compute are admitted only within the state the firmware programs are known to handle, and refused with ENOTSUPP otherwise. There is no recovery yet: a job that fails stops both coprocessors and retains every firmware-visible object until reboot. The driver's pools are mapped at their own address in each client VM the job is handed to, except in the VM that owns them, and the compute storage is reserved together with the parameter buffer, so that its address is free in every such VM. Tested on J813 (M5, 8 GPU cores) on the aura one-shot trial boot, with Mesa j813, against the same Mesa on the J813 kernel this code comes from: GLES2 16016 pass, 930 fail (identical per case); GLES3 40832 pass, 3547 fail, 2 timeouts (identical but for one known flake); GLES31 32813 pass, 4517 fail (t70: 32804/4520; the 32 differing cases are 9 fail->pass and flakes); the sway desktop renders on the GPU from boot, also during the CTS runs. This consolidates the M5 work of Acelogic <miguelc4600@gmail.com> and the G17P render, UAPI and initdata encoders of DjDeveloperr <hey@djdev.me>, with contributions by Ryan Murray, Eryk Wieliczko and Chris Kearney, from the J813 kernel tree, ported onto integration's driver. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
integration/aurora added a bound-device owner to the platform driver data and a usage client to Gpu::new_queue. Create the owner in the M5 probe path like the other backends and accept the usage client on the M5 queue. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
The M5 (T8142) has a Hibiscus generation AVD with the T8140 register layout but its own firmware tunables and H.264 buffer layout. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
The M5 AVD (macOS CAvdMcpuHibiscus, avd-version 4) uses T8140's VP slot layout and v5 HEVC header with the avd-fw v5 tier 2 tunables. Its H.264 co-located motion vector buffer takes 128 bytes per macroblock instead of 64; with 64 inter frames decode with corrupted motion. Add AVD_QUIRK_H264_MV_128 and the t8142 variant. Tested on the J813 (MacBook Air M5): H.264, HEVC Main/Main10, VP9 and AV1 decode bit-exact against the software decoders through GStreamer v4l2codecs and FFmpeg's V4L2 request hwaccels. Also mark the device runtime-suspended before enabling runtime PM in probe, so a binding after a failed CM3 boot (e.g. missing firmware) starts from a clean state instead of an inherited runtime PM error. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
avd_boot() returned -ETIMEDOUT without a message when the CM3 did not raise FLAG0, which made a wrong firmware image or a missing power domain look like a silent probe failure. Log the flag value. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
The M5's ISP is the A18 Pro's ISP17a at another base address. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
The J813's ISP is the A18 Pro's ISP17a: the T8140 generation with the H17 firmware ABI, its own MMIO windows (the J813 ADT's dart-isp dapf-instance-0 ranges, including a DSID window and two new ranges), the PMP clock and bandwidth scratch registers, the T6031 mailbox interrupt enable and the SCL1 output path (T8142 has no BES scaler). Its IMX958 setfile (isp_2224_01XX.dat, the one macOS's appleh16camerad selects for sensor 0x958) keeps the lens shading row strides where H17 reads the offset's high half, as the T6040's do: setfile_stride_fixup zeroes them on T8142 too. The camera streams at 1280x720 and 1920x1080 (NV12). White balance stays at the setfile's default gains: the H17 firmware's AWB is semantic AWB, which needs the ANE. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
J873: enable capture-free GPU startup, PMC and QSPI
The rebased Thomas Glanzmann (@sithglan) port is already present. Preserve the current aurora-wip source tree, including later J873 fixes. Integration and exact-tree verification by Acelogic with Codex assistance.
The rebased Thomas Glanzmann (@sithglan) port is already present. Preserve the current aurora-wip source tree, including later J873 fixes. Integration and exact-tree verification by Acelogic with Codex assistance.
The rebased Thomas Glanzmann (@sithglan) port is already present. Preserve the current aurora-wip source tree, including later J873 fixes. Integration and exact-tree verification by Acelogic with Codex assistance.
…61106 media: qualify J813 AVD and ISP support on aurora-wip
Validate complete depth and stencil allocations in sample space, discard both single-layer strides, and derive the captured fragment controls for two- and four-sample RGBA8 tiles. Use the UAPI utile dimensions once when sizing tile lists. Keep unknown formats, layouts and render modes outside admission. Hardware qualification is pending.
Carries the work merged on aurora-wip since #1018 into the release branch: M5 T8142/J813 bring-up (#995 #996 #997 #998 #1001 #1002 #1003), T8152/J873 bring-up (#984 #1009 #1013 #1022), J813 AVD/ISP (#1026) and the selftest harness updates (#1014). The merge is clean; the 13 integration/aurora commits since #1018 are kept. Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
Mesa aligns a 32-bit render target sample stride to eight bytes. Preserve the bounded native sample layouts while accepting that real UAPI value, and include stride and positions in rejection diagnostics. The first physical stencil/depth probe passed; the initial multisample probe was safely refused by the four-byte stride check.
…61106 drm/asahi: enable bounded M5 stencil and 2x/4x rendering
Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com> Assisted-by: LLM
Contributor
Author
|
Merge-train gate (MTR2). Since the hardware run, integration/aurora gained #826 (T6050 cpuidle) and #1033 (DT bindings), and aurora-wip gained #1028 (M5 stencil/MSAA, 🤖 Generated with Claude Code |
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.
Brings integration/aurora up to date with aurora-wip b5a0fdd. This is the reverse of #1018: aurora-wip has had its own merges since that sync, so this is a normal merge commit (no rebase, no history rewrite). It's clean, with no conflicts. Three files merged automatically (
drivers/gpu/drm/apple/dcp.c,iomfb_template.cand the apple-dcpdesktop.pyselftest). In each one the two sides changed different hunks. The 13 integration/aurora commits since #1018 are kept: #1015, #1016, #1021, #1023 and #1024.Included from aurora-wip
#984 is still open against integration/aurora. This merge carries its aurora-wip version, so GitHub may mark it merged once this lands.
Build and host tests (buildbox, merge vs integration/aurora e5ed737)
The fleet build uses the fleet17 recipe (Fedora 7.0.13 base + asahi.config) with release
7.3.0-aurora-sync1106. Image, modules and dtbs built: rc=0, 5886 modules, asahi.config survival 0 mismatches, distro gate ok.tools/asahi/run-host-tests.pyThe new backends (
DRM_ASAHI_M5,DRM_ASAHI_G18,PCIE_APPLE_MSI) are off in the fleet config, so the M1/M2/M4 fleet kernels don't build them. Turned on in the fleet config, they build cleanly as part ofaurora.koalong withpcie-apple-msi(rc=0). One follow-up for the M5/G18 authors: withDRM_ASAHI_M5=y/DRM_ASAHI_G18=ybuilt in, a minimal KUnit config fails to build. The code callsbindings::__module_get(g18/boot/mod.rs, m5/live_boot.rs),cpufreq_cpu_get/put(g18/compat/host_path.rs) andkernel::firmware, and Kconfig doesn't express the dependencies (CPU_FREQ,RUST_FW_LOADER_ABSTRACTIONS, and a module-get binding). This doesn't affect the fleet config and isn't a regression on integration. It's left to the authors and not patched in this sync.Hardware: all four pass, no regression (one-shot boot of 7.3.0-aurora-sync1106, compared with each Mac's default; fleet default restored afterwards)
🤖 Generated with Claude Code