Repository navigation
Conversation
erykwieliczko
left a comment
There was a problem hiding this comment.
Thanks, reviewed at 28f257d57f.
Base. #274 is merged into integration/aurora (ba46b626), so please retarget this PR to integration/aurora. No rebase is needed: t6031-die0.dtsi hasn't changed there since e34ca781b5, and the compare shows only this commit on top.
The change matches the T6030 patch from #274 line for line: the three Chapel cells (0x2000, 0x2008, 0x200e), interrupts-extended = <&nub_spmi 2 IRQ_TYPE_EDGE_RISING>, wakeup-source, and interrupt-controller plus #interrupt-cells = <2> on nub_spmi. The cell names and the interrupt are what apple,smc-rtc.yaml describes. It also fixes an existing schema violation: apple,spmi.yaml already requires interrupt-controller and #interrupt-cells for apple,t6031-spmi, and today's T6031 node has neither. That's worth a line in the commit message.
One note on scope. t6031-j514c and t6032-j575d (M3 Ultra) build from t6031-die0.dtsi too. With v4's patch 3, the driver writes to the PMU at probe whenever the alarm cells are present: before it requests the interrupt, it disarms the alarm (read-modify-write of 0x2000, mask 0x200e set to 1). J514C is the same SoC, so that's almost certainly fine. For J575D, if anyone has its ADT, a quick check that the primary PMU's alarm registers and the SPMI interrupt match would settle it. Otherwise, the commit message could say that only the J516C ADT was read, as the PR description already does. Not a blocker from my side.
Your J516C runs (3/3 with and without the GPU, woken by apple_spmi 2) cover what this commit adds. Looks good to me.
🤖 Generated with Claude Code
The J516C's primary Chapel PMU (ADT /arm-io/nub-spmi0/spmi-chapelL1-b, is-primary) keeps its RTC alarm where the T6030 one does: info-rtc_alarm_ctrl 0x2000 (enable mask 0x40, event mask 0x2, monitor mask 0x1), info-rtc_alarm_offset 0x2008 and info-rtc_irq_mask_offset 0x200e (mask value 1), next to info-rtc 0x2002 and the 0x2100 offset cell already described. It raises peripheral interrupt 2 (interrupts = <2>) of nub-spmi0 (interrupt-parent), which is the controller at 0x2a1014000. Make the controller an interrupt controller, add the alarm cells to the PMIC layout and give them, the interrupt and wakeup-source to the SMC RTC, as t6030.dtsi does, so a timer can wake the system. The 4-byte compare cell and the rising-edge type are not in the ADT: the PMU alarm driver reads a 32-bit compare value and the SPMI controller takes only rising edges. The SPMI binding already requires the interrupt-controller and #interrupt-cells properties of an apple,t6031-spmi controller, which today's node lacks, so this also fixes that schema violation. Tested on an M3 Max J516C whose live tree had these same properties (its boot loader's device tree predates them, so a local patch added them at boot from the ADT): rtcwake -s 30 woke suspend-to-idle through the alarm in 6 of 6 runs. Only the J516C ADT was read; J514C, T6032 and T6034 include this file and were not checked. With these cells the PMU alarm driver writes to them at probe, to disarm the alarm, on every board that includes this file. Generated-by: LLM Signed-off-by: Samuel Carreño <soyminero11yt@gmail.com>
28f257d to
8fda934
Compare
|
Thanks, Eryk. Retargeted to The commit message now says it also fixes the existing schema violation (today's T6031 SPMI node has neither |
Problem. On the M3 Max (T6031) the device tree has no RTC alarm, so with this series
rtcwakeand timed wake-ups still don't work there.Change. One commit on top of #274, now in
integration/aurora:arm64: dts: apple: t6031: Describe the RTC alarm, the T6031 counterpart of patch 4. The J516C's primary Chapel PMU has the alarm at the T6030 registers (0x2000/0x2008/0x200e) and raises peripheral interrupt 2 of nub-spmi0, as its ADT says. nub_spmi becomes an interrupt controller, whichapple,spmi.yamlalready requires forapple,t6031-spmi, and the SMC RTC gets the three cells, the interrupt andwakeup-source.Checked on a J516C (M3 Max, 64 GB) running integration
2f725546d6acwith v3 of your series (12aec36c2267, before the split), #259 and my local J516C patches (HDMI on dcpext0, G15, a panel power-off board flag). Its boot loader's device tree predates the alarm, so a local patch added this commit's properties at boot from the ADT. The DTB built from this branch has the same cells, interrupt and controller properties as that live tree.rtcwake -s 30+ s2idle, GPU driver not loaded: 3/3 woke on the alarm and resumed with no PM errors, panel back.apple_spmi 2,macsmc-rtc), the GPU ran compute jobs after each resume, and its GFX domain stayed on through every run. That part needs a separate G15 change: drm/asahi: g15: keep the T6031 GFX domain on through system sleep #288.W=1and no new warnings, andcheck-commits.pyis clean.Not checked.
t6031-die0.dtsi, but only the J516C ADT was read.dtbs_check: no dt-schema here.Left out. Aurora has no T6031 external display support yet, so patch 5 has nothing to act on there. My T6031 HDMI sleep changes (dispext0 kept powered through sleep, an optional DISPEXT0 release) stay with the HDMI port they need. The panel power-off board flag went with the panel patch to #283: #284.
🤖 Generated with Claude Code