[PATCH] drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

[PATCH] drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

[Imre Deak]

Atm disabling either DP or eDP outputs can generate a spurious short
pulse interrupt. The reason is that after disabling the port the source
will stop sending a valid stream data, while the sink expects either a
valid stream or the idle pattern. Since neither of this is sent the sink
assumes (after an arbitrary delay) that the link is lost and requests
for link retraining with a short pulse.

The spurious pulse is a real problem at least for eDP panels with long
power-off / power-cycle delays: as part of disabling the output we
disable the panel power. The subsequent spurious short pulse handling
will have to turn the power back on, which means the driver has to do a
redundant wait for the power-off and power-cycle delays. During system
suspend this leads to an unnecessary delay up to ~1s on systems with
such panels as reported by Rui.

To fix this put the sink to DPMS D3 state before turning off the port.
According to the DP spec in this state the sink should not request
retraining. This is also what we do already on pre-ddi platforms.

As an alternative I also tried configuring the port to send idle pattern
- which is against BSPec - and leave the port in normal mode before
turning off the port. Neither of these resolved the problem.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: David Weinehall <david.weinehall@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reported-and-tested-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
---
 drivers/gpu/drm/i915/intel_ddi.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0914ad9..8bac628 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1732,12 +1732,18 @@ static void intel_ddi_post_disable(struct intel_encoder *intel_encoder,
 	struct drm_i915_private *dev_priv = to_i915(encoder->dev);
 	enum port port = intel_ddi_get_encoder_port(intel_encoder);
 	struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+	struct intel_dp *intel_dp = NULL;
 	int type = intel_encoder->type;
 	uint32_t val;
 	bool wait = false;
 
 	/* old_crtc_state and old_conn_state are NULL when called from DP_MST */
 
+	if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
+		intel_dp = enc_to_intel_dp(encoder);
+		intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
+	}
+
 	val = I915_READ(DDI_BUF_CTL(port));
 	if (val & DDI_BUF_CTL_ENABLE) {
 		val &= ~DDI_BUF_CTL_ENABLE;
@@ -1753,9 +1759,7 @@ static void intel_ddi_post_disable(struct intel_encoder *intel_encoder,
 	if (wait)
 		intel_wait_ddi_buf_idle(dev_priv, port);
 
-	if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
-		struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
-		intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
+	if (intel_dp) {
 		intel_edp_panel_vdd_on(intel_dp);
 		intel_edp_panel_off(intel_dp);
 	}
-- 
2.7.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

[Ville Syrjälä]

On Wed, May 31, 2017 at 08:05:35PM +0300, Imre Deak wrote:
> Atm disabling either DP or eDP outputs can generate a spurious short
> pulse interrupt. The reason is that after disabling the port the source
> will stop sending a valid stream data, while the sink expects either a
> valid stream or the idle pattern. Since neither of this is sent the sink
> assumes (after an arbitrary delay) that the link is lost and requests
> for link retraining with a short pulse.
> 
> The spurious pulse is a real problem at least for eDP panels with long
> power-off / power-cycle delays: as part of disabling the output we
> disable the panel power. The subsequent spurious short pulse handling
> will have to turn the power back on, which means the driver has to do a
> redundant wait for the power-off and power-cycle delays. During system
> suspend this leads to an unnecessary delay up to ~1s on systems with
> such panels as reported by Rui.
> 
> To fix this put the sink to DPMS D3 state before turning off the port.
> According to the DP spec in this state the sink should not request
> retraining. This is also what we do already on pre-ddi platforms.
> 
> As an alternative I also tried configuring the port to send idle pattern
> - which is against BSPec - and leave the port in normal mode before
> turning off the port. Neither of these resolved the problem.
> 
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: David Weinehall <david.weinehall@linux.intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Reported-and-tested-by: Zhang Rui <rui.zhang@intel.com>
> Signed-off-by: Imre Deak <imre.deak@intel.com>

Makes sense to me.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
> index 0914ad9..8bac628 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1732,12 +1732,18 @@ static void intel_ddi_post_disable(struct intel_encoder *intel_encoder,
>  	struct drm_i915_private *dev_priv = to_i915(encoder->dev);
>  	enum port port = intel_ddi_get_encoder_port(intel_encoder);
>  	struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> +	struct intel_dp *intel_dp = NULL;
>  	int type = intel_encoder->type;
>  	uint32_t val;
>  	bool wait = false;
>  
>  	/* old_crtc_state and old_conn_state are NULL when called from DP_MST */
>  
> +	if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
> +		intel_dp = enc_to_intel_dp(encoder);
> +		intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> +	}
> +
>  	val = I915_READ(DDI_BUF_CTL(port));
>  	if (val & DDI_BUF_CTL_ENABLE) {
>  		val &= ~DDI_BUF_CTL_ENABLE;
> @@ -1753,9 +1759,7 @@ static void intel_ddi_post_disable(struct intel_encoder *intel_encoder,
>  	if (wait)
>  		intel_wait_ddi_buf_idle(dev_priv, port);
>  
> -	if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
> -		struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> -		intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> +	if (intel_dp) {
>  		intel_edp_panel_vdd_on(intel_dp);
>  		intel_edp_panel_off(intel_dp);
>  	}
> -- 
> 2.7.4

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.BAT: success for drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

[Patchwork]

== Series Details ==

Series: drm/i915/ddi: Avoid long delays during system suspend / eDP disabling
URL   : https://patchwork.freedesktop.org/series/25116/
State : success

== Summary ==

Series 25116v1 drm/i915/ddi: Avoid long delays during system suspend / eDP disabling
https://patchwork.freedesktop.org/api/1.0/series/25116/revisions/1/mbox/

fi-bdw-5557u     total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  time:444s
fi-bdw-gvtdvm    total:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  time:432s
fi-bsw-n3050     total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  time:579s
fi-bxt-j4205     total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  time:510s
fi-byt-j1900     total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  time:491s
fi-byt-n2820     total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  time:488s
fi-hsw-4770      total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  time:428s
fi-hsw-4770r     total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  time:412s
fi-ilk-650       total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  time:420s
fi-ivb-3520m     total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  time:497s
fi-ivb-3770      total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  time:461s
fi-kbl-7500u     total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  time:458s
fi-kbl-7560u     total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  time:572s
fi-skl-6260u     total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  time:461s
fi-skl-6700hq    total:278  pass:239  dwarn:0   dfail:1   fail:17  skip:21  time:427s
fi-skl-6700k     total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  time:469s
fi-skl-6770hq    total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  time:500s
fi-skl-gvtdvm    total:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  time:436s
fi-snb-2520m     total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  time:532s
fi-snb-2600      total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  time:402s

593aae9587d79f8a823a36f4e6cc12e23b547d07 drm-tip: 2017y-05m-31d-14h-36m-16s UTC integration manifest
1119300 drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4845/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: ✓ Fi.CI.BAT: success for drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

[Imre Deak]

On Wed, May 31, 2017 at 05:34:42PM +0000, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/ddi: Avoid long delays during system suspend / eDP disabling
> URL   : https://patchwork.freedesktop.org/series/25116/
> State : success
> 
> == Summary ==
> 
> Series 25116v1 drm/i915/ddi: Avoid long delays during system suspend / eDP disabling
> https://patchwork.freedesktop.org/api/1.0/series/25116/revisions/1/mbox/

I pushed this to -dinq, thanks for the review.

> 
> fi-bdw-5557u     total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  time:444s
> fi-bdw-gvtdvm    total:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  time:432s
> fi-bsw-n3050     total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  time:579s
> fi-bxt-j4205     total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  time:510s
> fi-byt-j1900     total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  time:491s
> fi-byt-n2820     total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  time:488s
> fi-hsw-4770      total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  time:428s
> fi-hsw-4770r     total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  time:412s
> fi-ilk-650       total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  time:420s
> fi-ivb-3520m     total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  time:497s
> fi-ivb-3770      total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  time:461s
> fi-kbl-7500u     total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  time:458s
> fi-kbl-7560u     total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  time:572s
> fi-skl-6260u     total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  time:461s
> fi-skl-6700hq    total:278  pass:239  dwarn:0   dfail:1   fail:17  skip:21  time:427s
> fi-skl-6700k     total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  time:469s
> fi-skl-6770hq    total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  time:500s
> fi-skl-gvtdvm    total:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  time:436s
> fi-snb-2520m     total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  time:532s
> fi-snb-2600      total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  time:402s
> 
> 593aae9587d79f8a823a36f4e6cc12e23b547d07 drm-tip: 2017y-05m-31d-14h-36m-16s UTC integration manifest
> 1119300 drm/i915/ddi: Avoid long delays during system suspend / eDP disabling
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4845/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

[Jani Nikula]

On Wed, 31 May 2017, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Wed, May 31, 2017 at 08:05:35PM +0300, Imre Deak wrote:
>> Atm disabling either DP or eDP outputs can generate a spurious short
>> pulse interrupt. The reason is that after disabling the port the source
>> will stop sending a valid stream data, while the sink expects either a
>> valid stream or the idle pattern. Since neither of this is sent the sink
>> assumes (after an arbitrary delay) that the link is lost and requests
>> for link retraining with a short pulse.
>> 
>> The spurious pulse is a real problem at least for eDP panels with long
>> power-off / power-cycle delays: as part of disabling the output we
>> disable the panel power. The subsequent spurious short pulse handling
>> will have to turn the power back on, which means the driver has to do a
>> redundant wait for the power-off and power-cycle delays. During system
>> suspend this leads to an unnecessary delay up to ~1s on systems with
>> such panels as reported by Rui.
>> 
>> To fix this put the sink to DPMS D3 state before turning off the port.
>> According to the DP spec in this state the sink should not request
>> retraining. This is also what we do already on pre-ddi platforms.
>> 
>> As an alternative I also tried configuring the port to send idle pattern
>> - which is against BSPec - and leave the port in normal mode before
>> turning off the port. Neither of these resolved the problem.
>> 
>> Cc: Zhang Rui <rui.zhang@intel.com>
>> Cc: David Weinehall <david.weinehall@linux.intel.com>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Reported-and-tested-by: Zhang Rui <rui.zhang@intel.com>
>> Signed-off-by: Imre Deak <imre.deak@intel.com>
>
> Makes sense to me.

I wonder if we should write D0 on hotplug.

BR,
Jani.


>
> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
>> ---
>>  drivers/gpu/drm/i915/intel_ddi.c | 10 +++++++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
>> index 0914ad9..8bac628 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -1732,12 +1732,18 @@ static void intel_ddi_post_disable(struct intel_encoder *intel_encoder,
>>  	struct drm_i915_private *dev_priv = to_i915(encoder->dev);
>>  	enum port port = intel_ddi_get_encoder_port(intel_encoder);
>>  	struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
>> +	struct intel_dp *intel_dp = NULL;
>>  	int type = intel_encoder->type;
>>  	uint32_t val;
>>  	bool wait = false;
>>  
>>  	/* old_crtc_state and old_conn_state are NULL when called from DP_MST */
>>  
>> +	if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
>> +		intel_dp = enc_to_intel_dp(encoder);
>> +		intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
>> +	}
>> +
>>  	val = I915_READ(DDI_BUF_CTL(port));
>>  	if (val & DDI_BUF_CTL_ENABLE) {
>>  		val &= ~DDI_BUF_CTL_ENABLE;
>> @@ -1753,9 +1759,7 @@ static void intel_ddi_post_disable(struct intel_encoder *intel_encoder,
>>  	if (wait)
>>  		intel_wait_ddi_buf_idle(dev_priv, port);
>>  
>> -	if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
>> -		struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>> -		intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
>> +	if (intel_dp) {
>>  		intel_edp_panel_vdd_on(intel_dp);
>>  		intel_edp_panel_off(intel_dp);
>>  	}
>> -- 
>> 2.7.4

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

[Ville Syrjälä]

On Thu, Jun 01, 2017 at 03:55:13PM +0300, Jani Nikula wrote:
> On Wed, 31 May 2017, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > On Wed, May 31, 2017 at 08:05:35PM +0300, Imre Deak wrote:
> >> Atm disabling either DP or eDP outputs can generate a spurious short
> >> pulse interrupt. The reason is that after disabling the port the source
> >> will stop sending a valid stream data, while the sink expects either a
> >> valid stream or the idle pattern. Since neither of this is sent the sink
> >> assumes (after an arbitrary delay) that the link is lost and requests
> >> for link retraining with a short pulse.
> >> 
> >> The spurious pulse is a real problem at least for eDP panels with long
> >> power-off / power-cycle delays: as part of disabling the output we
> >> disable the panel power. The subsequent spurious short pulse handling
> >> will have to turn the power back on, which means the driver has to do a
> >> redundant wait for the power-off and power-cycle delays. During system
> >> suspend this leads to an unnecessary delay up to ~1s on systems with
> >> such panels as reported by Rui.
> >> 
> >> To fix this put the sink to DPMS D3 state before turning off the port.
> >> According to the DP spec in this state the sink should not request
> >> retraining. This is also what we do already on pre-ddi platforms.
> >> 
> >> As an alternative I also tried configuring the port to send idle pattern
> >> - which is against BSPec - and leave the port in normal mode before
> >> turning off the port. Neither of these resolved the problem.
> >> 
> >> Cc: Zhang Rui <rui.zhang@intel.com>
> >> Cc: David Weinehall <david.weinehall@linux.intel.com>
> >> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> Reported-and-tested-by: Zhang Rui <rui.zhang@intel.com>
> >> Signed-off-by: Imre Deak <imre.deak@intel.com>
> >
> > Makes sense to me.
> 
> I wonder if we should write D0 on hotplug.

D0 is the default power state IIRC, so when you plug something in it
should automagically go into D0. That's actually a slight problem
power-wise if there's no subsequent modeset to drop it into D3.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

[Jani Nikula]

On Thu, 01 Jun 2017, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Thu, Jun 01, 2017 at 03:55:13PM +0300, Jani Nikula wrote:
>> On Wed, 31 May 2017, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
>> > On Wed, May 31, 2017 at 08:05:35PM +0300, Imre Deak wrote:
>> >> Atm disabling either DP or eDP outputs can generate a spurious short
>> >> pulse interrupt. The reason is that after disabling the port the source
>> >> will stop sending a valid stream data, while the sink expects either a
>> >> valid stream or the idle pattern. Since neither of this is sent the sink
>> >> assumes (after an arbitrary delay) that the link is lost and requests
>> >> for link retraining with a short pulse.
>> >> 
>> >> The spurious pulse is a real problem at least for eDP panels with long
>> >> power-off / power-cycle delays: as part of disabling the output we
>> >> disable the panel power. The subsequent spurious short pulse handling
>> >> will have to turn the power back on, which means the driver has to do a
>> >> redundant wait for the power-off and power-cycle delays. During system
>> >> suspend this leads to an unnecessary delay up to ~1s on systems with
>> >> such panels as reported by Rui.
>> >> 
>> >> To fix this put the sink to DPMS D3 state before turning off the port.
>> >> According to the DP spec in this state the sink should not request
>> >> retraining. This is also what we do already on pre-ddi platforms.
>> >> 
>> >> As an alternative I also tried configuring the port to send idle pattern
>> >> - which is against BSPec - and leave the port in normal mode before
>> >> turning off the port. Neither of these resolved the problem.
>> >> 
>> >> Cc: Zhang Rui <rui.zhang@intel.com>
>> >> Cc: David Weinehall <david.weinehall@linux.intel.com>
>> >> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> >> Reported-and-tested-by: Zhang Rui <rui.zhang@intel.com>
>> >> Signed-off-by: Imre Deak <imre.deak@intel.com>
>> >
>> > Makes sense to me.
>> 
>> I wonder if we should write D0 on hotplug.
>
> D0 is the default power state IIRC, so when you plug something in it
> should automagically go into D0. That's actually a slight problem
> power-wise if there's no subsequent modeset to drop it into D3.

Right. The thought was about branch devices that don't wake up and
aren't disconnected/reconnected after D3. But then we don't receive HPD
for them aither.

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

[Imre Deak]

On Thu, Jun 01, 2017 at 04:58:50PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 01, 2017 at 03:55:13PM +0300, Jani Nikula wrote:
> > On Wed, 31 May 2017, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > On Wed, May 31, 2017 at 08:05:35PM +0300, Imre Deak wrote:
> > >> Atm disabling either DP or eDP outputs can generate a spurious short
> > >> pulse interrupt. The reason is that after disabling the port the source
> > >> will stop sending a valid stream data, while the sink expects either a
> > >> valid stream or the idle pattern. Since neither of this is sent the sink
> > >> assumes (after an arbitrary delay) that the link is lost and requests
> > >> for link retraining with a short pulse.
> > >> 
> > >> The spurious pulse is a real problem at least for eDP panels with long
> > >> power-off / power-cycle delays: as part of disabling the output we
> > >> disable the panel power. The subsequent spurious short pulse handling
> > >> will have to turn the power back on, which means the driver has to do a
> > >> redundant wait for the power-off and power-cycle delays. During system
> > >> suspend this leads to an unnecessary delay up to ~1s on systems with
> > >> such panels as reported by Rui.
> > >> 
> > >> To fix this put the sink to DPMS D3 state before turning off the port.
> > >> According to the DP spec in this state the sink should not request
> > >> retraining. This is also what we do already on pre-ddi platforms.
> > >> 
> > >> As an alternative I also tried configuring the port to send idle pattern
> > >> - which is against BSPec - and leave the port in normal mode before
> > >> turning off the port. Neither of these resolved the problem.
> > >> 
> > >> Cc: Zhang Rui <rui.zhang@intel.com>
> > >> Cc: David Weinehall <david.weinehall@linux.intel.com>
> > >> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >> Reported-and-tested-by: Zhang Rui <rui.zhang@intel.com>
> > >> Signed-off-by: Imre Deak <imre.deak@intel.com>
> > >
> > > Makes sense to me.
> > 
> > I wonder if we should write D0 on hotplug.
> 
> D0 is the default power state IIRC, so when you plug something in it
> should automagically go into D0. That's actually a slight problem
> power-wise if there's no subsequent modeset to drop it into D3.

There was this DP->VGA adaptor that seems to require that we set D0
explicitly:
https://bugs.freedesktop.org/show_bug.cgi?id=99114#c5

But it's an odd behaviour, the DPCD read itself succeeds, only reading a
certain register fails (DPCD_SINK_COUNT). Based on the DP spec a sink
should respond to AUX transfers even after being put to D3, possibly
with a longer wake-up delay (up to 20ms AFAIR).

--Imre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

[Jani Nikula]

On Thu, 01 Jun 2017, Imre Deak <imre.deak@intel.com> wrote:
> On Thu, Jun 01, 2017 at 04:58:50PM +0300, Ville Syrjälä wrote:
>> On Thu, Jun 01, 2017 at 03:55:13PM +0300, Jani Nikula wrote:
>> > On Wed, 31 May 2017, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
>> > > On Wed, May 31, 2017 at 08:05:35PM +0300, Imre Deak wrote:
>> > >> Atm disabling either DP or eDP outputs can generate a spurious short
>> > >> pulse interrupt. The reason is that after disabling the port the source
>> > >> will stop sending a valid stream data, while the sink expects either a
>> > >> valid stream or the idle pattern. Since neither of this is sent the sink
>> > >> assumes (after an arbitrary delay) that the link is lost and requests
>> > >> for link retraining with a short pulse.
>> > >> 
>> > >> The spurious pulse is a real problem at least for eDP panels with long
>> > >> power-off / power-cycle delays: as part of disabling the output we
>> > >> disable the panel power. The subsequent spurious short pulse handling
>> > >> will have to turn the power back on, which means the driver has to do a
>> > >> redundant wait for the power-off and power-cycle delays. During system
>> > >> suspend this leads to an unnecessary delay up to ~1s on systems with
>> > >> such panels as reported by Rui.
>> > >> 
>> > >> To fix this put the sink to DPMS D3 state before turning off the port.
>> > >> According to the DP spec in this state the sink should not request
>> > >> retraining. This is also what we do already on pre-ddi platforms.
>> > >> 
>> > >> As an alternative I also tried configuring the port to send idle pattern
>> > >> - which is against BSPec - and leave the port in normal mode before
>> > >> turning off the port. Neither of these resolved the problem.
>> > >> 
>> > >> Cc: Zhang Rui <rui.zhang@intel.com>
>> > >> Cc: David Weinehall <david.weinehall@linux.intel.com>
>> > >> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> > >> Reported-and-tested-by: Zhang Rui <rui.zhang@intel.com>
>> > >> Signed-off-by: Imre Deak <imre.deak@intel.com>
>> > >
>> > > Makes sense to me.
>> > 
>> > I wonder if we should write D0 on hotplug.
>> 
>> D0 is the default power state IIRC, so when you plug something in it
>> should automagically go into D0. That's actually a slight problem
>> power-wise if there's no subsequent modeset to drop it into D3.
>
> There was this DP->VGA adaptor that seems to require that we set D0
> explicitly:
> https://bugs.freedesktop.org/show_bug.cgi?id=99114#c5
>
> But it's an odd behaviour, the DPCD read itself succeeds, only reading a
> certain register fails (DPCD_SINK_COUNT). Based on the DP spec a sink
> should respond to AUX transfers even after being put to D3, possibly
> with a longer wake-up delay (up to 20ms AFAIR).

Also [1] where AFAICT there isn't even a hotplug after D3.

BR,
Jani.



[1] https://bugs.freedesktop.org/show_bug.cgi?id=101044

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx