Re: [RESEND] drm/i915/hdmi: Poll for 200 msec for TMDS_Scrambler_Status

Re: [RESEND] drm/i915/hdmi: Poll for 200 msec for TMDS_Scrambler_Status

[Jérôme Tollet]

Hi Ville, Ankit,

Gentle ping on this thread - it's been about 10 days since my last
message in the thread (Jan 28).

To recap, we have three potential approaches for this fix:
1. Generic SCDC polling after port enable (current patch) - aligns
with Windows behavior
2. Panel-specific quirk for affected displays (Cisco Desk Pro in my case)
3. Fixed delay after SCDC config (my v2 patch from Jan 14)

Testing showed the delay works at any placement in the modeset
sequence, suggesting this is a timing issue rather than
operation-specific.
I'm happy to implement whichever approach you prefer. Please let me
know which direction you'd like me to take this.

Thanks,
Jerome


Le mer. 28 janv. 2026 à 15:42, Jérôme Tollet <jerome.tollet@gmail.com> a écrit :
>
> Hi Ville,
> Following Ankit's response on January 21st where he suggested
> considering a panel-specific quirk instead of a generic solution, I
> wanted to get your input on the preferred approach.
> As a reminder, testing showed the delay works at any placement in the
> modeset sequence (all 4 test positions succeeded), suggesting this is
> a timing issue rather than being tied to a specific operation.
>
> Three approaches are available:
> 1. Generic SCDC polling after port enable - aligns with Windows
> behavior which also performs ~200ms SCDC poll post-enable
> 2. Panel-specific quirk for affected displays (Cisco Desk Pro in my case)
> 3. Fixed delay after SCDC config (my v2 patch from Jan 14)
>
> I'm happy with any approach that gets merged.
>
> Thanks
> Jerome

Re: [RESEND] drm/i915/hdmi: Poll for 200 msec for TMDS_Scrambler_Status

[Jérôme Tollet]

Hi Ville, Ankit,

Update on testing (Feb 14):
After isolated testing of each patch on kernel 6.18.7, I can now
definitively confirm:

- SCDC polling patch ALONE: Works perfectly ✓
- delay patch (150ms) ALONE: Screen remains black ✗
- Both patches together: Works (but delay is unnecessary)

This definitively answers the question: approach #1 (Generic SCDC
polling after port enable) is the correct solution. The v2 delay patch
is NOT needed and should be disregarded.

The SCDC polling aligns with HDMI 2.0 spec requirements and Windows
behavior, making it the proper generic solution.

Sorry for any confusion from my earlier messages.

Thanks,
Jerome

Le sam. 7 févr. 2026 à 04:14, Jérôme Tollet <jerome.tollet@gmail.com> a écrit :
>
> Hi Ville, Ankit,
>
> Gentle ping on this thread - it's been about 10 days since my last
> message in the thread (Jan 28).
>
> To recap, we have three potential approaches for this fix:
> 1. Generic SCDC polling after port enable (current patch) - aligns
> with Windows behavior
> 2. Panel-specific quirk for affected displays (Cisco Desk Pro in my case)
> 3. Fixed delay after SCDC config (my v2 patch from Jan 14)
>
> Testing showed the delay works at any placement in the modeset
> sequence, suggesting this is a timing issue rather than
> operation-specific.
> I'm happy to implement whichever approach you prefer. Please let me
> know which direction you'd like me to take this.
>
> Thanks,
> Jerome
>
>
> Le mer. 28 janv. 2026 à 15:42, Jérôme Tollet <jerome.tollet@gmail.com> a écrit :
> >
> > Hi Ville,
> > Following Ankit's response on January 21st where he suggested
> > considering a panel-specific quirk instead of a generic solution, I
> > wanted to get your input on the preferred approach.
> > As a reminder, testing showed the delay works at any placement in the
> > modeset sequence (all 4 test positions succeeded), suggesting this is
> > a timing issue rather than being tied to a specific operation.
> >
> > Three approaches are available:
> > 1. Generic SCDC polling after port enable - aligns with Windows
> > behavior which also performs ~200ms SCDC poll post-enable
> > 2. Panel-specific quirk for affected displays (Cisco Desk Pro in my case)
> > 3. Fixed delay after SCDC config (my v2 patch from Jan 14)
> >
> > I'm happy with any approach that gets merged.
> >
> > Thanks
> > Jerome

Re: [RESEND] drm/i915/hdmi: Poll for 200 msec for TMDS_Scrambler_Status

[Nautiyal, Ankit K]

On 2/14/2026 9:47 PM, Jérôme Tollet wrote:
> Hi Ville, Ankit,
>
> Update on testing (Feb 14):
> After isolated testing of each patch on kernel 6.18.7, I can now
> definitively confirm:
>
> - SCDC polling patch ALONE: Works perfectly ✓
> - delay patch (150ms) ALONE: Screen remains black ✗
> - Both patches together: Works (but delay is unnecessary)
>
> This definitively answers the question: approach #1 (Generic SCDC
> polling after port enable) is the correct solution. The v2 delay patch
> is NOT needed and should be disregarded.
>
> The SCDC polling aligns with HDMI 2.0 spec requirements and Windows
> behavior, making it the proper generic solution.


Thanks Jerome for testing.

Lets have all discussion in the original thread on the patch [1].

It seems your recent mails are on a separate thread.


Regards,


Ankit


[1] 
https://lore.kernel.org/intel-xe/73e0de50-b7e3-4315-ab81-0a3ecebc2363@intel.com/



> Sorry for any confusion from my earlier messages.
>
> Thanks,
> Jerome
>
> Le sam. 7 févr. 2026 à 04:14, Jérôme Tollet <jerome.tollet@gmail.com> a écrit :
>> Hi Ville, Ankit,
>>
>> Gentle ping on this thread - it's been about 10 days since my last
>> message in the thread (Jan 28).
>>
>> To recap, we have three potential approaches for this fix:
>> 1. Generic SCDC polling after port enable (current patch) - aligns
>> with Windows behavior
>> 2. Panel-specific quirk for affected displays (Cisco Desk Pro in my case)
>> 3. Fixed delay after SCDC config (my v2 patch from Jan 14)
>>
>> Testing showed the delay works at any placement in the modeset
>> sequence, suggesting this is a timing issue rather than
>> operation-specific.
>> I'm happy to implement whichever approach you prefer. Please let me
>> know which direction you'd like me to take this.
>>
>> Thanks,
>> Jerome
>>
>>
>> Le mer. 28 janv. 2026 à 15:42, Jérôme Tollet <jerome.tollet@gmail.com> a écrit :
>>> Hi Ville,
>>> Following Ankit's response on January 21st where he suggested
>>> considering a panel-specific quirk instead of a generic solution, I
>>> wanted to get your input on the preferred approach.
>>> As a reminder, testing showed the delay works at any placement in the
>>> modeset sequence (all 4 test positions succeeded), suggesting this is
>>> a timing issue rather than being tied to a specific operation.
>>>
>>> Three approaches are available:
>>> 1. Generic SCDC polling after port enable - aligns with Windows
>>> behavior which also performs ~200ms SCDC poll post-enable
>>> 2. Panel-specific quirk for affected displays (Cisco Desk Pro in my case)
>>> 3. Fixed delay after SCDC config (my v2 patch from Jan 14)
>>>
>>> I'm happy with any approach that gets merged.
>>>
>>> Thanks
>>> Jerome

[RESEND] drm/i915/hdmi: Poll for 200 msec for TMDS_Scrambler_Status

[Ankit Nautiyal]

From: Jerome Tollet <jerome.tollet@gmail.com>

As per HDMI 2.0 specification, after scrambled video transmission begins,
the source must poll the TMDS_Scrambler_Status bit until it reads 1 or
until a timeout of 200 ms.

Add a polling step after enabling the HDMI port to verify scrambling
status, following the spec requirement.

Without the wait for the scrambling bit to set, some HDMI 2.0 monitors fail
to decode the signal at 4K@60Hz (594 MHz) when SCDC scrambling is not yet
fully configured by the sink.

v2:
 - Instead of the fixed delay, poll for TMDS scramble status for 200 msec
   as per the HDMI spec. (Ankit)

Reported-by: Jerome Tollet <jerome.tollet@gmail.com>
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6868
Link: https://lore.kernel.org/dri-devel/20251230091037.5603-1-jerome.tollet@gmail.com/
Signed-off-by: Jerome Tollet <jerome.tollet@gmail.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
---

Rebased and resend to intel-gfx and intel-xe so that the patch is picked
up by intel gfx CI.

---
 drivers/gpu/drm/i915/display/intel_ddi.c  |  2 ++
 drivers/gpu/drm/i915/display/intel_hdmi.c | 25 +++++++++++++++++++++++
 drivers/gpu/drm/i915/display/intel_hdmi.h |  2 ++
 3 files changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c
index cb91d07cdaa6..c708b713f0e8 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3506,6 +3506,8 @@ static void intel_ddi_enable_hdmi(struct intel_atomic_state *state,
 	}
 
 	intel_ddi_buf_enable(encoder, buf_ctl);
+
+	intel_hdmi_poll_for_scrambling_enable(crtc_state, connector);
 }
 
 static void intel_ddi_enable(struct intel_atomic_state *state,
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 055e68810d0d..6f7dcd7365a4 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3363,3 +3363,28 @@ intel_hdmi_dsc_get_bpp(int src_fractional_bpp, int slice_width, int num_slices,
 
 	return 0;
 }
+
+/*
+ * As Per HDMI 2.0 spec: after scrambled video transmission begins,
+ * poll TMDS_Scrambler_Status until it reads 1, for up to 200 ms.
+ */
+void
+intel_hdmi_poll_for_scrambling_enable(const struct intel_crtc_state *crtc_state,
+				      struct drm_connector *_connector)
+{
+	struct intel_connector *connector = to_intel_connector(_connector);
+	struct intel_display *display = to_intel_display(crtc_state);
+	bool scrambling_enabled = false;
+	int ret;
+
+	if (!crtc_state->hdmi_scrambling)
+		return;
+
+	/* Poll for a max of 200 msec as per HDMI spec */
+	ret = poll_timeout_us(scrambling_enabled = drm_scdc_get_scrambling_status(&connector->base),
+			      scrambling_enabled, 1000, 200 * 1000, false);
+	if (ret)
+		drm_dbg_kms(display->drm,
+			    "[CONNECTOR:%d:%s] Timed out waiting for scrambling enable\n",
+			    connector->base.base.id, connector->base.name);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.h b/drivers/gpu/drm/i915/display/intel_hdmi.h
index be2fad57e4ad..0fa3661568e8 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.h
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.h
@@ -70,5 +70,7 @@ void hsw_read_infoframe(struct intel_encoder *encoder,
 			const struct intel_crtc_state *crtc_state,
 			unsigned int type,
 			void *frame, ssize_t len);
+void intel_hdmi_poll_for_scrambling_enable(const struct intel_crtc_state *crtc_state,
+					   struct drm_connector *_connector);
 
 #endif /* __INTEL_HDMI_H__ */
-- 
2.45.2

Re: [RESEND] drm/i915/hdmi: Poll for 200 msec for TMDS_Scrambler_Status

[Ville Syrjälä]

On Tue, Jan 13, 2026 at 07:08:45PM +0530, Ankit Nautiyal wrote:
> From: Jerome Tollet <jerome.tollet@gmail.com>
> 
> As per HDMI 2.0 specification, after scrambled video transmission begins,
> the source must poll the TMDS_Scrambler_Status bit until it reads 1 or
> until a timeout of 200 ms.
> 
> Add a polling step after enabling the HDMI port to verify scrambling
> status, following the spec requirement.
> 
> Without the wait for the scrambling bit to set, some HDMI 2.0 monitors fail
> to decode the signal at 4K@60Hz (594 MHz) when SCDC scrambling is not yet
> fully configured by the sink.
> 
> v2:
>  - Instead of the fixed delay, poll for TMDS scramble status for 200 msec
>    as per the HDMI spec. (Ankit)
> 
> Reported-by: Jerome Tollet <jerome.tollet@gmail.com>
> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6868
> Link: https://lore.kernel.org/dri-devel/20251230091037.5603-1-jerome.tollet@gmail.com/
> Signed-off-by: Jerome Tollet <jerome.tollet@gmail.com>
> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> ---
> 
> Rebased and resend to intel-gfx and intel-xe so that the patch is picked
> up by intel gfx CI.
> 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c  |  2 ++
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 25 +++++++++++++++++++++++
>  drivers/gpu/drm/i915/display/intel_hdmi.h |  2 ++
>  3 files changed, 29 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c
> index cb91d07cdaa6..c708b713f0e8 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3506,6 +3506,8 @@ static void intel_ddi_enable_hdmi(struct intel_atomic_state *state,
>  	}
>  
>  	intel_ddi_buf_enable(encoder, buf_ctl);
> +
> +	intel_hdmi_poll_for_scrambling_enable(crtc_state, connector);

This is the last thing we do in the modeset (apart for some HDCP stuff),
so it's not at all clear why this would fix anything. The only thing that
will change after this is the actual video data or some infoframes (audio
in particular). It would be good to find out what exactly is the thing
that needs the delay (ie. keep moving the delay further forward in the
modeset sequence until it fails again).

>  }
>  
>  static void intel_ddi_enable(struct intel_atomic_state *state,
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 055e68810d0d..6f7dcd7365a4 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -3363,3 +3363,28 @@ intel_hdmi_dsc_get_bpp(int src_fractional_bpp, int slice_width, int num_slices,
>  
>  	return 0;
>  }
> +
> +/*
> + * As Per HDMI 2.0 spec: after scrambled video transmission begins,
> + * poll TMDS_Scrambler_Status until it reads 1, for up to 200 ms.
> + */
> +void
> +intel_hdmi_poll_for_scrambling_enable(const struct intel_crtc_state *crtc_state,
> +				      struct drm_connector *_connector)
> +{
> +	struct intel_connector *connector = to_intel_connector(_connector);
> +	struct intel_display *display = to_intel_display(crtc_state);
> +	bool scrambling_enabled = false;
> +	int ret;
> +
> +	if (!crtc_state->hdmi_scrambling)
> +		return;
> +
> +	/* Poll for a max of 200 msec as per HDMI spec */
> +	ret = poll_timeout_us(scrambling_enabled = drm_scdc_get_scrambling_status(&connector->base),
> +			      scrambling_enabled, 1000, 200 * 1000, false);
> +	if (ret)
> +		drm_dbg_kms(display->drm,
> +			    "[CONNECTOR:%d:%s] Timed out waiting for scrambling enable\n",
> +			    connector->base.base.id, connector->base.name);
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.h b/drivers/gpu/drm/i915/display/intel_hdmi.h
> index be2fad57e4ad..0fa3661568e8 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.h
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.h
> @@ -70,5 +70,7 @@ void hsw_read_infoframe(struct intel_encoder *encoder,
>  			const struct intel_crtc_state *crtc_state,
>  			unsigned int type,
>  			void *frame, ssize_t len);
> +void intel_hdmi_poll_for_scrambling_enable(const struct intel_crtc_state *crtc_state,
> +					   struct drm_connector *_connector);
>  
>  #endif /* __INTEL_HDMI_H__ */
> -- 
> 2.45.2

-- 
Ville Syrjälä
Intel

Re: [RESEND] drm/i915/hdmi: Poll for 200 msec for TMDS_Scrambler_Status

[Nautiyal, Ankit K]

On 1/14/2026 3:09 AM, Ville Syrjälä wrote:
> On Tue, Jan 13, 2026 at 07:08:45PM +0530, Ankit Nautiyal wrote:
>> From: Jerome Tollet <jerome.tollet@gmail.com>
>>
>> As per HDMI 2.0 specification, after scrambled video transmission begins,
>> the source must poll the TMDS_Scrambler_Status bit until it reads 1 or
>> until a timeout of 200 ms.
>>
>> Add a polling step after enabling the HDMI port to verify scrambling
>> status, following the spec requirement.
>>
>> Without the wait for the scrambling bit to set, some HDMI 2.0 monitors fail
>> to decode the signal at 4K@60Hz (594 MHz) when SCDC scrambling is not yet
>> fully configured by the sink.
>>
>> v2:
>>   - Instead of the fixed delay, poll for TMDS scramble status for 200 msec
>>     as per the HDMI spec. (Ankit)
>>
>> Reported-by: Jerome Tollet <jerome.tollet@gmail.com>
>> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6868
>> Link: https://lore.kernel.org/dri-devel/20251230091037.5603-1-jerome.tollet@gmail.com/
>> Signed-off-by: Jerome Tollet <jerome.tollet@gmail.com>
>> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
>> ---
>>
>> Rebased and resend to intel-gfx and intel-xe so that the patch is picked
>> up by intel gfx CI.
>>
>> ---
>>   drivers/gpu/drm/i915/display/intel_ddi.c  |  2 ++
>>   drivers/gpu/drm/i915/display/intel_hdmi.c | 25 +++++++++++++++++++++++
>>   drivers/gpu/drm/i915/display/intel_hdmi.h |  2 ++
>>   3 files changed, 29 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c
>> index cb91d07cdaa6..c708b713f0e8 100644
>> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>> @@ -3506,6 +3506,8 @@ static void intel_ddi_enable_hdmi(struct intel_atomic_state *state,
>>   	}
>>   
>>   	intel_ddi_buf_enable(encoder, buf_ctl);
>> +
>> +	intel_hdmi_poll_for_scrambling_enable(crtc_state, connector);
> This is the last thing we do in the modeset (apart for some HDCP stuff),
> so it's not at all clear why this would fix anything. The only thing that
> will change after this is the actual video data or some infoframes (audio
> in particular). It would be good to find out what exactly is the thing
> that needs the delay (ie. keep moving the delay further forward in the
> modeset sequence until it fails again).


As mentioned by Jerome in [1], all the earlier placements worked, which 
suggests this is a timing issue rather than anything tied to a specific 
step in the sequence.
However, the HDMI 2.0 spec requires checking TMDS_Scrambler_Status only 
after scrambled video has actually begun, which perhaps would take place 
after intel_ddi_buf_enable().
Windows also seems to perform a ~200 ms SCDC poll for the scrambling 
status after port enable as part of its post‑enable sequence, which 
aligns with this.

On the other hand, if we are not sure about the placement or requirement 
for this polling, should we just add the delay as a panel specific quirk?
I mean we do not see issues on other panels, adding this delay or poll 
at an earlier generic point would unnecessarily slow down all HDMI 
configurations.
If the SCDC poll for scrambling bit does not make sense, then perhaps we 
can add a panel‑specific quirk placed immediately after enabling SCDC 
for that panel only.

[1] https://patchwork.freedesktop.org/patch/698437/?series=160074&rev=1

Regards,
Ankit

>
>>   }
>>   
>>   static void intel_ddi_enable(struct intel_atomic_state *state,
>> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
>> index 055e68810d0d..6f7dcd7365a4 100644
>> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
>> @@ -3363,3 +3363,28 @@ intel_hdmi_dsc_get_bpp(int src_fractional_bpp, int slice_width, int num_slices,
>>   
>>   	return 0;
>>   }
>> +
>> +/*
>> + * As Per HDMI 2.0 spec: after scrambled video transmission begins,
>> + * poll TMDS_Scrambler_Status until it reads 1, for up to 200 ms.
>> + */
>> +void
>> +intel_hdmi_poll_for_scrambling_enable(const struct intel_crtc_state *crtc_state,
>> +				      struct drm_connector *_connector)
>> +{
>> +	struct intel_connector *connector = to_intel_connector(_connector);
>> +	struct intel_display *display = to_intel_display(crtc_state);
>> +	bool scrambling_enabled = false;
>> +	int ret;
>> +
>> +	if (!crtc_state->hdmi_scrambling)
>> +		return;
>> +
>> +	/* Poll for a max of 200 msec as per HDMI spec */
>> +	ret = poll_timeout_us(scrambling_enabled = drm_scdc_get_scrambling_status(&connector->base),
>> +			      scrambling_enabled, 1000, 200 * 1000, false);
>> +	if (ret)
>> +		drm_dbg_kms(display->drm,
>> +			    "[CONNECTOR:%d:%s] Timed out waiting for scrambling enable\n",
>> +			    connector->base.base.id, connector->base.name);
>> +}
>> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.h b/drivers/gpu/drm/i915/display/intel_hdmi.h
>> index be2fad57e4ad..0fa3661568e8 100644
>> --- a/drivers/gpu/drm/i915/display/intel_hdmi.h
>> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.h
>> @@ -70,5 +70,7 @@ void hsw_read_infoframe(struct intel_encoder *encoder,
>>   			const struct intel_crtc_state *crtc_state,
>>   			unsigned int type,
>>   			void *frame, ssize_t len);
>> +void intel_hdmi_poll_for_scrambling_enable(const struct intel_crtc_state *crtc_state,
>> +					   struct drm_connector *_connector);
>>   
>>   #endif /* __INTEL_HDMI_H__ */
>> -- 
>> 2.45.2

Re: [RESEND] drm/i915/hdmi: Poll for 200 msec for TMDS_Scrambler_Status

[Jerome Tollet]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

From: Jérôme Tollet <jerome.tollet@gmail.com>

Hi Ankit,

Thanks for the reminder. I apologize for fragmenting the discussion - I'll make sure to continue in the original thread going forward.

To summarize the testing results for that thread:
- SCDC polling patch alone: Works perfectly
- The v2 delay patch is not needed

I'll post this confirmation in the proper thread.

Thanks,
Jerome