drm: rockchip: dw-dp: add AUX recovery for USB-C DP Alt Mode

[mingzhangqun]

Summary

On RK3576 with USB-C DisplayPort Alt Mode (via FUSB302), the AUX channel in the DesignWare DP controller gets stuck after ~15 seconds of continuous main link transmission. This causes all subsequent AUX commands to time out silently, breaking DP after the display manager re-enables the output.

Fix

• Reinitialize the completion before each AUX command via reinit_completion()
• Add retry: on timeout, reset the AUX module via DPTX_SOFT_RESET_CTRL and retry once
• Cache EDID after successful read; fall back to cached EDID on subsequent failures

Tested on Seeed reComputer RK3576 DevKit with USB-C DP hotplug/re-plug scenarios.

Test plan

• USB-C DP Alt Mode hotplug works after display manager restart
• Re-plugging Type-C cable restores DP functionality
• No regressions on standard HDMI output

[HeyMeco]

Can you give a short comment how this bug was observed / caused? It seems unusal as we haven't had this happen on other FUSB302 based DP Alt Mode connections. I will likely merge it but I want to try if this affects other boards aswell

[mingzhangqun]

@HeyMeco Thanks for looking at this. Here's how the bug was observed:

Board: reComputer RK3576 (FUSB302-based USB-C DP Alt Mode)
Monitor: Standard DP display over USB-C

Reproduction:

1. Boot with DP monitor connected via USB-C → display works normally
2. After ~15 seconds of active main link transmission, the AUX channel in the DW-DP controller gets stuck
3. All subsequent AUX commands time out silently — EDID reads fail, resolution drops to 1024×768
4. The trigger is the display manager re-enabling the DP output: by that point the completion struct used by the AUX ISR has already been consumed and was never re-initialized before the next transfer

Why it may not affect other boards:
RK3576 uses a different DWC DP controller instance (0x27e40000) with its own AUX implementation. The reinit_completion() call before each AUX transfer ensures the completion is fresh regardless of timing. The soft-reset + retry path is only exercised on actual timeout, so boards that don't hit the stuck condition won't be affected.

Happy to test any changes on RK3576 if needed.