[fbalazsy]

Follow-up to #446 (merged), from the note on the 50/59.94/48 Hz modesets of the J616s internal panel.

Problem. Setting 50, 59.94 or 48 Hz on the T6041 desktop path logs received unknown callback D202 (24, 0) and the modeset times out in set_digital_out_mode; every later modeset times out too. A mode change makes the 26.6 desktop firmware retire the piodma buffers it mapped for it with unmap_piodma (D202), then their descriptors with release_mem_desc (D454). The desktop callback table had neither.

Change. One commit in iomfb_v26_6_desktop.c:

• D202 is not the record the older firmware sends: the buffer id and the id again, then the DVA unaligned at offset 12, then one word (24 bytes). Reading it as struct dcp_unmap_buf_resp makes the existing handler's DVA check fail and leaves the piodma translation standing. The new handler decodes the 24 bytes and calls that handler.
• D454 carries a 32-bit descriptor id and takes a 32-bit result back (the older firmware returned a byte). The new handler runs the existing release handler and returns its result as 32 bits.

Answering D454 alone, with the buffers still mapped, makes the firmware crash (RTKit: co-processor has crashed, found while bisecting); both together run clean.

Hardware tested on: MacBook Pro 16" M4 Pro (J616s), DCP firmware 26.6.2. Local kernel = integration/aurora ff1510c plus this commit plus the J616s device tree and display series that are local (the Type-C routes of #451 and the gate), so not this branch alone.

	Result
Internal panel 50, 59.94, 48, 47.95, 60, 120 Hz	every mode applies, no unknown callback, no timeout, no DCP crash
48 mode changes in a row (50 / 120 / 59.94 / 60 x12)	clean; descriptor ids are recycled (without the release the 128 ids run out after five changes)
Mode changes with D202 not unmapping (D454 answered only)	DCP crash
pm_test=devices suspend	eDP-1, HDMI-A-1 and DP-1 back
Build	W=1 clean for iomfb_v26_6_desktop.o with DRM_APPLE=m
apple-dcp host selftests	57/63; the six that fail do not build here with clang 23 and fail the same without the commit

Not tested: the measured page-flip rate of the non-integer modes (modetest needs the session stopped) and the other SoCs (the change is in the desktop 26.6 table only).

#451 adds a callback size table to this file; whichever of the two merges second needs [202] (24 bytes in) and [454] (4 in, 4 out) in it. I will add them to #451 if this goes in first.

[RyanTheTide]

#454 covers the desktop D202 and D454 callbacks, including the DVA at offset 12. I will use this commit and drop my overlapping callback implementation. My earlier 24-byte decoder placed that address at offset 16, so it was not equivalent.

One additional behavior in my older patch was extending the shared piodma_mapped ownership tracking from H17P to desktop 26.6. It sets the flag after map_piodma and requires it before unmap_piodma. That prevents a duplicate D202 from unmapping the same buffer twice, and lets release_mem_desc identify a desktop translation still present when release arrives without an unmap. This is separate from the wire adapters and is not needed by the normal map/unmap/release sequence tested here.

I will keep the unknown-callback modeset failure guard separate on top of this change.

The older patch also checked the exact D202 input/output and packet lengths and added a host callback-during-A413 regression. I will keep the tests and generic transport validation on top of this commit, without another D202/D454 implementation.

[RyanTheTide]

Tested on a second J616s (MacBook Pro 16 M4 Pro, DCP firmware 26.6.2) before merge. Kernel: integration/aurora ff1510c plus the GPU bring-up stack and this commit, universal WERROR build with 0 warnings, production-style boot with the T6041 handoff. Switched 120, 50, 59.94, 48, 60 and back to 120 Hz, twice. Every mode set completed, with no unknown callbacks, no set_digital_out_mode timeouts and no coprocessor crash. Flips measured 120.00, 50.00, 59.94, 60.00 and 120.00 Hz. The GPU and panel were unaffected. One small follow-up, not a blocker: in the 48 Hz mode the firmware applied 3456x2234@48, but page flips still completed at 60 Hz, so flip completion isn't paced to the 48 Hz scanout. The apple-dcp host selftests give the same result with and without this commit. Thanks for tracking this down, including the note that D454 alone crashes the coprocessor.