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

["Maíra Canal" <mcanal@igalia.com>]

Hi Lucas,

On 27/10/26 10:53, Lucas Tanure wrote:
> On Tue, Oct 27, 2026 at 1:07 PM Maíra Canal <mcanal@igalia.com> 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@collabora.com/___.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). 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