[PATCH] drm/i915/vrr: Fix transmission line for Adaptive Sync SDP

[PATCH] drm/i915/vrr: Fix transmission line for Adaptive Sync SDP

[Ankit Nautiyal]

Currently the EMP_AS_SDP_TL is set to vrr.vsync_start which is
incorrect.

As per Bspec:71197 the transmission line must be within the SCL +
guardband region. Before guardband optimization, guradband was same as
vblank length so EMP_AS_SDP_TL set with vrr.sync_start was falling in
this region and it was not giving an issue.

Now with optimized guardband, this is falling outside the SCL +
guardband region and since the same transmission line is used by VSC SDP
also, this results in PSR timeout issues.

Further restrictions on the position of the transmission line:
For DP/eDP, if there is a set context latency (SCL) window, then it
cannot be the first line of SCL
For DP/eDP, if there is no SCL window, then it cannot be the first line of
the Delayed V. Blank

Fix the EMP_AS_SDP_TL to VTOTAL - (delayed vblank_start - SCL + 1)
Internally the HW computes the value as VTOTAL - EMP_AS_SDP_TL.

Fixes: e1123e617e51 ("drm/i915/vrr: Program EMP_AS_SDP_TL for DP AS SDP")
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
---
 drivers/gpu/drm/i915/display/intel_vrr.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
index 92fb72b56f16..dd81d2133aba 100644
--- a/drivers/gpu/drm/i915/display/intel_vrr.c
+++ b/drivers/gpu/drm/i915/display/intel_vrr.c
@@ -655,18 +655,24 @@ void intel_vrr_set_db_point_and_transmission_line(const struct intel_crtc_state
 {
 	struct intel_display *display = to_intel_display(crtc_state);
 	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
+	const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
+	int transmission_line;
 
 	/*
 	 * For BMG and LNL+ onwards the EMP_AS_SDP_TL is used for programming
 	 * double buffering point and transmission line for VRR packets for
 	 * HDMI2.1/DP/eDP/DP->HDMI2.1 PCON.
 	 * Since currently we support VRR only for DP/eDP, so this is programmed
-	 * to for Adaptive Sync SDP to Vsync start.
+	 * for Adaptive Sync SDP.
 	 */
-	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20)
+	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20) {
+		transmission_line = adjusted_mode->crtc_vtotal - (adjusted_mode->crtc_vblank_start -
+								  crtc_state->set_context_latency +
+								  1);
 		intel_de_write(display,
 			       EMP_AS_SDP_TL(display, cpu_transcoder),
-			       EMP_AS_SDP_DB_TL(crtc_state->vrr.vsync_start));
+			       EMP_AS_SDP_DB_TL(transmission_line));
+	}
 }
 
 static int intel_vrr_hw_vmin(const struct intel_crtc_state *crtc_state)
-- 
2.45.2

Re: [PATCH] drm/i915/vrr: Fix transmission line for Adaptive Sync SDP

[Hogander, Jouni]

On Thu, 2025-10-23 at 13:46 +0530, Ankit Nautiyal wrote:
> Currently the EMP_AS_SDP_TL is set to vrr.vsync_start which is
> incorrect.
> 
> As per Bspec:71197 the transmission line must be within the SCL +
> guardband region. Before guardband optimization, guradband was same
> as
> vblank length so EMP_AS_SDP_TL set with vrr.sync_start was falling in
> this region and it was not giving an issue.
> 
> Now with optimized guardband, this is falling outside the SCL +
> guardband region and since the same transmission line is used by VSC
> SDP
> also, this results in PSR timeout issues.
> 
> Further restrictions on the position of the transmission line:
> For DP/eDP, if there is a set context latency (SCL) window, then it
> cannot be the first line of SCL
> For DP/eDP, if there is no SCL window, then it cannot be the first
> line of
> the Delayed V. Blank
> 
> Fix the EMP_AS_SDP_TL to VTOTAL - (delayed vblank_start - SCL + 1)
> Internally the HW computes the value as VTOTAL - EMP_AS_SDP_TL.
> 
> Fixes: e1123e617e51 ("drm/i915/vrr: Program EMP_AS_SDP_TL for DP AS
> SDP")
> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> Cc: Jouni Högander <jouni.hogander@intel.com>
> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

> ---
>  drivers/gpu/drm/i915/display/intel_vrr.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
> b/drivers/gpu/drm/i915/display/intel_vrr.c
> index 92fb72b56f16..dd81d2133aba 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> @@ -655,18 +655,24 @@ void
> intel_vrr_set_db_point_and_transmission_line(const struct
> intel_crtc_state
>  {
>  	struct intel_display *display =
> to_intel_display(crtc_state);
>  	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> +	const struct drm_display_mode *adjusted_mode = &crtc_state-
> >hw.adjusted_mode;
> +	int transmission_line;
>  
>  	/*
>  	 * For BMG and LNL+ onwards the EMP_AS_SDP_TL is used for
> programming
>  	 * double buffering point and transmission line for VRR
> packets for
>  	 * HDMI2.1/DP/eDP/DP->HDMI2.1 PCON.
>  	 * Since currently we support VRR only for DP/eDP, so this
> is programmed
> -	 * to for Adaptive Sync SDP to Vsync start.
> +	 * for Adaptive Sync SDP.
>  	 */
> -	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display)
> >= 20)
> +	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display)
> >= 20) {
> +		transmission_line = adjusted_mode->crtc_vtotal -
> (adjusted_mode->crtc_vblank_start -
> +								 
> crtc_state->set_context_latency +
> +								 
> 1);
>  		intel_de_write(display,
>  			       EMP_AS_SDP_TL(display,
> cpu_transcoder),
> -			       EMP_AS_SDP_DB_TL(crtc_state-
> >vrr.vsync_start));
> +			       EMP_AS_SDP_DB_TL(transmission_line));
> +	}
>  }
>  
>  static int intel_vrr_hw_vmin(const struct intel_crtc_state
> *crtc_state)

Re: [PATCH] drm/i915/vrr: Fix transmission line for Adaptive Sync SDP

[Ville Syrjälä]

On Thu, Oct 23, 2025 at 01:46:14PM +0530, Ankit Nautiyal wrote:
> Currently the EMP_AS_SDP_TL is set to vrr.vsync_start which is
> incorrect.
> 
> As per Bspec:71197 the transmission line must be within the SCL +
> guardband region. Before guardband optimization, guradband was same as
> vblank length so EMP_AS_SDP_TL set with vrr.sync_start was falling in
> this region and it was not giving an issue.
> 
> Now with optimized guardband, this is falling outside the SCL +
> guardband region and since the same transmission line is used by VSC SDP
> also, this results in PSR timeout issues.
> 
> Further restrictions on the position of the transmission line:
> For DP/eDP, if there is a set context latency (SCL) window, then it
> cannot be the first line of SCL
> For DP/eDP, if there is no SCL window, then it cannot be the first line of
> the Delayed V. Blank
> 
> Fix the EMP_AS_SDP_TL to VTOTAL - (delayed vblank_start - SCL + 1)
> Internally the HW computes the value as VTOTAL - EMP_AS_SDP_TL.
> 
> Fixes: e1123e617e51 ("drm/i915/vrr: Program EMP_AS_SDP_TL for DP AS SDP")
> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> Cc: Jouni Högander <jouni.hogander@intel.com>
> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_vrr.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
> index 92fb72b56f16..dd81d2133aba 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> @@ -655,18 +655,24 @@ void intel_vrr_set_db_point_and_transmission_line(const struct intel_crtc_state
>  {
>  	struct intel_display *display = to_intel_display(crtc_state);
>  	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> +	const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
> +	int transmission_line;
>  
>  	/*
>  	 * For BMG and LNL+ onwards the EMP_AS_SDP_TL is used for programming
>  	 * double buffering point and transmission line for VRR packets for
>  	 * HDMI2.1/DP/eDP/DP->HDMI2.1 PCON.
>  	 * Since currently we support VRR only for DP/eDP, so this is programmed
> -	 * to for Adaptive Sync SDP to Vsync start.
> +	 * for Adaptive Sync SDP.
>  	 */
> -	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20)
> +	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20) {
> +		transmission_line = adjusted_mode->crtc_vtotal - (adjusted_mode->crtc_vblank_start -
> +								  crtc_state->set_context_latency +
> +								  1);
>  		intel_de_write(display,
>  			       EMP_AS_SDP_TL(display, cpu_transcoder),
> -			       EMP_AS_SDP_DB_TL(crtc_state->vrr.vsync_start));
> +			       EMP_AS_SDP_DB_TL(transmission_line));
> +	}

Pretty sure we are expected to send it at vsync_start.

>  }
>  
>  static int intel_vrr_hw_vmin(const struct intel_crtc_state *crtc_state)
> -- 
> 2.45.2

-- 
Ville Syrjälä
Intel

Re: [PATCH] drm/i915/vrr: Fix transmission line for Adaptive Sync SDP

[Nautiyal, Ankit K]

On 10/23/2025 5:34 PM, Ville Syrjälä wrote:
> On Thu, Oct 23, 2025 at 01:46:14PM +0530, Ankit Nautiyal wrote:
>> Currently the EMP_AS_SDP_TL is set to vrr.vsync_start which is
>> incorrect.
>>
>> As per Bspec:71197 the transmission line must be within the SCL +
>> guardband region. Before guardband optimization, guradband was same as
>> vblank length so EMP_AS_SDP_TL set with vrr.sync_start was falling in
>> this region and it was not giving an issue.
>>
>> Now with optimized guardband, this is falling outside the SCL +
>> guardband region and since the same transmission line is used by VSC SDP
>> also, this results in PSR timeout issues.
>>
>> Further restrictions on the position of the transmission line:
>> For DP/eDP, if there is a set context latency (SCL) window, then it
>> cannot be the first line of SCL
>> For DP/eDP, if there is no SCL window, then it cannot be the first line of
>> the Delayed V. Blank
>>
>> Fix the EMP_AS_SDP_TL to VTOTAL - (delayed vblank_start - SCL + 1)
>> Internally the HW computes the value as VTOTAL - EMP_AS_SDP_TL.
>>
>> Fixes: e1123e617e51 ("drm/i915/vrr: Program EMP_AS_SDP_TL for DP AS SDP")
>> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
>> Cc: Jouni Högander <jouni.hogander@intel.com>
>> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
>> ---
>>   drivers/gpu/drm/i915/display/intel_vrr.c | 12 +++++++++---
>>   1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
>> index 92fb72b56f16..dd81d2133aba 100644
>> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
>> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
>> @@ -655,18 +655,24 @@ void intel_vrr_set_db_point_and_transmission_line(const struct intel_crtc_state
>>   {
>>   	struct intel_display *display = to_intel_display(crtc_state);
>>   	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
>> +	const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
>> +	int transmission_line;
>>   
>>   	/*
>>   	 * For BMG and LNL+ onwards the EMP_AS_SDP_TL is used for programming
>>   	 * double buffering point and transmission line for VRR packets for
>>   	 * HDMI2.1/DP/eDP/DP->HDMI2.1 PCON.
>>   	 * Since currently we support VRR only for DP/eDP, so this is programmed
>> -	 * to for Adaptive Sync SDP to Vsync start.
>> +	 * for Adaptive Sync SDP.
>>   	 */
>> -	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20)
>> +	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20) {
>> +		transmission_line = adjusted_mode->crtc_vtotal - (adjusted_mode->crtc_vblank_start -
>> +								  crtc_state->set_context_latency +
>> +								  1);
>>   		intel_de_write(display,
>>   			       EMP_AS_SDP_TL(display, cpu_transcoder),
>> -			       EMP_AS_SDP_DB_TL(crtc_state->vrr.vsync_start));
>> +			       EMP_AS_SDP_DB_TL(transmission_line));
>> +	}
> Pretty sure we are expected to send it at vsync_start.

Hmm.. then do we need to move vsync_start too similar to vblank_start 
for optimized guardband?

If we do not move vsync_start, and set the transmission line to 
vsync_start, it will never fall in the region SCL + guardband with a 
reduced guardband.

Meaning effectively the guardband will be full vblank length.


Regards,

Ankit


>>   }
>>   
>>   static int intel_vrr_hw_vmin(const struct intel_crtc_state *crtc_state)
>> -- 
>> 2.45.2

Re: [PATCH] drm/i915/vrr: Fix transmission line for Adaptive Sync SDP

[Nautiyal, Ankit K]

On 10/23/2025 5:57 PM, Nautiyal, Ankit K wrote:
>
> On 10/23/2025 5:34 PM, Ville Syrjälä wrote:
>> On Thu, Oct 23, 2025 at 01:46:14PM +0530, Ankit Nautiyal wrote:
>>> Currently the EMP_AS_SDP_TL is set to vrr.vsync_start which is
>>> incorrect.
>>>
>>> As per Bspec:71197 the transmission line must be within the SCL +
>>> guardband region. Before guardband optimization, guradband was same as
>>> vblank length so EMP_AS_SDP_TL set with vrr.sync_start was falling in
>>> this region and it was not giving an issue.
>>>
>>> Now with optimized guardband, this is falling outside the SCL +
>>> guardband region and since the same transmission line is used by VSC 
>>> SDP
>>> also, this results in PSR timeout issues.
>>>
>>> Further restrictions on the position of the transmission line:
>>> For DP/eDP, if there is a set context latency (SCL) window, then it
>>> cannot be the first line of SCL
>>> For DP/eDP, if there is no SCL window, then it cannot be the first 
>>> line of
>>> the Delayed V. Blank
>>>
>>> Fix the EMP_AS_SDP_TL to VTOTAL - (delayed vblank_start - SCL + 1)
>>> Internally the HW computes the value as VTOTAL - EMP_AS_SDP_TL.
>>>
>>> Fixes: e1123e617e51 ("drm/i915/vrr: Program EMP_AS_SDP_TL for DP AS 
>>> SDP")
>>> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
>>> Cc: Jouni Högander <jouni.hogander@intel.com>
>>> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
>>> ---
>>>   drivers/gpu/drm/i915/display/intel_vrr.c | 12 +++++++++---
>>>   1 file changed, 9 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c 
>>> b/drivers/gpu/drm/i915/display/intel_vrr.c
>>> index 92fb72b56f16..dd81d2133aba 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
>>> @@ -655,18 +655,24 @@ void 
>>> intel_vrr_set_db_point_and_transmission_line(const struct 
>>> intel_crtc_state
>>>   {
>>>       struct intel_display *display = to_intel_display(crtc_state);
>>>       enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
>>> +    const struct drm_display_mode *adjusted_mode = 
>>> &crtc_state->hw.adjusted_mode;
>>> +    int transmission_line;
>>>         /*
>>>        * For BMG and LNL+ onwards the EMP_AS_SDP_TL is used for 
>>> programming
>>>        * double buffering point and transmission line for VRR 
>>> packets for
>>>        * HDMI2.1/DP/eDP/DP->HDMI2.1 PCON.
>>>        * Since currently we support VRR only for DP/eDP, so this is 
>>> programmed
>>> -     * to for Adaptive Sync SDP to Vsync start.
>>> +     * for Adaptive Sync SDP.
>>>        */
>>> -    if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 
>>> 20)
>>> +    if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 
>>> 20) {
>>> +        transmission_line = adjusted_mode->crtc_vtotal - 
>>> (adjusted_mode->crtc_vblank_start -
>>> + crtc_state->set_context_latency +
>>> +                                  1);
>>>           intel_de_write(display,
>>>                      EMP_AS_SDP_TL(display, cpu_transcoder),
>>> - EMP_AS_SDP_DB_TL(crtc_state->vrr.vsync_start));
>>> +                   EMP_AS_SDP_DB_TL(transmission_line));
>>> +    }
>> Pretty sure we are expected to send it at vsync_start.
>
> Hmm.. then do we need to move vsync_start too similar to vblank_start 
> for optimized guardband?
>
> If we do not move vsync_start, and set the transmission line to 
> vsync_start, it will never fall in the region SCL + guardband with a 
> reduced guardband.


Technically for AS_SDP case with optimized guardband, we can increase 
SCL lines such that it starts at vsync _start and guardband is reduced, 
but I am not sure if it is right.

-Ankit


>
> Meaning effectively the guardband will be full vblank length.
>
>
> Regards,
>
> Ankit
>
>
>>>   }
>>>     static int intel_vrr_hw_vmin(const struct intel_crtc_state 
>>> *crtc_state)
>>> -- 
>>> 2.45.2

Re: [PATCH] drm/i915/vrr: Fix transmission line for Adaptive Sync SDP

[Ville Syrjälä]

On Thu, Oct 23, 2025 at 05:57:02PM +0530, Nautiyal, Ankit K wrote:
> 
> On 10/23/2025 5:34 PM, Ville Syrjälä wrote:
> > On Thu, Oct 23, 2025 at 01:46:14PM +0530, Ankit Nautiyal wrote:
> >> Currently the EMP_AS_SDP_TL is set to vrr.vsync_start which is
> >> incorrect.
> >>
> >> As per Bspec:71197 the transmission line must be within the SCL +
> >> guardband region. Before guardband optimization, guradband was same as
> >> vblank length so EMP_AS_SDP_TL set with vrr.sync_start was falling in
> >> this region and it was not giving an issue.
> >>
> >> Now with optimized guardband, this is falling outside the SCL +
> >> guardband region and since the same transmission line is used by VSC SDP
> >> also, this results in PSR timeout issues.
> >>
> >> Further restrictions on the position of the transmission line:
> >> For DP/eDP, if there is a set context latency (SCL) window, then it
> >> cannot be the first line of SCL
> >> For DP/eDP, if there is no SCL window, then it cannot be the first line of
> >> the Delayed V. Blank
> >>
> >> Fix the EMP_AS_SDP_TL to VTOTAL - (delayed vblank_start - SCL + 1)
> >> Internally the HW computes the value as VTOTAL - EMP_AS_SDP_TL.
> >>
> >> Fixes: e1123e617e51 ("drm/i915/vrr: Program EMP_AS_SDP_TL for DP AS SDP")
> >> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> >> Cc: Jouni Högander <jouni.hogander@intel.com>
> >> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> >> ---
> >>   drivers/gpu/drm/i915/display/intel_vrr.c | 12 +++++++++---
> >>   1 file changed, 9 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
> >> index 92fb72b56f16..dd81d2133aba 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> >> @@ -655,18 +655,24 @@ void intel_vrr_set_db_point_and_transmission_line(const struct intel_crtc_state
> >>   {
> >>   	struct intel_display *display = to_intel_display(crtc_state);
> >>   	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> >> +	const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
> >> +	int transmission_line;
> >>   
> >>   	/*
> >>   	 * For BMG and LNL+ onwards the EMP_AS_SDP_TL is used for programming
> >>   	 * double buffering point and transmission line for VRR packets for
> >>   	 * HDMI2.1/DP/eDP/DP->HDMI2.1 PCON.
> >>   	 * Since currently we support VRR only for DP/eDP, so this is programmed
> >> -	 * to for Adaptive Sync SDP to Vsync start.
> >> +	 * for Adaptive Sync SDP.
> >>   	 */
> >> -	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20)
> >> +	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20) {
> >> +		transmission_line = adjusted_mode->crtc_vtotal - (adjusted_mode->crtc_vblank_start -
> >> +								  crtc_state->set_context_latency +
> >> +								  1);
> >>   		intel_de_write(display,
> >>   			       EMP_AS_SDP_TL(display, cpu_transcoder),
> >> -			       EMP_AS_SDP_DB_TL(crtc_state->vrr.vsync_start));
> >> +			       EMP_AS_SDP_DB_TL(transmission_line));
> >> +	}
> > Pretty sure we are expected to send it at vsync_start.
> 
> Hmm.. then do we need to move vsync_start too similar to vblank_start 
> for optimized guardband?

The vsync pulse location is dictated by the timings.

> 
> If we do not move vsync_start, and set the transmission line to 
> vsync_start, it will never fall in the region SCL + guardband with a 
> reduced guardband.

Only if the vsync pulse is early in the vblank. That's up to the
display.

> 
> Meaning effectively the guardband will be full vblank length.
> 
> 
> Regards,
> 
> Ankit
> 
> 
> >>   }
> >>   
> >>   static int intel_vrr_hw_vmin(const struct intel_crtc_state *crtc_state)
> >> -- 
> >> 2.45.2

-- 
Ville Syrjälä
Intel

Re: [PATCH] drm/i915/vrr: Fix transmission line for Adaptive Sync SDP

[Nautiyal, Ankit K]

On 10/23/2025 8:10 PM, Ville Syrjälä wrote:
> On Thu, Oct 23, 2025 at 05:57:02PM +0530, Nautiyal, Ankit K wrote:
>> On 10/23/2025 5:34 PM, Ville Syrjälä wrote:
>>> On Thu, Oct 23, 2025 at 01:46:14PM +0530, Ankit Nautiyal wrote:
>>>> Currently the EMP_AS_SDP_TL is set to vrr.vsync_start which is
>>>> incorrect.
>>>>
>>>> As per Bspec:71197 the transmission line must be within the SCL +
>>>> guardband region. Before guardband optimization, guradband was same as
>>>> vblank length so EMP_AS_SDP_TL set with vrr.sync_start was falling in
>>>> this region and it was not giving an issue.
>>>>
>>>> Now with optimized guardband, this is falling outside the SCL +
>>>> guardband region and since the same transmission line is used by VSC SDP
>>>> also, this results in PSR timeout issues.
>>>>
>>>> Further restrictions on the position of the transmission line:
>>>> For DP/eDP, if there is a set context latency (SCL) window, then it
>>>> cannot be the first line of SCL
>>>> For DP/eDP, if there is no SCL window, then it cannot be the first line of
>>>> the Delayed V. Blank
>>>>
>>>> Fix the EMP_AS_SDP_TL to VTOTAL - (delayed vblank_start - SCL + 1)
>>>> Internally the HW computes the value as VTOTAL - EMP_AS_SDP_TL.
>>>>
>>>> Fixes: e1123e617e51 ("drm/i915/vrr: Program EMP_AS_SDP_TL for DP AS SDP")
>>>> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
>>>> Cc: Jouni Högander <jouni.hogander@intel.com>
>>>> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
>>>> ---
>>>>    drivers/gpu/drm/i915/display/intel_vrr.c | 12 +++++++++---
>>>>    1 file changed, 9 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
>>>> index 92fb72b56f16..dd81d2133aba 100644
>>>> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
>>>> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
>>>> @@ -655,18 +655,24 @@ void intel_vrr_set_db_point_and_transmission_line(const struct intel_crtc_state
>>>>    {
>>>>    	struct intel_display *display = to_intel_display(crtc_state);
>>>>    	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
>>>> +	const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
>>>> +	int transmission_line;
>>>>    
>>>>    	/*
>>>>    	 * For BMG and LNL+ onwards the EMP_AS_SDP_TL is used for programming
>>>>    	 * double buffering point and transmission line for VRR packets for
>>>>    	 * HDMI2.1/DP/eDP/DP->HDMI2.1 PCON.
>>>>    	 * Since currently we support VRR only for DP/eDP, so this is programmed
>>>> -	 * to for Adaptive Sync SDP to Vsync start.
>>>> +	 * for Adaptive Sync SDP.
>>>>    	 */
>>>> -	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20)
>>>> +	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20) {
>>>> +		transmission_line = adjusted_mode->crtc_vtotal - (adjusted_mode->crtc_vblank_start -
>>>> +								  crtc_state->set_context_latency +
>>>> +								  1);
>>>>    		intel_de_write(display,
>>>>    			       EMP_AS_SDP_TL(display, cpu_transcoder),
>>>> -			       EMP_AS_SDP_DB_TL(crtc_state->vrr.vsync_start));
>>>> +			       EMP_AS_SDP_DB_TL(transmission_line));
>>>> +	}
>>> Pretty sure we are expected to send it at vsync_start.
>> Hmm.. then do we need to move vsync_start too similar to vblank_start
>> for optimized guardband?
> The vsync pulse location is dictated by the timings.

Hmm... then with transmission line set as vsync_start, with a reduced 
guardband we might need to increase the SCL so that vsync_start is more 
or less inside the SCL + guardband.

So, if the panel supports AS_SDP while optimizing the guardband we 
increase the SCL for this.

-Ankit

>
>> If we do not move vsync_start, and set the transmission line to
>> vsync_start, it will never fall in the region SCL + guardband with a
>> reduced guardband.
> Only if the vsync pulse is early in the vblank. That's up to the
> display.
>
>> Meaning effectively the guardband will be full vblank length.
>>
>>
>> Regards,
>>
>> Ankit
>>
>>
>>>>    }
>>>>    
>>>>    static int intel_vrr_hw_vmin(const struct intel_crtc_state *crtc_state)
>>>> -- 
>>>> 2.45.2

Re: [PATCH] drm/i915/vrr: Fix transmission line for Adaptive Sync SDP

[Ville Syrjälä]

On Thu, Oct 23, 2025 at 08:37:14PM +0530, Nautiyal, Ankit K wrote:
> 
> On 10/23/2025 8:10 PM, Ville Syrjälä wrote:
> > On Thu, Oct 23, 2025 at 05:57:02PM +0530, Nautiyal, Ankit K wrote:
> >> On 10/23/2025 5:34 PM, Ville Syrjälä wrote:
> >>> On Thu, Oct 23, 2025 at 01:46:14PM +0530, Ankit Nautiyal wrote:
> >>>> Currently the EMP_AS_SDP_TL is set to vrr.vsync_start which is
> >>>> incorrect.
> >>>>
> >>>> As per Bspec:71197 the transmission line must be within the SCL +
> >>>> guardband region. Before guardband optimization, guradband was same as
> >>>> vblank length so EMP_AS_SDP_TL set with vrr.sync_start was falling in
> >>>> this region and it was not giving an issue.
> >>>>
> >>>> Now with optimized guardband, this is falling outside the SCL +
> >>>> guardband region and since the same transmission line is used by VSC SDP
> >>>> also, this results in PSR timeout issues.
> >>>>
> >>>> Further restrictions on the position of the transmission line:
> >>>> For DP/eDP, if there is a set context latency (SCL) window, then it
> >>>> cannot be the first line of SCL
> >>>> For DP/eDP, if there is no SCL window, then it cannot be the first line of
> >>>> the Delayed V. Blank
> >>>>
> >>>> Fix the EMP_AS_SDP_TL to VTOTAL - (delayed vblank_start - SCL + 1)
> >>>> Internally the HW computes the value as VTOTAL - EMP_AS_SDP_TL.
> >>>>
> >>>> Fixes: e1123e617e51 ("drm/i915/vrr: Program EMP_AS_SDP_TL for DP AS SDP")
> >>>> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> >>>> Cc: Jouni Högander <jouni.hogander@intel.com>
> >>>> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> >>>> ---
> >>>>    drivers/gpu/drm/i915/display/intel_vrr.c | 12 +++++++++---
> >>>>    1 file changed, 9 insertions(+), 3 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
> >>>> index 92fb72b56f16..dd81d2133aba 100644
> >>>> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> >>>> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> >>>> @@ -655,18 +655,24 @@ void intel_vrr_set_db_point_and_transmission_line(const struct intel_crtc_state
> >>>>    {
> >>>>    	struct intel_display *display = to_intel_display(crtc_state);
> >>>>    	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> >>>> +	const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
> >>>> +	int transmission_line;
> >>>>    
> >>>>    	/*
> >>>>    	 * For BMG and LNL+ onwards the EMP_AS_SDP_TL is used for programming
> >>>>    	 * double buffering point and transmission line for VRR packets for
> >>>>    	 * HDMI2.1/DP/eDP/DP->HDMI2.1 PCON.
> >>>>    	 * Since currently we support VRR only for DP/eDP, so this is programmed
> >>>> -	 * to for Adaptive Sync SDP to Vsync start.
> >>>> +	 * for Adaptive Sync SDP.
> >>>>    	 */
> >>>> -	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20)
> >>>> +	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20) {
> >>>> +		transmission_line = adjusted_mode->crtc_vtotal - (adjusted_mode->crtc_vblank_start -
> >>>> +								  crtc_state->set_context_latency +
> >>>> +								  1);
> >>>>    		intel_de_write(display,
> >>>>    			       EMP_AS_SDP_TL(display, cpu_transcoder),
> >>>> -			       EMP_AS_SDP_DB_TL(crtc_state->vrr.vsync_start));
> >>>> +			       EMP_AS_SDP_DB_TL(transmission_line));
> >>>> +	}
> >>> Pretty sure we are expected to send it at vsync_start.
> >> Hmm.. then do we need to move vsync_start too similar to vblank_start
> >> for optimized guardband?
> > The vsync pulse location is dictated by the timings.
> 
> Hmm... then with transmission line set as vsync_start, with a reduced 
> guardband we might need to increase the SCL so that vsync_start is more 
> or less inside the SCL + guardband.
> 
> So, if the panel supports AS_SDP while optimizing the guardband we 
> increase the SCL for this.

From the vblank evasion pov the easiest thing would be to make
delayed vblank match vsync start exactly, and then bump SCL up one
line to deal with whatever PSR issue there is. But that wouldn't
allow us to use the max guardband, so I guess not really an option.

So at the very least we do need to allow guardband > vsync_start,
but that actually already has a vblank evasion issue because we
might be past the delayed vblank but not yet at vsync start when
we write the registers. Fixing that for the DSB should be pretty
easy, but for the MMIO path it'll take more thinking...

And the guardband < vsync_start case I guess could be made to work
as well. The MMIO vblank evasion would need to be updated to evade
the SCL window when the AS SDP needs reprogramming (or at least
evade starting from vsync_start). IIRC the DSB vblank evasion
evades the entire SCL window anyway so should already be fine.
But that last point actually means that the deadline for a commit
is anyway defined by the start of SCL, so not sure there's any actual
benefit from stretching the SCL rather than the guardband.

-- 
Ville Syrjälä
Intel

Re: [PATCH] drm/i915/vrr: Fix transmission line for Adaptive Sync SDP

[Ville Syrjälä]

On Thu, Oct 23, 2025 at 05:40:09PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 23, 2025 at 05:57:02PM +0530, Nautiyal, Ankit K wrote:
> > 
> > On 10/23/2025 5:34 PM, Ville Syrjälä wrote:
> > > On Thu, Oct 23, 2025 at 01:46:14PM +0530, Ankit Nautiyal wrote:
> > >> Currently the EMP_AS_SDP_TL is set to vrr.vsync_start which is
> > >> incorrect.
> > >>
> > >> As per Bspec:71197 the transmission line must be within the SCL +
> > >> guardband region. Before guardband optimization, guradband was same as
> > >> vblank length so EMP_AS_SDP_TL set with vrr.sync_start was falling in
> > >> this region and it was not giving an issue.
> > >>
> > >> Now with optimized guardband, this is falling outside the SCL +
> > >> guardband region and since the same transmission line is used by VSC SDP
> > >> also, this results in PSR timeout issues.
> > >>
> > >> Further restrictions on the position of the transmission line:
> > >> For DP/eDP, if there is a set context latency (SCL) window, then it
> > >> cannot be the first line of SCL
> > >> For DP/eDP, if there is no SCL window, then it cannot be the first line of
> > >> the Delayed V. Blank
> > >>
> > >> Fix the EMP_AS_SDP_TL to VTOTAL - (delayed vblank_start - SCL + 1)
> > >> Internally the HW computes the value as VTOTAL - EMP_AS_SDP_TL.
> > >>
> > >> Fixes: e1123e617e51 ("drm/i915/vrr: Program EMP_AS_SDP_TL for DP AS SDP")
> > >> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> > >> Cc: Jouni Högander <jouni.hogander@intel.com>
> > >> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> > >> ---
> > >>   drivers/gpu/drm/i915/display/intel_vrr.c | 12 +++++++++---
> > >>   1 file changed, 9 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
> > >> index 92fb72b56f16..dd81d2133aba 100644
> > >> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> > >> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> > >> @@ -655,18 +655,24 @@ void intel_vrr_set_db_point_and_transmission_line(const struct intel_crtc_state
> > >>   {
> > >>   	struct intel_display *display = to_intel_display(crtc_state);
> > >>   	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > >> +	const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
> > >> +	int transmission_line;
> > >>   
> > >>   	/*
> > >>   	 * For BMG and LNL+ onwards the EMP_AS_SDP_TL is used for programming
> > >>   	 * double buffering point and transmission line for VRR packets for
> > >>   	 * HDMI2.1/DP/eDP/DP->HDMI2.1 PCON.
> > >>   	 * Since currently we support VRR only for DP/eDP, so this is programmed
> > >> -	 * to for Adaptive Sync SDP to Vsync start.
> > >> +	 * for Adaptive Sync SDP.
> > >>   	 */
> > >> -	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20)
> > >> +	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20) {
> > >> +		transmission_line = adjusted_mode->crtc_vtotal - (adjusted_mode->crtc_vblank_start -
> > >> +								  crtc_state->set_context_latency +
> > >> +								  1);
> > >>   		intel_de_write(display,
> > >>   			       EMP_AS_SDP_TL(display, cpu_transcoder),
> > >> -			       EMP_AS_SDP_DB_TL(crtc_state->vrr.vsync_start));
> > >> +			       EMP_AS_SDP_DB_TL(transmission_line));
> > >> +	}
> > > Pretty sure we are expected to send it at vsync_start.
> > 
> > Hmm.. then do we need to move vsync_start too similar to vblank_start 
> > for optimized guardband?
> 
> The vsync pulse location is dictated by the timings.
> 
> > 
> > If we do not move vsync_start, and set the transmission line to 
> > vsync_start, it will never fall in the region SCL + guardband with a 
> > reduced guardband.
> 
> Only if the vsync pulse is early in the vblank. That's up to the
> display.

Oh and I think we should get rid of that 'assume_all_enabled' stuff
for the AS SDP, and account for it only when actually needed.
Which I *think* means PCON or panel replay with AUX-less ALPM.

There's also that t1 vs. t2 setup time thing for the panel replay,
which seems to be telling me that we could sometimes transmit the
AS SDP later. But if I'm reading that right we have to switch to the
t1 (vsync) transmission line whenever we switch to live frame mode,
which I presume can happen basically at any time. So maybe we can't
actually use that t2 transmission line.

-- 
Ville Syrjälä
Intel

Re: [PATCH] drm/i915/vrr: Fix transmission line for Adaptive Sync SDP

[Nautiyal, Ankit K]

On 10/23/2025 8:38 PM, Ville Syrjälä wrote:
> On Thu, Oct 23, 2025 at 05:40:09PM +0300, Ville Syrjälä wrote:
>> On Thu, Oct 23, 2025 at 05:57:02PM +0530, Nautiyal, Ankit K wrote:
>>> On 10/23/2025 5:34 PM, Ville Syrjälä wrote:
>>>> On Thu, Oct 23, 2025 at 01:46:14PM +0530, Ankit Nautiyal wrote:
>>>>> Currently the EMP_AS_SDP_TL is set to vrr.vsync_start which is
>>>>> incorrect.
>>>>>
>>>>> As per Bspec:71197 the transmission line must be within the SCL +
>>>>> guardband region. Before guardband optimization, guradband was same as
>>>>> vblank length so EMP_AS_SDP_TL set with vrr.sync_start was falling in
>>>>> this region and it was not giving an issue.
>>>>>
>>>>> Now with optimized guardband, this is falling outside the SCL +
>>>>> guardband region and since the same transmission line is used by VSC SDP
>>>>> also, this results in PSR timeout issues.
>>>>>
>>>>> Further restrictions on the position of the transmission line:
>>>>> For DP/eDP, if there is a set context latency (SCL) window, then it
>>>>> cannot be the first line of SCL
>>>>> For DP/eDP, if there is no SCL window, then it cannot be the first line of
>>>>> the Delayed V. Blank
>>>>>
>>>>> Fix the EMP_AS_SDP_TL to VTOTAL - (delayed vblank_start - SCL + 1)
>>>>> Internally the HW computes the value as VTOTAL - EMP_AS_SDP_TL.
>>>>>
>>>>> Fixes: e1123e617e51 ("drm/i915/vrr: Program EMP_AS_SDP_TL for DP AS SDP")
>>>>> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
>>>>> Cc: Jouni Högander <jouni.hogander@intel.com>
>>>>> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
>>>>> ---
>>>>>    drivers/gpu/drm/i915/display/intel_vrr.c | 12 +++++++++---
>>>>>    1 file changed, 9 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
>>>>> index 92fb72b56f16..dd81d2133aba 100644
>>>>> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
>>>>> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
>>>>> @@ -655,18 +655,24 @@ void intel_vrr_set_db_point_and_transmission_line(const struct intel_crtc_state
>>>>>    {
>>>>>    	struct intel_display *display = to_intel_display(crtc_state);
>>>>>    	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
>>>>> +	const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
>>>>> +	int transmission_line;
>>>>>    
>>>>>    	/*
>>>>>    	 * For BMG and LNL+ onwards the EMP_AS_SDP_TL is used for programming
>>>>>    	 * double buffering point and transmission line for VRR packets for
>>>>>    	 * HDMI2.1/DP/eDP/DP->HDMI2.1 PCON.
>>>>>    	 * Since currently we support VRR only for DP/eDP, so this is programmed
>>>>> -	 * to for Adaptive Sync SDP to Vsync start.
>>>>> +	 * for Adaptive Sync SDP.
>>>>>    	 */
>>>>> -	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20)
>>>>> +	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20) {
>>>>> +		transmission_line = adjusted_mode->crtc_vtotal - (adjusted_mode->crtc_vblank_start -
>>>>> +								  crtc_state->set_context_latency +
>>>>> +								  1);
>>>>>    		intel_de_write(display,
>>>>>    			       EMP_AS_SDP_TL(display, cpu_transcoder),
>>>>> -			       EMP_AS_SDP_DB_TL(crtc_state->vrr.vsync_start));
>>>>> +			       EMP_AS_SDP_DB_TL(transmission_line));
>>>>> +	}
>>>> Pretty sure we are expected to send it at vsync_start.
>>> Hmm.. then do we need to move vsync_start too similar to vblank_start
>>> for optimized guardband?
>> The vsync pulse location is dictated by the timings.
>>
>>> If we do not move vsync_start, and set the transmission line to
>>> vsync_start, it will never fall in the region SCL + guardband with a
>>> reduced guardband.
>> Only if the vsync pulse is early in the vblank. That's up to the
>> display.
> Oh and I think we should get rid of that 'assume_all_enabled' stuff
> for the AS SDP, and account for it only when actually needed.
> Which I *think* means PCON or panel replay with AUX-less ALPM.

Currently we are enabling it for VRR and CMRR with AVT and FAVT mode 
respectively.


>
> There's also that t1 vs. t2 setup time thing for the panel replay,
> which seems to be telling me that we could sometimes transmit the
> AS SDP later. But if I'm reading that right we have to switch to the
> t1 (vsync) transmission line whenever we switch to live frame mode,
> which I presume can happen basically at any time. So maybe we can't
> actually use that t2 transmission line.

I think it will be prudent to set the min guardband to accommodate the 
vsync_start as done by Jouni in patch: 
https://patchwork.freedesktop.org/patch/682984/?series=156341&rev=2

Need to remove 'assume_all_enabled' as mentioned, and have some check 
for whether AS_SDP is supported (and can be enabled later).

To have this check is a bit challenging in intel_dp_sdp_min_guardband() 
since its called from 
intel_crtc_compute_config()->intel_vrr_compute_guardband() also, where 
we do not have obvious way to get intel_dp.


Regards,

Ankit



>

Re: [PATCH] drm/i915/vrr: Fix transmission line for Adaptive Sync SDP

[Ville Syrjälä]

On Fri, Oct 24, 2025 at 09:30:26AM +0530, Nautiyal, Ankit K wrote:
> 
> On 10/23/2025 8:38 PM, Ville Syrjälä wrote:
> > On Thu, Oct 23, 2025 at 05:40:09PM +0300, Ville Syrjälä wrote:
> >> On Thu, Oct 23, 2025 at 05:57:02PM +0530, Nautiyal, Ankit K wrote:
> >>> On 10/23/2025 5:34 PM, Ville Syrjälä wrote:
> >>>> On Thu, Oct 23, 2025 at 01:46:14PM +0530, Ankit Nautiyal wrote:
> >>>>> Currently the EMP_AS_SDP_TL is set to vrr.vsync_start which is
> >>>>> incorrect.
> >>>>>
> >>>>> As per Bspec:71197 the transmission line must be within the SCL +
> >>>>> guardband region. Before guardband optimization, guradband was same as
> >>>>> vblank length so EMP_AS_SDP_TL set with vrr.sync_start was falling in
> >>>>> this region and it was not giving an issue.
> >>>>>
> >>>>> Now with optimized guardband, this is falling outside the SCL +
> >>>>> guardband region and since the same transmission line is used by VSC SDP
> >>>>> also, this results in PSR timeout issues.
> >>>>>
> >>>>> Further restrictions on the position of the transmission line:
> >>>>> For DP/eDP, if there is a set context latency (SCL) window, then it
> >>>>> cannot be the first line of SCL
> >>>>> For DP/eDP, if there is no SCL window, then it cannot be the first line of
> >>>>> the Delayed V. Blank
> >>>>>
> >>>>> Fix the EMP_AS_SDP_TL to VTOTAL - (delayed vblank_start - SCL + 1)
> >>>>> Internally the HW computes the value as VTOTAL - EMP_AS_SDP_TL.
> >>>>>
> >>>>> Fixes: e1123e617e51 ("drm/i915/vrr: Program EMP_AS_SDP_TL for DP AS SDP")
> >>>>> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> >>>>> Cc: Jouni Högander <jouni.hogander@intel.com>
> >>>>> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> >>>>> ---
> >>>>>    drivers/gpu/drm/i915/display/intel_vrr.c | 12 +++++++++---
> >>>>>    1 file changed, 9 insertions(+), 3 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
> >>>>> index 92fb72b56f16..dd81d2133aba 100644
> >>>>> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> >>>>> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> >>>>> @@ -655,18 +655,24 @@ void intel_vrr_set_db_point_and_transmission_line(const struct intel_crtc_state
> >>>>>    {
> >>>>>    	struct intel_display *display = to_intel_display(crtc_state);
> >>>>>    	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> >>>>> +	const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
> >>>>> +	int transmission_line;
> >>>>>    
> >>>>>    	/*
> >>>>>    	 * For BMG and LNL+ onwards the EMP_AS_SDP_TL is used for programming
> >>>>>    	 * double buffering point and transmission line for VRR packets for
> >>>>>    	 * HDMI2.1/DP/eDP/DP->HDMI2.1 PCON.
> >>>>>    	 * Since currently we support VRR only for DP/eDP, so this is programmed
> >>>>> -	 * to for Adaptive Sync SDP to Vsync start.
> >>>>> +	 * for Adaptive Sync SDP.
> >>>>>    	 */
> >>>>> -	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20)
> >>>>> +	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20) {
> >>>>> +		transmission_line = adjusted_mode->crtc_vtotal - (adjusted_mode->crtc_vblank_start -
> >>>>> +								  crtc_state->set_context_latency +
> >>>>> +								  1);
> >>>>>    		intel_de_write(display,
> >>>>>    			       EMP_AS_SDP_TL(display, cpu_transcoder),
> >>>>> -			       EMP_AS_SDP_DB_TL(crtc_state->vrr.vsync_start));
> >>>>> +			       EMP_AS_SDP_DB_TL(transmission_line));
> >>>>> +	}
> >>>> Pretty sure we are expected to send it at vsync_start.
> >>> Hmm.. then do we need to move vsync_start too similar to vblank_start
> >>> for optimized guardband?
> >> The vsync pulse location is dictated by the timings.
> >>
> >>> If we do not move vsync_start, and set the transmission line to
> >>> vsync_start, it will never fall in the region SCL + guardband with a
> >>> reduced guardband.
> >> Only if the vsync pulse is early in the vblank. That's up to the
> >> display.
> > Oh and I think we should get rid of that 'assume_all_enabled' stuff
> > for the AS SDP, and account for it only when actually needed.
> > Which I *think* means PCON or panel replay with AUX-less ALPM.
> 
> Currently we are enabling it for VRR and CMRR with AVT and FAVT mode 
> respectively.
> 
> 
> >
> > There's also that t1 vs. t2 setup time thing for the panel replay,
> > which seems to be telling me that we could sometimes transmit the
> > AS SDP later. But if I'm reading that right we have to switch to the
> > t1 (vsync) transmission line whenever we switch to live frame mode,
> > which I presume can happen basically at any time. So maybe we can't
> > actually use that t2 transmission line.
> 
> I think it will be prudent to set the min guardband to accommodate the 
> vsync_start as done by Jouni in patch: 
> https://patchwork.freedesktop.org/patch/682984/?series=156341&rev=2
> 
> Need to remove 'assume_all_enabled' as mentioned, and have some check 
> for whether AS_SDP is supported (and can be enabled later).

I'm thinking we should perhaps just enable it always if
PCON+vrr.in_range or PR+AUX-less ALPM is possible. Although I'm
not sure if we're actually handling all the VRR details correctly
with PCONs, and not sure we even can due to the disaster that is
HDMI 2.1...

> To have this check is a bit challenging in intel_dp_sdp_min_guardband() 
> since its called from 
> intel_crtc_compute_config()->intel_vrr_compute_guardband() also, where 
> we do not have obvious way to get intel_dp.

.compute_config() should be able to decide whether AS SDP is needed or
not.

-- 
Ville Syrjälä
Intel

Re: [PATCH] drm/i915/vrr: Fix transmission line for Adaptive Sync SDP

[Ville Syrjälä]

On Thu, Oct 23, 2025 at 06:08:47PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 23, 2025 at 05:40:09PM +0300, Ville Syrjälä wrote:
> > On Thu, Oct 23, 2025 at 05:57:02PM +0530, Nautiyal, Ankit K wrote:
> > > 
> > > On 10/23/2025 5:34 PM, Ville Syrjälä wrote:
> > > > On Thu, Oct 23, 2025 at 01:46:14PM +0530, Ankit Nautiyal wrote:
> > > >> Currently the EMP_AS_SDP_TL is set to vrr.vsync_start which is
> > > >> incorrect.
> > > >>
> > > >> As per Bspec:71197 the transmission line must be within the SCL +
> > > >> guardband region. Before guardband optimization, guradband was same as
> > > >> vblank length so EMP_AS_SDP_TL set with vrr.sync_start was falling in
> > > >> this region and it was not giving an issue.
> > > >>
> > > >> Now with optimized guardband, this is falling outside the SCL +
> > > >> guardband region and since the same transmission line is used by VSC SDP
> > > >> also, this results in PSR timeout issues.
> > > >>
> > > >> Further restrictions on the position of the transmission line:
> > > >> For DP/eDP, if there is a set context latency (SCL) window, then it
> > > >> cannot be the first line of SCL
> > > >> For DP/eDP, if there is no SCL window, then it cannot be the first line of
> > > >> the Delayed V. Blank
> > > >>
> > > >> Fix the EMP_AS_SDP_TL to VTOTAL - (delayed vblank_start - SCL + 1)
> > > >> Internally the HW computes the value as VTOTAL - EMP_AS_SDP_TL.
> > > >>
> > > >> Fixes: e1123e617e51 ("drm/i915/vrr: Program EMP_AS_SDP_TL for DP AS SDP")
> > > >> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> > > >> Cc: Jouni Högander <jouni.hogander@intel.com>
> > > >> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> > > >> ---
> > > >>   drivers/gpu/drm/i915/display/intel_vrr.c | 12 +++++++++---
> > > >>   1 file changed, 9 insertions(+), 3 deletions(-)
> > > >>
> > > >> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
> > > >> index 92fb72b56f16..dd81d2133aba 100644
> > > >> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> > > >> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> > > >> @@ -655,18 +655,24 @@ void intel_vrr_set_db_point_and_transmission_line(const struct intel_crtc_state
> > > >>   {
> > > >>   	struct intel_display *display = to_intel_display(crtc_state);
> > > >>   	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > > >> +	const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
> > > >> +	int transmission_line;
> > > >>   
> > > >>   	/*
> > > >>   	 * For BMG and LNL+ onwards the EMP_AS_SDP_TL is used for programming
> > > >>   	 * double buffering point and transmission line for VRR packets for
> > > >>   	 * HDMI2.1/DP/eDP/DP->HDMI2.1 PCON.
> > > >>   	 * Since currently we support VRR only for DP/eDP, so this is programmed
> > > >> -	 * to for Adaptive Sync SDP to Vsync start.
> > > >> +	 * for Adaptive Sync SDP.
> > > >>   	 */
> > > >> -	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20)
> > > >> +	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20) {
> > > >> +		transmission_line = adjusted_mode->crtc_vtotal - (adjusted_mode->crtc_vblank_start -
> > > >> +								  crtc_state->set_context_latency +
> > > >> +								  1);
> > > >>   		intel_de_write(display,
> > > >>   			       EMP_AS_SDP_TL(display, cpu_transcoder),
> > > >> -			       EMP_AS_SDP_DB_TL(crtc_state->vrr.vsync_start));
> > > >> +			       EMP_AS_SDP_DB_TL(transmission_line));
> > > >> +	}
> > > > Pretty sure we are expected to send it at vsync_start.
> > > 
> > > Hmm.. then do we need to move vsync_start too similar to vblank_start 
> > > for optimized guardband?
> > 
> > The vsync pulse location is dictated by the timings.
> > 
> > > 
> > > If we do not move vsync_start, and set the transmission line to 
> > > vsync_start, it will never fall in the region SCL + guardband with a 
> > > reduced guardband.
> > 
> > Only if the vsync pulse is early in the vblank. That's up to the
> > display.
> 
> Oh and I think we should get rid of that 'assume_all_enabled' stuff
> for the AS SDP, and account for it only when actually needed.
> Which I *think* means PCON or panel replay with AUX-less ALPM.
> 
> There's also that t1 vs. t2 setup time thing for the panel replay,
> which seems to be telling me that we could sometimes transmit the
> AS SDP later. But if I'm reading that right we have to switch to the
> t1 (vsync) transmission line whenever we switch to live frame mode,
> which I presume can happen basically at any time. So maybe we can't
> actually use that t2 transmission line.

Ah, apparently we have to always put t1 into EMP_AS_SDP_TL, and 
there's some other logic for panel replay to use t2 when possible.
But since it's all dynamic we have to use t1 when calculating the
guardband/SCL.

-- 
Ville Syrjälä
Intel

Re: [PATCH] drm/i915/vrr: Fix transmission line for Adaptive Sync SDP

[Nautiyal, Ankit K]

On 10/24/2025 6:09 PM, Ville Syrjälä wrote:
> On Thu, Oct 23, 2025 at 06:08:47PM +0300, Ville Syrjälä wrote:
>> On Thu, Oct 23, 2025 at 05:40:09PM +0300, Ville Syrjälä wrote:
>>> On Thu, Oct 23, 2025 at 05:57:02PM +0530, Nautiyal, Ankit K wrote:
>>>> On 10/23/2025 5:34 PM, Ville Syrjälä wrote:
>>>>> On Thu, Oct 23, 2025 at 01:46:14PM +0530, Ankit Nautiyal wrote:
>>>>>> Currently the EMP_AS_SDP_TL is set to vrr.vsync_start which is
>>>>>> incorrect.
>>>>>>
>>>>>> As per Bspec:71197 the transmission line must be within the SCL +
>>>>>> guardband region. Before guardband optimization, guradband was same as
>>>>>> vblank length so EMP_AS_SDP_TL set with vrr.sync_start was falling in
>>>>>> this region and it was not giving an issue.
>>>>>>
>>>>>> Now with optimized guardband, this is falling outside the SCL +
>>>>>> guardband region and since the same transmission line is used by VSC SDP
>>>>>> also, this results in PSR timeout issues.
>>>>>>
>>>>>> Further restrictions on the position of the transmission line:
>>>>>> For DP/eDP, if there is a set context latency (SCL) window, then it
>>>>>> cannot be the first line of SCL
>>>>>> For DP/eDP, if there is no SCL window, then it cannot be the first line of
>>>>>> the Delayed V. Blank
>>>>>>
>>>>>> Fix the EMP_AS_SDP_TL to VTOTAL - (delayed vblank_start - SCL + 1)
>>>>>> Internally the HW computes the value as VTOTAL - EMP_AS_SDP_TL.
>>>>>>
>>>>>> Fixes: e1123e617e51 ("drm/i915/vrr: Program EMP_AS_SDP_TL for DP AS SDP")
>>>>>> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
>>>>>> Cc: Jouni Högander <jouni.hogander@intel.com>
>>>>>> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
>>>>>> ---
>>>>>>    drivers/gpu/drm/i915/display/intel_vrr.c | 12 +++++++++---
>>>>>>    1 file changed, 9 insertions(+), 3 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
>>>>>> index 92fb72b56f16..dd81d2133aba 100644
>>>>>> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
>>>>>> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
>>>>>> @@ -655,18 +655,24 @@ void intel_vrr_set_db_point_and_transmission_line(const struct intel_crtc_state
>>>>>>    {
>>>>>>    	struct intel_display *display = to_intel_display(crtc_state);
>>>>>>    	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
>>>>>> +	const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
>>>>>> +	int transmission_line;
>>>>>>    
>>>>>>    	/*
>>>>>>    	 * For BMG and LNL+ onwards the EMP_AS_SDP_TL is used for programming
>>>>>>    	 * double buffering point and transmission line for VRR packets for
>>>>>>    	 * HDMI2.1/DP/eDP/DP->HDMI2.1 PCON.
>>>>>>    	 * Since currently we support VRR only for DP/eDP, so this is programmed
>>>>>> -	 * to for Adaptive Sync SDP to Vsync start.
>>>>>> +	 * for Adaptive Sync SDP.
>>>>>>    	 */
>>>>>> -	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20)
>>>>>> +	if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >= 20) {
>>>>>> +		transmission_line = adjusted_mode->crtc_vtotal - (adjusted_mode->crtc_vblank_start -
>>>>>> +								  crtc_state->set_context_latency +
>>>>>> +								  1);
>>>>>>    		intel_de_write(display,
>>>>>>    			       EMP_AS_SDP_TL(display, cpu_transcoder),
>>>>>> -			       EMP_AS_SDP_DB_TL(crtc_state->vrr.vsync_start));
>>>>>> +			       EMP_AS_SDP_DB_TL(transmission_line));
>>>>>> +	}
>>>>> Pretty sure we are expected to send it at vsync_start.
>>>> Hmm.. then do we need to move vsync_start too similar to vblank_start
>>>> for optimized guardband?
>>> The vsync pulse location is dictated by the timings.
>>>
>>>> If we do not move vsync_start, and set the transmission line to
>>>> vsync_start, it will never fall in the region SCL + guardband with a
>>>> reduced guardband.
>>> Only if the vsync pulse is early in the vblank. That's up to the
>>> display.
>> Oh and I think we should get rid of that 'assume_all_enabled' stuff
>> for the AS SDP, and account for it only when actually needed.
>> Which I *think* means PCON or panel replay with AUX-less ALPM.
>>
>> There's also that t1 vs. t2 setup time thing for the panel replay,
>> which seems to be telling me that we could sometimes transmit the
>> AS SDP later. But if I'm reading that right we have to switch to the
>> t1 (vsync) transmission line whenever we switch to live frame mode,
>> which I presume can happen basically at any time. So maybe we can't
>> actually use that t2 transmission line.
> Ah, apparently we have to always put t1 into EMP_AS_SDP_TL, and
> there's some other logic for panel replay to use t2 when possible.
> But since it's all dynamic we have to use t1 when calculating the
> guardband/SCL.

Yeah t2 will be taken up by HW based on PR_ALPM_CTL adaptive sync SDP 
position (to have either t1/t2 or t1 always or t2 always) and also what 
we send in AS SDP payload wrt to Fixed Vtotal, Fixed AVG VTotal mode.

I agree with your suggestion above. For PCON, VRR support still needs 
work so perhaps we can skip that. Makes sense to always enable AS  SDP 
when Panel replay with Auxless-ALPM is supported.

With that we can use Jouni's patch to increase the guardband such that 
Vsync falls in the required region [1], effectively 
`crtc_state->vrr.vsync_start + 1`.

I was trying with the above changes suggested, sent also to trybot [2].

But now I see that we have a problem with LRR on such panels.

When switching to lower mode with LRR, the `vsync_start` changes, which 
results in guardband being changed.

So seamless switch to the required lower mode cannot take place. :-(


[1] https://patchwork.freedesktop.org/patch/682984/?series=156341&rev=2

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


Regards,

Ankit

>

✗ i915.CI.BAT: failure for drm/i915/vrr: Fix transmission line for Adaptive Sync SDP

[Patchwork]

[-- Attachment #1: Type: text/plain, Size: 4924 bytes --]

== Series Details ==

Series: drm/i915/vrr: Fix transmission line for Adaptive Sync SDP
URL   : https://patchwork.freedesktop.org/series/156411/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_17414 -> Patchwork_156411v1
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_156411v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_156411v1, please notify your bug team (I915-ci-infra@lists.freedesktop.org) to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_156411v1/index.html

Participating hosts (45 -> 44)
------------------------------

  Missing    (1): fi-snb-2520m 

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_156411v1:

### IGT changes ###

#### Possible regressions ####

  * igt@gem_close_race@basic-threads:
    - bat-atsm-1:         [PASS][1] -> [INCOMPLETE][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17414/bat-atsm-1/igt@gem_close_race@basic-threads.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_156411v1/bat-atsm-1/igt@gem_close_race@basic-threads.html

  
Known issues
------------

  Here are the changes found in Patchwork_156411v1 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@dmabuf@all-tests@dma_fence_chain:
    - fi-bsw-nick:        [PASS][3] -> [ABORT][4] ([i915#12904]) +1 other test abort
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17414/fi-bsw-nick/igt@dmabuf@all-tests@dma_fence_chain.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_156411v1/fi-bsw-nick/igt@dmabuf@all-tests@dma_fence_chain.html

  * igt@i915_selftest@live:
    - bat-apl-1:          [PASS][5] -> [DMESG-FAIL][6] ([i915#14808]) +1 other test dmesg-fail
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17414/bat-apl-1/igt@i915_selftest@live.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_156411v1/bat-apl-1/igt@i915_selftest@live.html

  * igt@i915_selftest@live@workarounds:
    - bat-dg2-9:          [PASS][7] -> [DMESG-FAIL][8] ([i915#12061]) +1 other test dmesg-fail
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17414/bat-dg2-9/igt@i915_selftest@live@workarounds.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_156411v1/bat-dg2-9/igt@i915_selftest@live@workarounds.html
    - bat-dg2-11:         [PASS][9] -> [DMESG-FAIL][10] ([i915#12061]) +1 other test dmesg-fail
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17414/bat-dg2-11/igt@i915_selftest@live@workarounds.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_156411v1/bat-dg2-11/igt@i915_selftest@live@workarounds.html
    - bat-dg2-14:         [PASS][11] -> [DMESG-FAIL][12] ([i915#12061]) +1 other test dmesg-fail
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17414/bat-dg2-14/igt@i915_selftest@live@workarounds.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_156411v1/bat-dg2-14/igt@i915_selftest@live@workarounds.html
    - bat-arls-6:         [PASS][13] -> [DMESG-FAIL][14] ([i915#12061]) +1 other test dmesg-fail
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17414/bat-arls-6/igt@i915_selftest@live@workarounds.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_156411v1/bat-arls-6/igt@i915_selftest@live@workarounds.html

  * igt@runner@aborted:
    - fi-bsw-n3050:       NOTRUN -> [FAIL][15] ([i915#15124])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_156411v1/fi-bsw-n3050/igt@runner@aborted.html

  
#### Possible fixes ####

  * igt@i915_selftest@live@workarounds:
    - bat-arls-5:         [DMESG-FAIL][16] ([i915#12061]) -> [PASS][17] +1 other test pass
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17414/bat-arls-5/igt@i915_selftest@live@workarounds.html
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_156411v1/bat-arls-5/igt@i915_selftest@live@workarounds.html

  
  [i915#12061]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12061
  [i915#12904]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12904
  [i915#14808]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14808
  [i915#15124]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15124


Build changes
-------------

  * Linux: CI_DRM_17414 -> Patchwork_156411v1

  CI-20190529: 20190529
  CI_DRM_17414: e5409e1beaa3a7a89c5b5d90fd3a616ecacb1df4 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_8595: 8595
  Patchwork_156411v1: e5409e1beaa3a7a89c5b5d90fd3a616ecacb1df4 @ git://anongit.freedesktop.org/gfx-ci/linux

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_156411v1/index.html

[-- Attachment #2: Type: text/html, Size: 5975 bytes --]