Re: [PATCH v3 0/3] drm/vc4: hdmi: enable scrambling before the TMDS clock starts

[Cristian Ciocaltea]

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 <mcanal@xxxxxxxxxx> 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/20261014-vc4-common-scramb-v3-0-c68d58d959a2@xxxxxxxxxxxxx/___.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?

>> 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.

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