[sithglan]

Four fixes to integration's drm/apple for the MacBook Air M5 (J813, H17G DCP firmware), which otherwise already drives the J813 panel:

• Backlight control: H17G announces powerlog-service with only ep-has-desc-mgr and interface-id, so the service carrying the brightness reports never bound ("AFK[ep:20]: failed to extract init props: -2"); match it by name for the H17G method profile only. H17G ignores the DAC words and takes nits in the H17P swap encoding, so the flush uses that encoder on H17G.
• CoreAnalyticsSendEvent: answer H17G with the empty dictionary as on H17P. The zeroed reply fails the firmware's OSDictionary deserialization and the DCP panics with "app NMI" one hour after boot.
• Soft DPMS: blank the H17G internal panel instead of stopping the pipe, so the panel comes back after lid close and idle-off.
• Colours: H17G blends the fourth byte of an XRGB surface as alpha and ignores the opaque-X property, as H17P does. The primary plane now offers only formats with alpha, and the fbdev console is ARGB as on H17P. Before this, sway scanned out XR24 and blue and cyan text showed as black and grey on the panel, although the pixels in memory were right.

Tested on the J813: backlight control was verified on the J813 kernel this comes from (apple-panel-bl 0-500 nits, actual_brightness follows, the powerlog error gone; DPMS and CoreAnalytics as described above). On the rebased tree (integration/aurora 11eccbe with all nine J813 branches) drm/apple drives the panel through a full boot; the brightness and DPMS retest on this exact base is still to be done.

Stability caveat: a second boot of the same image hung about 38 s in, just after the NTP step set off the daily fstrim/apt timers, with no panic record (no pstore). The first boot went through the same timer burst and stayed up for minutes. Until the hang is understood, the combined tree is not proven stable across reboots.

cc @Acelogic @DjDeveloperr @RyanTheTide @LiamRay10

[MrNews89]

On J815/T8142 (15-inch M5 Air, 25G76), GPU/MSAA/AVD/Wi-Fi pass, but DCP startup times out. D408 requests service PROV (0x50524f56), arg=0. The public H17P handler rejects arg 0; Linux has a 24 MHz primary clock and no clock-194. Same-boot ADT has 174 clock-frequency cells and disp0 IDs 0x249/0x1af, outside the older id-256 lookup.

On the working J813 boot, does D408 request PROV/0, and what rate/source supplies the reply? Which exact combined kernel and aura commits produced the working panel, and is another provider-property/clock handoff required?

[Acelogic]

@MrNews89 Thanks for the trace. I checked aurora-wip at 5778921cef98: the clock decoder only accepts 0x154 and 0x194, and does not inspect service. For ID 0, it returns -ENOENT; the D408 wrapper then replies with a zero rate. So the mismatch you identified is present. This PR does not change that path. The zero reply alone does not establish the intended rate or whether it fully explains the startup timeout.

The working J813 boot reported here used 11eccbedc3ed plus the nine J813 branches. The newer report in #997 documents a working panel after rebasing onto c6cc36e4, booted as 7.3.0-aurora-j813-rb+. Those reports do not identify the final combined kernel SHA, installed aura SHA, or D408 request/reply, so I cannot confirm that the working J813 also requests PROV/0.

@sithglan Could you share, from the working J813 boot:

• The combined kernel SHA and installed aura revision, including any local changes.
• The raw D408 request/reply and the source of the returned rate.
• The corresponding disp0 ADT clock properties and Linux DT clock/provider properties.

That comparison should help distinguish H17G callback semantics from a missing clock/provider handoff. We do not yet have evidence that the 24 MHz primary clock is the correct reply to PROV/0.

[sithglan]

@MrNews89 @Acelogic Both J813 questions: yes, the working J813 makes the identical D408 call, and nothing supplies the rate — the reply is a plain zero.

1. The raw D408 request/reply on the working J813 (live configured boot, kernel 7.3.0-aurora-j813-rb+ #9, integration/aurora c6cc36e4 plus the nine J813 branches; the same four lines also appear in the 7.3.0-aurora-j813+ boot on 11eccbedc3ed and in the 2026-11-01 7.1.12-aurora-j813-pm+ boot, so it is not kernel-base dependent):

[1.584020] apple-dcp: RTKit: peDCP_H17GSCD.cpp:13076: IOMFB updateFrequencies: minimum-frequency property not found, using getClockFrequency(0) instead.
[1.584413] apple-dcp: unknown display clock ID 0x0
[1.584670] apple-dcp: RTKit: peDCP_H17GSCD.cpp:13079: IOMFB updateFrequencies getClockFrequency returned pixelClock = 0
[1.584981] apple-dcp: RTKit: peDCP_H17GSCD.cpp:13108: IOMFB updateFrequencies EDT ERROR: getClockFrequency(0) (0) < videoClock 138521008! Giving up on frequencies.
[1.586355] apple-dcp: RTKit: ipeDCP_H17GSCD.cpp:1646: IOMFB: videoClock is zero, defaulting to 138521000

It repeats twice per boot (two updateFrequencies calls), and the panel comes up regardless (card1-eDP-1 connected, 2560x1600). Frame programming then continues: set_disp_perf_state: video_clock = 138521000, disp_clock = 180077280, program_frame_size: pixel_clock 277042000, vid0 138521000.

So the arg is 0, in the same slot your trace shows as PROV. The service 4CC is not printed on our side because trampoline_get_frequency_h17p() never inspects it, but it is the same firmware call. The reply is rate 0 from no source: apple_dcp_h17p_clock_rate() (dcp-link.h) accepts only 0x154 → dcp->clk (the DT's single 24 MHz fixed-clock clkref) and 0x194 → clock-194 (optional and absent on J813, clk_get_rate(NULL) = 0); ID 0 hits the default, returns -ENOENT, and the wrapper writes 0. The 24 MHz primary clock is not what answers this — on J813 nothing answers it, and the H17G firmware recovers internally to its 138.521 MHz videoClock default. A zero reply to PROV/0 is therefore evidently not fatal to this H17G firmware build. Unless the J815 firmware revision differs, I would look elsewhere for the startup timeout first.

2. Clock properties, DT and ADT. J813 ADT disp0 clock-ids = [585, 431] = [0x249, 0x1AF] — the same IDs as the J815 — but the J813 ADT carries no clock-frequency table for disp0 (only two clock-frequency properties in the entire ADT, neither under disp0; the J815's 174 cells are the machine difference). Linux DT: the dcp node has exactly one clock — clkref, 24 MHz fixed-clock (phandle 7, clock-frequency 0x16e3600); no clock-194, no apple,clock-ids. Provider property (VORP) requests are short-circuited with a cleared reply on the H17G method profile, D003 bandwidth answers from the pmgr_dcp bw-scratch/bw-doorbell cells, and D408 replies zero as above. No other provider/clock handoff runs, and the panel works. If J815's firmware does block on PROV/0, the candidate fix is to extend the decoder past 0x154/0x194 and answer the ADT clock IDs 0x249/0x1af with real rates from the 174-cell clock-frequency table that only J815's ADT carries.

3. Exact commits behind the working panel.

• Kernel: rb/j813-boot top 2648f372935e = integration/aurora c6cc36e + nvme 44e3ab5 (J813: internal NVMe on the MacBook Air M5 (T8142 ANS2) #995), platform 5c9cbb2 (J813: WFxT, T8142 idle and i2c-pasemi resume #996), soc b8c71bb (J813: T8142 mailbox, PMC, CLPC (GPU input) and PMP #997), wireless 2d950321 (J813: N1 Wi-Fi and Bluetooth on the MacBook Air M5, with real MSIs #998), media 38c26d2 (J813: AVD video decoder and ISP camera on the MacBook Air M5 #999), sound e42e2b8 (J813: AOP sound on the MacBook Air M5 (speakers, jack, microphones) #1000), dts a175068 (arm64: dts: apple: t8142-j813: the MacBook Air M5 device tree #1001), display 5e98b68 (J813: H17G backlight, CoreAnalytics reply, soft DPMS and colours (MacBook Air M5) #1002), gpu-m5 f4dadb0 (J813: the M5 GPU as an m5/ backend of drm/asahi (MacBook Air M5) #1003). No local source changes beyond those merges; five Kconfig options were re-enabled in the build config to match /proc/config.gz (CONFIG_APPLE_CENTAURI, CONFIG_BT_CENTAURI, CONFIG_PCIE_APPLE_MSI, CONFIG_DRM_ASAHI_M5, CONFIG_SND_SOC_APPLE_T8152_AOP_AUDIO). Image.gz sha256 900b8f7b10cf…, DTB t8142-j813-desktop.dtb sha256 fcac073d1b4e….
• Aura: the enrolled Mach-O object reports 1.0.0b5-g7edb514a for both stage versions (read from /proc/device-tree/chosen/asahi,m1n1-stage{1,2}-version; iBoot mBoot-20457.41.3) = rb/j813-all: main 7edb514a + n1 Moved · 🧩 T6020 · M2 Pro — board index #79 21c3f707, gpu-handoff Moved · 🧩 T6021 · M2 Max — board index #80 1c01e9f9, isp Moved · 🧩 T6022 · M2 Ultra — board index #81 f81abefd, aura-try Moved · 🧩 T8122 · M3 — board index #82 b6dac114, dcp-segment Moved · 🧩 T6030 · M3 Pro — board index #83 cc2819b3; packaged as aura-j813-audio.macho, sha256 413346bc624f8fb8592ec2e7ab9282241f0ad16d903d256aafb0470217305ffc. The dcp-segment fix (skip the __OS_LOG segment iBoot leaves unmapped) is part of this working aura — if J815 is not running an aura with that fix, I would check it before touching the clock decoder.