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

[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

[Jérôme Tollet]

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,

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

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

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

[Jerome Tollet]

Hi Ankit,

I've completed isolated testing and can confirm the SCDC polling patch works perfectly.

Test results:
- Kernel: 6.19.2
- Hardware: Intel Alder Lake-N (N100) with integrated UHD Graphics
- Display: Cisco Desk Pro (CS-DESKPRO-2) 4K@60Hz via HDMI 2.0
- Status: 4K@60Hz (3840x2160@60Hz) working correctly
- Result: Stable display, no corruption, works across reboots

The SCDC polling approach is also more consistent with other implementations
like Windows, which performs similar SCDC polling after port enable.

Relevant dmesg output:
[    5.491988] i915: loading out-of-tree module taints kernel.
[    6.104904] i915 0000:00:02.0: [drm] Found alderlake_p/alderlake_n (device ID 46d1) integrated display version 13.00 stepping D0
[    6.218551] i915 0000:00:02.0: [drm] GT0: GuC firmware i915/tgl_guc_70.bin version 70.49.4
[    6.268439] [drm] Initialized i915 1.6.0 for 0000:00:02.0 on minor 1
[    6.691347] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device

Thanks,
Jerome

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

[Jerome Tollet]

Hi Ankit, Ville,

Gentle ping on this patch series. As confirmed in my previous testing
(Feb 21), the SCDC polling patch works perfectly on kernel 6.19.2 with
my Alder Lake-N (N100) + Cisco Desk Pro (CS-DESKPRO-2) setup.

The isolated testing showed that the SCDC polling approach alone
resolves the 4K@60Hz HDMI issue, which aligns with both the HDMI 2.0
spec requirements and Windows driver behavior.

Is there anything else needed from my side to help move this forward?

Thanks,
Jerome

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

[Nautiyal, Ankit K]

On 2/27/2026 6:46 PM, Jerome Tollet wrote:
> Hi Ankit, Ville,
>
> Gentle ping on this patch series. As confirmed in my previous testing
> (Feb 21), the SCDC polling patch works perfectly on kernel 6.19.2 with
> my Alder Lake-N (N100) + Cisco Desk Pro (CS-DESKPRO-2) setup.

As mentioned in [1], to me polling for TMDS scramble status makes sense.

Perhaps the best way would have been to work with `SCDC Read Request` 
implemented, where in the sink notifies the source to check the SCDC 
status flags, where we have bit for Scrambling_Status.

However we do not have that support. Also not all panels support this.


Since I have also contributed to the patch, I cannot review the change here.


Ville, do you think this change makes sense?


PS: I was trying my hands on SCDC RR sometime back but didnt go through. [2]


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

[2] https://patchwork.freedesktop.org/series/101191/


Regards,

Ankit




>
> The isolated testing showed that the SCDC polling approach alone
> resolves the 4K@60Hz HDMI issue, which aligns with both the HDMI 2.0
> spec requirements and Windows driver behavior.
>
> Is there anything else needed from my side to help move this forward?
>
> Thanks,
> Jerome

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

[Jerome Tollet]

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

Hi Ankit, Ville,

Following up on this patch.

As previously reported, the SCDC polling approach fixes the 4K@60Hz HDMI
issue on my Alder Lake-N (N100) + Cisco Desk Pro setup, and I have not
seen regressions in testing.

Ville, do you see any remaining concern with this approach, or is there
anything else you would like me to test to help move this forward?

Thanks,
Jerome

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

[Ville Syrjälä]

On Thu, Mar 26, 2026 at 06:41:12AM +0100, Jerome Tollet wrote:
> From: Jerome Tollet <jerome.tollet@gmail.com>
> 
> Hi Ankit, Ville,
> 
> Following up on this patch.
> 
> As previously reported, the SCDC polling approach fixes the 4K@60Hz HDMI
> issue on my Alder Lake-N (N100) + Cisco Desk Pro setup, and I have not
> seen regressions in testing.
> 
> Ville, do you see any remaining concern with this approach, or is there
> anything else you would like me to test to help move this forward?

My main concern is having the synchronous polling appear to fix
something now, and if we later make it asynchronous the original
problem may re-appear.

That said, after perusing the spec a bit, it looks to me that sinks
should be able sync up after at most two video fields. I suppose
having effectively two extra vblank waits in a full modeset sequence
isn't the end of world. The extra complexity of asynchronous polling
might not even be worth the hassle.

But the commit message should still highlight that (AFAICS) synchronous
polling is not required by the spec, and thus the fact that this fixes
some monitors is sort of an accidental byproduct.

-- 
Ville Syrjälä
Intel

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

[Jerome Tollet]

Hi Ville, Ankit,

Thanks for the review.

Ankit, Arun Murthy also reviewed the patch (in the [PATCH v2] thread)
and asked for the HDMI 2.0 spec section reference in the code comment.
The requirement comes from Section 10.4.1 (SCDC scrambling enable
sequence), Table 10-19, register 0x21 (TMDS_Scrambler_Status), bit 0.
Could you confirm the exact sub-section in your copy of the spec and
add it to the comment in v3?

Thanks,
Jérôme

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

[Jerome Tollet]

Hi Ankit, Arun,

I submitted patch v3 on April 20th but CI is blocked because my address
jerome.tollet@gmail.com is not on the Intel GFX CI allowlist.

I contacted i915-ci-infra@lists.freedesktop.org twice (April 24th and
April 30th) but received no response.

Could you help get this unblocked?

Series: https://patchwork.freedesktop.org/series/160028/

Thanks,
Jerome