[sithglan]

Base: integration/aurora (673f618). Branch thomas/fw27-dcp-backlight, two commits. They were found while bringing the J813 (M5 MacBook Air) up on the macOS 27.2 stub (#1683), and both also apply to 27.0.

drm/apple: dcp: Send a present without a surface at the completed level

With the panel backlight active, iomfb_apply_backlight_h17p() drops every present that dcp_backlight_prepare() refuses. dcp_bl_prepare() refuses a present without a surface (-ENODATA), because such a present cannot apply a new level. As a result the whole present is dropped, not only the level. On firmware 27 the first present of every new KMS client hits this: modetest and kmscube log "present dropped: backlight prepare -61" and "swap failed!".

A present without a surface is now treated as one with nothing to reserve. It carries the last completed level and is sent, and a pending level waits, still dirty, for the next present with a surface. Only the H17P/firmware-27 path asks without a surface; the M4 and 14.7 callers always pass one. There is a new KUnit case, v14_bl_surfaceless_present. It fails without the change (-ENODATA instead of -EALREADY) and passes with it.

drm/apple: afk: T8142: Bind powerlog-service on firmware 27

The M5's DCP announces powerlog-service on ep:20 with only ep-has-desc-mgr and interface-id. AFK matches such a service by its announced name, but only for the H17G method profile, and a T8142 on firmware 27 runs the default profile. So the service was never bound ("AFK[ep:20]: failed to extract init props: -2"), and its mNits reports could not reach dcp_backlight_takeover().

The name fallback now covers a T8142 on firmware 27 too: the H17P-generation processor (hw.firmware_compat) that probe admits as firmware 27. The service-rebind host test's struct apple_dcp gets that field. On 27.2 the service binds on channel 1. That firmware sent no report in the first minutes after boot, though, so the backlight still starts from the fallback level there. The loader's level is in NVRAM backlight-nits (0x008c0000, 140 nits), and userspace restores it.

Testing

Tested on the J813 under the macOS 27.2 stub, on top of #1683, with aura aurora-silicon/aura#192 (chainloaded in place). The hardware run used an equivalent check, of_device_is_compatible(..., "apple,t8142-dcp"), which the host test cannot compile; on the J813 both conditions hold:

• AFK[ep:20]: new service powerlog-service on channel 1, and no init-props error.
• modetest -M apple -s 43@41:2560x1600@AR24 -v flips at 60.00 Hz, and kmscube starts, with no "present dropped" and no "swap failed". Before, modetest's and kmscube's first present was dropped.
• Sway runs on the panel. The GPU and the camera run alongside, and the backlight reads 140 nits.
• KUnit, all CONFIG_DRM_APPLE_DISPLAY_KUNIT_TEST suites: 101 passed, 1 skipped, on this branch and on top of drm/asahi, drm/apple: J813 (M5 MacBook Air) GPU and display on the macOS 27.2 firmware #1683.
• tools/asahi/run-host-tests.py --only apple-dcp: 88 of 88 pass.
• Each commit builds (Image.gz, modules, dtbs; LLVM 22).

cc @Acelogic @DjDeveloperr @RyanTheTide @LiamRay10

[RyanTheTide]

The surfaceless present now goes out with the last completed level, and the KUnit case shows the pending level waits for the next surface. We ran it on the J700 (H17P present path): new KMS clients, VT switch, blank/unblank and brightness steps, with no dropped presents and the level held. Looks good.

[sithglan]

@RyanTheTide thanks for the J700 run. The branch no longer merged into integration, so I rebased it onto 673f618. It is now 55d5f6d (was 850e0bd).

• The only conflict was the hw struct in the service-rebind host test (edid.py). 3159fee added num_dptx_ports to it, and this branch adds firmware_compat, so the struct now carries both.
• Nothing else changed.
• The apple-dcp host tests pass at both commits, and KUnit apple runs 102 tests: 101 passed, 1 skipped.