Hi Lucas, On 2026/10/26, Lucas Tanure wrote: > HDMI 2.0 asks the source to set TMDS_Bit_Clock_Ratio in the sink while > the TMDS clock is stopped and to start the clock at least 1 ms later. > vc4 writes the bit, and enables the scrambler, at the end of the enable > sequence, long after the PHY has started, and clears it before the PHY > stops. A sink that samples the bit when the clock appears never locks > a 4K60 signal from a Raspberry Pi 5, while laptops that follow the > order work on the same sink. > > Patch 3 is the fix. Patch 1 is needed on BCM2712, where phy_disable() > was an empty stub upstream, so the PHY kept running after disable; the > Raspberry Pi tree has carried this since 2024. Patch 2 fixes a > pre-existing race in the scrambling work cancel that the fix would > otherwise make easier to hit. > > v1 was tested on a Raspberry Pi 5 running the Raspberry Pi 6.18 kernel > with the same change applied, against the sink that showed the > problem: plain enable at 4K60, 1080p60 to 4K60, 4K30 to 4K60, a sink > reset and a sink power cycle all lock with zero character errors. v2 > and v3 carry the same code; the hardware test of the final form is > still pending and will be reported in this thread. Mainline was not > booted on the Pi 5. The BCM2711 path is unchanged except for the > enable order; I have no Pi 4 at hand.
While converting vc4 to the common HDMI 2.0 scrambling infrastructure, I ran several tests on the Raspberry Pi 5 and didn't notice any (obvious) issues. Hence, could you please verify whether your problem reproduces with a recent mainline kernel? If it does, could you also give [1] a try and report back the actual behavior? [1] https://lore.kernel.org/lkml/[email protected]/ Regards, Cristian
