Repository navigation
Merge integration/aurora (merge train 06/11 batch) into aurora-wip - #1018
Merged
Merged
Conversation
The 1280x720 preset cropped the top-left 1280x720 corner of the 1920x1080 window that firmware configuration 5 delivers, without scaling. A 720p stream, which video calls often ask for, therefore showed an off-centre view about two thirds as wide as the 1080p one. Crop the whole 1920x1080 window and let the scaler bring it down to 1280x720, as the driver already does for the sizes it derives itself (such as 640x480 from the 1080p crop). The driver offered P010 only for presets whose crop equals their output, so the scaled preset would lose it and a 1280x720 P010 request would fall back to 1280x960. Accept a crop at the origin with the output's aspect ratio that is no smaller than the output instead. Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
With CONFIG_SCHEDSTATS=n, struct sched_statistics is an empty
____cacheline_aligned struct. bindgen 0.73.2 drops the alignment of a
zero-sized non-opaque struct and emits `pub struct sched_statistics {}`
with alignment 1. Rust then puts task_struct::stats at offset 792 where C
has 832, and later fields, including mm, move with it.
Commit 7b563df ("rust: require checked binding layouts for every
kernel build") made the layout assertions mandatory, so a build with
stock bindgen stops with E0080. Trees that pass --no-layout-tests still
build, with the wrong offsets.
Declare the type opaque. bindgen takes an opaque type's layout from Clang,
so stock bindgen emits #[repr(align(64))] and the assertions pass without
preparing tools/aurora-bindgen. The C layout does not change and no Rust
code reads these fields.
Update the documentation and the rust_is_available.sh warning, which said
default Asahi builds fail on this type.
Signed-off-by: Diljit Singh <hey@djdev.me>
On T8132 a display pipe votes for memory bandwidth and for a faster display clock through two PMC interfaces: bandwidth request (BWR) and boost. Each interface has an enable word with one bit per agent, and the PMC ignores the votes of a pipe whose bits are clear. macOS sets a pipe's two bits when the pipe's SYS power state powers on, and clears them before it powers off. Describe such a pair of bits as an interface-* child node of the PMC, provided as a power domain whose parent is the power state the enables need. The bits are set after the parent powers on and cleared before it powers off. Only the T8132 PMC has these words, so other PMCs may not have interface nodes. Signed-off-by: Erik Bourget <erik@ebourget.net>
… domains The T8132 PMC ignores an external display pipe's bandwidth and boost votes until the pipe's bits are set in the BWR and boost interface enable words. With them clear, the pipe's display clock stays at its lowest state, and a 4K mode at 120 Hz shows only the first lines of each frame. macOS sets the bits when the pipe's SYS power state powers on, and clears them before it powers off. Add the offsets of the two enable words in the "rails" region to the per-SoC layout: 0x2020 and 0x2028 on T8132, and 0 elsewhere, where an interface node is rejected. Provide each interface-* child node as a power domain that joins its parent domain like the cluster domains do. Power on sets the pipe's boost bit and then its BWR bit, and power off clears them, each with a read-modify-write under the PMC lock that is read back. If the BWR word does not take the change, the boost bit gets back the value it had before, and the call fails with -EIO. A bit claimed by two domains is rejected. The domain is IRQ safe: the PMGR power states that depend on it are, and genpd refuses an IRQ-safe subdomain under a parent that is not. The callbacks only take the PMC's raw spinlock and access MMIO. Like a voter domain, an interface domain starts from the hardware state: it is on if both of its bits are already set. With only one bit set it starts off and that bit is left alone until the domain powers on, which sets the other one; a failed power on keeps it as well. So the driver never drops a vote the boot loader left before the pipe powers off. When the PMC goes away, the domains' bits get back their values at probe, as the rail enables do. System sleep needs nothing extra: genpd powers the domain off and on with the domains that depend on it, and the words, like the rail enables, are not saved and restored. Show both words in the debugfs status, and add KUnit cases for setting and clearing a pipe's bits next to the internal display's boost bit, for a BWR word that does not take the change, for the boot states, and for the domain linked between IRQ-safe SYS and FE power states the way the PMGR driver links them, powered through a device on FE. Signed-off-by: Erik Bourget <erik@ebourget.net>
The PMC ignores the bandwidth and boost votes of an external display pipe until the pipe's BWR and boost interface enables are set, so the pipe's display clock stays at its lowest state and a 4K mode at 120 Hz shows only the first lines of each frame. Describe the enables of dispext0 (BWR bit 3, boost bit 1) and dispext1 (BWR bit 4, boost bit 2) under the PMC, each with the pipe's SYS power state as its parent. On the J713, where the PMC is enabled, make each pipe's FE power state depend on them as well as on SYS. genpd then powers on SYS, the enables and FE in that order, and powers them off in reverse, so the enables are only set while SYS is on. The other T8132 boards keep the PMC disabled, so the dependency lives in the J713 DT and not in t8132-pmgr.dtsi, where it would hold their FE power states back for good. The legacy-loader adapter copies the t8132-memory.dtsi nodes, phandles included, into a loader tree that lacks them. The interface nodes' parents do not resolve there, and the loader's PMGR states do not use the nodes, so drop them from the adapter's data. Signed-off-by: Erik Bourget <erik@ebourget.net>
An external sink can list timings, such as 3840x2160 at 120 Hz, whose 8-bpc RGB SDR colour elements the timing marks as needing DSC (DSCRequiredColorElementIDs). The TimingElements walk treated those like the unsafe ones (UnsafeColorElementIDs), so such a timing was never offered. Tell the two lists apart in the parser, and offer a timing whose only 8-bpc RGB SDR colour element needs DSC. An element that needs DSC is considered only at 8 bpc, and the lowest depth still comes first, then an element that needs no DSC over one that does. The choice is unchanged for every timing whose lowest uncompressed depth is 8 bpc or less. A DSC mode is checked against the link at 8 bpp, the lowest DSC target; the firmware picks the compressed rate itself. A DSC mode is never marked preferred and never taken as the fallback: it is used only when userspace picks it. Signed-off-by: Erik Bourget <erik@ebourget.net>
…ailbox The external DCP firmware asks for a realtime bandwidth mailbox at pipe start (D003, rt_bandwidth_setup_ap) and writes its bandwidth requests there every frame. The M4 backend declined the service, so the pipe never requested the bandwidth it needs at high pixel rates such as 3840x2160 at 120 Hz. macOS answers D003 for a T8132 external pipe with the pipe's 8-byte bandwidth request slot in the PMC as the mailbox. The mailbox length (8) selects the scratch-only protocol, with no doorbell, which the firmware reaches through its display register window 4. Take the slot from the DT, through apple,bw-scratch as on the other DCPs: the provider's reg range, the firmware display register index (which must be 4) and an offset. The slot must lie inside the DCP's disp-4 window. Answer D003 with it, and decline as before without one, as on the internal panel, whose node has none. The firmware then maps its register windows with D411 (mapDeviceMemoryWithIndex). Answer it for every disp-N window the DT describes, with the physical address as the DVA, as the desktop 26.x backends do: the firmware reaches those windows on its DART-bypass stream. An index the DT does not describe is refused. Signed-off-by: Erik Bourget <erik@ebourget.net>
The T8132 external DCPs take apple,bw-scratch for their 8-byte realtime bandwidth request slot in the PMC. Unlike the other DCPs, where the scratch register becomes an extra display register window, the slot lies inside the window the display index names (disp-4). Say so in the property's description. Signed-off-by: Erik Bourget <erik@ebourget.net>
… slots Describe the external pipes' realtime bandwidth request slots in the PMC, 0x2c000 (dcpext0) and 0x30000 (dcpext1) into the window both DCPs have as disp-4, and point each dcpext at its slot with apple,bw-scratch (display register index 4), so that the driver can hand the slot to the firmware as its bandwidth mailbox. Signed-off-by: Erik Bourget <erik@ebourget.net>
The J713 external DCP completes a direct swap (D590) several milliseconds after its A407 reply, up to about 10 ms whatever the refresh rate. With one swap in flight and the flip event sent at D590, a frame takes that time plus the compositor's own, which holds a 120 Hz mode to about 60 frames a second. Let up to two direct swaps be outstanding, set by the module parameter t8132_ext_swap_depth (2 by default, 1 to send every flip at its D590 as before): - A replied direct swap moves from the session's swap state to an ordered queue (oldest first) with its window, link generation and 5 s deadline, so that the next A406/A407 can go out. A third frame while two are in flight gets -EBUSY; the copy path stays refused while any direct swap is in flight. - Flip events: a frame submitted with nothing older in flight gets its flip event at once (iomfb_m4_ext_present_direct() returns 1); one submitted behind another gets it when the older swap completes or is given up. At depth 2 a flip event can therefore come before the firmware confirms that the frame replaced the previous one, so a compositor may draw into a buffer that is still on screen. - Completions: a D590 completes the swap it names, with its displayed flag, and the earlier swaps in its head-of-line list, which macOS completes as displayed. A swap it does not name stays in flight until its own D590 or its give-up. The firmware completes swaps in order; a newer swap completing first is warned about. A swap completed through a later swap's D590 is remembered, so that its own late D590 is dropped, and A406 handing out such an ID again orphans the start, as for given-up swaps. - Screen state follows the D590s in arrival order, a D590 that comes before its swap's A407 reply included. With displayed = 1 the swap's window is the one on screen; with displayed = 0 nothing on screen is retired, on the direct, given-up, copy and blank paths alike. Windows of both swaps in flight, and of every given-up swap that may still show them, stay mapped. Every direct completion, and every give-up, leaves the copy surfaces stale. - The give-up work expires queued swaps one by one at their own deadline, or at once when the link goes; settle, sleep, suspend and hotplug wait for or drop the whole queue. - D581 (swap_complete_head_of_line) is logged and left to the D590 or the give-up. With the PMC's display bandwidth agents enabled (a separate change), a 3840x2160 120 Hz DSC mode runs at 120 frames a second at depth 2. Signed-off-by: Erik Bourget <erik@ebourget.net>
TB_HOST_DP_HBR2_MAX caps every DP tunnel from the host router's DP IN adapters at HBR2, because both DP IN streams of the PHY must run at one link rate. A single display does not need that cap: alone on the host router a DP tunnel can run at HBR3 x4 (25920 Mb/s), which carries modes that HBR2 x4 (17280 Mb/s) cannot. Rename the flag to TB_HOST_DP_SHARED_RATE and decide the cap where DP IN and DP OUT adapters are paired, under the domain lock: - when one DP tunnel will be up on the host router, it may offer up to HBR3; when more will, each new one offers HBR2 at most; - when another DP tunnel is wanted (a second DP OUT adapter became available) while one is up above HBR2, that one is torn down and set up again between the same adapters at HBR2 first; the new one then takes its rate. Its display sees an unplug and a plug. If it cannot be set up again, pairing runs once more, and at the next event; - a tunnel alone that has to be reduced takes the combination with the most bandwidth (HBR2 x4 rather than HBR3 x2). Held at HBR2, or next to another tunnel, it keeps the rate and gives up lanes as before. A host DP tunnel is also counted at its cap at most in the bandwidth left for the others. Once its DPRX is done, the bandwidth it takes is worked out from what its DP IN adapter reports, which the cap does not bound: held at HBR2 between adapters that take HBR3, it could be counted at HBR3 x4, and a second display next to it would then get HBR2 x2 rather than x4. Nothing is set up again during a system sleep transition: from its PREPARE event (a PM notifier ahead of all others) until it is over, POST callbacks and the rollback of a refused PREPARE included (the gate is reopened by a work item that takes the system sleep lock after the POST event); a re-link admitted before holds the transition back until it is done. The re-link, and the pairing that needs it, then wait: a work item on the freezable workqueue hands them to the domain's ordered workqueue once the transition is over, behind any DPRX or teardown work queued before. The request also stays pending for the resume and thaw replays, and a failed runtime resume of the domain is retried a few times. The KUnit tests reach the connection manager's DP bandwidth accounting on a domain set up without hardware, reading adapter registers through a static stub on tb_cfg_read(); tb_cm_init() is split out of tb_probe() for that. The DP repair host test models the connection manager's private data: add the new work item there, and take the work initializers from tb_cm_init(). Signed-off-by: Erik Bourget <erik@ebourget.net>
Under TB_HOST_DP_SHARED_RATE two DP tunnels from the host router run at HBR2. When one of them goes because its display or its router was unplugged, the one left stays at HBR2 although it could now run at HBR3. Set it up again at up to HBR3, between the same adapters, once a debounce of 2.5 s is over, from the re-link work on the domain's ordered workqueue (so that DPRX or teardown work queued before it has released its paths): - only after a hot unplug of a DP OUT adapter or a router that took DP tunnels from the host router, and only for the one left alone below the rate both its adapters take. DPRX failures, failed activations and teardown for system sleep never lead to it; - once per unplug: the tunnel set up again is not marked; - dropped when another DP tunnel is up or can be paired by then, so an unplug and replug, or a display that drops and asserts HPD again while it retrains, causes no re-link. Until it is set up again the tunnel keeps its HBR2 cap and is counted at HBR2. When another one is wanted during the debounce, the tunnel is held at HBR2, its estimated bandwidth is worked out again and the debounce is stopped, all before the new one is given any bandwidth, so the new one gets HBR2 x4 next to it; - when a second DP tunnel takes the rate back down within a minute of such a re-link, the next debounce is doubled, up to 40 s; - not during a system sleep transition: tunnels that go then mark nothing, and a re-link that is due waits for the transition to end; a marked tunnel is looked at again at resume and runtime resume; - if the tunnel cannot be set up at the higher rate, it is set up at HBR2 again at once; if it is set up but does not come up (DPRX), it is set up at HBR2 again once its DPRX work is over, with its adapters kept for pairing and no new re-link up. If neither works, pairing runs again, at HBR2, and at the next event. The KUnit tests run the marking and the pairing on such a domain too. The DP repair host test models the connection manager: add the new fields there, with no tunnel re-linked at a higher rate. Signed-off-by: Erik Bourget <erik@ebourget.net>
The per-queue Proof skips the page-table walk only when it covers every range a submission names. Otherwise the whole request set is walked again, and every GPUVM map step moves the mapping epoch, which discards all cached proofs. Mesa records each frame's commands into command-buffer chunks at fresh addresses, so nearly every submission names at least one range the proof has not seen. Each of those re-walks every range in the submission, including the render targets: thousands of pages per full-resolution attachment, under the GPUVM exec lock. Under an unchanged epoch the cached proofs still hold, so walk only the ranges they do not cover and record the whole request set as before. If the epoch moved between the cache check and the walk, walk everything, as before. A GPUVM map step only maps addresses nothing maps yet: GPUVM runs the unmap and remap steps for any overlap first, and those remain full mutations. Every range a proof covers therefore stays mapped across a map step, so it no longer advances the epoch. Cached validation still pauses while the step's leaf writes are in flight. Signed-off-by: AxxzyWasTaken <axxzytte@gmail.com>
apple-pmu-rtc binds to the rtc child of the PMU's SPMI node, but the nvmem driver only populates children on Baku and Abbey PMICs. J616C's PMU is a Chapel with the Abbey alarm layout, so the node never became a device and the machine had no RTC wake alarm. Populate the children of a Chapel PMIC too. Signed-off-by: AxxzyWasTaken <axxzytte@gmail.com>
t6030.dtsi and t6031-die0.dtsi already use apple,chapel-pmic, and the M4 Max's main PMIC is a Chapel too. Signed-off-by: AxxzyWasTaken <axxzytte@gmail.com>
The tree inherits the J616s's Abbey at 0xe on nub-spmi0, which doesn't exist here: the J616C ADT has a Chapel at 0xb (spmi-chapelL1-b), so the SMC RTC offset, boot stage and shutdown cells point at nothing. The cells and the RTC alarm registers are at the Abbey offsets (ADT info-rtc_alarm_*). Describe the Chapel with those cells and its RTC, and keep nub-spmi0's interrupt controller, which the RTC's alarm uses. Signed-off-by: AxxzyWasTaken <axxzytte@gmail.com>
T6041 has up to eight AMCCs with four cache planes each, six on the binned part (ADT amcc-enable-mask 0x3f). List the 24 planes every T6041 has, which the MCC driver takes since the plane limit went to 32, and enable it on the J616C, where it was left disabled. Signed-off-by: AxxzyWasTaken <axxzytte@gmail.com>
Apple DARTs have address filter (DAPF) registers next to their translation registers. They restrict the physical addresses the DART lets its masters reach, and lose their contents whenever the DART's power domain is off. Allow them as an optional second register range named "dapf", so that a device whose coprocessor reaches fixed MMIO windows through the DART can program them after every power-up, finding them on the DART it already references. Signed-off-by: Erik Bourget <erik@ebourget.net>
The T8132 (M4) ISP has the T6041's register layout and firmware memory model: the bootloader loads the firmware's text and data segments, described as reserved memory at the addresses the firmware runs them at. It uses the same fourteen ISP power domains as the T8140, plus two camera sensor power states. Describe it in its own schema, as the T6041 and T8140 are, since its power-domain list differs from both. Signed-off-by: Erik Bourget <erik@ebourget.net>
The ISP's own power states are children of ISP_SYS at PMGR + 0x4000, in the ADT's order: CPU, CPU cores 0 and 1, FE, DPRX, secure, STS0, STS1, Pearl, BE, CLR, CVD and CVM, with the parents the ADT gives them. The camera sensor power states ISPSENS0 and ISPSENS1 are at 0x188 and 0x190; the ADT lists both among the ISP's power gates. Add them disabled, like ISP_SYS, and let the J713 policy enable them. They have no consumer yet, so they stay off. Signed-off-by: Erik Bourget <erik@ebourget.net>
Describe the ISP from the ADT: the coprocessor, mailbox, handshake and doorbell registers at the T6041's offsets, the mailbox interrupt, and three DART instances on one interrupt, which remap streams 1, 2, 3, 6, 7, 10 and 11 to stream 0. The first instance also has the address filter registers. The DART's 0xe0000000 window above the firmware's 20 MiB main memory is the host's allocation aperture. Everything stays disabled until a board describes its firmware memory. Signed-off-by: Erik Bourget <erik@ebourget.net>
On T8132 the ADT gives the first ISP DART address filter windows for the fixed MMIO windows the ISP's coprocessor reaches, among them the ISP power states and the DSID broadcast-clear windows. The filter loses its windows whenever ISP_SYS is off and powers up with arbitrary contents. The camera streams with the filter cleared and with it left as it powers up, but program it as the ADT describes rather than leave it undefined. Take an optional per-SoC window list, find the filter registers on the first iommus DART, and program and verify the windows after every power-up, before the coprocessor starts. The windows lie inside the fw_mmio windows that the driver already maps into that DART for the firmware, so the list belongs next to fw_mmio; the DART driver itself has no use for them. Two KUnit cases check that every SoC's windows lie inside its fw_mmio windows, and the register image the writer produces. Signed-off-by: Erik Bourget <erik@ebourget.net>
Resident firmware is started at probe and runs while the driver is bound, so the ISP stays powered from boot even when the camera is never used. On the J713 (T8132) that costs about 100 mW, at idle and in suspend-to-idle. The video device can be registered without the firmware: its formats come from the device tree presets. Let a SoC defer the firmware start and the camera detection to the first stream start; from then on the firmware stays resident as before. Opening the device or listing its formats does not start it, as desktop services open every video node at login. On the J713 the deferred start, from power-up to a detected camera, adds about 0.2 s to the first VIDIOC_STREAMON. Deferring moves what detection checks to that first stream: an unsupported sensor, unexpected metadata sizes or a missing channel now fail it instead of probe, and leave the camera unusable until the next boot, like any failed resident start. Presets the firmware lacks can no longer be dropped from the formats userspace has already seen, so a stream on one is refused with -EINVAL instead. For the same reason a deferred start keeps the device tree presets: the IMX958 configuration discovery and P010 preview, which add formats at detection, stay with starts at probe. A KUnit case checks that only resident firmware defers its start. Signed-off-by: Erik Bourget <erik@ebourget.net>
The T8132 (M4) ISP is T6040's: the same coprocessor layout, firmware interface and boot path, with the bootloader's firmware described as reserved memory. It differs in: - two AMCCs (ADT mcc amcc_aperture_count), so two DSID broadcast-clear windows, passed one per AMCC without padding slots; - no PMP_CTRL_SET: T8132's PMP scratch offsets are not established, and the camera streams without the command. The firmware's MMIO windows still cover those PMP registers; - the firmware's MMIO windows are also opened in the DART's address filter. The firmware is resident as on T6040 and T8140. A second start after its domains were cycled fails on T8132 too: the ISP CPU cores then do not reach their active power state. So it runs while the driver is bound, and T8132 defers its start to the first stream, keeping the ISP off until the camera is used. T6040 and T8140 have not been tested with the deferred start and keep starting at probe. Signed-off-by: Erik Bourget <erik@ebourget.net>
Describe the ISP's firmware memory and the front IMX958's 1080p and 720p presets, configuration 5 as on the J616s. iBoot loads the ISP firmware outside the kernel's memory, at addresses that move with the boot firmware, so the firmware text and data are empty placeholders. The boot loader fills them from the ADT's isp segment-ranges, sets the platform ID from the ADT isp node's sensor-type, and enables the ISP and its DARTs. Without that the camera stays disabled. The ISP stays off until the first stream. From then on it stays powered until the driver is unbound, as on the other resident ISPs; on the J713 that costs about 100 mW at idle: 4.13 W against 4.03 W with the ISP off, mean battery power over 180 s with the display on. Signed-off-by: Erik Bourget <erik@ebourget.net>
…tart Firmware that the boot loader loads changes its data segment while it runs, and does not start again from that state. Add hw->fw_restore: probe keeps a copy of the data segment, taken before the firmware first runs, and every start puts it back and clears the firmware main memory above it. Stopping the firmware puts it back too, also after a start that failed, and a shutdown stops a stream and such firmware, so that a rebound driver or a kexec'd kernel finds the firmware as it was loaded. No SoC uses it yet. Signed-off-by: Erik Bourget <erik@ebourget.net>
Firmware that is started again after it stopped (hw->fw_restore) has to be stopped for good. SUSPEND leaves the camera module powered, with its light on, and it stays so even across a reboot. Send STOP before POWER_DOWN instead, which also powers the module down; POWER_DOWN follows even if STOP failed. This replaces the unused STOP sequence that was kept under #if 0. Some coprocessors also need a quiesce before their domains go down. Its CPU core domains otherwise stay busy after the power-down and never run again, so the next start of the firmware fails. Add hw->coproc_quiesce, the register whose bit 25 requests the quiesce and reads back once it has happened, and hw->coproc_status. With a quiesce register, the power-down of a coprocessor that was started waits for it to reach WFI, stops it, quiesces it, and only then powers its domains down. A start that fails after the coprocessor was started thus also leaves it ready for the next one. No SoC uses them yet. Signed-off-by: Erik Bourget <erik@ebourget.net>
T8132 firmware starts again after it stopped, from its data segment as loaded, once the coprocessor was quiesced before the power-down. Stop keeping it resident: restore its data before each start, quiesce it before each power-down, and power the ISP down after every stream, as the older SoCs do. The camera then costs nothing when it is not in use, not only until its first use, and can be used again after the firmware stopped (for example across hibernation). The deferred start no longer needs resident firmware, so it becomes deferred_start: the camera is detected at the first stream, which with firmware that starts again boots it a second time to stream. A deferred detection that fails is reported to the stream instead of deferring a probe. Metadata buffers are reset for each stream of firmware that starts again, as for resident firmware: none survives the restart. Signed-off-by: Erik Bourget <erik@ebourget.net>
Signed-off-by: Diljit Singh <hey@djdev.me>
rust: bindgen: make sched_statistics opaque Signed-off-by: Diljit Singh <hey@djdev.me>
When the boot sequence has started the firmware CPU, the driver keeps its module reference for as long as the device lives, because the firmware may still run and the module must not be unloaded under it. That is the normal result of every successful boot, but it was logged as a warning, so every M2 boot log carried a warning from a driver that was working. Log it at info level. A boot that fails after the CPU has started is still reported with dev_err() just below. Assisted-by: LLM Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com>
On M1 and M2 Macs m1n1 does not bring up the PCIe-C tunnel controller, and the kernel only cold-initialises it on the generations the PCI driver admits. Every USB4 port then logged a warning at probe, two on the M2 and three on the M1 Pro, although the router works and nothing failed: PCIe tunnelling is not offered on these ports. Say so once per port at info level. Errors while mapping or resetting a tunnel that is available are still reported as before. Assisted-by: LLM Signed-off-by: Ryan Murray <81541646+RyanTheTide@users.noreply.github.com>
arm64: dts: apple: t604x-j614-j616: scale the 720p camera preset
arm64: dts: apple: t6041: Chapel PMIC, PMU RTC and 24 cache planes on the J616C
nvmem: apple-spmi: populate the RTC child of a Chapel PMIC
drm/asahi: g17: walk only uncovered ranges when validating a submission
pmdomain: apple: pmc: enable the M4 external display boost, for 4K at 120 Hz
drm/apple: 4K at 120 Hz on the M4 MacBook Air external displays
thunderbolt: apple: HBR3 for a lone external monitor on the M4 (T8132), HBR2 when a second one comes
J713: enable the camera (T8132 ISP)
Report two normal probe states at info level (ANE pin, PCIe-C without preinit)
Contributor
Author
|
Status (MTR, 20:05): trial merge ecc48aaa is clean. Host tests 185/185 and apple-dcp selftests 86/86 pass on it. The full Image/modules/dtbs build with the fleet config is about 24k lines in on a loaded buildbox, with 0 errors so far. drm/asahi ( |
Contributor
Author
|
Gates done (MTR): the trial merge ecc48aaa built clean (Image, modules and dtbs with the fleet config, rc=0, 0 errors). Host tests are 185/185 and apple-dcp selftests 86/86. Since then, integration gained #1015 (two dev_warn -> dev_info lines) and aurora-wip gained #998 and #1013. Re-merging those heads (d0d5b94b) is clean. The only file both sides touched is |
RyanTheTide
added a commit
that referenced
this pull request
Nov 6, 2026
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
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 aurora-wip up to date with integration/aurora a620f41. That tip is the tested merge-train batch: #1005, #994, #930, #658, #1006, #1007, #1008, #531, plus #992. aurora-wip has its own merges since 11eccbe (the J813/M5/T8152 work: #995, #996, #1002, #1003, #984, #1009, #1014, ...), so a fast-forward isn't possible. This is a normal merge.
run-host-tests.pygive 185/185 and apple-dcp selftests 86/86.🤖 Generated with Claude Code