Re: [PATCH v3 0/3] drm/vc4: hdmi: enable scrambling before the TMDS clock starts
From: Maíra Canal
Date: Tue Oct 27 2026 - 10:02:35 EST
Hi Lucas,
On 27/10/26 10:53, Lucas Tanure wrote:
On Tue, Oct 27, 2026 at 1:07 PM Maíra Canal <mcanal@xxxxxxxxxx> wrote:
Hi Cristian, Maíra,
Hi Cristian,
On 26/10/26 22:23, Cristian Ciocaltea wrote:
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?
I suspect you didn't hit this on mainline because vc6_hdmi_phy_disable()
is a stub, so the TMDS clock never stops between disable and enable.
Best regards,
- Maíra
[1] https://protect.checkpoint.com/v2/r02/___https://lore.kernel.org/lkml/20261014-vc4-common-scramb-v3-0-c68d58d959a2@xxxxxxxxxxxxx/___.YzJlOm5lYXQ6YzpnOmQ1ODUyMWJlOGIwNzJjNjNmOWRiMDk3ZmFmYWFkNDliOjc6YTM1MTpiMzBiNzY3ODAyMzBkOGM2M2U0ZjRjMTY2MzE5ZjVhZWZjY2QxYmRjZDBlOWI4MzI0MGYxMjkyNjQ1Y2NkNzJiOnA6VDpG
Regards,
Cristian
Tested on a Raspberry Pi 5 with the Raspberry Pi 7.3 tree [1] as base
(pure mainline panics at boot on this board). That tree carries
vc6_hdmi_phy_disable() implemented, so the clock does stop on disable.
1. plain rpi-7.3.y: 4K60 never locks.
2. 7.3 + my patches: all lock.
3. 7.3 + the 7.4 scrambling infrastructure + Cristian's 9 patches: same
failures as in 1.
4. same as 3 + drm_connector_hdmi_enable_scrambling() moved before
phy_init() and drm_connector_hdmi_disable_scrambling() after
phy_disable(): all lock, zero errors, picture on the panel.
Maíra, I also tried 3 with vc6_hdmi_phy_disable() emptied again, as on
mainline: same failures as in 1. So the stub is not what hides this.
Cristian did not see it because his sink re-evaluates
TMDS_Bit_Clock_Ratio after the clock is running and forgives the late
write, as most TVs do. Ours samples the bit when the clock first
appears and never again. So to reproduce the issue you need a strict
HDMI input.
Happy to send a v4 on top of Cristian's series, with the two helper
calls moved and patch 2 dropped since the common helper already cancels
synchronously, if that is the preferred order.
As your patches are fixes, I'd prefer to push them to drm-misc-fixes and
then Cristian's would rebase on top of your patches, as their patches
will go to drm-misc-next.
Are you okay with this plan, Cristian?
Best regards,
- Maíra
[1] https://github.com/raspberrypi/linux/tree/rpi-7.3.y
Thanks,
Lucas Tanure