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

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

[Lucas Tanure]

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.

Changes in v3:
- Patch 1: rewrote the commit message as requested.
- Added Cc: stable@vger.kernel.org to all three patches as requested.
- Collected the Reviewed-by tags on patches 2 and 3.
- No code change since v2.
- v2: https://lore.kernel.org/lkml/20261020151948.83459-1-lucas.tanure@neat.no/

Changes in v2:
- Add Dom Cobley's vc6_hdmi_phy_disable() from the Raspberry Pi tree so
  the PHY really stops on BCM2712 before the SCDC bits are cleared.
- Cancel the scrambling work unconditionally with
  cancel_delayed_work_sync(); the pending check skipped a running
  instance that then re-armed itself.
- Enable the controller scrambler at the same point as the sink bits,
  before the PHY starts, instead of leaving it at the end of the enable
  sequence with the sink descrambler already on.
- Drop the extra usleep_range(); drm_scdc_set_high_tmds_clock_ratio()
  already waits.
- v1: https://lore.kernel.org/lkml/20261020134941.631907-1-lucas.tanure@neat.no/

Dom Cobley (1):
  drm/vc4: hdmi: power down the BCM2712 PHY when the output is disabled

Lucas Tanure (2):
  drm/vc4: hdmi: always cancel the scrambling work synchronously
  drm/vc4: hdmi: enable scrambling before the TMDS clock starts

 drivers/gpu/drm/vc4/vc4_hdmi.c     | 10 +++++-----
 drivers/gpu/drm/vc4/vc4_hdmi_phy.c |  5 +++++
 2 files changed, 10 insertions(+), 5 deletions(-)

-- 
2.56.0

[PATCH v3 1/3] drm/vc4: hdmi: power down the BCM2712 PHY when the output is disabled

[Lucas Tanure]

From: Dom Cobley <popcornmix@gmail.com>

vc6_hdmi_phy_disable() is empty, so on BCM2712 the PHY keeps its PLL
and TMDS drivers running after the HDMI output is disabled, until the
next vc6_hdmi_phy_init(). The TMDS clock is therefore not stopped
between two mode sets, which the SCDC clock ratio change requires, and
the idle PHY wastes power.

Reset and power down the PHY on disable, as the BCM2711 variant does.

Fixes: 0b1dbe82e051 ("drm/vc4: hdmi: Add support for BCM2712 HDMI controllers")
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
[lucas.tanure: Rewrote commit message to clarify the issue and fix]
Signed-off-by: Lucas Tanure <lucas.tanure@neat.no>
---
 drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
index 56e6a35da357..5040f014bf7e 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
@@ -1197,4 +1197,9 @@ void vc6_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
 
 void vc6_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi)
 {
+	unsigned long flags;
+
+	spin_lock_irqsave(&vc4_hdmi->hw_lock, flags);
+	vc6_hdmi_reset_phy(vc4_hdmi);
+	spin_unlock_irqrestore(&vc4_hdmi->hw_lock, flags);
 }
-- 
2.56.0

[PATCH v3 2/3] drm/vc4: hdmi: always cancel the scrambling work synchronously

[Lucas Tanure]

The scrambling work re-arms itself every second while a scrambled mode
is active. When the output is disabled, the work may be executing at
that moment rather than pending, and delayed_work_pending() is then
false, so the cancel is skipped. The running instance finishes after
the disable, sees the sink report scrambling off, writes the SCDC
scrambling and clock ratio bits back on, and queues itself again. The
sink is left configured for a scrambled 1/40 link that no longer exists
and the work keeps running until the next enable.

cancel_delayed_work_sync() handles both states: it waits for a running
instance and blocks it from queueing itself again.

Fixes: 257d36d493e9 ("drm/vc4: hdmi: Add a workqueue to set scrambling")
Assisted-by: LLM
Signed-off-by: Lucas Tanure <lucas.tanure@neat.no>
Reviewed-by: Maíra Canal <mcanal@igalia.com>
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 2cc46036f11d..4a386e053d3f 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -843,8 +843,7 @@ static void vc4_hdmi_disable_scrambling(struct drm_encoder *encoder)
 
 	vc4_hdmi->scdc_enabled = false;
 
-	if (delayed_work_pending(&vc4_hdmi->scrambling_work))
-		cancel_delayed_work_sync(&vc4_hdmi->scrambling_work);
+	cancel_delayed_work_sync(&vc4_hdmi->scrambling_work);
 
 	if (!drm_dev_enter(drm, &idx))
 		return;
-- 
2.56.0

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

[Lucas Tanure]

HDMI 2.0 requires a source to suspend the TMDS clock, write the
TMDS_Bit_Clock_Ratio bit in the sink's SCDC registers, wait at least
1 ms and only then resume the clock. vc4 does the opposite: the PHY
starts at the new rate first, and the SCDC bits are written tens of
milliseconds later, at the very end of the enable sequence, together
with the source side scrambler. On disable the bits are cleared while
the clock is still running.

Some sinks sample the bit only when the clock appears. One HDMI 2.0
sink we tested then sets up its receiver for a 1/10 clock and never
recovers: a Raspberry Pi 5 at 3840x2160@60 shows no picture, while
1080p60 and 4K30 work and other sources work at 4K60 on the same sink.
Writing the bit by hand before enabling the output makes the same mode
lock every time.

Enable scrambling, on the sink and in the controller, before the PHY is
started, and disable it only after the PHY has been stopped. The SCDC
helper already waits the required time after writing the ratio bit.

Fixes: c85695a2016e ("drm/vc4: hdmi: Enable the scrambler")
Link: https://github.com/raspberrypi/linux/issues/7693
Assisted-by: LLM
Signed-off-by: Lucas Tanure <lucas.tanure@neat.no>
Reviewed-by: Maíra Canal <mcanal@igalia.com>
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 4a386e053d3f..e57fc33af6b3 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -918,8 +918,6 @@ static void vc4_hdmi_encoder_post_crtc_disable(struct drm_encoder *encoder,
 		spin_unlock_irqrestore(&vc4_hdmi->hw_lock, flags);
 	}
 
-	vc4_hdmi_disable_scrambling(encoder);
-
 	drm_dev_exit(idx);
 
 out:
@@ -947,6 +945,8 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct drm_encoder *encoder,
 	if (vc4_hdmi->variant->phy_disable)
 		vc4_hdmi->variant->phy_disable(vc4_hdmi);
 
+	vc4_hdmi_disable_scrambling(encoder);
+
 	clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
 	clk_disable_unprepare(vc4_hdmi->pixel_clock);
 
@@ -1554,6 +1554,8 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder,
 		goto err_disable_pixel_clock;
 	}
 
+	vc4_hdmi_enable_scrambling(encoder);
+
 	if (vc4_hdmi->variant->phy_init)
 		vc4_hdmi->variant->phy_init(vc4_hdmi, conn_state);
 
@@ -1688,7 +1690,6 @@ static void vc4_hdmi_encoder_post_crtc_enable(struct drm_encoder *encoder,
 	}
 
 	vc4_hdmi_recenter_fifo(vc4_hdmi);
-	vc4_hdmi_enable_scrambling(encoder);
 
 	drm_dev_exit(idx);
 
-- 
2.56.0

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

[Cristian Ciocaltea]

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/20261014-vc4-common-scramb-v3-0-c68d58d959a2@collabora.com/

Regards,
Cristian

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

[Maíra Canal]

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://lore.kernel.org/lkml/20261014-vc4-common-scramb-v3-0-c68d58d959a2@collabora.com/
> 
> Regards,
> Cristian

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

[Lucas Tanure]

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.

[1] https://github.com/raspberrypi/linux/tree/rpi-7.3.y

Thanks,
Lucas Tanure

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

[Maíra Canal]

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

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

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