Fix 3DFP output on Amlogic HDMITX21

[boeschy]

Fix 3D MVC Frame-Packing output tearing on S6 (S905X5)

On my Ugoos AM9 Pro (Amlogic S6) box, 3D MVC playback in Frame-Packing depending on the 3D display, the output showed either severe V-Sync errors / image tearing, or didn't work at all. The same CoreELEC build with the same source plays 3D MVC correctly on G12B (S922X), which uses the legacy hdmitx20 driver instead of hdmitx21.

Root cause are two independent gaps in hdmitx21 relative to hdmitx20, both only relevant when hdev->tx_comm.flag_3dfp is set:

1. TMDS pixel clock not doubled. config_tv_enc_calc() already doubles v_active/v_total for the ENCP timing generator per the HDMI 1.4a / CEA-861 3D Frame Packing formula, but set_hdmitx_s6_htx_pll() computed the PLL/pixel clock purely from the plain 2D VIC table entry, with no flag_3dfp check at all. The ENCP therefore scanned out twice the line count per frame while being clocked at half the required rate, i.e. the encoder ran at roughly half the intended frame rate. The resulting offset accumulates over the frame, which is why the dependent (second) view tears worse than the base view. hdmitx20 avoids this via a dedicated setting_3dfp_enc_clk_val[] PLL table that has no equivalent in hdmitx21.
2. ENCP data-enable (DE) window computed generically, with a small but real drift from the validated timing. config_tv_enc_calc() derives the DE window for 3D FP by doubling v_active/v_total and reusing the unmodified 2D front/sync/back porch values with fixed hsync_st/vsync_st constants. Cross-checked against hdmitx20's hardware-validated tvregstab_3dfp[] table for 1080p24, this generic result is off by ~1 line vertically (ENCP_VIDEO_VAVON_BLINE: 42 vs. validated 41) and a few pixels horizontally (ENCP_DE_H_END: ~2117 vs. validated 2114).

Patch 1/4 doubles the TMDS pixel clock in set_hdmitx_s6_htx_pll() when flag_3dfp is set, before the VCO/divider search. Verified: for the 1080p24/25/30 VIC group this produces the same 5.94 GHz target VCO that hdmitx20's validated setting_3dfp_enc_clk_val[] table already uses for that group.
Patch 2/4 ports the relevant fixed ENCP register tables for 1080p24/25/30/50/60 and 720p50/60 verbatim from hdmitx20's tvregstab_3dfp[] and uses them directly for 3D FP instead of the generic calculation, avoiding the DE-window drift described above. Falls back to the generic path for any VIC not covered.
Patch 3/4 fixes a separate, independent bug: hdmi21_set_3d() sent the classic HDMI 1.4a 3D VSIF via a Dolby-Vision-aware routing helper that misroutes it to the HF-VSIF packet buffer on any display without an EDID InfoFrame Data Block - which is most standalone 3D TVs. On such a display, none of Frame Packing/Top-and-Bottom/ Side-by-Side ever activated, regardless of trigger (manual toggle or playback start), even though the packet content itself was correct.
Patch 4/4 fixes two Frame-Packing-specific timing/sequencing issues once patch 3 gets the VSIF to the right buffer: PHY enable needs to wait for ENCP/VPU to settle into the new FP timing, and the VSIF (sent before the mode-set, against the old timing) needs to be re-sent once ENCP has been reprogrammed for the new one, so the packet scheduler's auto blanking-relative position stays valid.

This has only been tested on my Ugoos AM9 Pro box connected to an LG 3D TV and a 3D capable Xgimi beamer. It needs to be verified to work on other S6/hdmitx21 boxes.
Edit: My LG 3D TV didn't switch to 3D output, therefor commit 3 (fixes TAB/SBS output) and 4 (fixes FP output) have been added.

Disclaimer: Claude helped me to analyze the issue and to create the fix and comments.

[Portisch]

I will test it next week. 3dfp is completely missed in hdmitx21 driver, so maybe there are other places to where a switch is need.

Please remove all the AI comment text in the commits. The commit itself have the description already.

[boeschy]

The two additional commits are necessary to properly switch my LG 3D TV to 3D either with TAB/SBS or FP signal.