[twobip]

drm/apple: keep a DP2HDMI connect when no link configuration arrives

On a Mac mini (t8112, G14) with a DP2HDMI output, appledrm never gets the
display up: the DCP boots and reads the sink's modes, HPD is asserted, and then
dcp_dptx_connect() times out waiting for a link-configuration notification
that this firmware does not send. The timeout is treated as fatal, so the
connect is withdrawn and the machine ends up with a registered DRM device and
no output.

apple-dcp 271c00000.dcp: DCP booted
apple-dcp 271c00000.dcp: dcp_hotplug() connected:1 valid_mode:0 nr_modes:32
apple-dcp 271c00000.dcp: dcp_enable_dp2hdmi_hpd: DP2HDMI HPD connected:1
apple-dcp 271c00000.dcp: dcp_dptx_connect: timed out waiting for port 0 link configuration
apple-dcp 271c00000.dcp: RTKit: syslog message: IOMFB: IOAVVideoInterface terminated
apple-dcp 271c00000.dcp: RTKit: syslog message: display HPD removed
apple-dcp 271c00000.dcp: dcp_hotplug() connected:0 valid_mode:0 nr_modes:32

Note that dcp_dptx_connect() already tolerates this timeout twice, for the
compact 26.x endpoints and for the late-HPD case; this adds the third case it
was missing, a 13.x DP2HDMI output.

A DP2HDMI output asserts its own HPD in dcp_enable_dp2hdmi_hpd(), so on that
path the link-configuration wait can only time out; the driver already has the
"proceed without the notification" behaviour for the late-HPD case
(dcp_ext_dptx_607()). This extends it to DP2HDMI outputs, identified by having
the HPD GPIO and not being a Type-C output, so Type-C connects keep their
existing path.

With the change, the same machine sets a mode and stays up:

apple-dcp 271c00000.dcp: dcp_enable_dp2hdmi_hpd: DP2HDMI HPD connected:1
apple-dcp 271c00000.dcp: set_digital_out_mode(color:87 timing:82) "3440x1440": 100 543500 3440 3488 3552 3600 1440 1443 1453 1510 0x40 0x0
apple-dcp 271c00000.dcp: set_digital_out_mode finished:7866

and the compositor reports HDMI-A-1 3440x1440 @ 100.

Scope

• Tested on one machine: M2 mini (t8112), DP2HDMI out, apple,firmware-compat
  13.x — the pre-26.x firmware line, so this is unrelated to the desktop 26.x /
  T6041 work in drm/apple: T6041 (M4 Pro/Max) displays on desktop 26.6 firmware (carries #445) #446.
• The T6030 / T8122 / H17P paths are untouched: late_hpd and
  dcp_ext_dptx_607() behave exactly as before, and dcp_is_typec_output()
  keeps Type-C outputs out of the new branch.
• I did not find an existing commit, PR or issue covering this: the wait is
  unchanged in integration/aurora as of 99dac994, t8112-dcpext still falls
  through to the generic apple,dcpext data, and the recent "desktop" commits
  are about 26.x firmware and T6040/T6041, not this path.

It would be worth a second opinion on the predicate from someone who knows why
T8122 asserts HPD after the wait — if another property identifies "this
firmware never notifies" more precisely, that would be a better condition than
the HPD GPIO and the Type-C check.

[RyanTheTide]

This no longer merges into integration/aurora. dcp_dptx_connect_raw() gained a bool t8132 = dcp_is_t8132_ext(dcp); declaration next to late_hpd, and that conflicts with the new dp2hdmi declaration. Keeping both declarations resolves it. Could you rebase onto the current integration/aurora?

The change looks fine otherwise. Only the timeout branch changes, so a DP2HDMI output that does get its link configuration behaves as before. Type-C outputs stay out of the predicate.

[twobip]

Rebased onto current integration/aurora (8333109) and kept both declarations, t8132 then dp2hdmi. The branch is now a direct child of the integration tip, so it merges as a fast-forward.

Only the timeout branch changed; dp2hdmi still requires dcp->hdmi_hpd and stays outside dcp_is_typec_output(). Rebuilt drivers/gpu/drm/apple/dcp.o with the t8112 config (no warnings), and checkpatch is clean.