[AxxzyWasTaken]

Replaces #1089, rebased onto current integration/aurora as requested. The review asked for a reworded commit message ("at least 400 ms"), which needs new history, so this is a new branch; #1089's branch is left as it was.

Lowers power on the M4 Max in everyday use. On T6040/T6041, any reported GPU work holds the top memory and fabric floor, and the GPU runs at full effort for quiet work.

• CLPC: the GPU driver reports its busy share, and the floor follows a per-SoC table in struct apple_clpc_hw (DCS 1, 2, 4, 5 and fabric 0, 0, 0, 2, split at gpu_busy_mid 160, gpu_busy_high 500 and gpu_busy_top 800 permille). Going down happens at least 400 ms after the last change. CPU map quarters now use 4.512 GHz for both clusters, and the T6040 map is lower.
• G17: a light effort governor, half effort after four quiet windows, with separate entry and exit points. note_submission() no longer skips it.

M4 Max, AC, 120 Hz	Old	New
Scrolling	24.9 W	22.1 W
Page workload	23.84 W	22.73 W, score -0.9 %

Effort sweep on a 1080p30 clip: full 14.0 W, half 10.4 W.

Changes since #1089 (review by RyanTheTide):

• gpu_busy_top, gpu_busy_high and gpu_busy_mid are apple_clpc_hw fields next to gpu_busy with the same values for T6040/T6041, no longer 0644 module parameters.
• The commit message says the down-step happens at least 400 ms after the last change.
• apple_clpc_status_show() reads gpu->busy, busy_valid and level under the lock and no longer calls apple_clpc_gpu_level(), so reading debugfs can't move the level.
• tools/asahi/clpc-gpu-demand-tests.py extracts apple_clpc_gpu_level(), has a max_t macro and the new struct apple_clpc_gpu fields, and adds cases for no share reported, below gpu_busy_mid, between the thresholds, the 400 ms down-step hold and its restart, plus three negative controls.
• Rebased over Neo ANE: hold DRAM and fabric floors while the engine runs, keep gating off back-to-back (MobileNet 2.3-2.5 -> 1.25-1.31 ms) #1137: struct apple_clpc_hw and the T6040 table keep both the ANE fields and the busy-share fields. The T6040 comments that said a busy CPU cluster or GPU work gets DCS 5 / fabric 2 now match the new tables. The CPU map is unchanged from soc: apple: clpc, drm/asahi: g17: busy-share memory floor and light effort for T604x #1089.
• The G17 commit is unchanged.

Tested: the logic has been the daily setup on my M4 Max since 5 Nov (7.3.0), with no GPU recoveries from it. For this exact head: python3 -I tools/asahi/run-host-tests.py --only with clpc, usage, g15-queue-credit, asahi-m4 and g17 passes (35 runs), and the CLPC demand test passes with all 15 negative controls. drivers/soc/apple/clpc.o and drivers/gpu/drm/asahi/g17/clpc.o build with LLVM=1 W=1 with no new warnings. Not done: KUnit was not run, and before the rebase this head had not been booted.

Built and booted, 12 Nov (the whole kernel, Rust drm/asahi included): rebased onto integration/aurora c6e08489, where clpc.c and g17/mod.rs conflicted. The GPU demand takes the busy-share column but never goes below a chip's new .gpu minimum; note_submission() keeps the new note_waiters() call and takes its effort from submission_effort(). The CLPC demand test passes with all its negative controls. This code is my daily kernel now on the M4 Max, together with #1664: a deep sleep, a desktop logout after the wake, and a game session, with the g17_light_* parameters taking effect and no GPU errors or recoveries in the log.

Please check:

• The CLPC table is shared with T6040, and I haven't tested an M4 Pro.
• The light effort governor is in the shared G17 code, so it applies to other G17 SoCs too. aurora.g17_light_effort=0 turns it off. Tell me if you'd rather have it scoped to T604x.

[RyanTheTide]

This no longer merges into integration/aurora: drivers/soc/apple/clpc.c conflicts with #1405 (T6050 CPU floor, merged as 1682b11). Please merge the current integration/aurora into the branch (or rebase) and keep both the T6050 floor and the T6041 busy-share path.

[RyanTheTide]

@AxxzyWasTaken thanks for the rebase and the power numbers. Three things before this can go in:

1. apple_clpc_hw_t6040 is also the M4 Pro's table. The CPU map change (DCS 1,1,3,4 and fabric 0,0,0,0 at the top, and level_khz for the E cluster) lowers the memory floor a busy CPU gets on the M4 Pro, where the comment above the table measures 237-242 GB/s at DCS 5 / fabric 2. Please give T6041 its own table and leave T6040 as it is, or add M4 Pro measurements. We can run the M4 Pro side if you split it.
2. The light-effort governor is in the shared G17 code and on by default, so it also changes the A18 Pro and M4 Pro. A 120 fps game reads about a third busy, under the 350 entry point, and stays under the 750 exit point once it runs at half effort. Please scope it per SoC (match data, T6041 first) until it has frame-time results on games, not only power.
3. Please replace the five g17_light_* module parameters with per-SoC values, as was done for the CLPC thresholds.

[AxxzyWasTaken]

Thanks. All three are in 33db416, on top of a merge of the current integration/aurora (e6588ee, clean).

1. T6041 has its own CLPC table. apple_clpc_hw_t6040 is back to exactly what integration/aurora has, so the M4 Pro keeps DCS 1,2,5,5 / fabric 0,1,2,2 and its ANE cluster floor. The M4 Max shares the apple,t6041-clpc compatible, so apple_clpc_machine_hw() picks the new apple_clpc_hw_t6041 on an "apple,t6041" machine. That table carries the CPU map, level_khz, the busy-share ladder, the Low Power Mode values and the ANE rails, with the J616c measurements in its comment. It leaves out the ANE cluster floor, which was measured on the M4 Pro only.
2. Light effort is per SoC. The G17 Config has a new light_effort: Option<power::LightEffort>. Only T6041's base config sets it, which covers both of its firmware builds. T6040, T6050, T8140 and T8142 have None, so every submission runs at full effort there and the busy share is reported unscaled.
3. No module parameters. The five g17_light_* parameters are gone. The thresholds come from that per-SoC value, and power::configure_light() loads them when the GPU starts.

Tested: Image and modules build at W=1 with no new warnings in drivers/soc/apple or drivers/gpu/drm/asahi, and tools/asahi/clpc-gpu-demand-tests.py passes, with the busy-share test now on the T6041 table. Not run on hardware yet, and there are no frame-time results for light effort yet, so it stays limited to T6041 until I have those.

[RyanTheTide]

@AxxzyWasTaken thanks, this addresses all three points. The T6040 table matches the base again, the T6041 table is picked by machine compatible, and light effort is off everywhere except T6041 with no module parameters. Two things before merge:

1. Please boot this head (33db416) on the M4 Max and post the scrolling power and a GPU smoke result. The light-effort and table code moved since your last numbers.
2. Small race in report_busy(): two submitters that both see elapsed >= BUSY_WINDOW_NS each swap BUSY_WINDOW_TOTAL, and the second one reports about 0 permille for the same window, which on T6041 also counts as a quiet window. A compare_exchange on BUSY_WINDOW_START (only the winner reports) closes it. Optional: clearing busy_valid when the GPU goes inactive, so a new burst does not start from the share it had before a long idle.
   We will run the M4 Pro and A18 Pro side to confirm nothing changes there.

[AxxzyWasTaken]

Thanks. The race is fixed in 2a87da9: report_busy() now does a compare_exchange on BUSY_WINDOW_START, and only the submitter that wins it swaps the total and reports. I also took the optional part: apple_clpc_gpu_set_active(false) clears busy_valid, so a burst after idle starts at the top of the ladder.

Boot of this head on the M4 Max (J616c), release 7.3.0-j616c-pr1369, built with the daily kernel's config:

• Boots. The CLPC status shows the T6041 table picked by machine compatible (dcs map 1,1,3,4, soc map 0,0,0,0). Light effort engages when the GPU is quiet (effort_full=false at idle).
• GPU smoke. vulkan-msaa-mrt (2x, including a 6-target spilling layout), vulkan-msaa-xfer and aurora-tile-visit all PASS, plus 6 repeated tile-visit runs. No G17 errors or GPU recovery in the kernel log. aurora-r11g11b10f fails only with the Mesa build installed on the Max; with the test build it was written against, it passes on this kernel too. So it's userspace, not this PR.
• Scrolling power: not done yet. The run was cut short when the Max was rebooted onto its daily kernel by other work. Note also that this head has no backlight device (the daily's display patches aren't in it), so its total power wouldn't be directly comparable to the earlier numbers anyway. I'll post the scrolling result from a boot that has the backlight.