drm/i915/dp: Send DPCD ON for MST before phy_up
Subsystems (3)
PATCH v2 1/1 drm/i915/dp: Send DPCD ON for MST before phy_up
When doing a modeset where the sink is transitioning from D3 to D0 , it would sometimes be possible for the initial power_up_phy() to start timing out. This would only be observed in the last action before the sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We originally thought this might be an issue with us accidentally shutting off the aux block when putting the sink into D3, but since the DP spec mandates that sinks must wake up within 1ms while we have 100ms to respond to an ESI irq, this didn't really add up. Turns out that the problem is more subtle then that:
It turns out that the timeout is from us not enabling DPMS on the MST hub before actually trying to initiate sideband communications. This would cause the first sideband communication (power_up_phy()), to start timing out because the sink wasn't ready to respond. Afterwards, we would call intel_dp_sink_dpms(DRM_MODE_DPMS_ON) in intel_ddi_pre_enable_dp(), which would actually result in waking up the sink so that sideband requests would work again.
Since DPMS is what lets us actually bring the hub up into a state where sideband communications become functional again, we just need to make sure to enable DPMS on the display before attempting to perform sideband communications.
Changes since v1:
- Remove comment above if (!intel_dp->is_mst) - vsryjala
- Move intel_dp_sink_dpms() for MST into intel_dp_post_disable_mst() to keep enable/disable paths symmetrical
- Improve commit message - dhnkrn
---
This email should hopefully actually be picked up by patchwork this time, hooray!
drivers/gpu/drm/i915/intel_ddi.c | 6 ++++-- drivers/gpu/drm/i915/intel_dp_mst.c | 2 ++ 2 files changed, 6 insertions(+), 2 deletions(-)
drivers/gpu/drm/i915/intel_ddi.c +4 -2
@@ -2324,7 +2324,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,intel_prepare_dp_ddi_buffers (encoder, crtc_state);intel_ddi_init_dp_buf_reg (encoder); -intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_ON ); +if (!intel_dp->is_mst) +intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_ON );intel_dp_start_link_train (intel_dp);if (port !=PORT_A ||INTEL_GEN (dev_priv) >=9 )intel_dp_stop_link_train (intel_dp);
@@ -2427,7 +2428,8 @@ static void intel_ddi_post_disable_dp(struct intel_encoder *encoder,* Power down sink before disabling the port, otherwise we end * up getting interrupts from the sink on detecting link loss. */ -intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_OFF ); +if (!intel_dp->is_mst) +intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_OFF );intel_disable_ddi_buf (encoder);
drivers/gpu/drm/i915/intel_dp_mst.c +2 -0
@@ -176,6 +176,7 @@ static void intel_mst_post_disable_dp(struct intel_encoder *encoder,*/ drm_dp_send_power_updown_phy (&intel_dp->mst_mgr, connector->port, false); +intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_OFF ); intel_dp->active_mst_links--;
@@ -223,6 +224,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder *encoder,DRM_DEBUG_KMS ("active links %d\n" , intel_dp->active_mst_links); +intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_ON );drm_dp_send_power_updown_phy (&intel_dp->mst_mgr, connector->port, true);if (intel_dp->active_mst_links ==0 ) intel_dig_port->base.pre_enable(&intel_dig_port->base,
Signature · 6 lines
2.14.3 _______________________________________________ Intel-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Actually - ignore this patch, I'm going to do a v3 because i just noticed there is something very silly and broken I just introduced into the disable codepath
Quoted 95 lines · Lyude Paul
When doing a modeset where the sink is transitioning from D3 to D0 , it would sometimes be possible for the initial
power_up_phy()to start timing out. This would only be observed in the last action before the sink went into D3 mode wasintel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We originally thought this might be an issue with us accidentally shutting off the aux block when putting the sink into D3, but since the DP spec mandates that sinks must wake up within 1ms while we have 100ms to respond to an ESI irq, this didn't really add up. Turns out that the problem is more subtle then that:It turns out that the timeout is from us not enabling DPMS on the MST hub before actually trying to initiate sideband communications. This would cause the first sideband communication (
power_up_phy()), to start timing out because the sink wasn't ready to respond. Afterwards, we would callintel_dp_sink_dpms(DRM_MODE_DPMS_ON)inintel_ddi_pre_enable_dp(), which would actually result in waking up the sink so that sideband requests would work again.Since DPMS is what lets us actually bring the hub up into a state where sideband communications become functional again, we just need to make sure to enable DPMS on the display before attempting to perform sideband communications.
Changes since v1:
- Remove comment above if (!intel_dp->is_mst) - vsryjala
- Moveintel_dp_sink_dpms()for MST intointel_dp_post_disable_mst()to keep enable/disable paths symmetrical
- Improve commit message - dhnkrnSigned-off-by Lyude Paul <[email protected]>Cc Dhinakaran Pandiyan <[email protected]>Cc Ville Syrjälä <[email protected]>Cc Laura Abbott <[email protected]>Fixes ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MSThub.")
---
This email should hopefully actually be picked up by patchwork this time, hooray!drivers/gpu/drm/i915/intel_ddi.c | 6 ++++-- drivers/gpu/drm/i915/intel_dp_mst.c | 2 ++ 2 files changed, 6 insertions(+), 2 deletions(-)drivers/gpu/drm/i915/intel_ddi.c +2
-1@@ -2324,7 +2324,8 @@ static void intel_ddi_pre_enable_dp(structintel_encoder *encoder,intel_prepare_dp_ddi_buffers (encoder ,crtc_state );intel_ddi_init_dp_buf_reg (encoder); -intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_ON ); +if (!intel_dp->is_mst) +intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_ON );intel_dp_start_link_train (intel_dp);if (port !=PORT_A ||INTEL_GEN (dev_priv) >=9 )drivers/gpu/drm/i915/intel_ddi.c +2
-1intel_dp_stop_link_train (intel_dp);@@ -2427,7 +2428,8 @@ static void intel_ddi_post_disable_dp(structintel_encoder *encoder, * Power down sink before disabling the port, otherwise we end * up getting interrupts from the sink on detecting link loss. */ -intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_OFF ); +if (!intel_dp->is_mst) +intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_OFF );intel_disable_ddi_buf (encoder);drivers/gpu/drm/i915/intel_dp_mst.c +2
-0@@ -176,6 +176,7 @@ static void intel_mst_post_disable_dp(structintel_encoder *encoder, */ drm_dp_send_power_updown_phy (&intel_dp->mst_mgr, connector->port, false); +intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_OFF ); intel_dp->active_mst_links--;@@ -223,6 +224,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder *encoder,DRM_DEBUG_KMS ("active links %d\n" , intel_dp->active_mst_links); +intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_ON );drm_dp_send_power_updown_phy (&intel_dp->mst_mgr, connector->port, true);drivers/gpu/drm/i915/intel_dp_mst.c +0
-0if (intel_dp->active_mst_links ==0 ) intel_dig_port->base.pre_enable(&intel_dig_port->base,
Signature · 2 lines
Cheers, Lyude Paul
Quoted 72 lines · Lyude Paul
When doing a modeset where the sink is transitioning from D3 to D0 , it would sometimes be possible for the initial
power_up_phy()to start timing out. This would only be observed in the last action before the sink went into D3 mode wasintel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We originally thought this might be an issue with us accidentally shutting off the aux block when putting the sink into D3, but since the DP spec mandates that sinks must wake up within 1ms while we have 100ms to respond to an ESI irq, this didn't really add up. Turns out that the problem is more subtle then that:It turns out that the timeout is from us not enabling DPMS on the MST hub before actually trying to initiate sideband communications. This would cause the first sideband communication (
power_up_phy()), to start timing out because the sink wasn't ready to respond. Afterwards, we would callintel_dp_sink_dpms(DRM_MODE_DPMS_ON)inintel_ddi_pre_enable_dp(), which would actually result in waking up the sink so that sideband requests would work again.Since DPMS is what lets us actually bring the hub up into a state where sideband communications become functional again, we just need to make sure to enable DPMS on the display before attempting to perform sideband communications.
Changes since v1:
- Remove comment above if (!intel_dp->is_mst) - vsryjala
- Moveintel_dp_sink_dpms()for MST intointel_dp_post_disable_mst()to keep enable/disable paths symmetrical
- Improve commit message - dhnkrnSigned-off-by Lyude Paul <[email protected]>Cc Dhinakaran Pandiyan <[email protected]>Cc Ville Syrjälä <[email protected]>Cc Laura Abbott <[email protected]>Fixes ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")---
This email should hopefully actually be picked up by patchwork this time, hooray!drivers/gpu/drm/i915/intel_ddi.c | 6 ++++-- drivers/gpu/drm/i915/intel_dp_mst.c | 2 ++ 2 files changed, 6 insertions(+), 2 deletions(-)drivers/gpu/drm/i915/intel_ddi.c +4
-2@@ -2324,7 +2324,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,intel_prepare_dp_ddi_buffers (encoder, crtc_state);intel_ddi_init_dp_buf_reg (encoder); -intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_ON ); +if (!intel_dp->is_mst) +intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_ON );intel_dp_start_link_train (intel_dp);if (port !=PORT_A ||INTEL_GEN (dev_priv) >=9 )intel_dp_stop_link_train (intel_dp);@@ -2427,7 +2428,8 @@ static void intel_ddi_post_disable_dp(struct intel_encoder *encoder,* Power down sink before disabling the port, otherwise we end * up getting interrupts from the sink on detecting link loss. */ -intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_OFF ); +if (!intel_dp->is_mst) +intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_OFF );intel_disable_ddi_buf (encoder);drivers/gpu/drm/i915/intel_dp_mst.c +0
-0
drivers/gpu/drm/i915/intel_dp_mst.c static void intel_mst_post_disable_dp(struct intel_encoder *encoder, · line 179
Quoted 4 lines
drivers/gpu/drm/i915/intel_dp_mst.c +1
-0@@ -176,6 +176,7 @@ static void intel_mst_post_disable_dp(struct intel_encoder *encoder,*/ drm_dp_send_power_updown_phy (&intel_dp->mst_mgr, connector->port, false); +intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_OFF );
Needed only when _links goes from 1 -> 0
drivers/gpu/drm/i915/intel_dp_mst.c static void intel_mst_pre_enable_dp(struct intel_encoder *encoder, · line 227
Quoted 8 lines
drivers/gpu/drm/i915/intel_dp_mst.c +1
-0intel_dp->active_mst_links--;@@ -223,6 +224,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder *encoder,DRM_DEBUG_KMS ("active links %d\n" , intel_dp->active_mst_links); +intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_ON );
Needed only when _links goes from 0 -> 1
drivers/gpu/drm/i915/intel_dp_mst.c static void intel_mst_pre_enable_dp(struct intel_encoder *encoder, · line 230
Quoted 3 lines
drivers/gpu/drm/i915/intel_dp_mst.c +0
-0drm_dp_send_power_updown_phy (&intel_dp->mst_mgr, connector->port, true);if (intel_dp->active_mst_links ==0 ) intel_dig_port->base.pre_enable(&intel_dig_port->base,
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
PATCH v3 1/1 drm/i915/dp: Send DPCD ON for MST before phy_up
In reply to Lyude PaulWhen doing a modeset where the sink is transitioning from D3 to D0 , it would sometimes be possible for the initial power_up_phy() to start timing out. This would only be observed in the last action before the sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We originally thought this might be an issue with us accidentally shutting off the aux block when putting the sink into D3, but since the DP spec mandates that sinks must wake up within 1ms while we have 100ms to respond to an ESI irq, this didn't really add up. Turns out that the problem is more subtle then that:
It turns out that the timeout is from us not enabling DPMS on the MST hub before actually trying to initiate sideband communications. This would cause the first sideband communication (power_up_phy()), to start timing out because the sink wasn't ready to respond. Afterwards, we would call intel_dp_sink_dpms(DRM_MODE_DPMS_ON) in intel_ddi_pre_enable_dp(), which would actually result in waking up the sink so that sideband requests would work again.
Since DPMS is what lets us actually bring the hub up into a state where sideband communications become functional again, we just need to make sure to enable DPMS on the display before attempting to perform sideband communications.
Changes since v1:
- Remove comment above if (!intel_dp->is_mst) - vsryjala
- Move intel_dp_sink_dpms() for MST into intel_dp_post_disable_mst() to keep enable/disable paths symmetrical
- Improve commit message - dhnkrn
Changes since v2:
- Only send DPMS off when we're disabling the last sink, and only send DPMS on when we're enabling the first sink - dhnkrn
--- drivers/gpu/drm/i915/intel_ddi.c | 6 ++++-- drivers/gpu/drm/i915/intel_dp_mst.c | 8 +++++++- 2 files changed, 11 insertions(+), 3 deletions(-)
drivers/gpu/drm/i915/intel_ddi.c +4 -2
@@ -2324,7 +2324,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,intel_prepare_dp_ddi_buffers (encoder, crtc_state);intel_ddi_init_dp_buf_reg (encoder); -intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_ON ); +if (!intel_dp->is_mst) +intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_ON );intel_dp_start_link_train (intel_dp);if (port !=PORT_A ||INTEL_GEN (dev_priv) >=9 )intel_dp_stop_link_train (intel_dp);
@@ -2427,7 +2428,8 @@ static void intel_ddi_post_disable_dp(struct intel_encoder *encoder,* Power down sink before disabling the port, otherwise we end * up getting interrupts from the sink on detecting link loss. */ -intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_OFF ); +if (!intel_dp->is_mst) +intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_OFF );intel_disable_ddi_buf (encoder);
drivers/gpu/drm/i915/intel_dp_mst.c +7 -1
@@ -180,9 +180,11 @@ static void intel_mst_post_disable_dp(struct intel_encoder *encoder, intel_dp->active_mst_links--; intel_mst->connector =NULL ; -if (intel_dp->active_mst_links ==0 ) +if (intel_dp->active_mst_links ==0 ) { +intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_OFF ); intel_dig_port->base.post_disable (&intel_dig_port->base, old_crtc_state,NULL ); + }DRM_DEBUG_KMS ("active links %d\n" , intel_dp->active_mst_links); }
@@ -223,7 +225,11 @@ static void intel_mst_pre_enable_dp(struct intel_encoder *encoder,DRM_DEBUG_KMS ("active links %d\n" , intel_dp->active_mst_links); +if (intel_dp->active_mst_links ==0 ) +intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_ON ); +drm_dp_send_power_updown_phy (&intel_dp->mst_mgr, connector->port, true); +if (intel_dp->active_mst_links ==0 ) intel_dig_port->base.pre_enable (&intel_dig_port->base, pipe_config,NULL );
Signature · 1 line
2.14.3
Quoted 48 lines · Lyude Paul
When doing a modeset where the sink is transitioning from D3 to D0 , it would sometimes be possible for the initial
power_up_phy()to start timing out. This would only be observed in the last action before the sink went into D3 mode wasintel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We originally thought this might be an issue with us accidentally shutting off the aux block when putting the sink into D3, but since the DP spec mandates that sinks must wake up within 1ms while we have 100ms to respond to an ESI irq, this didn't really add up. Turns out that the problem is more subtle then that:It turns out that the timeout is from us not enabling DPMS on the MST hub before actually trying to initiate sideband communications. This would cause the first sideband communication (
power_up_phy()), to start timing out because the sink wasn't ready to respond. Afterwards, we would callintel_dp_sink_dpms(DRM_MODE_DPMS_ON)inintel_ddi_pre_enable_dp(), which would actually result in waking up the sink so that sideband requests would work again.Since DPMS is what lets us actually bring the hub up into a state where sideband communications become functional again, we just need to make sure to enable DPMS on the display before attempting to perform sideband communications.
Changes since v1:
- Remove comment above if (!intel_dp->is_mst) - vsryjala
- Moveintel_dp_sink_dpms()for MST intointel_dp_post_disable_mst()to keep enable/disable paths symmetrical
- Improve commit message - dhnkrn
Changes since v2:
- Only send DPMS off when we're disabling the last sink, and only send DPMS on when we're enabling the first sink - dhnkrnSigned-off-by Lyude Paul <[email protected]>Cc Dhinakaran Pandiyan <[email protected]>Cc Ville Syrjälä <[email protected]>Cc Laura Abbott <[email protected]>Fixes ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")--- drivers/gpu/drm/i915/intel_ddi.c | 6 ++++-- drivers/gpu/drm/i915/intel_dp_mst.c | 8 +++++++- 2 files changed, 11 insertions(+), 3 deletions(-)drivers/gpu/drm/i915/intel_ddi.c +0
-0
drivers/gpu/drm/i915/intel_ddi.c static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder, · line 2328
Quoted 6 lines
drivers/gpu/drm/i915/intel_ddi.c +2
-1@@ -2324,7 +2324,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,intel_prepare_dp_ddi_buffers (encoder, crtc_state);intel_ddi_init_dp_buf_reg (encoder); -intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_ON ); +if (!intel_dp->is_mst) +intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_ON );
I believe Ville recommended to check for
is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)
here. The question is, are there cases where intel_dp->is_mst != is_mst? A disconnect in the middle of a modeset would cause intel_dp->is_mst to be false, wouldn't it?
Quoted 48 lines · Lyude Paul
When doing a modeset where the sink is transitioning from D3 to D0 , it would sometimes be possible for the initial
power_up_phy()to start timing out. This would only be observed in the last action before the sink went into D3 mode wasintel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We originally thought this might be an issue with us accidentally shutting off the aux block when putting the sink into D3, but since the DP spec mandates that sinks must wake up within 1ms while we have 100ms to respond to an ESI irq, this didn't really add up. Turns out that the problem is more subtle then that:It turns out that the timeout is from us not enabling DPMS on the MST hub before actually trying to initiate sideband communications. This would cause the first sideband communication (
power_up_phy()), to start timing out because the sink wasn't ready to respond. Afterwards, we would callintel_dp_sink_dpms(DRM_MODE_DPMS_ON)inintel_ddi_pre_enable_dp(), which would actually result in waking up the sink so that sideband requests would work again.Since DPMS is what lets us actually bring the hub up into a state where sideband communications become functional again, we just need to make sure to enable DPMS on the display before attempting to perform sideband communications.
Changes since v1:
- Remove comment above if (!intel_dp->is_mst) - vsryjala
- Moveintel_dp_sink_dpms()for MST intointel_dp_post_disable_mst()to keep enable/disable paths symmetrical
- Improve commit message - dhnkrn
Changes since v2:
- Only send DPMS off when we're disabling the last sink, and only send DPMS on when we're enabling the first sink - dhnkrnSigned-off-by Lyude Paul <[email protected]>Cc Dhinakaran Pandiyan <[email protected]>Cc Ville Syrjälä <[email protected]>Cc Laura Abbott <[email protected]>Fixes ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")--- drivers/gpu/drm/i915/intel_ddi.c | 6 ++++-- drivers/gpu/drm/i915/intel_dp_mst.c | 8 +++++++- 2 files changed, 11 insertions(+), 3 deletions(-)drivers/gpu/drm/i915/intel_ddi.c +0
-0
drivers/gpu/drm/i915/intel_ddi.c static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder, · line 2328
Quoted 6 lines
drivers/gpu/drm/i915/intel_ddi.c +2
-1@@ -2324,7 +2324,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,intel_prepare_dp_ddi_buffers (encoder, crtc_state);intel_ddi_init_dp_buf_reg (encoder); -intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_ON ); +if (!intel_dp->is_mst) +intel_dp_sink_dpms (intel_dp,DRM_MODE_DPMS_ON );
I believe Ville recommended to check for
is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)
here. The question is, are there cases where intel_dp->is_mst != is_mst? A disconnect in the middle of a modeset would cause intel_dp->is_mst to be false, wouldn't it?
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag, fixing commit: .
The bot has also determined it's probably a bug fixing patch. (score: 97.3902)
The bot has tested the following trees: v4.16.1, v4.15.16, v4.14.33, v4.9.93, v4.4.127.
v4.16.1: Build OK!
v4.15.16: Failed to apply! Possible dependencies:
1939ba51fd05 ("drm/i915: Pass a crtc state to ddi post_disable from MST code")
v4.14.33: Failed to apply! Possible dependencies:
1939ba51fd05 ("drm/i915: Pass a crtc state to ddi post_disable from MST code") 5ea2355a100a ("drm/i915/mst: Use MST sideband message transactions for dpms control") b1e314462bba ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") c5f93fcf2ee1 ("drm/i915: Disable infoframes when shutting down DDI HDMI") f45f3da7c4f6 ("drm/i915: Split intel_ddi_post_disable() into DP vs. HDMI variants")
v4.9.93: Failed to apply! Possible dependencies:
1939ba51fd05 ("drm/i915: Pass a crtc state to ddi post_disable from MST code") 5ea2355a100a ("drm/i915/mst: Use MST sideband message transactions for dpms control") b1e314462bba ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") c5f93fcf2ee1 ("drm/i915: Disable infoframes when shutting down DDI HDMI") e081c8463ac9 ("drm/i915: Remove duplicate DDI enabling logic from MST path") f45f3da7c4f6 ("drm/i915: Split intel_ddi_post_disable() into DP vs. HDMI variants")
v4.4.127: Failed to apply! Possible dependencies:
0552f7651bc2 ("drm/i915/mst: use reference counted connectors. (v3)") 1939ba51fd05 ("drm/i915: Pass a crtc state to ddi post_disable from MST code") 5ea2355a100a ("drm/i915/mst: Use MST sideband message transactions for dpms control") b1e314462bba ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") ba88d153526f ("drm/i915: Split intel_ddi_pre_enable() into DP and HDMI versions") c5f93fcf2ee1 ("drm/i915: Disable infoframes when shutting down DDI HDMI") e081c8463ac9 ("drm/i915: Remove duplicate DDI enabling logic from MST path") f45f3da7c4f6 ("drm/i915: Split intel_ddi_post_disable() into DP vs. HDMI variants") fd6bbda9c7a4 ("drm/i915: Pass crtc_state and connector_state to encoder functions")
Patchwork
CI✓ Fi.CI.BAT: success for drm/i915/dp: Send DPCD ON for MST before phy_up (rev2)
In reply to Lyude Paul== Series Details ==
== Series Details ==
Series: drm/i915/dp: Send DPCD ON for MST before phy_up (rev2)
URL : https://patchwork.freedesktop.org/series/41232/
State : success
== Summary ==
Series 41232v2 drm/i915/dp: Send DPCD ON for MST before phy_up
https://patchwork.freedesktop.org/api/1.0/series/41232/revisions/2/mbox/
---- Known issues:
Test debugfs_test:
Subgroup read_all_entries:
pass -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass -> FAIL (fi-gdg-551) fdo#102575
Test kms_flip:
Subgroup basic-plain-flip:
pass -> DMESG-WARN (fi-elk-e7500) fdo#103989 +1
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS (fi-cnl-y3) fdo#104951
Subgroup suspend-read-crc-pipe-c:
pass -> FAIL (fi-skl-guc) fdo#104108
Test prime_vgem:
Subgroup basic-fence-flip:
fail -> PASS (fi-ilk-650) fdo#104008fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951
fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:434s fi-bdw-gvtdvm total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:442s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:380s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:545s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:299s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:513s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:512s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:521s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:510s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:410s fi-cfl-s3 total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:560s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:515s fi-cnl-y3 total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:589s fi-elk-e7500 total:285 pass:224 dwarn:2 dfail:0 fail:0 skip:59 time:495s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:316s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:539s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:487s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:422s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:472s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:432s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:469s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:464s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:507s fi-pnv-d510 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:665s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:438s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:531s fi-skl-6700k2 total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:507s fi-skl-6770hq total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:511s fi-skl-guc total:285 pass:256 dwarn:0 dfail:0 fail:1 skip:28 time:411s fi-skl-gvtdvm total:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:448s fi-snb-2520m total:3 pass:2 dwarn:0 dfail:0 fail:0 skip:0 fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:401s
Blacklisted hosts:
fi-cnl-psr total:285 pass:256 dwarn:3 dfail:0 fail:0 skip:26 time:518s
fcaf73c13c14d6bfd64c4f37089bf5437fb32221 drm-tip: 2018y-04m-05d-15h-53m-18s UTC integration manifest d8f2fc5804b9 drm/i915/dp: Send DPCD ON for MST before phy_up
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8608/issues.html
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Patchwork
CI✓ Fi.CI.IGT: success for drm/i915/dp: Send DPCD ON for MST before phy_up (rev2)
In reply to Lyude Paul== Series Details ==
== Series Details ==
Series: drm/i915/dp: Send DPCD ON for MST before phy_up (rev2)
URL : https://patchwork.freedesktop.org/series/41232/
State : success
== Summary ==
---- Possible new issues:
Test kms_frontbuffer_tracking:
Subgroup fbcpsr-1p-primscrn-shrfb-msflip-blt:
fail -> SKIP (shard-snb)---- Known issues:
Test kms_flip:
Subgroup plain-flip-ts-check:
fail -> PASS (shard-hsw) fdo#100368
Test kms_plane_multiple:
Subgroup atomic-pipe-b-tiling-y:
pass -> FAIL (shard-apl) fdo#103166 +1
Test kms_rotation_crc:
Subgroup primary-rotation-180:
fail -> PASS (shard-snb) fdo#103925
Test kms_setmode:
Subgroup basic:
pass -> FAIL (shard-apl) fdo#99912
Test perf:
Subgroup blocking:
fail -> PASS (shard-hsw) fdo#102252fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
shard-apl total:2680 pass:1834 dwarn:1 dfail:0 fail:8 skip:836 time:12652s shard-hsw total:2680 pass:1785 dwarn:1 dfail:0 fail:2 skip:891 time:11392s shard-snb total:2680 pass:1378 dwarn:1 dfail:0 fail:2 skip:1299 time:6929s
Blacklisted hosts:
shard-kbl total:2000 pass:1462 dwarn:1 dfail:0 fail:7 skip:529 time:6487s
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8608/shards.html
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag, fixing commit: .
The bot has also determined it's probably a bug fixing patch. (score: 98.1292)
The bot has tested the following trees: v4.16.1, v4.15.16, v4.14.33, v4.9.93, v4.4.127.
v4.16.1: Build OK!
v4.15.16: Build OK!
v4.14.33: Failed to apply! Possible dependencies:
5ea2355a100a ("drm/i915/mst: Use MST sideband message transactions for dpms control") b1e314462bba ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") c5f93fcf2ee1 ("drm/i915: Disable infoframes when shutting down DDI HDMI") f45f3da7c4f6 ("drm/i915: Split intel_ddi_post_disable() into DP vs. HDMI variants")
v4.9.93: Failed to apply! Possible dependencies:
5ea2355a100a ("drm/i915/mst: Use MST sideband message transactions for dpms control") b1e314462bba ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") c5f93fcf2ee1 ("drm/i915: Disable infoframes when shutting down DDI HDMI") f45f3da7c4f6 ("drm/i915: Split intel_ddi_post_disable() into DP vs. HDMI variants")
v4.4.127: Failed to apply! Possible dependencies:
0552f7651bc2 ("drm/i915/mst: use reference counted connectors. (v3)")
5ea2355a100a ("drm/i915/mst: Use MST sideband message transactions for dpms control")
b1e314462bba ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")
ba88d153526f ("drm/i915: Split intel_ddi_pre_enable() into DP and HDMI versions")
c5f93fcf2ee1 ("drm/i915: Disable infoframes when shutting down DDI HDMI")
f45f3da7c4f6 ("drm/i915: Split intel_ddi_post_disable() into DP vs. HDMI variants")