On Tue, Oct 27, 2026 at 8:19 PM Cristian Ciocaltea
<[email protected]> wrote:
>
> Hi Maíra, Lucas,
>
> On 10/27/26 3:58 PM, Maíra Canal wrote:
> > Hi Lucas,
> >
> > On 27/10/26 10:53, Lucas Tanure wrote:
> >> On Tue, Oct 27, 2026 at 1:07 PM Maíra Canal <[email protected]> wrote:
> >>>
> >>> 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/[email protected]/___.YzJlOm5lYXQ6YzpnOmQ1ODUyMWJlOGIwNzJjNjNmOWRiMDk3ZmFmYWFkNDliOjc6YTM1MTpiMzBiNzY3ODAyMzBkOGM2M2U0ZjRjMTY2MzE5ZjVhZWZjY2QxYmRjZDBlOWI4MzI0MGYxMjkyNjQ1Y2NkNzJiOnA6VDpG
> >>>>
> >>>> Regards,
> >>>> Cristian
> >>>
> >>>
> >> Hi Cristian, Maíra,
> >>
> >> Tested on a Raspberry Pi 5 with the Raspberry Pi 7.3 tree [1] as base
> >> (pure mainline panics at boot on this board).
>
> I recall encountering this issue a while ago and spent significant time
> bisecting. The faulty commit was d87773de9efe1
> ("clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when
> running
> VHE"), introduced in v7.2-rc1. Reverting it restored the normal boot.
>
> Note this was later addressed via commit 94f39e4c017e
> ("clocksource/drivers/arm_arch_timer: Workaround bcm2712 broken EL2 virtual
> timer"), part of the v7.2 kernel release.
>
> Which is the mainline version you've tried?
Master at 6b4b543fa187 ("Merge tag 'parisc-for-7.4-rc1'",
v7.3-16411-g6b4b543fa187), so 94f39e4c017e is already in. The panic is
something else. I had no serial console on that boot, so I have no logs.
>
> >> 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.
>
> Thanks for testing all this.
>
> >> 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.
>
> Yeah, that's probably why this issue went unnoticed - most displays are pretty
> tolerant and don't require 100% spec conformance.
>
> >>
> >> 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?
>
> Yes, but sadly I will not be able to reproduce the issue and confirm my rebase
> will not regress. Hence I'd appreciate if Lucas could recheck this after I
> send
> that series out.
Sure, CC me.
>
> Also, Maíra, could you please let me know when you apply the fixes?
>
> I guess I then need to wait for drm-misc-fixes to get merged into
> drm-misc-next
> before I can proceed with the rebase.
>
> Kind regards,
> Cristian
Lucas
