GXL/S905X HDMI: 1440x900 DMT mode fails to display despite clean modeset (meson_drm)

[Steve_vr]

Hi all,

I'm debugging an HDMI output issue on a Meson GXL S905X box (board
gxl_p212_v1, Megafon M8S Pro+ Android TV box, now running mainline-based
Armbian/meson_drm from unifreq/linux-6.12.y). I'd like to check whether
this is a known limitation or something worth digging into further.

Setup:
- SoC: Amlogic S905X (GXL), compatible "amlogic,meson-gxl-dw-hdmi"
- Monitor: Acer V193W, 19" LCD, native 1440x900, VESA DMT, vsync range
  55-75 Hz per datasheet
- Kernel: linux-6.12.y (unifreq tree), meson_drm builtin

Problem:
Setting the HDMI mode to 1440x900 (either the EDID-probed native timing
via `video=HDMI-A-1:1440x900MR at 60e`, or an attempted CVT-RB timing at
~88.4 MHz) results in a completely black screen, but the kernel log
shows a clean, successful modeset with no errors at any layer:

- meson_hdmi_pll_find_params() computes valid PLL parameters for both
  the ~88.41 MHz (CVT-RB) and ~106.5 MHz (EDID native) pixel clocks
- meson_venc_hdmi_get_dmt_vmode() builds encoder timings generically
  from the DRM mode's own htotal/vtotal/hsync/vsync fields, same code
  path as working modes
- meson_hdmi_phy_setup_mode() in meson_dw_hdmi.c places both 88.41 MHz
  and 106.5 MHz in the same "<148500 kHz" PHY tuning bucket as our
  known-working 1024x768 at 60 (65 MHz) mode, so PHY register values
  (HHI_HDMI_PHY_CNTL0/CNTL3) are byte-identical to the working case
- meson_vclk_set() and the atomic commit both report success, fbcon
  switches over correctly (confirmed via console over the framebuffer)
- No DRM/HDMI errors, warnings, or link-training failures anywhere in
  dmesg with drm.debug=0x1f

By contrast, 1024x768 at 60 (65 MHz) on the exact same monitor/cable works
correctly and displays immediately.

I found the original DMT-support patch ("drm/meson: Add support for
DMT modes on HDMI", 2018, Neil Armstrong) only vendor-tested 7 specific
resolutions: 640x480 at 60, 800x600 at 60, 1024x768 at 60, 1152x864 at 75,
1280x1024 at 60, 1600x1200 at 60, 1920x1080 at 60 -- with timings sourced from
Amlogic's internal vendor tree. 1440x900 was never in that list. A
later patch made the DMT timing/PLL calculation generic, but I haven't
found evidence the generic path was validated on real GXL silicon for
resolutions outside the original 7.

My question: is there a known PLL lock-range or signal-integrity
limitation on GXL's HDMI PHY around the 85-110 MHz pixel clock range
that would explain a clean software modeset producing no picture? Or
is this more likely a monitor-side CVT-RB/timing-tolerance issue
rather than an SoC limitation? Is there a recommended way to debug
this further (e.g. is HPD/link status actually verifiable beyond what
drm.debug shows, is there a known-good register dump to compare
against for a successful vs failed link), short of using a scope on
the TMDS lines?

Happy to test patches or provide more dmesg/edid-decode output if
useful. Full technical writeup (mode strings tried, dmesg excerpts,
PHY register values) available on request.

Thanks