[Intel-gfx] ✗ Fi.CI.BAT: warning for Prep. for DP audio MST support (rev11)
== Series Details == Series: Prep. for DP audio MST support (rev11) URL : https://patchwork.freedesktop.org/series/11129/ State : warning == Summary == Series 11129v11 Prep. for DP audio MST support https://patchwork.freedesktop.org/api/1.0/series/11129/revisions/11/mbox/ Test kms_pipe_crc_basic: Subgroup read-crc-pipe-a: pass -> SKIP (fi-hsw-4770r) Subgroup read-crc-pipe-b: pass -> SKIP (fi-hsw-4770r) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:202 dwarn:0 dfail:0 fail:0 skip:42 fi-byt-n2820 total:244 pass:208 dwarn:0 dfail:0 fail:1 skip:35 fi-hsw-4770k total:244 pass:226 dwarn:0 dfail:0 fail:0 skip:18 fi-hsw-4770r total:244 pass:220 dwarn:0 dfail:0 fail:0 skip:24 fi-ilk-650 total:244 pass:183 dwarn:0 dfail:0 fail:1 skip:60 fi-ivb-3520m total:244 pass:219 dwarn:0 dfail:0 fail:0 skip:25 fi-ivb-3770 total:244 pass:207 dwarn:0 dfail:0 fail:0 skip:37 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:221 dwarn:0 dfail:0 fail:1 skip:22 fi-skl-6700k total:244 pass:219 dwarn:1 dfail:0 fail:0 skip:24 fi-skl-6770hqtotal:244 pass:228 dwarn:1 dfail:0 fail:1 skip:14 fi-snb-2520m total:244 pass:208 dwarn:0 dfail:0 fail:0 skip:36 fi-snb-2600 total:244 pass:207 dwarn:0 dfail:0 fail:0 skip:37 Results at /archive/results/CI_IGT_test/Patchwork_2558/ 4c518aef024daa0223692124baa2d7399f54dd97 drm-intel-nightly: 2016y-09m-19d-20h-40m-51s UTC integration manifest cf4f6db drm/i915: start adding dp mst audio 35f6d98 drm/i915: Move audio_connector to intel_encoder 99dc209 drm/i915: Switch to using port stored in intel_encoder 2ff487f drm/i915: Store port enum in intel_encoder 909c816 drm/i915: Standardize port type for DVO encoders ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 5/5] drm/i915: start adding dp mst audio
From: Libin Yang(This patch is developed by Dave Airlie originally) This patch adds support for DP MST audio in i915. Enable audio codec when DP MST is enabled if has_audio flag is set. Disable audio codec when DP MST is disabled if has_audio flag is set. Another separated patches to support DP MST audio will be implemented in audio driver. v2: Rebased. Signed-off-by: Libin Yang Signed-off-by: Dhinakaran Pandiyan Reviewed-by: Lyude --- drivers/gpu/drm/i915/i915_debugfs.c | 19 ++- drivers/gpu/drm/i915/intel_ddi.c| 20 +++- drivers/gpu/drm/i915/intel_dp_mst.c | 18 ++ drivers/gpu/drm/i915/intel_drv.h| 2 ++ 4 files changed, 53 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 27b0e34..1384da5 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2865,6 +2865,20 @@ static void intel_dp_info(struct seq_file *m, _dp->aux); } +static void intel_dp_mst_info(struct seq_file *m, + struct intel_connector *intel_connector) +{ + struct intel_encoder *intel_encoder = intel_connector->encoder; + struct intel_dp_mst_encoder *intel_mst = + enc_to_mst(_encoder->base); + struct intel_digital_port *intel_dig_port = intel_mst->primary; + struct intel_dp *intel_dp = _dig_port->dp; + bool has_audio = drm_dp_mst_port_has_audio(_dp->mst_mgr, + intel_connector->port); + + seq_printf(m, "\taudio support: %s\n", yesno(has_audio)); +} + static void intel_hdmi_info(struct seq_file *m, struct intel_connector *intel_connector) { @@ -2907,7 +2921,10 @@ static void intel_connector_info(struct seq_file *m, switch (connector->connector_type) { case DRM_MODE_CONNECTOR_DisplayPort: case DRM_MODE_CONNECTOR_eDP: - intel_dp_info(m, intel_connector); + if (intel_encoder->type == INTEL_OUTPUT_DP_MST) + intel_dp_mst_info(m, intel_connector); + else + intel_dp_info(m, intel_connector); break; case DRM_MODE_CONNECTOR_LVDS: if (intel_encoder->type == INTEL_OUTPUT_LVDS) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index daf3adb..24275e9 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -2230,6 +2230,19 @@ void intel_ddi_prepare_link_retrain(struct intel_dp *intel_dp) udelay(600); } +bool intel_ddi_is_audio_enabled(struct drm_i915_private *dev_priv, +struct intel_crtc *intel_crtc) +{ + u32 temp; + + if (intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_AUDIO)) { + temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD); + if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe)) + return true; + } + return false; +} + void intel_ddi_get_config(struct intel_encoder *encoder, struct intel_crtc_state *pipe_config) { @@ -2295,11 +2308,8 @@ void intel_ddi_get_config(struct intel_encoder *encoder, break; } - if (intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_AUDIO)) { - temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD); - if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe)) - pipe_config->has_audio = true; - } + pipe_config->has_audio = + intel_ddi_is_audio_enabled(dev_priv, intel_crtc); if (encoder->type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.bpp && pipe_config->pipe_bpp > dev_priv->vbt.edp.bpp) { diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index 3ffbd69..2fc9f81 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -37,6 +37,8 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder, struct intel_dp_mst_encoder *intel_mst = enc_to_mst(>base); struct intel_digital_port *intel_dig_port = intel_mst->primary; struct intel_dp *intel_dp = _dig_port->dp; + struct intel_connector *connector = + to_intel_connector(conn_state->connector); struct drm_atomic_state *state; int bpp; int lane_count, slots; @@ -59,6 +61,8 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder, state = pipe_config->base.state; + if (drm_dp_mst_port_has_audio(_dp->mst_mgr, connector->port)) + pipe_config->has_audio = true; mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp); pipe_config->pbn =
[Intel-gfx] [PATCH v7 1/5] drm/i915: Standardize port type for DVO encoders
From: "Pandiyan, Dhinakaran"Changing the return type from 'char' to 'enum port' in intel_dvo_port_name() makes it easier to later move the port information to intel_encoder. In addition, the port type conforms to what we have elsewhere. Removing the last conditional that handles invalid port because dvo_reg is intialized to valid values for all DVO devices at definition. v2: Changed return type, for real (Jani) Signed-off-by: Dhinakaran Pandiyan Reviewed-by: Lyude --- drivers/gpu/drm/i915/intel_dvo.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c index 2e452c5..6489755 100644 --- a/drivers/gpu/drm/i915/intel_dvo.c +++ b/drivers/gpu/drm/i915/intel_dvo.c @@ -412,16 +412,14 @@ intel_dvo_get_current_mode(struct drm_connector *connector) return mode; } -static char intel_dvo_port_name(i915_reg_t dvo_reg) +static enum port intel_dvo_port(i915_reg_t dvo_reg) { if (i915_mmio_reg_equal(dvo_reg, DVOA)) - return 'A'; + return PORT_A; else if (i915_mmio_reg_equal(dvo_reg, DVOB)) - return 'B'; - else if (i915_mmio_reg_equal(dvo_reg, DVOC)) - return 'C'; + return PORT_B; else - return '?'; + return PORT_C; } void intel_dvo_init(struct drm_device *dev) @@ -464,6 +462,7 @@ void intel_dvo_init(struct drm_device *dev) bool dvoinit; enum pipe pipe; uint32_t dpll[I915_MAX_PIPES]; + enum port port; /* Allow the I2C driver info to specify the GPIO to be used in * special cases, but otherwise default to what's defined @@ -511,9 +510,10 @@ void intel_dvo_init(struct drm_device *dev) if (!dvoinit) continue; + port = intel_dvo_port(dvo->dvo_reg); drm_encoder_init(dev, _encoder->base, _dvo_enc_funcs, encoder_type, -"DVO %c", intel_dvo_port_name(dvo->dvo_reg)); +"DVO %c", port_name(port)); intel_encoder->type = INTEL_OUTPUT_DVO; intel_encoder->crtc_mask = (1 << 0) | (1 << 1); -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 3/5] drm/i915: Switch to using port stored in intel_encoder
From: "Pandiyan, Dhinakaran"Now that we have the port enum stored in intel_encoder, use that instead of dereferencing intel_dig_port. Saves us a few locals. struct intel_encoder variables have been renamed to be consistent and convey type information. v2: Fix incorrect 'enum port' member names - s/attached_port/port Signed-off-by: Dhinakaran Pandiyan Reviewed-by: Lyude --- drivers/gpu/drm/i915/intel_audio.c | 32 ++-- 1 file changed, 14 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c index 6c70a5b..8f5c685 100644 --- a/drivers/gpu/drm/i915/intel_audio.c +++ b/drivers/gpu/drm/i915/intel_audio.c @@ -276,17 +276,15 @@ static void hsw_audio_codec_disable(struct intel_encoder *encoder) } static void hsw_audio_codec_enable(struct drm_connector *connector, - struct intel_encoder *encoder, + struct intel_encoder *intel_encoder, const struct drm_display_mode *adjusted_mode) { struct drm_i915_private *dev_priv = to_i915(connector->dev); - struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc); + struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder->base.crtc); enum pipe pipe = intel_crtc->pipe; + enum port port = intel_encoder->port; struct i915_audio_component *acomp = dev_priv->audio_component; const uint8_t *eld = connector->eld; - struct intel_digital_port *intel_dig_port = - enc_to_dig_port(>base); - enum port port = intel_dig_port->port; uint32_t tmp; int len, i; int n, rate; @@ -355,12 +353,12 @@ static void hsw_audio_codec_enable(struct drm_connector *connector, mutex_unlock(_priv->av_mutex); } -static void ilk_audio_codec_disable(struct intel_encoder *encoder) +static void ilk_audio_codec_disable(struct intel_encoder *intel_encoder) { - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); - struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc); - enum port port = enc_to_dig_port(>base)->port; + struct drm_i915_private *dev_priv = to_i915(intel_encoder->base.dev); + struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder->base.crtc); enum pipe pipe = intel_crtc->pipe; + enum port port = intel_encoder->port; uint32_t tmp, eldv; i915_reg_t aud_config, aud_cntrl_st2; @@ -400,13 +398,13 @@ static void ilk_audio_codec_disable(struct intel_encoder *encoder) } static void ilk_audio_codec_enable(struct drm_connector *connector, - struct intel_encoder *encoder, + struct intel_encoder *intel_encoder, const struct drm_display_mode *adjusted_mode) { struct drm_i915_private *dev_priv = to_i915(connector->dev); - struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc); - enum port port = enc_to_dig_port(>base)->port; + struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder->base.crtc); enum pipe pipe = intel_crtc->pipe; + enum port port = intel_encoder->port; uint8_t *eld = connector->eld; uint32_t tmp, eldv; int len, i; @@ -490,11 +488,10 @@ void intel_audio_codec_enable(struct intel_encoder *intel_encoder) struct intel_crtc *crtc = to_intel_crtc(encoder->crtc); const struct drm_display_mode *adjusted_mode = >config->base.adjusted_mode; struct drm_connector *connector; - struct drm_device *dev = encoder->dev; - struct drm_i915_private *dev_priv = to_i915(dev); + struct drm_i915_private *dev_priv = to_i915(encoder->dev); struct i915_audio_component *acomp = dev_priv->audio_component; struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder); - enum port port = intel_dig_port->port; + enum port port = intel_encoder->port; connector = drm_select_eld(encoder); if (!connector) @@ -537,11 +534,10 @@ void intel_audio_codec_enable(struct intel_encoder *intel_encoder) void intel_audio_codec_disable(struct intel_encoder *intel_encoder) { struct drm_encoder *encoder = _encoder->base; - struct drm_device *dev = encoder->dev; - struct drm_i915_private *dev_priv = to_i915(dev); + struct drm_i915_private *dev_priv = to_i915(encoder->dev); struct i915_audio_component *acomp = dev_priv->audio_component; struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder); - enum port port = intel_dig_port->port; + enum port port = intel_encoder->port; if (dev_priv->display.audio_codec_disable) dev_priv->display.audio_codec_disable(intel_encoder); -- 2.5.0
[Intel-gfx] [PATCH v7 4/5] drm/i915: Move audio_connector to intel_encoder
From: "Pandiyan, Dhinakaran"With DP MST, a digital_port can carry more than one audio stream. Hence, more than one audio_connector needs to be attached to intel_digital_port in such cases. However, each stream is associated with an unique encoder. So, instead of creating an array of audio_connectors per port, move audio_connector from struct intel_digital_port to struct intel_encoder. This also simplifies access to the right audio_connector from codec functions in intel_audio.c that receive intel_encoder. v2: Removed locals that are not needed anymore. v3: No code change except for minor change in context. Signed-off-by: Dhinakaran Pandiyan Reviewed-by: Lyude --- drivers/gpu/drm/i915/intel_audio.c | 12 drivers/gpu/drm/i915/intel_drv.h | 4 ++-- 2 files changed, 6 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c index 8f5c685..40fbdd8 100644 --- a/drivers/gpu/drm/i915/intel_audio.c +++ b/drivers/gpu/drm/i915/intel_audio.c @@ -490,7 +490,6 @@ void intel_audio_codec_enable(struct intel_encoder *intel_encoder) struct drm_connector *connector; struct drm_i915_private *dev_priv = to_i915(encoder->dev); struct i915_audio_component *acomp = dev_priv->audio_component; - struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder); enum port port = intel_encoder->port; connector = drm_select_eld(encoder); @@ -515,7 +514,7 @@ void intel_audio_codec_enable(struct intel_encoder *intel_encoder) adjusted_mode); mutex_lock(_priv->av_mutex); - intel_dig_port->audio_connector = connector; + intel_encoder->audio_connector = connector; /* referred in audio callbacks */ dev_priv->dig_port_map[port] = intel_encoder; mutex_unlock(_priv->av_mutex); @@ -536,14 +535,13 @@ void intel_audio_codec_disable(struct intel_encoder *intel_encoder) struct drm_encoder *encoder = _encoder->base; struct drm_i915_private *dev_priv = to_i915(encoder->dev); struct i915_audio_component *acomp = dev_priv->audio_component; - struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder); enum port port = intel_encoder->port; if (dev_priv->display.audio_codec_disable) dev_priv->display.audio_codec_disable(intel_encoder); mutex_lock(_priv->av_mutex); - intel_dig_port->audio_connector = NULL; + intel_encoder->audio_connector = NULL; dev_priv->dig_port_map[port] = NULL; mutex_unlock(_priv->av_mutex); @@ -704,7 +702,6 @@ static int i915_audio_component_get_eld(struct device *kdev, int port, { struct drm_i915_private *dev_priv = kdev_to_i915(kdev); struct intel_encoder *intel_encoder; - struct intel_digital_port *intel_dig_port; const u8 *eld; int ret = -EINVAL; @@ -713,10 +710,9 @@ static int i915_audio_component_get_eld(struct device *kdev, int port, /* intel_encoder might be NULL for DP MST */ if (intel_encoder) { ret = 0; - intel_dig_port = enc_to_dig_port(_encoder->base); - *enabled = intel_dig_port->audio_connector != NULL; + *enabled = intel_encoder->audio_connector != NULL; if (*enabled) { - eld = intel_dig_port->audio_connector->eld; + eld = intel_encoder->audio_connector->eld; ret = drm_eld_size(eld); memcpy(buf, eld, min(max_bytes, ret)); } diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 972040a..cf92bc0 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -248,6 +248,8 @@ struct intel_encoder { void (*suspend)(struct intel_encoder *); int crtc_mask; enum hpd_pin hpd_pin; + /* for communication with audio component; protected by av_mutex */ + const struct drm_connector *audio_connector; }; struct intel_panel { @@ -959,8 +961,6 @@ struct intel_digital_port { enum irqreturn (*hpd_pulse)(struct intel_digital_port *, bool); bool release_cl2_override; uint8_t max_lanes; - /* for communication with audio component; protected by av_mutex */ - const struct drm_connector *audio_connector; }; struct intel_dp_mst_encoder { -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 2/5] drm/i915: Store port enum in intel_encoder
From: "Pandiyan, Dhinakaran"Storing the port enum in intel_encoder makes it convenient to know the port attached to an encoder. Moving the port information up from intel_digital_port to intel_encoder avoids unecessary intel_digital_port access and handles MST encoders cleanly without requiring conditional checks for them (thanks danvet). v2: Renamed the port enum member from 'attached_port' to 'port' (danvet) Fixed missing initialization of port in intel_sdvo.c (danvet) v3: Fixed missing initialization of port in intel_crt.c (Ville) v4: Storing port for DVO encoders too. Signed-off-by: Dhinakaran Pandiyan Cc: Daniel Vetter Cc: Ville Syrjälä Acked-by: Daniel Vetter Reviewed-by: Lyude --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_crt.c| 2 ++ drivers/gpu/drm/i915/intel_ddi.c| 1 + drivers/gpu/drm/i915/intel_dp.c | 1 + drivers/gpu/drm/i915/intel_dp_mst.c | 1 + drivers/gpu/drm/i915/intel_drv.h| 1 + drivers/gpu/drm/i915/intel_dsi.c| 1 + drivers/gpu/drm/i915/intel_dvo.c| 2 ++ drivers/gpu/drm/i915/intel_hdmi.c | 1 + drivers/gpu/drm/i915/intel_lvds.c | 3 ++- drivers/gpu/drm/i915/intel_sdvo.c | 1 + drivers/gpu/drm/i915/intel_tv.c | 2 ++ 12 files changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 4dd307e..270543c 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -185,6 +185,7 @@ enum plane { #define sprite_name(p, s) ((p) * INTEL_INFO(dev)->num_sprites[(p)] + (s) + 'A') enum port { + PORT_NONE = -1, PORT_A = 0, PORT_B, PORT_C, diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c index dfbcf16..88ebbdd 100644 --- a/drivers/gpu/drm/i915/intel_crt.c +++ b/drivers/gpu/drm/i915/intel_crt.c @@ -917,10 +917,12 @@ void intel_crt_init(struct drm_device *dev) if (I915_HAS_HOTPLUG(dev)) crt->base.hpd_pin = HPD_CRT; if (HAS_DDI(dev)) { + crt->base.port = PORT_E; crt->base.get_config = hsw_crt_get_config; crt->base.get_hw_state = intel_ddi_get_hw_state; crt->base.post_disable = hsw_post_disable_crt; } else { + crt->base.port = PORT_NONE; crt->base.get_config = intel_crt_get_config; crt->base.get_hw_state = intel_crt_get_hw_state; } diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 8065a5f..daf3adb 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -2523,6 +2523,7 @@ void intel_ddi_init(struct drm_device *dev, enum port port) intel_dig_port->max_lanes = max_lanes; intel_encoder->type = INTEL_OUTPUT_UNKNOWN; + intel_encoder->port = port; intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2); intel_encoder->cloneable = 0; diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index acd0c51..0568fb5 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -5832,6 +5832,7 @@ bool intel_dp_init(struct drm_device *dev, intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2); } intel_encoder->cloneable = 0; + intel_encoder->port = port; intel_dig_port->hpd_pulse = intel_dp_hpd_pulse; dev_priv->hotplug.irq_port[port] = intel_dig_port; diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index 54a9d76..3ffbd69 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -523,6 +523,7 @@ intel_dp_create_fake_mst_encoder(struct intel_digital_port *intel_dig_port, enum DRM_MODE_ENCODER_DPMST, "DP-MST %c", pipe_name(pipe)); intel_encoder->type = INTEL_OUTPUT_DP_MST; + intel_encoder->port = intel_dig_port->port; intel_encoder->crtc_mask = 0x7; intel_encoder->cloneable = 0; diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 8fd16ad..972040a 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -206,6 +206,7 @@ struct intel_encoder { struct drm_encoder base; enum intel_output_type type; + enum port port; unsigned int cloneable; void (*hot_plug)(struct intel_encoder *); bool (*compute_config)(struct intel_encoder *, diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index b2e3d3a..727adaa 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -1488,6 +1488,7 @@ void intel_dsi_init(struct drm_device *dev) intel_connector->get_hw_state =
[Intel-gfx] [PATCH v7 0/5] Prep. for DP audio MST support
This series lays the groundwork for more DP MST audio work that will follow. v7: Added R-B tags and rebased. v6: Modified the return type for a helper that returns port in intel_dvo.c v5: Really renamed the port enum member from 'attached_port' to 'port' Rebased on atomic changes. v4: Fixed missing port initialization in intel_sdvo.c Renamed the port enum member from 'attached_port' to 'port' Fixed commit message typos. v3: Different solution to get port from encoder (danvet). Removed locals that are not needed any more. Minor variable renaming clean up. Rebased on dinq. Retained r-b for "start adding dp mst audio" as it does not change. v2: Different solution replacing the enc_to_dig_port() fix (Ville, Lyude). No changes to MST audio enabling and move audio_connector patches. Reordered the patches (Lyude) Pandiyan, Dhinakaran (4): drm/i915: Standardize port type for DVO encoders drm/i915: Store port enum in intel_encoder drm/i915: Switch to using port stored in intel_encoder drm/i915: Move audio_connector to intel_encoder Libin Yang (1): drm/i915: start adding dp mst audio drivers/gpu/drm/i915/i915_debugfs.c | 19 +++- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_audio.c | 44 +++-- drivers/gpu/drm/i915/intel_crt.c| 2 ++ drivers/gpu/drm/i915/intel_ddi.c| 21 +- drivers/gpu/drm/i915/intel_dp.c | 1 + drivers/gpu/drm/i915/intel_dp_mst.c | 19 drivers/gpu/drm/i915/intel_drv.h| 7 -- drivers/gpu/drm/i915/intel_dsi.c| 1 + drivers/gpu/drm/i915/intel_dvo.c| 16 -- drivers/gpu/drm/i915/intel_hdmi.c | 1 + drivers/gpu/drm/i915/intel_lvds.c | 3 ++- drivers/gpu/drm/i915/intel_sdvo.c | 1 + drivers/gpu/drm/i915/intel_tv.c | 2 ++ 14 files changed, 96 insertions(+), 42 deletions(-) -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] tests/kms_psr_sink_crc: commit before querying mode
From: Mika KuoppalaCommit to a mode before querying it. Tested-by: Rodrigo Vivi References: https://bugs.freedesktop.org/show_bug.cgi?id=97172 Cc: Maarten Lankhorst Signed-off-by: Mika Kuoppala Signed-off-by: Rodrigo Vivi --- tests/kms_psr_sink_crc.c | 8 1 file changed, 8 insertions(+) diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c index 8aafedb..68310d8 100644 --- a/tests/kms_psr_sink_crc.c +++ b/tests/kms_psr_sink_crc.c @@ -112,6 +112,14 @@ static void setup_output(data_t *data) continue; igt_output_set_pipe(output, pipe); + igt_display_commit(display); + + if (!output->valid) { + igt_output_set_pipe(output, PIPE_ANY); + igt_display_commit(display); + continue; + } + data->crtc_id = output->config.crtc->crtc_id; data->output = output; data->mode = igt_output_get_mode(output); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: Fix typo in encoder docs
== Series Details == Series: drm: Fix typo in encoder docs URL : https://patchwork.freedesktop.org/series/12666/ State : warning == Summary == Series 12666v1 drm: Fix typo in encoder docs https://patchwork.freedesktop.org/api/1.0/series/12666/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b-frame-sequence: pass -> SKIP (fi-hsw-4770r) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:202 dwarn:0 dfail:0 fail:0 skip:42 fi-byt-n2820 total:244 pass:208 dwarn:0 dfail:0 fail:1 skip:35 fi-hsw-4770k total:244 pass:226 dwarn:0 dfail:0 fail:0 skip:18 fi-hsw-4770r total:244 pass:221 dwarn:0 dfail:0 fail:0 skip:23 fi-ilk-650 total:244 pass:183 dwarn:0 dfail:0 fail:1 skip:60 fi-ivb-3520m total:244 pass:219 dwarn:0 dfail:0 fail:0 skip:25 fi-ivb-3770 total:244 pass:207 dwarn:0 dfail:0 fail:0 skip:37 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:221 dwarn:0 dfail:0 fail:1 skip:22 fi-skl-6700k total:244 pass:219 dwarn:1 dfail:0 fail:0 skip:24 fi-skl-6770hqtotal:244 pass:228 dwarn:1 dfail:0 fail:1 skip:14 fi-snb-2520m total:244 pass:208 dwarn:0 dfail:0 fail:0 skip:36 fi-snb-2600 total:244 pass:207 dwarn:0 dfail:0 fail:0 skip:37 Results at /archive/results/CI_IGT_test/Patchwork_2557/ 4c518aef024daa0223692124baa2d7399f54dd97 drm-intel-nightly: 2016y-09m-19d-20h-40m-51s UTC integration manifest 991a333 drm: Fix typo in encoder docs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Fix typo in encoder docs
Corrected typo in bridge and encoder comparison. Also, added a one-line encoder description from the previous documentation. Cc: Daniel VetterCc: Archit Taneja Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/drm_encoder.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c index 998a674..5c06771 100644 --- a/drivers/gpu/drm/drm_encoder.c +++ b/drivers/gpu/drm/drm_encoder.c @@ -31,20 +31,21 @@ * * Encoders represent the connecting element between the CRTC (as the overall * pixel pipeline, represented by struct _crtc) and the connectors (as the - * generic sink entity, represented by struct _connector). Encoders are - * objects exposed to userspace, originally to allow userspace to infer cloning - * and connector/CRTC restrictions. Unfortunately almost all drivers get this - * wrong, making the uabi pretty much useless. On top of that the exposed - * restrictions are too simple for todays hardware, and the recommend way to - * infer restrictions is by using the DRM_MODE_ATOMIC_TEST_ONLY flag for the - * atomic IOCTL. + * generic sink entity, represented by struct _connector). An encoder takes + * pixel data from a CRTC and converts it to a format suitable for any attached + * connector. Encoders are objects exposed to userspace, originally to allow + * userspace to infer cloning and connector/CRTC restrictions. Unfortunately + * almost all drivers get this wrong, making the uabi pretty much useless. On + * top of that the exposed restrictions are too simple for today's hardware, and + * the recommended way to infer restrictions is by using the + * DRM_MODE_ATOMIC_TEST_ONLY flag for the atomic IOCTL. * * Otherwise encoders aren't used in the uapi at all (any modeset request from * userspace directly connects a connector with a CRTC), drivers are therefore * free to use them however they wish. Modeset helper libraries make strong use * of encoders to facilitate code sharing. But for more complex settings it is * usually better to move shared code into a separate _bridge. Compared to - * encoders bridges also have the benefit of not being purely an internal + * encoders, bridges also have the benefit of being purely an internal * abstraction since they are not exposed to userspace at all. * * Encoders are initialized with drm_encoder_init() and cleaned up using -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 4/9] drm/i915: Decode system memory bandwidth
Hi Em Sex, 2016-09-09 às 13:31 +0530, Kumar, Mahesh escreveu: > From: Mahesh Kumar> > This patch adds support to decode system memory bandwidth > which will be used for arbitrated display memory percentage > calculation in GEN9 based system. This is not a complete review of this patch since I can't find the documentation for the registers used by the patch, but I'll try to provide some early feedback. Most of it is about styling, so feel free to provide counter arguments if you disagree. > > Signed-off-by: Mahesh Kumar > --- > drivers/gpu/drm/i915/i915_drv.c | 96 > + > drivers/gpu/drm/i915/i915_drv.h | 18 > drivers/gpu/drm/i915/i915_reg.h | 25 +++ > 3 files changed, 139 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > b/drivers/gpu/drm/i915/i915_drv.c > index 02c34d6..0a4f18d 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -973,6 +973,96 @@ static void intel_sanitize_options(struct > drm_i915_private *dev_priv) > DRM_DEBUG_DRIVER("use GPU sempahores? %s\n", > yesno(i915.semaphores)); > } > > +static void > +intel_get_memdev_info(struct drm_device *dev) In our current standards we prefer that you use drm_i915_private as the parameter here. And the new function doesn't even use drm_device for anything, so that reinforces the argument. > +{ > + struct drm_i915_private *dev_priv = to_i915(dev); > + uint32_t val = 0; > + uint32_t mem_speed = 0; > + uint8_t dram_type; > + uint32_t dram_channel; > + uint8_t num_channel; > + bool rank_valid = false; We generally don't zero-initialize things that don't need to be zero- initialized, like these 3 variables. I know this is an eternal discussion and each side has pros and cons, but following the already used coding style usually wins. Also, please just add this: struct memdev_info *memdev_info = _priv->memdev_info; All those "dev_priv->memdev_info" statements below are already making my fingers hurt, and I didn't even type them :) > + > + if (!IS_GEN9(dev_priv)) > + goto exit; If you just set memdev_info.valid to false right at the beginning of the function then you can just return here and below without using the goto. IMHO it will look better. Or you could even rely on the fact that we used kzalloc anyway. > + > + val = I915_READ(P_CR_MC_BIOS_REQ_0_0_0); > + mem_speed = div_u64((uint64_t) (val & REQ_DATA_MASK) * > + MEMORY_FREQ_MULTIPLIER, 1000); > + > + if (mem_speed == 0) > + goto exit; Perhaps a DRM_DEBUG_KMS("something something memory data is not valid") would be useful here too. > + > + dev_priv->memdev_info.valid = true; > + dev_priv->memdev_info.mem_speed = mem_speed; > + dram_type = (val >> DRAM_TYPE_SHIFT) & DRAM_TYPE_MASK; > + dram_channel = (val >> DRAM_CHANNEL_SHIFT) & > DRAM_CHANNEL_MASK; > + num_channel = hweight32(dram_channel); > + > + /* > + * The lpddr3 and lpddr4 technologies can have 1-4 channels > and the > + * channels are 32bits wide; while ddr3l technologies can > have 1-2 > + * channels and the channels are 64 bits wide. But SV team > found that in > + * case of single 64 bit wide DDR3L dimms two bits were set > and system > + * with two DDR3L 64bit dimm all four bits were set. > + */ I still don't have access to the spec, but this comment suggests the spec doesn't match the SV team findings. So can't the SV team request the specs to reflect their findings? As an outsider, I see this as the SV team's word against the HW team's words, and I don't know who made the mistake: the SV engineer or the HW engineer. So I expect a discussion between the two and the conclusions being reflected on the specification :). Errata knowledge shouldn't go straight to the drivers, that's a recipe for eternal doubt to the future people maintaining this code. > + > + switch (dram_type) { > + case DRAM_TYPE_LPDDR3: > + case DRAM_TYPE_LPDDR4: > + dev_priv->memdev_info.data_width = 4; > + dev_priv->memdev_info.num_channel = num_channel; > + break; > + case DRAM_TYPE_DDR3L: > + dev_priv->memdev_info.data_width = 8; > + dev_priv->memdev_info.num_channel = num_channel / 2; > + break; > + default: Again, no access to the spec here, but shouldn't this case reset memdev_info.valid to false and then return (possibly with a DRM_DEBUG_KMS)? > + dev_priv->memdev_info.data_width = 4; > + dev_priv->memdev_info.num_channel = num_channel; > + } > + > + /* > + * Now read each DUNIT8/9/10/11 to check the rank of each > dimms. > + * all the dimms should have same rank as in first valid > Dimm > + */ > > +#define D_CR_DRP0_DUNIT_INVALID 0x I'm not a huge fan of these mid-file
Re: [Intel-gfx] [i915] monitor is not detected unless it was active during boot
I checked both monitors, on displayport they work, on HDMI they share the same trouble. An interesting observation is that when plug the monitor into another system which has an older nvidia card using nouveau (only HDMI is available, card is too old for displayport). It seems that the i2c connection is unreliable, sometimes more or less data is retrieved, but never all of it seems, and sometimes none. I wonder if there is some sensitivity to i2c speed. My general observation of these monitors is that they are slow to turn on on displayport (locking in a mode takes some time), but on hdmi it is faster, is there some kind of throttling going on the displayport side that is being ignored on the HDMI side? [768542.009520] [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, remainder is 254 [768542.009561] Raw EDID: [768542.009575] 00 ff ff ff ff ff ff 00 4c 2d d0 0c 56 53 4d 30 [768542.009593] 20 19 01 03 80 34 1d 78 2a 12 55 a9 54 4d 9f 25 [768542.009610] 0c 50 54 bf ef 80 71 4f 81 00 81 c0 81 80 95 00 [768542.009626] a9 c0 b3 00 01 01 08 e8 00 30 f2 70 5a 80 b0 58 [768542.009642] 8a 00 09 25 21 00 00 1e 00 00 00 fd 00 18 4b 1e [768542.009658] 87 3c 00 0a 20 20 20 20 20 20 00 00 00 fc 00 55 [768542.009678] 32 34 45 38 35 30 0a 20 20 20 20 20 00 00 00 ff [768542.009694] 00 48 54 48 47 38 30 30 30 30 35 0a 20 20 07 ff [768542.010899] nouveau :01:00.0: DRM: DDC responded, but no EDID for HDMI-A-1 [768578.474150] [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, remainder is 157 [768578.474171] Raw EDID: [768578.474178] 00 ff ff ff ff ff ff 00 4c 2d d0 0c 56 53 4d 30 [768578.474187] 20 19 01 03 80 34 1d 78 2a 12 55 a9 54 4d 9f 25 [768578.474195] 0c 50 54 bf ef ff ff ff ff ff ff ff ff ff ff ff [768578.474202] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [768578.474210] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [768578.474218] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [768578.474225] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [768578.474233] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [768578.475264] nouveau :01:00.0: DRM: DDC responded, but no EDID for HDMI-A-1 [768590.904774] [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, remainder is 181 [768590.904813] Raw EDID: [768590.904826] 00 ff ff ff ff ff ff 00 4c 2d d0 0c 56 53 4d 30 [768590.904843] 20 19 01 03 80 34 1d 78 2a 12 55 a9 54 4d 9f 25 [768590.904860] 0c 50 54 bf ef 80 71 4f 81 00 81 c0 81 80 95 00 [768590.904876] a9 c0 b3 00 01 01 08 e8 00 30 f2 70 5a 80 b0 58 [768590.904892] 8a 00 09 25 21 00 00 1e 00 00 00 fd 00 18 4b 1e [768590.904908] 87 3c 00 0a 20 20 20 20 20 20 00 00 00 fc 00 55 [768590.904924] 32 34 45 38 35 30 0a 20 20 20 20 20 00 00 00 ff [768590.904940] 00 48 54 48 47 38 30 30 30 30 35 0b ff ff ff ff [768590.906012] nouveau :01:00.0: DRM: DDC responded, but no EDID for HDMI-A-1 On Mon, Sep 19, 2016 at 9:50 PM, Maarten Maathuiswrote: > The previous messages are about using the HDMI connection of my monitor on > the HDMI 2.0->DP bridge (whatever the formal name may be) of my motherboard, > > Using the HDMI 1.4 connection of my motherboard: > > [ 55.744581] [drm:intel_get_hpd_pins] hotplug event received, stat > 0x0040, dig 0x10101210, pins 0x0040 > [ 55.744589] [drm:intel_hpd_irq_storm_detect] Received HPD interrupt on > PIN 6 - cnt: 0 > [ 55.744620] [drm:i915_hotplug_work_func] running encoder hotplug > functions > [ 55.744625] [drm:i915_hotplug_work_func] Connector HDMI-A-2 (pin 6) > received hotplug event. > [ 55.744629] [drm:intel_hdmi_detect] [CONNECTOR:46:HDMI-A-2] > [ 55.744915] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr: > 0050 w(1) > [ 55.744922] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK on first > message, retry > [ 55.745190] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr: > 0050 w(1) > [ 55.745199] [drm:drm_do_probe_ddc_edid] drm: skipping non-existent > adapter i915 gmbus dpc > [ 55.745469] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr: > 0040 w(1) > [ 55.745476] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK on first > message, retry > [ 55.745744] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr: > 0040 w(1) > > As for my OS, i run archlinux: > Linux main 4.7.4-1-ARCH #1 SMP PREEMPT Thu Sep 15 15:24:29 CEST 2016 > x86_64 GNU/Linux > > The requested VBT information is somewhere in here, I couldn't filter it > since i couldn't see an end marker: > > [2.394379] [drm:intel_detect_pch] Found SunrisePoint PCH > [2.394380] [drm:get_allowed_dc_mask] Allowed DC state mask 03 > [2.394768] [drm:i915_dump_device_info] i915 device info: gen=9, > pciid=0x1912 rev=0x06 flags=need_gfx_hws,is_skylake, > has_fbc,has_hotplug,has_llc,has_ddi,has_fpga_dbg, > [2.394768] [drm:intel_device_info_runtime_init] slice total: 1 > [2.394769] [drm:intel_device_info_runtime_init] subslice total: 3 > [
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Update i915.reset to handle engine resets
On Mon, Sep 19, 2016 at 04:30:13PM +0100, Matthew Auld wrote: > From: "arun.siluv...@linux.intel.com"> > In preparation for engine reset work update this parameter to handle more > than one type of reset. Default at the moment is still full gpu reset. This is not ready yet. Please try integrating into the direct reset and request recovery. When done properly we won't even need a module option since it will safely fallback. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/7] drm/i915/tdr: Add support for per engine reset recovery
On Mon, Sep 19, 2016 at 04:30:15PM +0100, Matthew Auld wrote: > From: "arun.siluv...@linux.intel.com"> > This change implements support for per-engine reset as an initial, less > intrusive hang recovery option to be attempted before falling back to the > legacy full GPU reset recovery mode if necessary. This is only supported > from Gen8 onwards. > > Hangchecker determines which engines are hung and invokes error handler to > recover from it. Error handler schedules recovery for each of those engines > that are hung. The recovery procedure is as follows, > - identifies the request that caused the hang and it is dropped > - force engine to idle: this is done by issuing a reset request > - reset and re-init engine > - restart submissions to the engine > > If engine reset fails then we fall back to heavy weight full gpu reset > which resets all engines and reinitiazes complete state of HW and SW. > > v2 > - rebase > > Cc: Chris Wilson > Cc: Mika Kuoppala > Signed-off-by: Tomas Elf > Signed-off-by: Arun Siluvery > Signed-off-by: Matthew Auld > --- > drivers/gpu/drm/i915/i915_drv.c | 59 > + > drivers/gpu/drm/i915/i915_drv.h | 3 ++ > drivers/gpu/drm/i915/i915_gem.c | 2 +- > drivers/gpu/drm/i915/intel_lrc.c| 10 +++ > drivers/gpu/drm/i915/intel_lrc.h| 1 + > drivers/gpu/drm/i915/intel_uncore.c | 41 +++--- > 6 files changed, 105 insertions(+), 11 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 99fa690..8625207 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -1812,21 +1812,68 @@ error: > * Returns zero on successful reset or otherwise an error code. > * > * Procedure is fairly simple: > - * - force engine to idle > - * - save current state which includes head and current request > - * - reset engine > - * - restore saved state and resubmit context > + *- identifies the request that caused the hang and it is dropped > + *- force engine to idle: this is done by issuing a reset request > + *- reset engine > + *- restart submissions to the engine > */ > int i915_reset_engine(struct intel_engine_cs *engine) > { > int ret; > struct drm_i915_private *dev_priv = engine->i915; > > - /* FIXME: replace me with engine reset sequence */ > - ret = -ENODEV; > + /* > + * We need to first idle the engine by issuing a reset request, > + * then perform soft reset and re-initialize hw state, for all of > + * this GT power need to be awake so ensure it does throughout the > + * process > + */ > + intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL); > + > + /* > + * the request that caused the hang is stuck on elsp, identify the > + * active request and drop it, adjust head to skip the offending > + * request to resume executing remaining requests in the queue. > + */ > + i915_gem_reset_engine(engine); > + > + ret = intel_engine_reset_begin(engine); > + if (ret) { > + DRM_ERROR("Failed to disable %s\n", engine->name); > + goto error; > + } > + > + ret = intel_gpu_reset(dev_priv, intel_engine_flag(engine)); > + if (ret) { > + DRM_ERROR("Failed to reset %s, ret=%d\n", engine->name, ret); > + intel_engine_reset_cancel(engine); > + goto error; > + } Ordering is still broken. > + > + ret = engine->init_hw(engine); > + if (ret) > + goto error; > + > + intel_engine_reset_cancel(engine); > + intel_execlists_restart_submission(engine); This is broken. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915/tdr: Modify error handler for per engine hang recovery
On Mon, Sep 19, 2016 at 04:30:14PM +0100, Matthew Auld wrote: > From: "arun.siluv...@linux.intel.com"> > This is a preparatory patch which modifies error handler to do per engine > hang recovery. The actual patch which implements this sequence follows > later in the series. The aim is to prepare existing recovery function to > adapt to this new function where applicable (which fails at this point > because core implementation is lacking) and continue recovery using legacy > full gpu reset. > > A helper function is also added to query the availability of engine > reset. > > The error events behaviour that are used to notify user of reset are > adapted to engine reset such that it doesn't break users listening to these > events. In legacy we report an error event, a reset event before resetting > the gpu and a reset done event marking the completion of reset. The same > behaviour is adapted but reset event is only dispatched once even when > multiple engines are hung. Finally once reset is complete we send reset > done event as usual. > > v2 > - rework slightly > - prefer INTEL_GEN > - document engine_mask param > > Cc: Chris Wilson > Cc: Mika Kuoppala > Signed-off-by: Ian Lister > Signed-off-by: Tomas Elf > Signed-off-by: Arun Siluvery > Signed-off-by: Matthew Auld > --- > drivers/gpu/drm/i915/i915_drv.c | 26 +++ > drivers/gpu/drm/i915/i915_drv.h | 2 ++ > drivers/gpu/drm/i915/i915_irq.c | 50 > + > drivers/gpu/drm/i915/intel_uncore.c | 5 > 4 files changed, 78 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 7f4e8ad..99fa690 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -1804,6 +1804,32 @@ error: > goto wakeup; > } > > +/** > + * i915_reset_engine - reset GPU engine to recover from a hang > + * @engine: engine to reset > + * > + * Reset a specific GPU engine. Useful if a hang is detected. > + * Returns zero on successful reset or otherwise an error code. > + * > + * Procedure is fairly simple: > + * - force engine to idle > + * - save current state which includes head and current request > + * - reset engine > + * - restore saved state and resubmit context > + */ > +int i915_reset_engine(struct intel_engine_cs *engine) > +{ > + int ret; > + struct drm_i915_private *dev_priv = engine->i915; > + > + /* FIXME: replace me with engine reset sequence */ > + ret = -ENODEV; > + > + set_bit(I915_RESET_IN_PROGRESS, _priv->gpu_error.flags); > + > + return ret; > +} > + > static int i915_pm_suspend(struct device *kdev) > { > struct pci_dev *pdev = to_pci_dev(kdev); > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 4dd307e..79de74d 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -2888,6 +2888,8 @@ extern long i915_compat_ioctl(struct file *filp, > unsigned int cmd, > extern int intel_gpu_reset(struct drm_i915_private *dev_priv, u32 > engine_mask); > extern bool intel_has_gpu_reset(struct drm_i915_private *dev_priv); > extern void i915_reset(struct drm_i915_private *dev_priv); > +extern bool intel_has_engine_reset(struct drm_i915_private *dev_priv); > +extern int i915_reset_engine(struct intel_engine_cs *engine); > extern int intel_guc_reset(struct drm_i915_private *dev_priv); > extern void intel_engine_init_hangcheck(struct intel_engine_cs *engine); > extern unsigned long i915_chipset_val(struct drm_i915_private *dev_priv); > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > index c128fdb..45c5a26 100644 > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -2487,11 +2487,13 @@ static void i915_error_wake_up(struct > drm_i915_private *dev_priv) > /** > * i915_reset_and_wakeup - do process context error handling work > * @dev_priv: i915 device private > + * @engine_mask: engines which are marked as hung > * > * Fire an error uevent so userspace can see that a hang or error > * was detected. > */ > -static void i915_reset_and_wakeup(struct drm_i915_private *dev_priv) > +static void i915_reset_and_wakeup(struct drm_i915_private *dev_priv, > + u32 engine_mask) > { > struct kobject *kobj = _priv->drm.primary->kdev->kobj; > char *error_event[] = { I915_ERROR_UEVENT "=1", NULL }; > @@ -2501,6 +2503,15 @@ static void i915_reset_and_wakeup(struct > drm_i915_private *dev_priv) > kobject_uevent_env(kobj, KOBJ_CHANGE, error_event); > > DRM_DEBUG_DRIVER("resetting chip\n"); > + /* > + * This event needs to be sent before performing gpu reset. When > + * engine
Re: [Intel-gfx] [i915] monitor is not detected unless it was active during boot
The previous messages are about using the HDMI connection of my monitor on the HDMI 2.0->DP bridge (whatever the formal name may be) of my motherboard, Using the HDMI 1.4 connection of my motherboard: [ 55.744581] [drm:intel_get_hpd_pins] hotplug event received, stat 0x0040, dig 0x10101210, pins 0x0040 [ 55.744589] [drm:intel_hpd_irq_storm_detect] Received HPD interrupt on PIN 6 - cnt: 0 [ 55.744620] [drm:i915_hotplug_work_func] running encoder hotplug functions [ 55.744625] [drm:i915_hotplug_work_func] Connector HDMI-A-2 (pin 6) received hotplug event. [ 55.744629] [drm:intel_hdmi_detect] [CONNECTOR:46:HDMI-A-2] [ 55.744915] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr: 0050 w(1) [ 55.744922] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK on first message, retry [ 55.745190] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr: 0050 w(1) [ 55.745199] [drm:drm_do_probe_ddc_edid] drm: skipping non-existent adapter i915 gmbus dpc [ 55.745469] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr: 0040 w(1) [ 55.745476] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK on first message, retry [ 55.745744] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr: 0040 w(1) As for my OS, i run archlinux: Linux main 4.7.4-1-ARCH #1 SMP PREEMPT Thu Sep 15 15:24:29 CEST 2016 x86_64 GNU/Linux The requested VBT information is somewhere in here, I couldn't filter it since i couldn't see an end marker: [2.394379] [drm:intel_detect_pch] Found SunrisePoint PCH [2.394380] [drm:get_allowed_dc_mask] Allowed DC state mask 03 [2.394768] [drm:i915_dump_device_info] i915 device info: gen=9, pciid=0x1912 rev=0x06 flags=need_gfx_hws,is_skylake,has_fbc,has_hotplug,has_llc,has_ddi,has_fpga_dbg, [2.394768] [drm:intel_device_info_runtime_init] slice total: 1 [2.394769] [drm:intel_device_info_runtime_init] subslice total: 3 [2.394769] [drm:intel_device_info_runtime_init] subslice per slice: 3 [2.394770] [drm:intel_device_info_runtime_init] EU total: 24 [2.394770] [drm:intel_device_info_runtime_init] EU per subslice: 8 [2.394770] [drm:intel_device_info_runtime_init] has slice power gating: n [2.394771] [drm:intel_device_info_runtime_init] has subslice power gating: n [2.394771] [drm:intel_device_info_runtime_init] has EU power gating: y [2.394815] [drm:i915_gem_init_stolen] Memory reserved for graphics device: 262144K, usable: 261120K [2.394815] [drm] Memory usable by graphics device = 4096M [2.394816] [drm:i915_ggtt_init_hw] GMADR size = 256M [2.394816] [drm:i915_ggtt_init_hw] GTT stolen size = 256M [2.394817] [drm:i915_ggtt_init_hw] ppgtt mode: 3 [2.394818] checking generic (c000 1fb) vs hw (c000 1000) [2.394818] fb: switching to inteldrmfb from EFI VGA [2.403811] Console: switching to colour dummy device 80x25 [2.403875] [drm] Replacing VGA console driver [2.404199] [drm:intel_opregion_setup] graphic opregion physical addr: 0x77f83018 [2.404207] [drm:intel_opregion_setup] Public ACPI methods supported [2.404208] [drm:intel_opregion_setup] SWSCI supported [2.409161] [drm:swsci_setup] SWSCI GBDA callbacks 0cb3, SBCB callbacks 00300483 [2.409163] [drm:intel_opregion_setup] ASLE supported [2.409164] [drm:intel_opregion_setup] ASLE extension supported [2.409165] [drm:intel_opregion_setup] Found valid VBT in ACPI OpRegion (Mailbox #4) [2.409230] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [2.409231] [drm] Driver supports precise vblank timestamp query. [2.409233] [drm:init_vbt_defaults] Set default to SSC at 12 kHz [2.409234] [drm:intel_bios_init] VBT signature "$VBT SKYLAKE", BDB version 205 [2.409236] [drm:parse_general_features] BDB_GENERAL_FEATURES int_tv_support 0 int_crt_support 0 lvds_use_ssc 0 lvds_ssc_freq 12 display_clock_mode 1 fdi_rx_polarity_inverted 0 [2.409237] [drm:parse_general_definitions] crt_ddc_bus_pin: 2 [2.411255] [drm:intel_opregion_get_panel_type] Ignoring OpRegion panel type (0) [2.411257] [drm:parse_lfp_panel_data] Panel type: 2 (VBT) [2.411258] [drm:parse_lfp_panel_data] DRRS supported mode is static [2.411260] [drm:parse_lfp_panel_data] Found panel mode in BIOS VBT tables: [2.411262] [drm:drm_mode_debug_printmodeline] Modeline 0:"1024x768" 0 65000 1024 1048 1184 1344 768 771 777 806 0x8 0xa [2.411263] [drm:parse_lfp_panel_data] VBT initial LVDS value 300 [2.411264] [drm:parse_lfp_backlight] VBT backlight PWM modulation frequency 200 Hz, active high, min brightness 0, level 255 [2.411265] [drm:parse_sdvo_device_mapping] Unsupported child device size for SDVO mapping. [2.411266] [drm:parse_device_mapping] Expected child device config size for VBT version 205 not known; assuming 38 [2.411267] [drm:parse_driver_features] DRRS State Enabled:1 [2.411268] [drm:parse_ddi_port] Port B VBT info: DP:1 HDMI:1 DVI:1 EDP:0 CRT:0 [2.411269]
Re: [Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3
On Mon, 2016-09-19 at 08:09 -0700, James Bottomley wrote: > On Sun, 2016-09-18 at 13:35 +0200, Thorsten Leemhuis wrote: > > Hi! James & Paulo: What's the current status of this? > > No, the only interaction has been the suggestion below for a revert, > which didn't fix the problem. > > > Was this issue discussed elsewhere or even fixed in between? Just > > asking, because this issue is on the list of regressions for 4.8. > > > I'm just about to try out -rc7, but it's not fixed so far. OK, with -rc7 and the i915 fixes, there seems to be a marked improvement. I can no longer crash the crtc by using lots of xrandr switches, which was the principal problem. I've so far only got one of these in the logs [14858.635035] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun And the only residual problem seems to be that the monitor goes blank periodically, but this can be fixed by switching resolution a couple of times. I haven't seen any of the link training errors so far and I've run through my usual battery of be nasty to the external monitor tests. James ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i915] monitor is not detected unless it was active during boot
Hi Maarten, Is this the Debug message when you are connected to the external DP Port or the HDMI port? I want to know if the problem is with the native DP connector or LSPCON? Also could you send the log that has the Video Bios Table information (VBT) information? Manasi From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Maarten Maathuis Sent: Monday, September 19, 2016 11:39 AM To: intel-gfxSubject: [Intel-gfx] [i915] monitor is not detected unless it was active during boot Hi, I have a monitor, that when connected a skylake system, doesn't ever come up when hotplugging or after resume. The "bios" seems to not have problems bringing it up, even at the native 3840x2160 resolution, and when it works, all modes are correctly read (checked via xrandr). I tried both the HMDI 1.4 port, as well as the DP 1.2 -> HDMI 2.0 built in conversion chip. This is the dmesg output I have when plugging in this monitor, the DP-2 connector is the one that should be detected. Any advice on how to proceed? Please be aware I am not subscribed to this mailing list, so please reply to me directly as well. Maarten. [ 1634.666165] [drm:intel_get_hpd_pins] hotplug event received, stat 0x0080, dig 0x10121010, pins 0x0080 [ 1634.666179] [drm:intel_hpd_irq_handler] digital hpd port D - long [ 1634.666183] [drm:intel_hpd_irq_storm_detect] Received HPD interrupt on PIN 7 - cnt: 0 [ 1634.666229] [drm:intel_dp_hpd_pulse] got hpd irq on port D - long [ 1634.666253] [drm:i915_hotplug_work_func] running encoder hotplug functions [ 1634.666258] [drm:i915_hotplug_work_func] Connector DP-2 (pin 7) received hotplug event. [ 1634.666261] [drm:intel_dp_detect] [CONNECTOR:48:DP-2] [ 1634.666273] [drm:i915_hotplug_work_func] Connector HDMI-A-3 (pin 7) received hotplug event. [ 1634.666284] [drm:intel_hdmi_detect] [CONNECTOR:52:HDMI-A-3] [ 1634.769941] [drm:intel_hdmi_detect] HDMI live status down [ 1640.748356] [drm:intel_get_hpd_pins] hotplug event received, stat 0x0080, dig 0x10121010, pins 0x0080 [ 1640.748369] [drm:intel_hpd_irq_handler] digital hpd port D - long [ 1640.748373] [drm:intel_hpd_irq_storm_detect] Received HPD interrupt on PIN 7 - cnt: 0 [ 1640.748416] [drm:intel_dp_hpd_pulse] got hpd irq on port D - long [ 1640.756938] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.765400] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.773936] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.782410] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.790910] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.799389] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.807907] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.816409] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.824895] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.833427] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.841915] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.850426] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.858919] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.867423] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.875924] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.884424] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.892899] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.901454] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.910008] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.918494] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.926994] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.935486] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.943982] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.952461] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.960971] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.969459] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.978003] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.986482] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.994973] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1641.003497] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1641.011986] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1641.020504] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1641.020506] [drm:drm_dp_dpcd_access] too many retries, giving up [ 1641.020528] [drm:i915_hotplug_work_func] running encoder hotplug functions [ 1641.020529] [drm:i915_hotplug_work_func] Connector DP-2 (pin 7) received hotplug event. [ 1641.020530] [drm:intel_dp_detect] [CONNECTOR:48:DP-2] [ 1641.029054] [drm:intel_dp_aux_ch]
Re: [Intel-gfx] [i915] monitor is not detected unless it was active during boot
And the normal output at bootup: [2.826131] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:48:DP-2] [2.826135] [drm:intel_dp_detect] [CONNECTOR:48:DP-2] [2.826645] [drm:intel_dp_get_dpcd] DPCD: 12 14 c4 01 01 15 00 01 00 00 04 00 0f 00 00 [2.827032] [drm:intel_dp_get_dpcd] Display Port TPS3 support: source yes, sink yes [2.827038] [drm:intel_dp_print_rates] source rates: 162000, 216000, 27, 324000, 432000, 54 [2.827043] [drm:intel_dp_print_rates] sink rates: 162000, 27, 54 [2.827047] [drm:intel_dp_print_rates] common rates: 162000, 27, 54 [2.827905] [drm:intel_dp_probe_mst] Sink is not MST capable [2.828350] [drm:drm_dp_i2c_do_msg] native defer [2.829760] [drm:drm_dp_i2c_do_msg] native defer [2.831102] [drm:drm_dp_i2c_do_msg] native defer [2.832462] [drm:drm_dp_i2c_do_msg] native defer [2.833887] [drm:drm_dp_i2c_do_msg] native defer [2.835215] [drm:drm_dp_i2c_do_msg] native defer [2.836834] [drm:drm_dp_i2c_do_msg] native defer [2.838207] [drm:drm_dp_i2c_do_msg] native defer [2.839592] [drm:drm_dp_i2c_do_msg] native defer [2.841003] [drm:drm_dp_i2c_do_msg] native defer [2.842434] [drm:drm_dp_i2c_do_msg] native defer [2.843871] [drm:drm_dp_i2c_do_msg] native defer [2.845284] [drm:drm_dp_i2c_do_msg] native defer [2.846771] [drm:drm_dp_i2c_do_msg] native defer [2.848228] [drm:drm_dp_i2c_do_msg] native defer [2.849683] [drm:drm_dp_i2c_do_msg] native defer [2.851073] [drm:drm_dp_i2c_do_msg] native defer [2.852430] [drm:drm_dp_i2c_do_msg] native defer [2.853824] [drm:drm_dp_i2c_do_msg] native defer [2.855163] [drm:drm_dp_i2c_do_msg] native defer [2.856661] [drm:drm_dp_i2c_do_msg] native defer [2.858053] [drm:drm_dp_i2c_do_msg] native defer [2.859543] [drm:drm_dp_i2c_do_msg] native defer [2.860923] [drm:drm_dp_i2c_do_msg] native defer [2.862372] [drm:drm_dp_i2c_do_msg] native defer [2.863839] [drm:drm_dp_i2c_do_msg] native defer [2.865228] [drm:drm_dp_i2c_do_msg] native defer [2.866830] [drm:drm_dp_i2c_do_msg] native defer [2.868279] [drm:drm_dp_i2c_do_msg] native defer [2.869180] [drm:drm_detect_monitor_audio] Monitor has basic audio support [2.869975] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:48:DP-2] status updated from unknown to connected [2.870173] [drm:drm_edid_to_eld] ELD monitor U24E850 [2.870180] [drm:parse_hdmi_vsdb] HDMI: DVI dual 0, max TMDS clock 300, latency present 0 0, video latency 16 1, audio latency 96 2 [2.870184] [drm:drm_edid_to_eld] ELD size 32, SAD count 1 [2.870273] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:48:DP-2] probed modes : [2.870279] [drm:drm_mode_debug_printmodeline] Modeline 74:"3840x2160" 60 594000 3840 4016 4104 4400 2160 2168 2178 2250 0x48 0x5 [2.870285] [drm:drm_mode_debug_printmodeline] Modeline 108:"3840x2160" 30 297000 3840 4016 4104 4400 2160 2168 2178 2250 0x40 0x5 [2.870290] [drm:drm_mode_debug_printmodeline] Modeline 119:"3840x2160" 30 296703 3840 4016 4104 4400 2160 2168 2178 2250 0x40 0x5 [2.870294] [drm:drm_mode_debug_printmodeline] Modeline 109:"3840x2160" 25 297000 3840 4896 4984 5280 2160 2168 2178 2250 0x40 0x5 [2.870299] [drm:drm_mode_debug_printmodeline] Modeline 110:"3840x2160" 24 297000 3840 5116 5204 5500 2160 2168 2178 2250 0x40 0x5 [2.870304] [drm:drm_mode_debug_printmodeline] Modeline 120:"3840x2160" 24 296703 3840 5116 5204 5500 2160 2168 2178 2250 0x40 0x5 [2.870309] [drm:drm_mode_debug_printmodeline] Modeline 78:"2560x1440" 60 241500 2560 2608 2640 2720 1440 1443 1448 1481 0x40 0x9 [2.870314] [drm:drm_mode_debug_printmodeline] Modeline 75:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5 [2.870318] [drm:drm_mode_debug_printmodeline] Modeline 111:"1920x1080" 60 148352 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5 [2.870323] [drm:drm_mode_debug_printmodeline] Modeline 76:"1920x1080" 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5 [2.870328] [drm:drm_mode_debug_printmodeline] Modeline 105:"1920x1080" 30 74250 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5 [2.870333] [drm:drm_mode_debug_printmodeline] Modeline 117:"1920x1080" 30 74176 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5 [2.870338] [drm:drm_mode_debug_printmodeline] Modeline 104:"1920x1080" 24 74250 1920 2558 2602 2750 1080 1084 1089 1125 0x40 0x5 [2.870343] [drm:drm_mode_debug_printmodeline] Modeline 116:"1920x1080" 24 74176 1920 2558 2602 2750 1080 1084 1089 1125 0x40 0x5 [2.870348] [drm:drm_mode_debug_printmodeline] Modeline 84:"1680x1050" 60 119000 1680 1728 1760 1840 1050 1053 1059 1080 0x40 0x9 [2.870356] [drm:drm_mode_debug_printmodeline] Modeline 83:"1600x900" 60 108000 1600 1624 1704 1800 900 901 904 1000 0x40 0x5 [2.870360] [drm:drm_mode_debug_printmodeline] Modeline 92:"1280x1024" 75 135000 1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5 [
[Intel-gfx] [i915] monitor is not detected unless it was active during boot
Hi, I have a monitor, that when connected a skylake system, doesn't ever come up when hotplugging or after resume. The "bios" seems to not have problems bringing it up, even at the native 3840x2160 resolution, and when it works, all modes are correctly read (checked via xrandr). I tried both the HMDI 1.4 port, as well as the DP 1.2 -> HDMI 2.0 built in conversion chip. This is the dmesg output I have when plugging in this monitor, the DP-2 connector is the one that should be detected. Any advice on how to proceed? Please be aware I am not subscribed to this mailing list, so please reply to me directly as well. Maarten. [ 1634.666165] [drm:intel_get_hpd_pins] hotplug event received, stat 0x0080, dig 0x10121010, pins 0x0080 [ 1634.666179] [drm:intel_hpd_irq_handler] digital hpd port D - long [ 1634.666183] [drm:intel_hpd_irq_storm_detect] Received HPD interrupt on PIN 7 - cnt: 0 [ 1634.666229] [drm:intel_dp_hpd_pulse] got hpd irq on port D - long [ 1634.666253] [drm:i915_hotplug_work_func] running encoder hotplug functions [ 1634.666258] [drm:i915_hotplug_work_func] Connector DP-2 (pin 7) received hotplug event. [ 1634.666261] [drm:intel_dp_detect] [CONNECTOR:48:DP-2] [ 1634.666273] [drm:i915_hotplug_work_func] Connector HDMI-A-3 (pin 7) received hotplug event. [ 1634.666284] [drm:intel_hdmi_detect] [CONNECTOR:52:HDMI-A-3] [ 1634.769941] [drm:intel_hdmi_detect] HDMI live status down [ 1640.748356] [drm:intel_get_hpd_pins] hotplug event received, stat 0x0080, dig 0x10121010, pins 0x0080 [ 1640.748369] [drm:intel_hpd_irq_handler] digital hpd port D - long [ 1640.748373] [drm:intel_hpd_irq_storm_detect] Received HPD interrupt on PIN 7 - cnt: 0 [ 1640.748416] [drm:intel_dp_hpd_pulse] got hpd irq on port D - long [ 1640.756938] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.765400] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.773936] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.782410] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.790910] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.799389] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.807907] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.816409] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.824895] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.833427] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.841915] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.850426] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.858919] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.867423] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.875924] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.884424] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.892899] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.901454] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.910008] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.918494] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.926994] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.935486] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.943982] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.952461] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.960971] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.969459] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.978003] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.986482] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1640.994973] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1641.003497] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1641.011986] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1641.020504] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1641.020506] [drm:drm_dp_dpcd_access] too many retries, giving up [ 1641.020528] [drm:i915_hotplug_work_func] running encoder hotplug functions [ 1641.020529] [drm:i915_hotplug_work_func] Connector DP-2 (pin 7) received hotplug event. [ 1641.020530] [drm:intel_dp_detect] [CONNECTOR:48:DP-2] [ 1641.029054] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1641.037563] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1641.046092] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1641.054583] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1641.063076] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1641.071567] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1641.080094] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1641.088568] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f [ 1641.097054]
Re: [Intel-gfx] [PATCH v3 2/9] drm/i915/skl+: use linetime latency instead of ddb size
Em Seg, 2016-09-19 às 15:19 -0300, Paulo Zanoni escreveu: > Em Sex, 2016-09-09 às 13:30 +0530, Kumar, Mahesh escreveu: > > > > From: Mahesh Kumar> > > > This patch make changes to use linetime latency instead of > > allocated > > DDB size during plane watermark calculation in switch case, This is > > required to implement new DDB allocation algorithm. > > > > In New Algorithm DDB is allocated based on WM values, because of > > which > > number of DDB blocks will not be available during WM calculation, > > So this "linetime latency" is suggested by SV/HW team to use during > > switch-case for WM blocks selection. > > Why is this not part of BSpec? If there's some problem with the > current > algorithm and we need a new one, why is it not part of our spec? > > > > > > > Changes since v1: > > - Rebase on top of Paulo's patch series > > > > Signed-off-by: Mahesh Kumar > > --- > > drivers/gpu/drm/i915/intel_pm.c | 7 ++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > > b/drivers/gpu/drm/i915/intel_pm.c > > index 3fdec4d..cfd9b7d1 100644 > > --- a/drivers/gpu/drm/i915/intel_pm.c > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > @@ -3622,10 +3622,15 @@ static int skl_compute_plane_wm(const > > struct > > drm_i915_private *dev_priv, > > fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) { > > selected_result = max(method2, y_tile_minimum); > > } else { > > + uint32_t linetime_us = 0; > > + > > + linetime_us = DIV_ROUND_UP(width * 1000, > > + skl_pipe_pixel_rate(cstate)); Also, shouldn't this be width * 8 * 1000? > > + > > if ((cpp * cstate->base.adjusted_mode.crtc_htotal > > / > > 512 < 1) && > > (plane_bytes_per_line / 512 < 1)) > > selected_result = method2; > > - else if ((ddb_allocation / plane_blocks_per_line) > > >= > > 1) > > + if (latency >= linetime_us) > > selected_result = min(method1, method2); > > else > > selected_result = method1; > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/9] drm/i915/skl+: use linetime latency instead of ddb size
Em Sex, 2016-09-09 às 13:30 +0530, Kumar, Mahesh escreveu: > From: Mahesh Kumar> > This patch make changes to use linetime latency instead of allocated > DDB size during plane watermark calculation in switch case, This is > required to implement new DDB allocation algorithm. > > In New Algorithm DDB is allocated based on WM values, because of > which > number of DDB blocks will not be available during WM calculation, > So this "linetime latency" is suggested by SV/HW team to use during > switch-case for WM blocks selection. Why is this not part of BSpec? If there's some problem with the current algorithm and we need a new one, why is it not part of our spec? > > Changes since v1: > - Rebase on top of Paulo's patch series > > Signed-off-by: Mahesh Kumar > --- > drivers/gpu/drm/i915/intel_pm.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > b/drivers/gpu/drm/i915/intel_pm.c > index 3fdec4d..cfd9b7d1 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -3622,10 +3622,15 @@ static int skl_compute_plane_wm(const struct > drm_i915_private *dev_priv, > fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) { > selected_result = max(method2, y_tile_minimum); > } else { > + uint32_t linetime_us = 0; > + > + linetime_us = DIV_ROUND_UP(width * 1000, > + skl_pipe_pixel_rate(cstate)); > + > if ((cpp * cstate->base.adjusted_mode.crtc_htotal / > 512 < 1) && > (plane_bytes_per_line / 512 < 1)) > selected_result = method2; > - else if ((ddb_allocation / plane_blocks_per_line) >= > 1) > + if (latency >= linetime_us) > selected_result = min(method1, method2); > else > selected_result = method1; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/bxt: Broxton decoupled MMIO (rev2)
== Series Details == Series: drm/i915/bxt: Broxton decoupled MMIO (rev2) URL : https://patchwork.freedesktop.org/series/12028/ State : warning == Summary == Series 12028v2 drm/i915/bxt: Broxton decoupled MMIO https://patchwork.freedesktop.org/api/1.0/series/12028/revisions/2/mbox/ Test kms_cursor_legacy: Subgroup basic-flip-after-cursor-varying-size: skip -> PASS (fi-hsw-4770r) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-b-frame-sequence: pass -> SKIP (fi-hsw-4770r) Subgroup read-crc-pipe-c-frame-sequence: skip -> PASS (fi-hsw-4770r) Subgroup suspend-read-crc-pipe-a: dmesg-warn -> PASS (fi-skl-6700k) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:202 dwarn:0 dfail:0 fail:0 skip:42 fi-hsw-4770k total:244 pass:226 dwarn:0 dfail:0 fail:0 skip:18 fi-hsw-4770r total:244 pass:221 dwarn:0 dfail:0 fail:0 skip:23 fi-ilk-650 total:244 pass:183 dwarn:0 dfail:0 fail:1 skip:60 fi-ivb-3520m total:244 pass:219 dwarn:0 dfail:0 fail:0 skip:25 fi-ivb-3770 total:244 pass:207 dwarn:0 dfail:0 fail:0 skip:37 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:221 dwarn:0 dfail:0 fail:1 skip:22 fi-skl-6700k total:244 pass:219 dwarn:1 dfail:0 fail:0 skip:24 fi-skl-6770hqtotal:244 pass:228 dwarn:1 dfail:0 fail:1 skip:14 fi-snb-2520m total:244 pass:208 dwarn:0 dfail:0 fail:0 skip:36 fi-snb-2600 total:244 pass:207 dwarn:0 dfail:0 fail:0 skip:37 Results at /archive/results/CI_IGT_test/Patchwork_2556/ 0e34cb5b35f0f837219495c402073141481b1b90 drm-intel-nightly: 2016y-09m-19d-15h-38m-53s UTC integration manifest 7261225 drm/i915/bxt: Broxton decoupled MMIO ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/dp/mst: Add support for upfront link training for DP MST
On Mon, Sep 19, 2016 at 10:03:29AM -0700, Jim Bride wrote: > On Thu, Sep 15, 2016 at 12:25:51PM -0700, Manasi Navare wrote: > > On Thu, Sep 15, 2016 at 10:48:17AM -0700, Pandiyan, Dhinakaran wrote: > > > On Tue, 2016-09-13 at 18:08 -0700, Manasi Navare wrote: > > > > From: Jim Bride> > > > > > > > Add upfront link training to intel_dp_mst_mode_valid() so that we know > > > > topology constraints before we validate the legality of modes to be > > > > checked. > > > > > > > > > > The patch seems to do a lot more things than just what is described > > > here. I guess, it would be better to split this into multiple patches or > > > at least provide adequate description here. > > > > > > > I think the only other thing its doing is making some functions > > non static so they can be used for MST upfront enabling. > > But I think that can be in the same patch since it is done in order > > to enable upfront for MST. > > Jim, any thoughts? > > This is exactly the case. > > Jim I have already resubmitted a newer version of the patch with the description more coherent to what the patch is doing. Manasi > > > > > > > v3: > > > > * Reset the upfront values but dont unset the EDID for MST. (Manasi) > > > > v2: > > > > * Rebased on new revision of link training patch. (Manasi) > > > > > > > > Signed-off-by: Manasi Navare > > > > Signed-off-by: Jim Bride > > > > --- > > > > drivers/gpu/drm/i915/intel_dp.c | 15 > > > > drivers/gpu/drm/i915/intel_dp_mst.c | 74 > > > > +++-- > > > > drivers/gpu/drm/i915/intel_drv.h| 3 ++ > > > > 3 files changed, 64 insertions(+), 28 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > > > b/drivers/gpu/drm/i915/intel_dp.c > > > > index 9042d28..635830e 100644 > > > > --- a/drivers/gpu/drm/i915/intel_dp.c > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > > > @@ -131,7 +131,7 @@ static void vlv_steal_power_sequencer(struct > > > > drm_device *dev, > > > > enum pipe pipe); > > > > static void intel_dp_unset_edid(struct intel_dp *intel_dp); > > > > > > > > -static int > > > > +int > > > > intel_dp_max_link_bw(struct intel_dp *intel_dp) > > > > { > > > > int max_link_bw = intel_dp->dpcd[DP_MAX_LINK_RATE]; > > > > @@ -150,7 +150,7 @@ intel_dp_max_link_bw(struct intel_dp *intel_dp) > > > > return max_link_bw; > > > > } > > > > > > > > -static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp) > > > > +u8 intel_dp_max_lane_count(struct intel_dp *intel_dp) > > > > { > > > > struct intel_digital_port *intel_dig_port = > > > > dp_to_dig_port(intel_dp); > > > > u8 temp, source_max, sink_max; > > > > @@ -296,8 +296,7 @@ static int intersect_rates(const int *source_rates, > > > > int source_len, > > > > return k; > > > > } > > > > > > > > -static int intel_dp_common_rates(struct intel_dp *intel_dp, > > > > -int *common_rates) > > > > +int intel_dp_common_rates(struct intel_dp *intel_dp, int *common_rates) > > > > { > > > > const int *source_rates, *sink_rates; > > > > int source_len, sink_len; > > > > @@ -321,7 +320,7 @@ static int intel_dp_common_rates(struct intel_dp > > > > *intel_dp, > > > >common_rates); > > > > } > > > > > > > > -static bool intel_dp_upfront_link_train(struct intel_dp *intel_dp) > > > > +bool intel_dp_upfront_link_train(struct intel_dp *intel_dp) > > > > { > > > > struct intel_digital_port *intel_dig_port = > > > > dp_to_dig_port(intel_dp); > > > > struct intel_encoder *intel_encoder = _dig_port->base; > > > > @@ -4545,12 +4544,12 @@ intel_dp_long_pulse(struct intel_connector > > > > *intel_connector) > > > > } > > > > > > > > out: > > > > - if ((status != connector_status_connected) && > > > > - (intel_dp->is_mst == false)) { > > > > - intel_dp_unset_edid(intel_dp); > > > > + if (status != connector_status_connected) { > > > > intel_dp->upfront_done = false; > > > > intel_dp->max_lanes_upfront = 0; > > > > intel_dp->max_link_rate_upfront = 0; > > > > + if (intel_dp->is_mst == false) > > > > + intel_dp_unset_edid(intel_dp); > > > > } > > > > > > > > intel_display_power_put(to_i915(dev), power_domain); > > > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c > > > > b/drivers/gpu/drm/i915/intel_dp_mst.c > > > > index 54a9d76..98d45a4 100644 > > > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c > > > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c > > > > @@ -41,21 +41,30 @@ static bool intel_dp_mst_compute_config(struct > > > > intel_encoder *encoder, > > > > int bpp; > > > > int lane_count, slots; > > > > const struct drm_display_mode
[Intel-gfx] [PATCH v2] drm/i915/bxt: Broxton decoupled MMIO
Decoupled MMIO is an alternative way to access forcewake domain registers, which requires less cycles and avoids frequent software forcewake. v2: - Moved platform check out of the function and got rid of duplicate functions to find out decoupled power domain. - Added a check for forcewake already held and skipped decoupled access - Skipped writing 64 bit register through decoupled MMIO Signed-off-by: Zhe WangSigned-off-by: Damien Lespiau Signed-off-by: Ankitprasad Sharma Signed-off-by: Praveen Paneri --- drivers/gpu/drm/i915/i915_drv.h | 11 drivers/gpu/drm/i915/i915_reg.h | 7 +++ drivers/gpu/drm/i915/intel_uncore.c | 118 +++- 3 files changed, 134 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 4dd307e..065247b 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -558,6 +558,16 @@ enum forcewake_domains { #define FW_REG_READ (1) #define FW_REG_WRITE (2) +enum power_domains { + GEN9_DECOUPLED_PD_BLITTER = 0, + GEN9_DECOUPLED_PD_RENDER, + GEN9_DECOUPLED_PD_MEDIA, + GEN9_DECOUPLED_PD_ALL +}; + +#define GEN9_DECOUPLED_OP_WRITE (0) +#define GEN9_DECOUPLED_OP_READ (1) + enum forcewake_domains intel_uncore_forcewake_for_reg(struct drm_i915_private *dev_priv, i915_reg_t reg, unsigned int op); @@ -2854,6 +2864,7 @@ struct drm_i915_cmd_table { #define GT_FREQUENCY_MULTIPLIER 50 #define GEN9_FREQ_SCALER 3 +#define HAS_DECOUPLED_MMIO(dev_priv) (IS_BROXTON(dev_priv) && IS_BXT_REVID(dev_priv, BXT_REVID_C0, REVID_FOREVER)) #include "i915_trace.h" static inline bool intel_scanout_needs_vtd_wa(struct drm_i915_private *dev_priv) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 70d9616..be59803 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -7394,6 +7394,13 @@ enum { #define SKL_FUSE_PG1_DIST_STATUS (1<<26) #define SKL_FUSE_PG2_DIST_STATUS (1<<25) +/* Decoupled MMIO register pair for kernel driver */ +#define GEN9_DECOUPLED_REG0_DW0_MMIO(0xF00) +#define GEN9_DECOUPLED_REG0_DW1_MMIO(0xF04) +#define GEN9_DECOUPLED_DW1_GO (1<<31) +#define GEN9_DECOUPLED_PD_SHIFT28 +#define GEN9_DECOUPLED_OP_SHIFT24 + /* Per-pipe DDI Function Control */ #define _TRANS_DDI_FUNC_CTL_A 0x60400 #define _TRANS_DDI_FUNC_CTL_B 0x61400 diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index a9b6c93..06fffba 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -816,6 +816,42 @@ unclaimed_reg_debug(struct drm_i915_private *dev_priv, __unclaimed_reg_debug(dev_priv, reg, read, before); } +/* + * Decoupled MMIO access for only 1 DWORD + */ +static void __gen9_decoupled_mmio_access(struct drm_i915_private *dev_priv, +uint32_t reg, u32 *ptr_data, +enum forcewake_domains fw_engine, int operation) +{ + enum power_domains pd_engine; + u32 ctrl_reg_data = 0; + + if (operation == GEN9_DECOUPLED_OP_WRITE) + __raw_i915_write32(dev_priv, + GEN9_DECOUPLED_REG0_DW0, + *ptr_data); + + pd_engine = (fw_engine == (FORCEWAKE_RENDER || FORCEWAKE_BLITTER)) ? \ +!(fw_engine >> 1) : (fw_engine >> 1); \ + + ctrl_reg_data |= reg; + ctrl_reg_data |= (operation << GEN9_DECOUPLED_OP_SHIFT); + ctrl_reg_data |= (pd_engine << GEN9_DECOUPLED_PD_SHIFT); + __raw_i915_write32(dev_priv, GEN9_DECOUPLED_REG0_DW1, ctrl_reg_data); + + ctrl_reg_data |= GEN9_DECOUPLED_DW1_GO; + __raw_i915_write32(dev_priv, GEN9_DECOUPLED_REG0_DW1, ctrl_reg_data); + + if (wait_for_atomic((__raw_i915_read32(dev_priv, + GEN9_DECOUPLED_REG0_DW1) & GEN9_DECOUPLED_DW1_GO) == 0, + FORCEWAKE_ACK_TIMEOUT_MS)) + DRM_ERROR("Decoupled MMIO wait timed out\n"); + + if (operation == GEN9_DECOUPLED_OP_READ) + *ptr_data = __raw_i915_read32(dev_priv, + GEN9_DECOUPLED_REG0_DW0); +} + #define GEN2_READ_HEADER(x) \ u##x val = 0; \ assert_rpm_wakelock_held(dev_priv); @@ -892,6 +928,20 @@ static inline void __force_wake_auto(struct drm_i915_private *dev_priv, dev_priv->uncore.funcs.force_wake_get(dev_priv, fw_domains); } +static inline bool __is_forcewake_active(struct drm_i915_private *dev_priv, +enum forcewake_domains fw_domains) +{ + struct
Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/dp/mst: Add support for upfront link training for DP MST
On Thu, Sep 15, 2016 at 12:25:51PM -0700, Manasi Navare wrote: > On Thu, Sep 15, 2016 at 10:48:17AM -0700, Pandiyan, Dhinakaran wrote: > > On Tue, 2016-09-13 at 18:08 -0700, Manasi Navare wrote: > > > From: Jim Bride> > > > > > Add upfront link training to intel_dp_mst_mode_valid() so that we know > > > topology constraints before we validate the legality of modes to be > > > checked. > > > > > > > The patch seems to do a lot more things than just what is described > > here. I guess, it would be better to split this into multiple patches or > > at least provide adequate description here. > > > > I think the only other thing its doing is making some functions > non static so they can be used for MST upfront enabling. > But I think that can be in the same patch since it is done in order > to enable upfront for MST. > Jim, any thoughts? This is exactly the case. Jim > > > > v3: > > > * Reset the upfront values but dont unset the EDID for MST. (Manasi) > > > v2: > > > * Rebased on new revision of link training patch. (Manasi) > > > > > > Signed-off-by: Manasi Navare > > > Signed-off-by: Jim Bride > > > --- > > > drivers/gpu/drm/i915/intel_dp.c | 15 > > > drivers/gpu/drm/i915/intel_dp_mst.c | 74 > > > +++-- > > > drivers/gpu/drm/i915/intel_drv.h| 3 ++ > > > 3 files changed, 64 insertions(+), 28 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > > b/drivers/gpu/drm/i915/intel_dp.c > > > index 9042d28..635830e 100644 > > > --- a/drivers/gpu/drm/i915/intel_dp.c > > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > > @@ -131,7 +131,7 @@ static void vlv_steal_power_sequencer(struct > > > drm_device *dev, > > > enum pipe pipe); > > > static void intel_dp_unset_edid(struct intel_dp *intel_dp); > > > > > > -static int > > > +int > > > intel_dp_max_link_bw(struct intel_dp *intel_dp) > > > { > > > int max_link_bw = intel_dp->dpcd[DP_MAX_LINK_RATE]; > > > @@ -150,7 +150,7 @@ intel_dp_max_link_bw(struct intel_dp *intel_dp) > > > return max_link_bw; > > > } > > > > > > -static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp) > > > +u8 intel_dp_max_lane_count(struct intel_dp *intel_dp) > > > { > > > struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); > > > u8 temp, source_max, sink_max; > > > @@ -296,8 +296,7 @@ static int intersect_rates(const int *source_rates, > > > int source_len, > > > return k; > > > } > > > > > > -static int intel_dp_common_rates(struct intel_dp *intel_dp, > > > - int *common_rates) > > > +int intel_dp_common_rates(struct intel_dp *intel_dp, int *common_rates) > > > { > > > const int *source_rates, *sink_rates; > > > int source_len, sink_len; > > > @@ -321,7 +320,7 @@ static int intel_dp_common_rates(struct intel_dp > > > *intel_dp, > > > common_rates); > > > } > > > > > > -static bool intel_dp_upfront_link_train(struct intel_dp *intel_dp) > > > +bool intel_dp_upfront_link_train(struct intel_dp *intel_dp) > > > { > > > struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); > > > struct intel_encoder *intel_encoder = _dig_port->base; > > > @@ -4545,12 +4544,12 @@ intel_dp_long_pulse(struct intel_connector > > > *intel_connector) > > > } > > > > > > out: > > > - if ((status != connector_status_connected) && > > > - (intel_dp->is_mst == false)) { > > > - intel_dp_unset_edid(intel_dp); > > > + if (status != connector_status_connected) { > > > intel_dp->upfront_done = false; > > > intel_dp->max_lanes_upfront = 0; > > > intel_dp->max_link_rate_upfront = 0; > > > + if (intel_dp->is_mst == false) > > > + intel_dp_unset_edid(intel_dp); > > > } > > > > > > intel_display_power_put(to_i915(dev), power_domain); > > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c > > > b/drivers/gpu/drm/i915/intel_dp_mst.c > > > index 54a9d76..98d45a4 100644 > > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c > > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c > > > @@ -41,21 +41,30 @@ static bool intel_dp_mst_compute_config(struct > > > intel_encoder *encoder, > > > int bpp; > > > int lane_count, slots; > > > const struct drm_display_mode *adjusted_mode = > > > _config->base.adjusted_mode; > > > - int mst_pbn; > > > + int mst_pbn, common_len; > > > + int common_rates[DP_MAX_SUPPORTED_RATES] = {}; > > > > > > pipe_config->dp_encoder_is_mst = true; > > > pipe_config->has_pch_encoder = false; > > > - bpp = 24; > > > + > > > /* > > > - * for MST we always configure max link bw - the spec doesn't > > > - * seem to suggest we should do otherwise. > > > + * For MST we always configure for the maximum trainable link bw - > > > + * the spec doesn't seem to suggest we should do otherwise. The > > > + * calls to
Re: [Intel-gfx] [PATCH] drm/i915/bxt: Broxton decoupled MMIO
On Tuesday 06 September 2016 12:06 PM, Chris Wilson wrote: On Tue, Sep 06, 2016 at 10:54:14AM +0530, Praveen Paneri wrote: Decoupled MMIO is an alternative way to access forcewake domain registers, which requires less cycles and avoids frequent software forcewake. How about when forcewake is already held? You'll note that we still Will try to add the same check (for domain->wake_count) in decoupled MMIO path as well and do a direct register access if forcewake is already held. require irq-spinlocks so the mmio access is still not great. And we still will have to frequently take forcewake manually, apparently. Do you have any statistics to say that we do reduce grabing the fw wakelock and that the busywait you add instead is negligible. You are still using a 50ms timeout, so there is some doubt about "less cycles". Sorry didn't find any such statistics with Windows folks. But can do an exercise myself to measure the actual benefit of Decoupled MMIO. Please can you suggest some method to do that. The feature definitely helps HW for synchronization as the cycles are internally serialized in GT and eliminates the risk of hitting certain hangs which exist in theory. +/* + * Decoupled MMIO access for only 1 DWORD + */ +static void __gen9_decoupled_mmio_access(struct drm_i915_private *dev_priv, +uint32_t reg, u32 *ptr_data, +enum power_domains pd, int operation) +{ + u32 ctrl_reg_data = 0; + + if (operation == GEN9_DECOUPLED_OP_WRITE) + __raw_i915_write32(dev_priv, + GEN9_DECOUPLED_REG0_DW0, + *ptr_data); + + ctrl_reg_data |= reg; + ctrl_reg_data |= (operation << GEN9_DECOUPLED_OP_SHIFT); + ctrl_reg_data |= (pd << GEN9_DECOUPLED_PD_SHIFT); + __raw_i915_write32(dev_priv, GEN9_DECOUPLED_REG0_DW1, ctrl_reg_data); + + ctrl_reg_data |= GEN9_DECOUPLED_DW1_GO; + __raw_i915_write32(dev_priv, GEN9_DECOUPLED_REG0_DW1, ctrl_reg_data); + + if (wait_for_atomic((__raw_i915_read32(dev_priv, + GEN9_DECOUPLED_REG0_DW1) & GEN9_DECOUPLED_DW1_GO) == 0, + FORCEWAKE_ACK_TIMEOUT_MS)) + DRM_ERROR("Decoupled MMIO wait timed out\n"); + + if (operation == GEN9_DECOUPLED_OP_READ) + *ptr_data = __raw_i915_read32(dev_priv, + GEN9_DECOUPLED_REG0_DW0); +} + #define GEN2_READ_HEADER(x) \ u##x val = 0; \ assert_rpm_wakelock_held(dev_priv); @@ -932,12 +997,27 @@ chv_read##x(struct drm_i915_private *dev_priv, i915_reg_t reg, bool trace) { \ static u##x \ gen9_read##x(struct drm_i915_private *dev_priv, i915_reg_t reg, bool trace) { \ enum forcewake_domains fw_engine; \ + enum power_domains pd_engine; \ GEN6_READ_HEADER(x); \ - fw_engine = __gen9_reg_read_fw_domains(offset); \ - if (fw_engine) \ - __force_wake_auto(dev_priv, fw_engine); \ - val = __raw_i915_read##x(dev_priv, reg); \ - GEN6_READ_FOOTER; \ + pd_engine = __gen9_reg_read_power_domains(offset); \ + if (HAS_DECOUPLED_MMIO(dev_priv) && pd_engine && x%32 == 0) { \ Move the platform test out of here (since it is already a per-platform vfunc) and then skip the duplicated gen9 functions. + u32 *ptr_data = (u32 *) \ + unsigned i = 0; \ + for (i = 0; i < x/32; i++) { \ And tidy up the reassignments. + __gen9_decoupled_mmio_access(dev_priv, \ + (offset + i*4), \ + ptr_data + i, \ + pd_engine, \ + GEN9_DECOUPLED_OP_READ); \ + ptr_data++; \ + } \ + } else { \ + fw_engine = __gen9_reg_read_fw_domains(offset); \ + if (fw_engine) \ + __force_wake_auto(dev_priv, fw_engine); \ + val = __raw_i915_read##x(dev_priv, reg); \ + } \ + GEN6_READ_FOOTER; \ Misleading indentation. } __gen9_read(8) @@ -1101,11 +1181,26 @@ static void \ gen9_write##x(struct drm_i915_private *dev_priv, i915_reg_t reg, u##x val, \ bool trace) { \ enum forcewake_domains fw_engine; \ + enum power_domains pd_engine; \ GEN6_WRITE_HEADER; \ - fw_engine = __gen9_reg_write_fw_domains(offset); \ - if (fw_engine) \ - __force_wake_auto(dev_priv, fw_engine); \ - __raw_i915_write##x(dev_priv, reg, val); \ + pd_engine = __gen9_reg_write_power_domains(offset); \ + if (HAS_DECOUPLED_MMIO(dev_priv) && pd_engine && x%32 == 0) { \ + u32 *ptr_data = (u32 *) \ + unsigned i = 0; \ + for (i = 0; i < x/32; i++) { \ +
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/7] drm/i915: Update i915.reset to handle engine resets
== Series Details == Series: series starting with [1/7] drm/i915: Update i915.reset to handle engine resets URL : https://patchwork.freedesktop.org/series/12651/ State : failure == Summary == Series 12651v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/12651/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-flip-after-cursor-varying-size: skip -> PASS (fi-hsw-4770r) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-c-frame-sequence: skip -> PASS (fi-hsw-4770r) Subgroup suspend-read-crc-pipe-a: dmesg-warn -> PASS (fi-skl-6700k) Subgroup suspend-read-crc-pipe-c: pass -> INCOMPLETE (fi-hsw-4770k) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:202 dwarn:0 dfail:0 fail:0 skip:42 fi-byt-n2820 total:244 pass:208 dwarn:0 dfail:0 fail:1 skip:35 fi-hsw-4770k total:208 pass:191 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ilk-650 total:244 pass:183 dwarn:0 dfail:0 fail:1 skip:60 fi-ivb-3520m total:244 pass:219 dwarn:0 dfail:0 fail:0 skip:25 fi-ivb-3770 total:244 pass:207 dwarn:0 dfail:0 fail:0 skip:37 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:221 dwarn:0 dfail:0 fail:1 skip:22 fi-skl-6700k total:244 pass:219 dwarn:1 dfail:0 fail:0 skip:24 fi-skl-6770hqtotal:244 pass:228 dwarn:1 dfail:0 fail:1 skip:14 fi-snb-2520m total:244 pass:208 dwarn:0 dfail:0 fail:0 skip:36 fi-snb-2600 total:244 pass:207 dwarn:0 dfail:0 fail:0 skip:37 Results at /archive/results/CI_IGT_test/Patchwork_2555/ 0e34cb5b35f0f837219495c402073141481b1b90 drm-intel-nightly: 2016y-09m-19d-15h-38m-53s UTC integration manifest 63084e5 drm/i915/tdr: Enable Engine reset and recovery support 803d39e drm/i915/tdr: Export reset count info to debugfs c13c4dc drm/i915/tdr: Add engine reset count to error state 1f33769 drm/i915: Skip reset request if there is one already 412f59f drm/i915/tdr: Add support for per engine reset recovery d95b6e3 drm/i915/tdr: Modify error handler for per engine hang recovery 5768c16 drm/i915: Update i915.reset to handle engine resets ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests: kms_pipe_color: fix ctm tests
On Mon, 19 Sep 2016, Lionel Landwerlinwrote: > Some of the Intel platforms have odd numbers of LUT entries and we > need to tests a couple of values around the expected result. Bring > back the CRC equal function we need that doesn't trigger an assert > right away, while we still assert if we can't find a correct result in > the outter loop. > > bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97691 > Fixes: 582ce4cd19c627606047b1a8fdd987c4dc07353c We might as well stick to kernel style for Fixes: tags: Fixes: 582ce4cd19c6 ("lib/debugs: nuke igt_crc_equal again") You can get that with: $ git log -1 582ce4cd19c627606047b1a8fdd987c4dc07353c --pretty="format:Fixes: %h (\"%s\")" 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
[Intel-gfx] [PATCH i-g-t] tests: kms_pipe_color: fix ctm tests
Some of the Intel platforms have odd numbers of LUT entries and we need to tests a couple of values around the expected result. Bring back the CRC equal function we need that doesn't trigger an assert right away, while we still assert if we can't find a correct result in the outter loop. bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97691 Fixes: 582ce4cd19c627606047b1a8fdd987c4dc07353c Cc: Daniel VetterCc: Christophe Prigent --- tests/kms_pipe_color.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/tests/kms_pipe_color.c b/tests/kms_pipe_color.c index b0a2f07..ebfceab 100644 --- a/tests/kms_pipe_color.c +++ b/tests/kms_pipe_color.c @@ -652,6 +652,16 @@ static void test_pipe_legacy_gamma_reset(data_t *data, free(gamma_zero); } +static bool crc_equal(igt_crc_t *a, igt_crc_t *b) +{ + int i; + + for (i = 0; i < a->n_words; i++) +if (a->crc[i] != b->crc[i]) + return false; + return true; +} + /* * Draw 3 rectangles using before colors with the ctm matrix apply and verify * the CRC is equal to using after colors with an identify ctm matrix. @@ -724,7 +734,7 @@ static bool test_pipe_ctm(data_t *data, /* Verify that the CRC of the software computed output is * equal to the CRC of the CTM matrix transformation output. */ - igt_assert_crc_equal(_software, _hardware); + ret &= crc_equal(_software, _hardware); igt_output_set_pipe(output, PIPE_ANY); } -- 2.8.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: keep declarations in i915_drv.h
On to, 2016-09-15 at 16:28 +0300, Jani Nikula wrote: > Fix sparse warnings: > > drivers/gpu/drm/i915/i915_drv.c:1179:5: warning: symbol > 'i915_driver_load' was not declared. Should it be static? > > drivers/gpu/drm/i915/i915_drv.c:1267:6: warning: symbol > 'i915_driver_unload' was not declared. Should it be static? > > drivers/gpu/drm/i915/i915_drv.c:2444:25: warning: symbol 'i915_pm_ops' > was not declared. Should it be static? > Hmm, Chris, were not these change in the middle of a series, did the cleanup patches just fall off? Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/18] drm/i915: Record space required for request emission
On ma, 2016-09-19 at 12:32 +0100, Chris Wilson wrote: > On Mon, Sep 19, 2016 at 01:47:30PM +0300, Joonas Lahtinen wrote: > > On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > > > @@ -2677,8 +2681,21 @@ static void intel_ring_default_vfuncs(struct > > > drm_i915_private *dev_priv, > > > engine->reset_hw = reset_ring_common; > > > > > > engine->emit_request = i9xx_emit_request; > > > - if (i915.semaphores) > > > + engine->emit_request_sz = i9xx_emit_request_sz; > > > + if (i915.semaphores) { > > > + int num_rings; > > > > 'initialized_rings' to differentiate as suggested by Tvrtko too. > > Tvrtko wasn't referring to this. The point is that we don't know > initialized_rings here, just the declared set of rings we think > the hardware is supposed to have. Can't we afford to calculate this to the info struct anyway? Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/18] drm/i915: Reserve space in the global seqno during request allocation
On ma, 2016-09-19 at 18:35 +0300, Jani Nikula wrote: > > On Mon, 19 Sep 2016, Joonas Lahtinen> > wrote: > > > > On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > > > > > > +static int reserve_global_seqno(struct drm_i915_private *i915) > > > { > > > - struct i915_gem_timeline *tl = _priv->gt.global_timeline; > > > + struct i915_gem_timeline *tl = >gt.global_timeline; > > > + u32 next_seqno = atomic_read(>next_seqno); > > > > > > - /* reserve 0 for non-seqno */ > > > - if (unlikely(tl->next_seqno == 0)) { > > > > Meh, do not hide the ++i915->gt.active_requests in if (unlikely(...)). > > *shudder* it doesn't get any better by removing unlikely! > Well, it gets twice as bad by adding it, though :P My below recommendation would be preferred by lifting the increment before the if (). > > > > > > + if (unlikely(next_seqno + ++i915->gt.active_requests <= next_seqno)) { > > > int ret; > > > > > > > Why not if (likely(next_seqno + active_requests > next_seqno)) > > > > return 0; Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/18] drm/i915: Restore nonblocking awaits for modesetting
Maarten, could you give this a look? On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > After combining the dma-buf reservation object and the GEM reservation > object, we lost the ability to do a nonblocking wait on the i915 request > (as we blocked upon the reservation object during prepare_fb). We can > instead convert the reservation object into a fence upon which we can > asynchronously wait (including a forced timeout in case the DMA fence is > never signaled). > > > Signed-off-by: Chris Wilson> --- > drivers/gpu/drm/i915/intel_display.c | 78 > ++-- > drivers/gpu/drm/i915/intel_drv.h | 2 + > 2 files changed, 51 insertions(+), 29 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 5c0ea08dddb3..294df122f7c6 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -14383,12 +14383,33 @@ static void intel_atomic_commit_tail(struct > drm_atomic_state *state) > > static void intel_atomic_commit_work(struct work_struct *work) > { > > - struct drm_atomic_state *state = container_of(work, > > - struct drm_atomic_state, > > - commit_work); > > + struct drm_atomic_state *state = > > + container_of(work, struct drm_atomic_state, commit_work); > + > > intel_atomic_commit_tail(state); > } > > +static int __i915_sw_fence_call > +intel_atomic_commit_ready(struct i915_sw_fence *fence, > > + enum i915_sw_fence_notify notify) > +{ > > + struct intel_atomic_state *state = > > + container_of(fence, struct intel_atomic_state, commit_ready); > + > > + switch (notify) { > > + case FENCE_COMPLETE: > > + if (state->base.commit_work.func) > > + queue_work(system_unbound_wq, >base.commit_work); > > + break; > + > > + case FENCE_FREE: > > + drm_atomic_state_put(>base); > > + break; > > + } > + > > + return NOTIFY_DONE; > +} > + > static void intel_atomic_track_fbs(struct drm_atomic_state *state) > { > > struct drm_plane_state *old_plane_state; > @@ -14434,11 +14455,14 @@ static int intel_atomic_commit(struct drm_device > *dev, > > if (ret) > > return ret; > > > - INIT_WORK(>commit_work, intel_atomic_commit_work); > > + drm_atomic_state_get(state); > > + i915_sw_fence_init(_state->commit_ready, > > + intel_atomic_commit_ready); > > > ret = intel_atomic_prepare_commit(dev, state); > > if (ret) { > > DRM_DEBUG_ATOMIC("Preparing state failed with %i\n", ret); > > + i915_sw_fence_commit(_state->commit_ready); > > return ret; > > } > > @@ -14449,10 +14473,14 @@ static int intel_atomic_commit(struct drm_device > *dev, > > intel_atomic_track_fbs(state); > > > drm_atomic_state_get(state); > > - if (nonblock) > > - queue_work(system_unbound_wq, >commit_work); > > - else > > + INIT_WORK(>commit_work, > > + nonblock ? intel_atomic_commit_work : NULL); > + > > + i915_sw_fence_commit(_state->commit_ready); > > + if (!nonblock) { > > + i915_sw_fence_wait(_state->commit_ready); > > intel_atomic_commit_tail(state); > > + } > > > return 0; > } > @@ -14568,8 +14596,7 @@ intel_prepare_plane_fb(struct drm_plane *plane, > > struct drm_framebuffer *fb = new_state->fb; > > struct drm_i915_gem_object *obj = intel_fb_obj(fb); > > struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->state->fb); > > - long lret; > > - int ret = 0; > > + int ret; > > > if (!obj && !old_obj) > > return 0; > @@ -14577,7 +14604,6 @@ intel_prepare_plane_fb(struct drm_plane *plane, > > if (old_obj) { > > struct drm_crtc_state *crtc_state = > > drm_atomic_get_existing_crtc_state(new_state->state, > > plane->state->crtc); > > - long timeout = 0; > > > /* Big Hammer, we also need to ensure that any pending > > * MI_WAIT_FOR_EVENT inside a user batch buffer on the > @@ -14590,31 +14616,25 @@ intel_prepare_plane_fb(struct drm_plane *plane, > > * This should only fail upon a hung GPU, in which case we > > * can safely continue. > > */ > > - if (needs_modeset(crtc_state)) > > - timeout = i915_gem_object_wait(old_obj, > > - I915_WAIT_INTERRUPTIBLE | > > - I915_WAIT_LOCKED, > > - MAX_SCHEDULE_TIMEOUT, > > - NULL); > > - if (timeout < 0) { > > - /* GPU hangs should have been swallowed by the wait */ > > -
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Update i915.reset to handle engine resets
On ma, 2016-09-19 at 16:30 +0100, Matthew Auld wrote: > From: "arun.siluv...@linux.intel.com"> I assume "From:" needs to be properly formatted just like "Signed-off-by:". So in all patches; From: Arun Siluvery Cover letters are also gaining popularity, and remember to use --reroll-count=N when submitting new iterations of the same series, will help people and Patchwork :) Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/18] drm/i915: Enable multiple timelines
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > @@ -315,17 +304,42 @@ submit_notify(struct i915_sw_fence *fence, enum > i915_sw_fence_notify state) > { > struct drm_i915_gem_request *request = > container_of(fence, typeof(*request), submit); > + struct intel_timeline *timeline; > + struct intel_engine_cs *engine = request->engine; > + unsigned long flags; > + u32 seqno; > > /* Will be called from irq-context when using foreign DMA fences */ > > - switch (state) { > - case FENCE_COMPLETE: > - request->engine->submit_request(request); > - break; > + if (state != FENCE_COMPLETE) > + return NOTIFY_DONE; > > - case FENCE_FREE: > - break; > - } > + timeline = engine->timeline; > + GEM_BUG_ON(timeline == request->timeline); Umm, why this BUG_ON? > + > + spin_lock_irqsave(>lock, flags); > + > + seqno = timeline_get_seqno(>i915->gt.global_timeline); > + GEM_BUG_ON(seqno == 0); > + > + request->previous_seqno = timeline->last_submitted_seqno; > + timeline->last_submitted_seqno = seqno; > + > + spin_lock_nested(>lock, SINGLE_DEPTH_NESTING); A comment might be in place for the nested locking. > + request->global_seqno = seqno; > + if (test_bit(FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags)) > + intel_engine_enable_signaling(request); > + spin_unlock(>lock); > + > + engine->emit_request(request, request->ring->vaddr + request->postfix); Is it just me or does this look very strange, let's "emit the request" at "vaddr + request->postfix" offset. Makes no sense. Maybe reconsider refreshing the vfunc name. > + > + spin_lock_nested(>timeline->lock, SINGLE_DEPTH_NESTING); > + list_move_tail(>link, >requests); > + spin_unlock(>timeline->lock); > + > + engine->submit_request(request); > + > + spin_unlock_irqrestore(>lock, flags); > > return NOTIFY_DONE; > } > > @@ -685,12 +697,15 @@ void __i915_add_request(struct drm_i915_gem_request > *request, bool flush_caches) > > i915_sw_fence_await_sw_fence(>submit, >submit, > >submitq, GFP_NOWAIT); > > - request->emitted_jiffies = jiffies; > - request->previous_seqno = timeline->last_submitted_seqno; > + spin_lock_irq(>lock); > + list_add_tail(>link, >requests); > + spin_unlock_irq(>lock); > + > timeline->last_submitted_seqno = request->fence.seqno; > i915_gem_active_set(>last_request, request); > - list_add_tail(>link, >requests); > + > list_add_tail(>ring_link, >request_list); > + request->emitted_jiffies = jiffies; Is this assigment really worth delaying here? Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 0/7] drm/i915: clean up dsi sequences
On Mon, 19 Sep 2016, Ville Syrjäläwrote: > On Mon, Sep 19, 2016 at 03:02:23PM +0300, Jani Nikula wrote: >> v2 of an old series, addressing issues pointed out by Ville. > > Entire series looks reasonable. Spec is vague, so hard to be 100% sure. We're about to find out, I pushed the lot. Thanks for the review. BR, Jani. > > Reviewed-by: Ville Syrjälä > >> >> BR, >> Jani. >> >> Jani Nikula (7): >> drm/i915/dsi: don't debug log "missing" sequences >> drm/i915/dsi: add debug logging to element execution >> drm/i915/dsi: add skip functions for spi and pmic elements >> drm/i915/dsi: update reset and power sequences in panel >> prepare/unprepare hooks >> drm/i915/dsi: run backlight on/off sequences in panel enable/disable >> hooks >> drm/i915/bios: log about presence of DSI sequences we do not run >> drm/i915/dsi: double check element parsing against size if present >> >> drivers/gpu/drm/i915/intel_bios.c | 4 +++ >> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 48 >> +- >> 2 files changed, 45 insertions(+), 7 deletions(-) >> >> -- >> 2.1.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: [Intel-gfx] [PATCH 15/18] drm/i915: Reserve space in the global seqno during request allocation
On Mon, 19 Sep 2016, Joonas Lahtinenwrote: > On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: >> +static int reserve_global_seqno(struct drm_i915_private *i915) >> { >> -struct i915_gem_timeline *tl = _priv->gt.global_timeline; >> +struct i915_gem_timeline *tl = >gt.global_timeline; >> +u32 next_seqno = atomic_read(>next_seqno); >> >> -/* reserve 0 for non-seqno */ >> -if (unlikely(tl->next_seqno == 0)) { > > Meh, do not hide the ++i915->gt.active_requests in if (unlikely(...)). *shudder* it doesn't get any better by removing unlikely! BR, Jani. > >> +if (unlikely(next_seqno + ++i915->gt.active_requests <= next_seqno)) { >> int ret; >> > > Why not if (likely(next_seqno + active_requests > next_seqno)) > return 0; > >> -ret = i915_gem_init_global_seqno(dev_priv, 0); >> -if (ret) >> +ret = i915_gem_init_global_seqno(i915, 0); >> +if (ret) { >> +i915->gt.active_requests--; >> return ret; > > With above change the built-in teardown becomes OK. Otherwise split. > >> - >> -tl->next_seqno = 1; >> +} >> } >> >> -*seqno = tl->next_seqno++; >> return 0; >> } >> >> +static u32 timeline_get_seqno(struct i915_gem_timeline *tl) >> +{ >> +return atomic_inc_return(>next_seqno); >> +} >> + > > How about u32 timeline_peek_seqno(), as you have quite a few > atomic_reads on it. Also, lockdep_assert_held would be useful sprinkled > ni the functions. > > Reviewed-by: Joonas Lahtinen > > Regards, Joonas -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] drm/i915/tdr: Add engine reset count to error state
From: "arun.siluv...@linux.intel.com"Driver maintains count of how many times a given engine is reset, useful to capture this in error state also. It gives an idea of how engine is coping up with the workloads it is executing before this error state. v2 - rebase Cc: Chris Wilson Cc: Mika Kuoppala Signed-off-by: Arun Siluvery Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_drv.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 9 + drivers/gpu/drm/i915/i915_gpu_error.c | 3 +++ 3 files changed, 13 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 8625207..0017ab5 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1857,6 +1857,7 @@ int i915_reset_engine(struct intel_engine_cs *engine) intel_engine_reset_cancel(engine); intel_execlists_restart_submission(engine); + dev_priv->gpu_error.engine_reset_count[engine->id]++; intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL); return 0; diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 3dcf3f6..722aea3 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -774,6 +774,7 @@ struct drm_i915_error_state { enum intel_engine_hangcheck_action hangcheck_action; struct i915_address_space *vm; int num_requests; + u32 reset_count; /* our own tracking of ring head and tail */ u32 cpu_ring_head; @@ -1431,6 +1432,8 @@ struct i915_gpu_error { #define I915_RESET_IN_PROGRESS 0 #define I915_WEDGED(BITS_PER_LONG - 1) + unsigned long engine_reset_count[I915_NUM_ENGINES]; + /** * Waitqueue to signal when a hang is detected. Used to for waiters * to release the struct_mutex for the reset to procede. @@ -3268,6 +3271,12 @@ static inline u32 i915_reset_count(struct i915_gpu_error *error) return READ_ONCE(error->reset_count); } +static inline u32 i915_engine_reset_count(struct i915_gpu_error *error, + struct intel_engine_cs *engine) +{ + return READ_ONCE(error->engine_reset_count[engine->id]); +} + void i915_gem_reset(struct drm_i915_private *dev_priv); void i915_gem_set_wedged(struct drm_i915_private *dev_priv); void i915_gem_reset_engine(struct intel_engine_cs *engine); diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c index 334f15d..905b649 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.c +++ b/drivers/gpu/drm/i915/i915_gpu_error.c @@ -296,6 +296,7 @@ static void error_print_engine(struct drm_i915_error_state_buf *m, err_printf(m, " hangcheck: %s [%d]\n", hangcheck_action_to_str(ee->hangcheck_action), ee->hangcheck_score); + err_printf(m, " engine reset count: %u\n", ee->reset_count); } void i915_error_printf(struct drm_i915_error_state_buf *e, const char *f, ...) @@ -1056,6 +1057,8 @@ static void error_record_engine_registers(struct drm_i915_error_state *error, ee->hangcheck_score = engine->hangcheck.score; ee->hangcheck_action = engine->hangcheck.action; + ee->reset_count = i915_engine_reset_count(_priv->gpu_error, + engine); if (USES_PPGTT(dev_priv)) { int i; -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/i915/tdr: Add support for per engine reset recovery
From: "arun.siluv...@linux.intel.com"This change implements support for per-engine reset as an initial, less intrusive hang recovery option to be attempted before falling back to the legacy full GPU reset recovery mode if necessary. This is only supported from Gen8 onwards. Hangchecker determines which engines are hung and invokes error handler to recover from it. Error handler schedules recovery for each of those engines that are hung. The recovery procedure is as follows, - identifies the request that caused the hang and it is dropped - force engine to idle: this is done by issuing a reset request - reset and re-init engine - restart submissions to the engine If engine reset fails then we fall back to heavy weight full gpu reset which resets all engines and reinitiazes complete state of HW and SW. v2 - rebase Cc: Chris Wilson Cc: Mika Kuoppala Signed-off-by: Tomas Elf Signed-off-by: Arun Siluvery Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_drv.c | 59 + drivers/gpu/drm/i915/i915_drv.h | 3 ++ drivers/gpu/drm/i915/i915_gem.c | 2 +- drivers/gpu/drm/i915/intel_lrc.c| 10 +++ drivers/gpu/drm/i915/intel_lrc.h| 1 + drivers/gpu/drm/i915/intel_uncore.c | 41 +++--- 6 files changed, 105 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 99fa690..8625207 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1812,21 +1812,68 @@ error: * Returns zero on successful reset or otherwise an error code. * * Procedure is fairly simple: - * - force engine to idle - * - save current state which includes head and current request - * - reset engine - * - restore saved state and resubmit context + *- identifies the request that caused the hang and it is dropped + *- force engine to idle: this is done by issuing a reset request + *- reset engine + *- restart submissions to the engine */ int i915_reset_engine(struct intel_engine_cs *engine) { int ret; struct drm_i915_private *dev_priv = engine->i915; - /* FIXME: replace me with engine reset sequence */ - ret = -ENODEV; + /* +* We need to first idle the engine by issuing a reset request, +* then perform soft reset and re-initialize hw state, for all of +* this GT power need to be awake so ensure it does throughout the +* process +*/ + intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL); + + /* +* the request that caused the hang is stuck on elsp, identify the +* active request and drop it, adjust head to skip the offending +* request to resume executing remaining requests in the queue. +*/ + i915_gem_reset_engine(engine); + + ret = intel_engine_reset_begin(engine); + if (ret) { + DRM_ERROR("Failed to disable %s\n", engine->name); + goto error; + } + + ret = intel_gpu_reset(dev_priv, intel_engine_flag(engine)); + if (ret) { + DRM_ERROR("Failed to reset %s, ret=%d\n", engine->name, ret); + intel_engine_reset_cancel(engine); + goto error; + } + + ret = engine->init_hw(engine); + if (ret) + goto error; + + intel_engine_reset_cancel(engine); + intel_execlists_restart_submission(engine); + intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL); + return 0; + +error: + /* use full gpu reset to recover on error */ set_bit(I915_RESET_IN_PROGRESS, _priv->gpu_error.flags); + /* Engine reset is performed without taking struct_mutex, since it +* failed we now fallback to full gpu reset. Wakeup any waiters +* which should now see the reset_in_progress and release +* struct_mutex for us to continue recovery. +*/ + rcu_read_lock(); + intel_engine_wakeup(engine); + rcu_read_unlock(); + + intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL); return ret; } diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 79de74d..3dcf3f6 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2889,6 +2889,8 @@ extern int intel_gpu_reset(struct drm_i915_private *dev_priv, u32 engine_mask); extern bool intel_has_gpu_reset(struct drm_i915_private *dev_priv); extern void i915_reset(struct drm_i915_private *dev_priv); extern bool intel_has_engine_reset(struct drm_i915_private *dev_priv); +extern int intel_engine_reset_begin(struct intel_engine_cs *engine); +extern int intel_engine_reset_cancel(struct intel_engine_cs *engine); extern int i915_reset_engine(struct intel_engine_cs
[Intel-gfx] [PATCH 6/7] drm/i915/tdr: Export reset count info to debugfs
From: "arun.siluv...@linux.intel.com"A new variable is added to export the reset counts to debugfs, this includes full gpu reset and engine reset count. This is useful for tests where they areexpected to trigger reset; these counts are checked before and after the test to ensure the same. v2 - rebase Cc: Chris Wilson Cc: Mika Kuoppala Signed-off-by: Arun Siluvery Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_debugfs.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 27b0e34..83c8b02 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -1354,6 +1354,24 @@ static int i915_hangcheck_info(struct seq_file *m, void *unused) return 0; } +static int i915_reset_info(struct seq_file *m, void *unused) +{ + struct drm_info_node *node = m->private; + struct drm_device *dev = node->minor->dev; + struct drm_i915_private *dev_priv = dev->dev_private; + struct i915_gpu_error *error = _priv->gpu_error; + struct intel_engine_cs *engine; + + seq_printf(m, "full gpu reset = %u\n", i915_reset_count(error)); + + for_each_engine(engine, dev_priv) { + seq_printf(m, "%s = %u\n", engine->name, + i915_engine_reset_count(error, engine)); + } + + return 0; +} + static int ironlake_drpc_info(struct seq_file *m) { struct drm_i915_private *dev_priv = node_to_i915(m->private); @@ -5263,6 +5281,7 @@ static const struct drm_info_list i915_debugfs_list[] = { {"i915_guc_log_dump", i915_guc_log_dump, 0}, {"i915_frequency_info", i915_frequency_info, 0}, {"i915_hangcheck_info", i915_hangcheck_info, 0}, + {"i915_reset_info", i915_reset_info, 0}, {"i915_drpc_info", i915_drpc_info, 0}, {"i915_emon_status", i915_emon_status, 0}, {"i915_ring_freq_table", i915_ring_freq_table, 0}, -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/i915/tdr: Modify error handler for per engine hang recovery
From: "arun.siluv...@linux.intel.com"This is a preparatory patch which modifies error handler to do per engine hang recovery. The actual patch which implements this sequence follows later in the series. The aim is to prepare existing recovery function to adapt to this new function where applicable (which fails at this point because core implementation is lacking) and continue recovery using legacy full gpu reset. A helper function is also added to query the availability of engine reset. The error events behaviour that are used to notify user of reset are adapted to engine reset such that it doesn't break users listening to these events. In legacy we report an error event, a reset event before resetting the gpu and a reset done event marking the completion of reset. The same behaviour is adapted but reset event is only dispatched once even when multiple engines are hung. Finally once reset is complete we send reset done event as usual. v2 - rework slightly - prefer INTEL_GEN - document engine_mask param Cc: Chris Wilson Cc: Mika Kuoppala Signed-off-by: Ian Lister Signed-off-by: Tomas Elf Signed-off-by: Arun Siluvery Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_drv.c | 26 +++ drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/i915_irq.c | 50 + drivers/gpu/drm/i915/intel_uncore.c | 5 4 files changed, 78 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 7f4e8ad..99fa690 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1804,6 +1804,32 @@ error: goto wakeup; } +/** + * i915_reset_engine - reset GPU engine to recover from a hang + * @engine: engine to reset + * + * Reset a specific GPU engine. Useful if a hang is detected. + * Returns zero on successful reset or otherwise an error code. + * + * Procedure is fairly simple: + * - force engine to idle + * - save current state which includes head and current request + * - reset engine + * - restore saved state and resubmit context + */ +int i915_reset_engine(struct intel_engine_cs *engine) +{ + int ret; + struct drm_i915_private *dev_priv = engine->i915; + + /* FIXME: replace me with engine reset sequence */ + ret = -ENODEV; + + set_bit(I915_RESET_IN_PROGRESS, _priv->gpu_error.flags); + + return ret; +} + static int i915_pm_suspend(struct device *kdev) { struct pci_dev *pdev = to_pci_dev(kdev); diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 4dd307e..79de74d 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2888,6 +2888,8 @@ extern long i915_compat_ioctl(struct file *filp, unsigned int cmd, extern int intel_gpu_reset(struct drm_i915_private *dev_priv, u32 engine_mask); extern bool intel_has_gpu_reset(struct drm_i915_private *dev_priv); extern void i915_reset(struct drm_i915_private *dev_priv); +extern bool intel_has_engine_reset(struct drm_i915_private *dev_priv); +extern int i915_reset_engine(struct intel_engine_cs *engine); extern int intel_guc_reset(struct drm_i915_private *dev_priv); extern void intel_engine_init_hangcheck(struct intel_engine_cs *engine); extern unsigned long i915_chipset_val(struct drm_i915_private *dev_priv); diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index c128fdb..45c5a26 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -2487,11 +2487,13 @@ static void i915_error_wake_up(struct drm_i915_private *dev_priv) /** * i915_reset_and_wakeup - do process context error handling work * @dev_priv: i915 device private + * @engine_mask: engines which are marked as hung * * Fire an error uevent so userspace can see that a hang or error * was detected. */ -static void i915_reset_and_wakeup(struct drm_i915_private *dev_priv) +static void i915_reset_and_wakeup(struct drm_i915_private *dev_priv, + u32 engine_mask) { struct kobject *kobj = _priv->drm.primary->kdev->kobj; char *error_event[] = { I915_ERROR_UEVENT "=1", NULL }; @@ -2501,6 +2503,15 @@ static void i915_reset_and_wakeup(struct drm_i915_private *dev_priv) kobject_uevent_env(kobj, KOBJ_CHANGE, error_event); DRM_DEBUG_DRIVER("resetting chip\n"); + /* +* This event needs to be sent before performing gpu reset. When +* engine resets are supported we iterate through all engines and +* reset hung engines individually. To keep the event dispatch +* mechanism consistent with full gpu reset, this is only sent once +* even when multiple engines are hung. It is also safe to
[Intel-gfx] [PATCH 4/7] drm/i915: Skip reset request if there is one already
From: Mika KuoppalaTo perform engine reset we first disable engine to capture its state. This is done by issuing a reset request. Because we are reusing existing infrastructure, again when we actually reset an engine, reset function checks engine mask and issues reset request again which is unnecessary. To avoid this we check if the engine is already prepared, if so we just exit from that point. Cc: Chris Wilson Cc: Mika Kuoppala Signed-off-by: Mika Kuoppala Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/intel_uncore.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index 0738ac7..34f1658 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -1679,10 +1679,15 @@ int intel_wait_for_register(struct drm_i915_private *dev_priv, static int gen8_engine_reset_begin(struct intel_engine_cs *engine) { struct drm_i915_private *dev_priv = engine->i915; + const i915_reg_t reset_ctrl = RING_RESET_CTL(engine->mmio_base); + const u32 ready = RESET_CTL_REQUEST_RESET | RESET_CTL_READY_TO_RESET; int ret; - I915_WRITE_FW(RING_RESET_CTL(engine->mmio_base), - _MASKED_BIT_ENABLE(RESET_CTL_REQUEST_RESET)); + /* If engine has been already prepared, we can shortcut here */ + if ((I915_READ_FW(reset_ctrl) & ready) == ready) + return 0; + + I915_WRITE_FW(reset_ctrl, _MASKED_BIT_ENABLE(RESET_CTL_REQUEST_RESET)); ret = intel_wait_for_register_fw(dev_priv, RING_RESET_CTL(engine->mmio_base), -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] drm/i915/tdr: Enable Engine reset and recovery support
From: "arun.siluv...@linux.intel.com"This feature is made available only from Gen8, for previous gen devices driver uses legacy full gpu reset. v2 - rebase Cc: Chris Wilson Cc: Mika Kuoppala Signed-off-by: Tomas Elf Signed-off-by: Arun Siluvery Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_params.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index a945ec1..d2a6e83 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -46,7 +46,7 @@ struct i915_params i915 __read_mostly = { .prefault_disable = 0, .load_detect_test = 0, .force_reset_modeset_test = 0, - .reset = 1, + .reset = 2, .invert_brightness = 0, .disable_display = 0, .enable_cmd_parser = 1, @@ -113,7 +113,7 @@ MODULE_PARM_DESC(vbt_sdvo_panel_type, "(-2=ignore, -1=auto [default], index in VBT BIOS table)"); module_param_named_unsafe(reset, i915.reset, int, 0600); -MODULE_PARM_DESC(reset, "Attempt GPU resets (0=disabled, 1=full gpu reset [default], 2=engine reset)"); +MODULE_PARM_DESC(reset, "Attempt GPU resets (0=disabled, 1=full gpu reset, 2=engine reset [default])"); module_param_named_unsafe(enable_hangcheck, i915.enable_hangcheck, bool, 0644); MODULE_PARM_DESC(enable_hangcheck, -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/7] drm/i915: Update i915.reset to handle engine resets
From: "arun.siluv...@linux.intel.com"In preparation for engine reset work update this parameter to handle more than one type of reset. Default at the moment is still full gpu reset. v2 - rebase Cc: Chris Wilson Cc: Mika Kuoppala Signed-off-by: Arun Siluvery Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_params.c | 6 +++--- drivers/gpu/drm/i915/i915_params.h | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index 768ad89..a945ec1 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -46,7 +46,7 @@ struct i915_params i915 __read_mostly = { .prefault_disable = 0, .load_detect_test = 0, .force_reset_modeset_test = 0, - .reset = true, + .reset = 1, .invert_brightness = 0, .disable_display = 0, .enable_cmd_parser = 1, @@ -112,8 +112,8 @@ MODULE_PARM_DESC(vbt_sdvo_panel_type, "Override/Ignore selection of SDVO panel mode in the VBT " "(-2=ignore, -1=auto [default], index in VBT BIOS table)"); -module_param_named_unsafe(reset, i915.reset, bool, 0600); -MODULE_PARM_DESC(reset, "Attempt GPU resets (default: true)"); +module_param_named_unsafe(reset, i915.reset, int, 0600); +MODULE_PARM_DESC(reset, "Attempt GPU resets (0=disabled, 1=full gpu reset [default], 2=engine reset)"); module_param_named_unsafe(enable_hangcheck, i915.enable_hangcheck, bool, 0644); MODULE_PARM_DESC(enable_hangcheck, diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 3a0dd78..2f188bb 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -34,6 +34,7 @@ struct i915_params { int lvds_channel_mode; int panel_use_ssc; int vbt_sdvo_panel_type; + int reset; int enable_rc6; int enable_dc; int enable_fbc; @@ -58,7 +59,6 @@ struct i915_params { bool prefault_disable; bool load_detect_test; bool force_reset_modeset_test; - bool reset; bool disable_display; bool verbose_state_checks; bool nuclear_pageflip; -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3
On Sun, 2016-09-18 at 13:35 +0200, Thorsten Leemhuis wrote: > Hi! James & Paulo: What's the current status of this? No, the only interaction has been the suggestion below for a revert, which didn't fix the problem. > Was this issue discussed elsewhere or even fixed in between? Just > asking, because this issue is on the list of regressions for 4.8. I'm just about to try out -rc7, but it's not fixed so far. James > Ciao, Thorsten > > On 01.09.2016 00:25, James Bottomley wrote: > > On Wed, 2016-08-31 at 21:51 +, Zanoni, Paulo R wrote: > > > Em Qua, 2016-08-31 às 14:43 -0700, James Bottomley escreveu: > > > > On Wed, 2016-08-31 at 11:23 -0700, James Bottomley wrote: > > > > > On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote: > > > > > > We seem to have an xrandr regression with skylake now. > > > > > > What's > > > > > > happening is that I can get output on to a projector, but > > > > > > the > > > > > > system is losing video when I change the xrandr sessions > > > > > > (like > > > > > > going from a --above b to a --same-as b). The main screen > > > > > > goes > > > > > > blank, which is basically a reboot situation. > > > > > > Unfortunately, I > > > > > > can't seem to get the logs out of systemd to see if there > > > > > > was a > > > > > > dump to dmesg (the system was definitely responding). > > > > > > > > > > > > I fell back to 4.6.2 which worked perfectly, so this is > > > > > > definitely > > > > > > some sort of regression. I'll be able to debug more fully > > > > > > when > > > > > > I > > > > > > get back home from the Linux Security Summit. > > > > > > > > > > I'm home now. Unfortunately, my monitor isn't as problematic > > > > > as > > > > > the > > > > > projector, but by flipping between various modes and > > > > > separating > > > > > and > > > > > overlaying the panels with --above and --same-as (xrandr), I > > > > > can > > > > > eventually get it to the point where the main LCD panel goes > > > > > black > > > > > and can only be restarted by specifying a different mode. > > > > > > > > > > This seems to be associated with these lines in the X > > > > > > > > > > [ 14714.389] (EE) intel(0): failed to set mode: Invalid > > > > > argument > > > > > [22] > > > > > > > > > > But the curious thing is that even if this fails with the > > > > > error > > > > > message once, it may succeed a second time, so it looks to be > > > > > a > > > > > transient error translation problem from the kernel driver. > > > > > > > > > > I've attached the full log below. > > > > > > > > > > This is only with a VGA output. I currently don't have a > > > > > HDMI > > > > > dongle, but I'm in the process of acquiring one. > > > > > > > > After more playing around, I'm getting thousands of these in > > > > the > > > > kernel > > > > log (possibly millions: the log wraps very fast): > > > > > > > > [23504.873606] [drm:intel_dp_start_link_train [i915]] *ERROR* > > > > failed > > > > to train DP, aborting > > > > > > > > And then finally it gives up with > > > > > > > > [25023.770951] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] > > > > *ERROR* CPU pipe B FIFO underrun > > > > [25561.926075] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] > > > > *ERROR* CPU pipe A FIFO underrun > > > > > > > > And the crtc for the VGA output becomes non-responsive to any > > > > configuration command. This requires a reboot and sometimes a > > > > UEFI > > > > variable reset before it comes back. > > > > > > Please see this discussion: > > > https://patchwork.freedesktop.org/patch/103237/ > > > > > > Do you have this patch on your tree? Does the problem go away if > > > you > > > revert it? > > > > Yes, I've got it, it went in in 4.8-rc3 according to git: > > > > commit 58e311b09c319183254d9220c50a533e7157c9ab > > Author: Matt Roper> > Date: Thu Aug 4 14:08:00 2016 -0700 > > > > drm/i915/gen9: Give one extra block per line for SKL plane WM > > calculations > > > > Reverting it causes the secondary display not to sync pretty much > > at > > all. However, in the flickers I can see, it does work OK and > > doesn't > > now crash switching from --same-as to --above and back > > > > I also still get the logs filling up with the link training errors. > > > > On balance, although the behaviour is different, it's not an > > improvement because if I can't sync with the projector, I can't > > really > > use this as a fix. > > > > James > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: fix implicit declaration build error on ia64
On Fri, Sep 16, 2016 at 01:06:36PM +0300, Jani Nikula wrote: >drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_downstream_debug': > >> drivers/gpu/drm/drm_dp_helper.c:551:2: error: implicit declaration of > >> function 'seq_printf' [-Werror=implicit-function-declaration] > seq_printf(m, "\tDP branch device present: %s\n", > ^ > >> drivers/gpu/drm/drm_dp_helper.c:559:3: error: implicit declaration of > >> function 'seq_puts' [-Werror=implicit-function-declaration] > seq_puts(m, "\t\tType: DisplayPort\n"); > ^ > > Reported-by: kbuild test robot> References: > https://lists.freedesktop.org/archives/intel-gfx/2016-September/106638.html > Fixes: 80209e5f2c42 ("drm: Add DP branch device info on debugfs") > Cc: Mika Kahola > Signed-off-by: Jani Nikula Applied to drm-misc (yeah wrong branch, but easier that way ...). Thanks, Daniel > > --- > > The commit being fixed is only in drm-intel tree. I failed at actually > testing this, but I presume this is the fix... > --- > drivers/gpu/drm/drm_dp_helper.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c > index a5365142cdba..894a6ac6f6e7 100644 > --- a/drivers/gpu/drm/drm_dp_helper.c > +++ b/drivers/gpu/drm/drm_dp_helper.c > @@ -27,6 +27,7 @@ > #include > #include > #include > +#include > #include > #include > > -- > 2.1.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/10] drm: Move all decl for drm_edid.c to drm_edid.h
On Tue, Sep 06, 2016 at 12:59:39PM -0400, Sean Paul wrote: > On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter> wrote: > > Some were still left in drm_crtc.h. Also include drm_edid.h in the > > rst files. > > > > Signed-off-by: Daniel Vetter > > Reviewed-by: Sean Paul Merged up to this patch, thanks for the review. -Daniel > > > --- > > Documentation/gpu/drm-kms-helpers.rst | 3 +++ > > include/drm/drm_crtc.h| 30 +- > > include/drm/drm_edid.h| 30 ++ > > 3 files changed, 34 insertions(+), 29 deletions(-) > > > > diff --git a/Documentation/gpu/drm-kms-helpers.rst > > b/Documentation/gpu/drm-kms-helpers.rst > > index 48fc5a96bf95..bb4254d19cbb 100644 > > --- a/Documentation/gpu/drm-kms-helpers.rst > > +++ b/Documentation/gpu/drm-kms-helpers.rst > > @@ -208,6 +208,9 @@ Output Probing Helper Functions Reference > > EDID Helper Functions Reference > > === > > > > +.. kernel-doc:: include/drm/drm_edid.h > > + :internal: > > + > > .. kernel-doc:: drivers/gpu/drm/drm_edid.c > > :export: > > > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h > > index bf9ee1b97c26..7bb3aa87a8be 100644 > > --- a/include/drm/drm_crtc.h > > +++ b/include/drm/drm_crtc.h > > @@ -43,6 +43,7 @@ > > #include > > #include > > #include > > +#include > > > > struct drm_device; > > struct drm_mode_set; > > @@ -1992,33 +1993,4 @@ assert_drm_connector_list_read_locked(struct > > drm_mode_config *mode_config) > > !drm_modeset_is_locked(_config->connection_mutex)); > > } > > > > -/* drm_edid.c */ > > -bool drm_probe_ddc(struct i2c_adapter *adapter); > > -struct edid *drm_get_edid(struct drm_connector *connector, > > - struct i2c_adapter *adapter); > > -struct edid *drm_get_edid_switcheroo(struct drm_connector *connector, > > -struct i2c_adapter *adapter); > > -struct edid *drm_edid_duplicate(const struct edid *edid); > > -int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid); > > - > > -u8 drm_match_cea_mode(const struct drm_display_mode *to_match); > > -enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code); > > -bool drm_detect_hdmi_monitor(struct edid *edid); > > -bool drm_detect_monitor_audio(struct edid *edid); > > -bool drm_rgb_quant_range_selectable(struct edid *edid); > > -int drm_add_modes_noedid(struct drm_connector *connector, > > -int hdisplay, int vdisplay); > > -void drm_set_preferred_mode(struct drm_connector *connector, > > - int hpref, int vpref); > > - > > -int drm_edid_header_is_valid(const u8 *raw_edid); > > -bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid, > > - bool *edid_corrupt); > > -bool drm_edid_is_valid(struct edid *edid); > > -void drm_edid_get_monitor_name(struct edid *edid, char *name, > > - int buflen); > > -struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev, > > - int hsize, int vsize, int fresh, > > - bool rb); > > - > > #endif /* __DRM_CRTC_H__ */ > > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h > > index 919933d1beb4..c3a7d440bc11 100644 > > --- a/include/drm/drm_edid.h > > +++ b/include/drm/drm_edid.h > > @@ -25,6 +25,9 @@ > > > > #include > > > > +struct drm_device; > > +struct i2c_adapter; > > + > > #define EDID_LENGTH 128 > > #define DDC_ADDR 0x50 > > #define DDC_ADDR2 0x52 /* E-DDC 1.2 - where DisplayID can hide */ > > @@ -423,9 +426,36 @@ static inline u8 drm_eld_get_conn_type(const uint8_t > > *eld) > > return eld[DRM_ELD_SAD_COUNT_CONN_TYPE] & DRM_ELD_CONN_TYPE_MASK; > > } > > > > +bool drm_probe_ddc(struct i2c_adapter *adapter); > > struct edid *drm_do_get_edid(struct drm_connector *connector, > > int (*get_edid_block)(void *data, u8 *buf, unsigned int block, > > size_t len), > > void *data); > > +struct edid *drm_get_edid(struct drm_connector *connector, > > + struct i2c_adapter *adapter); > > +struct edid *drm_get_edid_switcheroo(struct drm_connector *connector, > > +struct i2c_adapter *adapter); > > +struct edid *drm_edid_duplicate(const struct edid *edid); > > +int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid); > > + > > +u8 drm_match_cea_mode(const struct drm_display_mode *to_match); > > +enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code); > > +bool drm_detect_hdmi_monitor(struct edid *edid); > > +bool drm_detect_monitor_audio(struct edid *edid); > > +bool drm_rgb_quant_range_selectable(struct edid *edid); > > +int drm_add_modes_noedid(struct drm_connector
Re: [Intel-gfx] [PATCH v2 0/7] drm/i915: clean up dsi sequences
On Mon, Sep 19, 2016 at 03:02:23PM +0300, Jani Nikula wrote: > v2 of an old series, addressing issues pointed out by Ville. Entire series looks reasonable. Spec is vague, so hard to be 100% sure. Reviewed-by: Ville Syrjälä> > BR, > Jani. > > Jani Nikula (7): > drm/i915/dsi: don't debug log "missing" sequences > drm/i915/dsi: add debug logging to element execution > drm/i915/dsi: add skip functions for spi and pmic elements > drm/i915/dsi: update reset and power sequences in panel > prepare/unprepare hooks > drm/i915/dsi: run backlight on/off sequences in panel enable/disable > hooks > drm/i915/bios: log about presence of DSI sequences we do not run > drm/i915/dsi: double check element parsing against size if present > > drivers/gpu/drm/i915/intel_bios.c | 4 +++ > drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 48 > +- > 2 files changed, 45 insertions(+), 7 deletions(-) > > -- > 2.1.4 -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/18] drm/i915: Reserve space in the global seqno during request allocation
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > +static int reserve_global_seqno(struct drm_i915_private *i915) > { > - struct i915_gem_timeline *tl = _priv->gt.global_timeline; > + struct i915_gem_timeline *tl = >gt.global_timeline; > + u32 next_seqno = atomic_read(>next_seqno); > > - /* reserve 0 for non-seqno */ > - if (unlikely(tl->next_seqno == 0)) { Meh, do not hide the ++i915->gt.active_requests in if (unlikely(...)). > + if (unlikely(next_seqno + ++i915->gt.active_requests <= next_seqno)) { > int ret; > Why not if (likely(next_seqno + active_requests > next_seqno)) return 0; > - ret = i915_gem_init_global_seqno(dev_priv, 0); > - if (ret) > + ret = i915_gem_init_global_seqno(i915, 0); > + if (ret) { > + i915->gt.active_requests--; > return ret; With above change the built-in teardown becomes OK. Otherwise split. > - > - tl->next_seqno = 1; > + } > } > > - *seqno = tl->next_seqno++; > return 0; > } > > +static u32 timeline_get_seqno(struct i915_gem_timeline *tl) > +{ > + return atomic_inc_return(>next_seqno); > +} > + How about u32 timeline_peek_seqno(), as you have quite a few atomic_reads on it. Also, lockdep_assert_held would be useful sprinkled ni the functions. Reviewed-by: Joonas LahtinenRegards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/18] drm/i915: Create a unique name for the context
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > @@ -310,12 +311,21 @@ __create_hw_context(struct drm_device *dev, > goto err_out; > } else > ret = DEFAULT_CONTEXT_HANDLE; Confusing indent, so add braces to above else and a newline here. Reviewed-by: Joonas LahtinenRegards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/18] drm/i915: Move the global sync optimisation to the timeline
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > @@ -262,6 +263,12 @@ static int i915_gem_init_global_seqno(struct > drm_i915_private *dev_priv, > for_each_engine(engine, dev_priv) > intel_engine_init_global_seqno(engine, seqno); > > + list_for_each_entry(tl, _priv->gt.timelines, link) { > + for (i = 0; i < ARRAY_SIZE(tl->engine); i++) > + memset(tl->engine[i].sync_seqno, 0, > + sizeof(tl->engine[i].sync_seqno)); > + } > + I think have braces in both loops or neither, looks extremely odd otherwise. > @@ -454,7 +461,7 @@ static int > i915_gem_request_await_request(struct drm_i915_gem_request *to, > > struct drm_i915_gem_request *from) > { > > - int idx, ret; > > + int ret; > > > GEM_BUG_ON(to == from); > > @@ -474,8 +481,7 @@ i915_gem_request_await_request(struct > drm_i915_gem_request *to, > return ret < 0 ? ret : 0; > } > > - idx = intel_engine_sync_index(from->engine, to->engine); You remove this here, and the only place it remains used is i915_gpu_error.c, maybe make it static in there? > @@ -263,16 +263,13 @@ static void error_print_engine(struct > drm_i915_error_state_buf *m, > if (INTEL_GEN(m->i915) >= 6) { > err_printf(m, " RC PSMI: 0x%08x\n", ee->rc_psmi); > err_printf(m, " FAULT_REG: 0x%08x\n", ee->fault_reg); > - err_printf(m, " SYNC_0: 0x%08x [last synced 0x%08x]\n", > - ee->semaphore_mboxes[0], > - ee->semaphore_seqno[0]); > - err_printf(m, " SYNC_1: 0x%08x [last synced 0x%08x]\n", > - ee->semaphore_mboxes[1], > - ee->semaphore_seqno[1]); > + err_printf(m, " SYNC_0: 0x%08x\n", > + ee->semaphore_mboxes[0]); > + err_printf(m, " SYNC_1: 0x%08x\n", > + ee->semaphore_mboxes[1]); > if (HAS_VEBOX(m->i915)) { > - err_printf(m, " SYNC_2: 0x%08x [last synced 0x%08x]\n", > - ee->semaphore_mboxes[2], > - ee->semaphore_seqno[2]); > + err_printf(m, " SYNC_2: 0x%08x\n", > + ee->semaphore_mboxes[2]); > } You can drop these braces too. Reviewed-by: Joonas LahtinenRegards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/10] drm/doc: Polish for drm_plane.[hc]
On Fri, Sep 02, 2016 at 03:00:38PM +0530, Archit Taneja wrote: > > > On 8/31/2016 9:39 PM, Daniel Vetter wrote: > > Big thing is untangling and carefully documenting the different uapi > > types of planes. I also sprinkled a few more cross references around > > to make this easier to discover. > > > > As usual, remove the kerneldoc for internal functions which are not > > exported. Aside: We should probably go OCD on all the ioctl handlers > > and consistenly give them an _ioctl postfix. > > > > Signed-off-by: Daniel Vetter> > --- > > Documentation/gpu/drm-kms.rst | 47 +-- > > drivers/gpu/drm/drm_crtc.c| 6 +- > > drivers/gpu/drm/drm_plane.c | 132 > > -- > > include/drm/drm_plane.h | 57 +- > > 4 files changed, 86 insertions(+), 156 deletions(-) > > > > > > +/** > > + * enum drm_plane_type - uapi plane type enumeration > > + * > > + * For historical reasons not all planes are made the same. This > > enumeration is > > + * used to tell the different types of planes apart to implement the > > different > > + * uapi semantics for them. For userspace which is universal plane aware > > and > > + * which is using that atomic IOCTL there's no difference between these > > planes > > + * (beyong what the driver and hardware can support of course). > > + * > > + * For compatibility with legacy userspace, only overlay planes are made > > + * available to userspace by default. Userspace clients may set the > > + * DRM_CLIENT_CAP_UNIVERSAL_PLANES client capability bit to indicate that > > they > > + * wish to receive a universal plane list containing all plane types. See > > also > > + * drm_for_each_legacy_plane(). > > + */ > > enum drm_plane_type { > > - DRM_PLANE_TYPE_OVERLAY, > > Any reason why you moved this down? I guess there is no harm, but people > might be printing plane type while debugging, and they'd assume > DRM_PLANE_TYPE_OVERLAY=0 I think starting out with 0 for the primary plane makes a lot more sense, and since it's an internal thing we can change it however we want. I also think from a documentation pov it reads better if the 2 special planes (primary and cursor) are first. But I'm happy to shuffle it back if you feel strongly the other way round. -Daniel > > Thanks, > Archit > > > + /** > > +* @DRM_PLANE_TYPE_PRIMARY: > > +* > > +* Primary planes represent a "main" plane for a CRTC. Primary planes > > +* are the planes operated upon by CRTC modesetting and flipping > > +* operations described in the page_flip and set_config hooks in struct > > +* _crtc_funcs. > > +*/ > > DRM_PLANE_TYPE_PRIMARY, > > + > > + /** > > +* @DRM_PLANE_TYPE_CURSOR: > > +* > > +* Cursor planes represent a "cursor" plane for a CRTC. Cursor planes > > +* are the planes operated upon by the DRM_IOCTL_MODE_CURSOR and > > +* DRM_IOCTL_MODE_CURSOR2 IOCTLs. > > +*/ > > DRM_PLANE_TYPE_CURSOR, > > + > > + /** > > +* @DRM_PLANE_TYPE_OVERLAY: > > +* > > +* Overlay planes represent all non-primary, non-cursor planes. Some > > +* drivers refer to these types of planes as "sprites" internally. > > +*/ > > + DRM_PLANE_TYPE_OVERLAY, > > }; > > > > > > @@ -458,11 +496,26 @@ static inline struct drm_plane *drm_plane_find(struct > > drm_device *dev, > > list_for_each_entry((plane), &(dev)->mode_config.plane_list, head) \ > > for_each_if ((plane_mask) & (1 << drm_plane_index(plane))) > > > > -/* Plane list iterator for legacy (overlay only) planes. */ > > +/** > > + * drm_for_each_legacy_plane - iterate over all planes for legacy userspace > > + * @plane: the loop cursor > > + * @dev: the DRM device > > + * > > + * Iterate over all legacy planes of @dev, excluding primary and cursor > > planes. > > + * This is useful for implementing userspace apis when userspace is not > > + * universal plane aware. See also enum _plane_type. > > + */ > > #define drm_for_each_legacy_plane(plane, dev) \ > > list_for_each_entry(plane, &(dev)->mode_config.plane_list, head) \ > > for_each_if (plane->type == DRM_PLANE_TYPE_OVERLAY) > > > > +/** > > + * drm_for_each_plane - iterate over all planes > > + * @plane: the loop cursor > > + * @dev: the DRM device > > + * > > + * Iterate over all planes of @dev, include primary and cursor planes. > > + */ > > #define drm_for_each_plane(plane, dev) \ > > list_for_each_entry(plane, &(dev)->mode_config.plane_list, head) > > > > > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/10] drm: Extract drm_plane.[hc]
On Tue, Sep 06, 2016 at 12:59:31PM -0400, Sean Paul wrote: > On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter> wrote: > > Just pure code movement, cleanup and polish will happen in later > > patches. > > > > v2: Don't forget all the ioctl! To extract those cleanly I decided to > > put check_src_coords into drm_framebuffer.c (and give it a > > drm_framebuffer_ prefix), since that just checks framebuffer > > constraints. > > > > Signed-off-by: Daniel Vetter > > --- > > Documentation/gpu/drm-kms.rst | 12 + > > drivers/gpu/drm/Makefile| 3 +- > > drivers/gpu/drm/drm_crtc.c | 939 > > +--- > > drivers/gpu/drm/drm_crtc_internal.h | 38 +- > > drivers/gpu/drm/drm_framebuffer.c | 26 + > > drivers/gpu/drm/drm_plane.c | 937 > > +++ > > include/drm/drm_atomic.h| 154 ++ > > include/drm/drm_crtc.h | 583 +- > > include/drm/drm_plane.h | 470 ++ > > 9 files changed, 1628 insertions(+), 1534 deletions(-) > > create mode 100644 drivers/gpu/drm/drm_plane.c > > create mode 100644 include/drm/drm_plane.h > > > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > > index f9a991bb87d4..33181be97151 100644 > > --- a/Documentation/gpu/drm-kms.rst > > +++ b/Documentation/gpu/drm-kms.rst > > @@ -110,6 +110,18 @@ Note that dumb objects may not be used for gpu > > acceleration, as has been > > attempted on some ARM embedded platforms. Such drivers really must have > > a hardware-specific ioctl to allocate suitable buffer objects. > > > > +Plane Abstraction > > += > > + > > +Plane Functions Reference > > +- > > + > > +.. kernel-doc:: include/drm/drm_plane.h > > + :internal: > > + > > +.. kernel-doc:: drivers/gpu/drm/drm_plane.c > > + :export: > > + > > Display Modes Function Reference > > > > > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > > index 439d89b25ae0..8eeb07a35798 100644 > > --- a/drivers/gpu/drm/Makefile > > +++ b/drivers/gpu/drm/Makefile > > @@ -14,7 +14,8 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \ > > drm_rect.o drm_vma_manager.o drm_flip_work.o \ > > drm_modeset_lock.o drm_atomic.o drm_bridge.o \ > > drm_framebuffer.o drm_connector.o drm_blend.o \ > > - drm_encoder.o drm_mode_object.o drm_property.o > > + drm_encoder.o drm_mode_object.o drm_property.o \ > > + drm_plane.o > > > > drm-$(CONFIG_COMPAT) += drm_ioc32.o > > drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > > index 0fad433f4d2d..513ab4729683 100644 > > --- a/drivers/gpu/drm/drm_crtc.c > > +++ b/drivers/gpu/drm/drm_crtc.c > > > > > - > > -static int check_src_coords(uint32_t src_x, uint32_t src_y, > > - uint32_t src_w, uint32_t src_h, > > - const struct drm_framebuffer *fb) > > -{ > > - unsigned int fb_width, fb_height; > > - > > - fb_width = fb->width << 16; > > - fb_height = fb->height << 16; > > - > > - /* Make sure source coordinates are inside the fb. */ > > - if (src_w > fb_width || > > - src_x > fb_width - src_w || > > - src_h > fb_height || > > - src_y > fb_height - src_h) { > > - DRM_DEBUG_KMS("Invalid source coordinates " > > - "%u.%06ux%u.%06u+%u.%06u+%u.%06u\n", > > - src_w >> 16, ((src_w & 0x) * 15625) >> 10, > > - src_h >> 16, ((src_h & 0x) * 15625) >> 10, > > - src_x >> 16, ((src_x & 0x) * 15625) >> 10, > > - src_y >> 16, ((src_y & 0x) * 15625) >> > > 10); > > - return -ENOSPC; > > - } > > - > > - return 0; > > -} > > I'm good with this change, but I'd argue that it probably belongs in > its own patch. Except for moving the function + giving it a prefix (since it's no longer static) there's no change here. > > > > > > /** > > - * drm_mode_page_flip_ioctl - schedule an asynchronous fb update > > - * @dev: DRM device > > - * @data: ioctl data > > - * @file_priv: DRM file info > > - * > > - * This schedules an asynchronous update on a given CRTC, called page flip. > > - * Optionally a drm event is generated to signal the completion of the > > event. > > - * Generic drivers cannot assume that a pageflip with changed framebuffer > > - * properties (including driver specific metadata like tiling layout) will > > work, > > - * but some drivers support e.g. pixel format changes through the pageflip > > - * ioctl. > > - * > > - * Called by the user via ioctl. > > - * > > - * Returns:
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: clean up dsi sequences
== Series Details == Series: drm/i915: clean up dsi sequences URL : https://patchwork.freedesktop.org/series/12640/ State : warning == Summary == Series 12640v1 drm/i915: clean up dsi sequences https://patchwork.freedesktop.org/api/1.0/series/12640/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: dmesg-warn -> PASS (fi-skl-6700k) Subgroup nonblocking-crc-pipe-b-frame-sequence: pass -> SKIP (fi-hsw-4770r) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:202 dwarn:0 dfail:0 fail:0 skip:42 fi-byt-n2820 total:244 pass:208 dwarn:0 dfail:0 fail:1 skip:35 fi-hsw-4770k total:244 pass:226 dwarn:0 dfail:0 fail:0 skip:18 fi-hsw-4770r total:244 pass:221 dwarn:0 dfail:0 fail:0 skip:23 fi-ivb-3520m total:244 pass:219 dwarn:0 dfail:0 fail:0 skip:25 fi-ivb-3770 total:244 pass:207 dwarn:0 dfail:0 fail:0 skip:37 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:221 dwarn:0 dfail:0 fail:1 skip:22 fi-skl-6700k total:244 pass:219 dwarn:1 dfail:0 fail:0 skip:24 fi-skl-6770hqtotal:244 pass:228 dwarn:1 dfail:0 fail:1 skip:14 fi-snb-2520m total:244 pass:208 dwarn:0 dfail:0 fail:0 skip:36 fi-snb-2600 total:244 pass:207 dwarn:0 dfail:0 fail:0 skip:37 Results at /archive/results/CI_IGT_test/Patchwork_2554/ 0d6fa72a8c18ec6ab4dbabf5202b8d1cad840e04 drm-intel-nightly: 2016y-09m-19d-09h-28m-11s UTC integration manifest 13c9cdf drm/i915/dsi: double check element parsing against size if present 57a905b drm/i915/bios: log about presence of DSI sequences we do not run c979437 drm/i915/dsi: run backlight on/off sequences in panel enable/disable hooks 248085c drm/i915/dsi: update reset and power sequences in panel prepare/unprepare hooks c34bc49 drm/i915/dsi: add skip functions for spi and pmic elements c82ca7c2 drm/i915/dsi: add debug logging to element execution b23a5c0 drm/i915/dsi: don't debug log "missing" sequences ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Only shrink the unbound objects during freeze
On ma, 2016-09-19 at 09:38 +0100, Chris Wilson wrote: > On Mon, Sep 19, 2016 at 11:31:37AM +0300, Joonas Lahtinen wrote: > > > > On pe, 2016-09-16 at 20:23 +0100, Chris Wilson wrote: > > > > > > int i915_gem_freeze_late(struct drm_i915_private *dev_priv) > > > { > > > > > > > > > > > > struct drm_i915_gem_object *obj; > > > @@ -4692,7 +4705,8 @@ int i915_gem_freeze_late(struct drm_i915_private > > > *dev_priv) > > > > > > > > > > > > * the objects as well. > > > > > > > > */ > > > > > > > > > > > > > > > - i915_gem_shrink_all(dev_priv); > > > > > > + mutex_lock(_priv->drm.struct_mutex); > > > > Previously the shrinking here was without a mutex. And the new > > shrinking during _freeze is also mutex protected, any specific reason? > > Silencing lockdep. We know we are single threaded here, but lockdep > doesn't. This version of i915_gem_shrink() doesn't automagically take > the struct_mutex (later versions do). Throw the info to commit message. Then all good. Regards, Joonas > -Chris > -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/18] drm/i915: Defer request emission
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > +static void gen8_emit_wa_tail(struct drm_i915_gem_request *request, u32 *out) > { > - struct intel_ring *ring = request->ring; > - int ret; > - > - ret = intel_ring_begin(request, 6 + WA_TAIL_DWORDS); > - if (ret) > - return ret; > + out[0] = MI_NOOP; > + out[1] = MI_NOOP; How about storing 'out' on the request and still using the emit wrapper? I assume passing a separate variable might end up rather fragile. > -static int gen8_rcs_signal(struct drm_i915_gem_request *req) > +static u32 *gen8_rcs_signal(struct drm_i915_gem_request *req, u32 *out) > { > - struct intel_ring *ring = req->ring; > struct drm_i915_private *dev_priv = req->i915; > struct intel_engine_cs *waiter; > enum intel_engine_id id; > - int ret, num_rings; > - > - num_rings = INTEL_INFO(dev_priv)->num_rings; > - ret = intel_ring_begin(req, (num_rings-1) * 8); > - if (ret) > - return ret; > > for_each_engine_id(waiter, dev_priv, id) { > u64 gtt_offset = req->engine->semaphore.signal_ggtt[id]; > if (gtt_offset == MI_SEMAPHORE_SYNC_INVALID) > continue; > > - intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(6)); > - intel_ring_emit(ring, > - PIPE_CONTROL_GLOBAL_GTT_IVB | > - PIPE_CONTROL_QW_WRITE | > - PIPE_CONTROL_CS_STALL); > - intel_ring_emit(ring, lower_32_bits(gtt_offset)); > - intel_ring_emit(ring, upper_32_bits(gtt_offset)); > - intel_ring_emit(ring, req->global_seqno); > - intel_ring_emit(ring, 0); > - intel_ring_emit(ring, > - MI_SEMAPHORE_SIGNAL | > - MI_SEMAPHORE_TARGET(waiter->hw_id)); > - intel_ring_emit(ring, 0); > + *out++ = GFX_OP_PIPE_CONTROL(6); > + *out++ = (PIPE_CONTROL_GLOBAL_GTT_IVB | > + PIPE_CONTROL_QW_WRITE | > + PIPE_CONTROL_CS_STALL); > + *out++ = lower_32_bits(gtt_offset); > + *out++ = upper_32_bits(gtt_offset); > + *out++ = req->global_seqno; > + *out++ = 0; > + *out++ = (MI_SEMAPHORE_SIGNAL | > + MI_SEMAPHORE_TARGET(waiter->hw_id)); > + *out++ = 0; And this is mixing a different approach in... Pick one and convert others to it. I like having the wrapper for easier grepping of emitted commands, but YMMV. > +static void gen6_sema_emit_request(struct drm_i915_gem_request *req, > + u32 *out) > { > - int ret; > - > - ret = req->engine->semaphore.signal(req); > - if (ret) > - return ret; > - > - return i9xx_emit_request(req); > + return i9xx_emit_request(req, req->engine->semaphore.signal(req, out)); Not sure if this chaining is beautiful, I'd split signal to its own line of "out = ...". Those addressed, Reviewed-by: Joonas LahtinenRegards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/7] drm/i915/bios: log about presence of DSI sequences we do not run
Leave behind some debugging clues in case some panels don't work properly. Signed-off-by: Jani Nikula--- drivers/gpu/drm/i915/intel_bios.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c index c6e69e4cfa83..83667e8cdd6b 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -996,6 +996,10 @@ parse_mipi_sequence(struct drm_i915_private *dev_priv, goto err; } + /* Log about presence of sequences we won't run. */ + if (seq_id == MIPI_SEQ_TEAR_ON || seq_id == MIPI_SEQ_TEAR_OFF) + DRM_DEBUG_KMS("Unsupported sequence %u\n", seq_id); + dev_priv->vbt.dsi.sequence[seq_id] = data + index; if (sequence->version >= 3) -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 5/7] drm/i915/dsi: run backlight on/off sequences in panel enable/disable hooks
Based on the documentation alone, it's anyone's guess when exactly we should be running these sequences. Add them where it feels logical. The drm panel hooks don't currently offer us more granularity anyway. Signed-off-by: Jani Nikula--- drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c index 2c5d14eb7851..24953f9f7e1d 100644 --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c @@ -477,12 +477,14 @@ static int vbt_panel_unprepare(struct drm_panel *panel) static int vbt_panel_enable(struct drm_panel *panel) { generic_exec_sequence(panel, MIPI_SEQ_DISPLAY_ON); + generic_exec_sequence(panel, MIPI_SEQ_BACKLIGHT_ON); return 0; } static int vbt_panel_disable(struct drm_panel *panel) { + generic_exec_sequence(panel, MIPI_SEQ_BACKLIGHT_OFF); generic_exec_sequence(panel, MIPI_SEQ_DISPLAY_OFF); return 0; -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/7] drm/i915/dsi: update reset and power sequences in panel prepare/unprepare hooks
Based on the documentation alone, it's anyone's guess when exactly we should be running these sequences. Add power on/off sequences where they feel logical and update assert/deassert reset. The drm panel hooks don't currently offer us more granularity anyway. v2: update assert/deassert reset as well (Ville) Signed-off-by: Jani Nikula--- drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c index 29156995a265..2c5d14eb7851 100644 --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c @@ -459,6 +459,8 @@ static void generic_exec_sequence(struct drm_panel *panel, enum mipi_seq seq_id) static int vbt_panel_prepare(struct drm_panel *panel) { generic_exec_sequence(panel, MIPI_SEQ_ASSERT_RESET); + generic_exec_sequence(panel, MIPI_SEQ_POWER_ON); + generic_exec_sequence(panel, MIPI_SEQ_DEASSERT_RESET); generic_exec_sequence(panel, MIPI_SEQ_INIT_OTP); return 0; @@ -466,7 +468,8 @@ static int vbt_panel_prepare(struct drm_panel *panel) static int vbt_panel_unprepare(struct drm_panel *panel) { - generic_exec_sequence(panel, MIPI_SEQ_DEASSERT_RESET); + generic_exec_sequence(panel, MIPI_SEQ_ASSERT_RESET); + generic_exec_sequence(panel, MIPI_SEQ_POWER_OFF); return 0; } -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 7/7] drm/i915/dsi: double check element parsing against size if present
Be a little paranoid in case the specs change or something. Signed-off-by: Jani Nikula--- drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c index 24953f9f7e1d..9f279a3d0f74 100644 --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c @@ -441,7 +441,15 @@ static void generic_exec_sequence(struct drm_panel *panel, enum mipi_seq seq_id) operation_size = *data++; if (mipi_elem_exec) { + const u8 *next = data + operation_size; + data = mipi_elem_exec(intel_dsi, data); + + /* Consistency check if we have size. */ + if (operation_size && data != next) { + DRM_ERROR("Inconsistent operation size\n"); + return; + } } else if (operation_size) { /* We have size, skip. */ DRM_DEBUG_KMS("Unsupported MIPI operation byte %u\n", -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/7] drm/i915/dsi: add debug logging to element execution
Just simple breadcrumbs for now. While at it, rename the i2c skip function. Signed-off-by: Jani Nikula--- drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c index a537c71cdcc6..89f77a142521 100644 --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c @@ -126,6 +126,8 @@ static const u8 *mipi_exec_send_packet(struct intel_dsi *intel_dsi, u16 len; enum port port; + DRM_DEBUG_KMS("\n"); + flags = *data++; type = *data++; @@ -199,6 +201,8 @@ static const u8 *mipi_exec_delay(struct intel_dsi *intel_dsi, const u8 *data) { u32 delay = *((const u32 *) data); + DRM_DEBUG_KMS("\n"); + usleep_range(delay, delay + 10); data += 4; @@ -307,6 +311,8 @@ static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data) u8 gpio_source, gpio_index; bool value; + DRM_DEBUG_KMS("\n"); + if (dev_priv->vbt.dsi.seq_version >= 3) data++; @@ -331,8 +337,10 @@ static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data) return data; } -static const u8 *mipi_exec_i2c_skip(struct intel_dsi *intel_dsi, const u8 *data) +static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8 *data) { + DRM_DEBUG_KMS("Skipping I2C element execution\n"); + return data + *(data + 6) + 7; } @@ -342,7 +350,7 @@ static const fn_mipi_elem_exec exec_elem[] = { [MIPI_SEQ_ELEM_SEND_PKT] = mipi_exec_send_packet, [MIPI_SEQ_ELEM_DELAY] = mipi_exec_delay, [MIPI_SEQ_ELEM_GPIO] = mipi_exec_gpio, - [MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c_skip, + [MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c, }; /* -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/7] drm/i915/dsi: add skip functions for spi and pmic elements
In sequence block v3 these are gracefully skipped anyway, but add the functions so we can have some debug breadcrumbs. v2: the pmic block is 15 bytes (Ville) Signed-off-by: Jani Nikula--- drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c index 89f77a142521..29156995a265 100644 --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c @@ -344,6 +344,20 @@ static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8 *data) return data + *(data + 6) + 7; } +static const u8 *mipi_exec_spi(struct intel_dsi *intel_dsi, const u8 *data) +{ + DRM_DEBUG_KMS("Skipping SPI element execution\n"); + + return data + *(data + 5) + 6; +} + +static const u8 *mipi_exec_pmic(struct intel_dsi *intel_dsi, const u8 *data) +{ + DRM_DEBUG_KMS("Skipping PMIC element execution\n"); + + return data + 15; +} + typedef const u8 * (*fn_mipi_elem_exec)(struct intel_dsi *intel_dsi, const u8 *data); static const fn_mipi_elem_exec exec_elem[] = { @@ -351,6 +365,8 @@ static const fn_mipi_elem_exec exec_elem[] = { [MIPI_SEQ_ELEM_DELAY] = mipi_exec_delay, [MIPI_SEQ_ELEM_GPIO] = mipi_exec_gpio, [MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c, + [MIPI_SEQ_ELEM_SPI] = mipi_exec_spi, + [MIPI_SEQ_ELEM_PMIC] = mipi_exec_pmic, }; /* -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/7] drm/i915/dsi: don't debug log "missing" sequences
This is not interesting. They are not "missing", they are just not part of the VBT sequences for the panel. Signed-off-by: Jani Nikula--- drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c index cd154ce6b6c1..a537c71cdcc6 100644 --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c @@ -385,11 +385,8 @@ static void generic_exec_sequence(struct drm_panel *panel, enum mipi_seq seq_id) return; data = dev_priv->vbt.dsi.sequence[seq_id]; - if (!data) { - DRM_DEBUG_KMS("MIPI sequence %d - %s not available\n", - seq_id, sequence_name(seq_id)); + if (!data) return; - } WARN_ON(*data != seq_id); -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/7] drm/i915: clean up dsi sequences
v2 of an old series, addressing issues pointed out by Ville. BR, Jani. Jani Nikula (7): drm/i915/dsi: don't debug log "missing" sequences drm/i915/dsi: add debug logging to element execution drm/i915/dsi: add skip functions for spi and pmic elements drm/i915/dsi: update reset and power sequences in panel prepare/unprepare hooks drm/i915/dsi: run backlight on/off sequences in panel enable/disable hooks drm/i915/bios: log about presence of DSI sequences we do not run drm/i915/dsi: double check element parsing against size if present drivers/gpu/drm/i915/intel_bios.c | 4 +++ drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 48 +- 2 files changed, 45 insertions(+), 7 deletions(-) -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/18] drm/i915: Record space required for request emission
On Mon, Sep 19, 2016 at 01:47:30PM +0300, Joonas Lahtinen wrote: > On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > > @@ -2677,8 +2681,21 @@ static void intel_ring_default_vfuncs(struct > > drm_i915_private *dev_priv, > > engine->reset_hw = reset_ring_common; > > > > engine->emit_request = i9xx_emit_request; > > - if (i915.semaphores) > > + engine->emit_request_sz = i9xx_emit_request_sz; > > + if (i915.semaphores) { > > + int num_rings; > > 'initialized_rings' to differentiate as suggested by Tvrtko too. Tvrtko wasn't referring to this. The point is that we don't know initialized_rings here, just the declared set of rings we think the hardware is supposed to have. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/18] drm/i915: Support asynchronous waits on struct fence from i915_gem_request
On Wed, Sep 14, 2016 at 10:37:18AM +0300, Joonas Lahtinen wrote: > On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > > + array = to_fence_array(fence); > > + for (i = 0; i < array->num_fences; i++) { > > + struct fence *child = array->fences[i]; > > + > > + if (fence_is_i915(child)) > > + ret = i915_gem_request_await_request(req, > > + to_request(child)); > > + else > > + ret = i915_sw_fence_await_dma_fence(>submit, > > + child, 10*HZ, > > + GFP_KERNEL); > > This chunk repeats from above, make it a small > __i915_gem_request_await_fence function. It's not a repeat. If it were, we could just recurse. Except we don't know how deep the fence-array could go. > > + if (ret < 0) > > + return ret; > > How about the failure case when we're half bound, no need to tear down? We submit the partial request that doesn't execute anything more than the context setup. The next request in the timeline with then inherit the context setup from this request. Same rule as everything else handling errors during request construction. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: fix pwm increment setup
== Series Details == Series: drm/i915: fix pwm increment setup URL : https://patchwork.freedesktop.org/series/12636/ State : warning == Summary == Series 12636v1 drm/i915: fix pwm increment setup https://patchwork.freedesktop.org/api/1.0/series/12636/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: dmesg-warn -> PASS (fi-skl-6700k) Test pm_rpm: Subgroup basic-rte: pass -> SKIP (fi-hsw-4770r) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:202 dwarn:0 dfail:0 fail:0 skip:42 fi-hsw-4770k total:244 pass:226 dwarn:0 dfail:0 fail:0 skip:18 fi-hsw-4770r total:244 pass:221 dwarn:0 dfail:0 fail:0 skip:23 fi-ilk-650 total:244 pass:183 dwarn:0 dfail:0 fail:1 skip:60 fi-ivb-3520m total:244 pass:219 dwarn:0 dfail:0 fail:0 skip:25 fi-ivb-3770 total:244 pass:207 dwarn:0 dfail:0 fail:0 skip:37 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:221 dwarn:0 dfail:0 fail:1 skip:22 fi-skl-6700k total:244 pass:219 dwarn:1 dfail:0 fail:0 skip:24 fi-skl-6770hqtotal:244 pass:228 dwarn:1 dfail:0 fail:1 skip:14 fi-snb-2520m total:244 pass:208 dwarn:0 dfail:0 fail:0 skip:36 fi-snb-2600 total:244 pass:207 dwarn:0 dfail:0 fail:0 skip:37 Results at /archive/results/CI_IGT_test/Patchwork_2553/ 0d6fa72a8c18ec6ab4dbabf5202b8d1cad840e04 drm-intel-nightly: 2016y-09m-19d-09h-28m-11s UTC integration manifest 67275e3 drm/i915/backlight: setup backlight pwm alternate increment on backlight enable aeef3b5 drm/i915/backlight: setup and cache pwm alternate increment value ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915 : Restore PWM_GRANULARITY after resume
Hi Shawn, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on v4.8-rc7 next-20160916] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on] [Check https://git-scm.com/docs/git-format-patch for more information] url: https://github.com/0day-ci/linux/commits/Lee-Shawn-C/drm-i915-Restore-PWM_GRANULARITY-after-resume/20160919-180644 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-randconfig-x012-201638 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): In file included from drivers/gpu/drm/i915/intel_drv.h:32:0, from drivers/gpu/drm/i915/intel_panel.c:36: drivers/gpu/drm/i915/intel_panel.c: In function 'lpt_enable_backlight': >> drivers/gpu/drm/i915/intel_panel.c:874:78: error: left shift count >= width >> of type [-Werror=shift-count-overflow] I915_WRITE(SOUTH_CHICKEN2, mul | (panel->backlight.pwm_alternate_increment << LPT_PWM_GRANULARITY)); ^ drivers/gpu/drm/i915/i915_drv.h:3735:83: note: in definition of macro 'I915_WRITE' #define I915_WRITE(reg, val) dev_priv->uncore.funcs.mmio_writel(dev_priv, (reg), (val), true) ^~~ cc1: all warnings being treated as errors vim +874 drivers/gpu/drm/i915/intel_panel.c 868 /* This won't stick until the above enable. */ 869 intel_panel_actually_set_backlight(connector, panel->backlight.level); 870 871 if (HAS_PCH_LPT(dev_priv)) { 872 mul = I915_READ(SOUTH_CHICKEN2); 873 mul &= ~LPT_PWM_GRANULARITY; > 874 I915_WRITE(SOUTH_CHICKEN2, mul | > (panel->backlight.pwm_alternate_increment << LPT_PWM_GRANULARITY)); 875 } else { 876 mul = I915_READ(SOUTH_CHICKEN1); 877 mul &= ~SPT_PWM_GRANULARITY; --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/backlight: setup backlight pwm alternate increment on backlight enable
Hi Shawn, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on v4.8-rc7 next-20160916] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on] [Check https://git-scm.com/docs/git-format-patch for more information] url: https://github.com/0day-ci/linux/commits/Jani-Nikula/drm-i915-backlight-setup-backlight-pwm-alternate-increment-on-backlight-enable/20160919-181342 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-randconfig-x008-201638 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/gpu/drm/i915/intel_panel.c: In function 'lpt_enable_backlight': >> drivers/gpu/drm/i915/intel_panel.c:855:23: error: 'struct ' has >> no member named 'alternate_pwm_increment' if (panel->backlight.alternate_pwm_increment) ^ drivers/gpu/drm/i915/intel_panel.c:862:23: error: 'struct ' has no member named 'alternate_pwm_increment' if (panel->backlight.alternate_pwm_increment) ^ vim +855 drivers/gpu/drm/i915/intel_panel.c 849 pch_ctl1 &= ~BLM_PCH_PWM_ENABLE; 850 I915_WRITE(BLC_PWM_PCH_CTL1, pch_ctl1); 851 } 852 853 if (HAS_PCH_LPT(dev_priv)) { 854 schicken = I915_READ(SOUTH_CHICKEN2); > 855 if (panel->backlight.alternate_pwm_increment) 856 schicken |= LPT_PWM_GRANULARITY; 857 else 858 schicken &= ~LPT_PWM_GRANULARITY; --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/18] drm/i915: Record space required for request emission
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > @@ -1572,6 +1572,8 @@ static int gen8_emit_request(struct > drm_i915_gem_request *request) > return intel_logical_ring_advance(request); > } > > +static const int gen8_emit_request_sz = 6 + WA_TAIL_DWORDS; Could argue these to be #define by current convention. > @@ -1677,6 +1681,7 @@ logical_ring_default_vfuncs(struct intel_engine_cs > *engine) > engine->reset_hw = reset_common_ring; > engine->emit_flush = gen8_emit_flush; > engine->emit_request = gen8_emit_request; > + engine->emit_request_sz = gen8_emit_request_sz; This assignment would then stand out better too, now it looks like a bunch of function assignments. > @@ -2677,8 +2681,21 @@ static void intel_ring_default_vfuncs(struct > drm_i915_private *dev_priv, > engine->reset_hw = reset_ring_common; > > engine->emit_request = i9xx_emit_request; > - if (i915.semaphores) > + engine->emit_request_sz = i9xx_emit_request_sz; > + if (i915.semaphores) { > + int num_rings; 'initialized_rings' to differentiate as suggested by Tvrtko too. > + > engine->emit_request = gen6_sema_emit_request; > + > + num_rings = hweight32(INTEL_INFO(dev_priv)->ring_mask) - 1; > + if (INTEL_GEN(dev_priv) >= 8) { > + engine->emit_request_sz += num_rings * 6; > + } else { > + engine->emit_request_sz += num_rings * 3; > + if (num_rings & 1) > + engine->emit_request_sz++; Please do add a comment explaining this. Reviewed-by: Joonas LahtinenRegards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/18] drm/i915: Introduce a global_seqno for each request
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > @@ -465,8 +466,15 @@ i915_gem_request_await_request(struct > drm_i915_gem_request *to, > return ret < 0 ? ret : 0; > } > > + if (from->global_seqno == 0) { Just use (!from->global_seqno) here too, for consistency. Might be worth adding to the commit message that currently global_seqno is still immediately assigned at creation. Reviewed-by: Joonas LahtinenRegards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/backlight: setup and cache pwm alternate increment value
This will also be needed later on when setting up the alternate increment in backlight enable. Cc: Shawn LeeSigned-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_panel.c | 14 +++--- 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 8fd16adf069b..c3e65e515c9d 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -263,6 +263,7 @@ struct intel_panel { bool enabled; bool combination_mode; /* gen 2/4 only */ bool active_low_pwm; + bool alternate_pwm_increment; /* lpt+ */ /* PWM chip */ bool util_pin_active_low; /* bxt+ */ diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index c10e9b0405e8..8bc43205d6a0 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -1242,10 +1242,10 @@ static u32 bxt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz) */ static u32 spt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz) { - struct drm_i915_private *dev_priv = to_i915(connector->base.dev); + struct intel_panel *panel = >panel; u32 mul; - if (I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY) + if (panel->backlight.alternate_pwm_increment) mul = 128; else mul = 16; @@ -1261,9 +1261,10 @@ static u32 spt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz) static u32 lpt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz) { struct drm_i915_private *dev_priv = to_i915(connector->base.dev); + struct intel_panel *panel = >panel; u32 mul, clock; - if (I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY) + if (panel->backlight.alternate_pwm_increment) mul = 16; else mul = 128; @@ -1414,6 +1415,13 @@ static int lpt_setup_backlight(struct intel_connector *connector, enum pipe unus struct drm_i915_private *dev_priv = to_i915(connector->base.dev); struct intel_panel *panel = >panel; u32 pch_ctl1, pch_ctl2, val; + bool alt; + + if (HAS_PCH_LPT(dev_priv)) + alt = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY; + else + alt = I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY; + panel->backlight.alternate_pwm_increment = alt; pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1); panel->backlight.active_low_pwm = pch_ctl1 & BLM_PCH_POLARITY; -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/backlight: setup backlight pwm alternate increment on backlight enable
From: Shawn LeeBacklight enable is supposed to do a full setup of the backlight. We were missing the PWM alternate increment bit in the south chicken registers on lpt+ pch. This potentially caused a PWM frequency change when the chicken register value was lost e.g. on suspend. v2 by Jani, rebase on the patch caching alt increment Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486 Cc: Cooper Chiou Cc: Wei Shun Chen Cc: Gary C Wang Cc: sta...@vger.kernel.org Signed-off-by: Shawn Lee Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_panel.c | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index 8bc43205d6a0..be4b4d546fd9 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -841,7 +841,7 @@ static void lpt_enable_backlight(struct intel_connector *connector) { struct drm_i915_private *dev_priv = to_i915(connector->base.dev); struct intel_panel *panel = >panel; - u32 pch_ctl1, pch_ctl2; + u32 pch_ctl1, pch_ctl2, schicken; pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1); if (pch_ctl1 & BLM_PCH_PWM_ENABLE) { @@ -850,6 +850,22 @@ static void lpt_enable_backlight(struct intel_connector *connector) I915_WRITE(BLC_PWM_PCH_CTL1, pch_ctl1); } + if (HAS_PCH_LPT(dev_priv)) { + schicken = I915_READ(SOUTH_CHICKEN2); + if (panel->backlight.alternate_pwm_increment) + schicken |= LPT_PWM_GRANULARITY; + else + schicken &= ~LPT_PWM_GRANULARITY; + I915_WRITE(SOUTH_CHICKEN2, schicken); + } else { + schicken = I915_READ(SOUTH_CHICKEN1); + if (panel->backlight.alternate_pwm_increment) + schicken |= SPT_PWM_GRANULARITY; + else + schicken &= ~SPT_PWM_GRANULARITY; + I915_WRITE(SOUTH_CHICKEN1, schicken); + } + pch_ctl2 = panel->backlight.max << 16; I915_WRITE(BLC_PWM_PCH_CTL2, pch_ctl2); -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/2] drm/i915: fix pwm increment setup
CI got confused by all the patches flowing in the earlier thread, so resend. No changes. BR, Jani. Jani Nikula (1): drm/i915/backlight: setup and cache pwm alternate increment value Shawn Lee (1): drm/i915/backlight: setup backlight pwm alternate increment on backlight enable drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_panel.c | 32 2 files changed, 29 insertions(+), 4 deletions(-) -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915 : Restore PWM_GRANULARITY after resume
Hi Shawn, [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on v4.8-rc7 next-20160916] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on] [Check https://git-scm.com/docs/git-format-patch for more information] url: https://github.com/0day-ci/linux/commits/Lee-Shawn-C/drm-i915-Restore-PWM_GRANULARITY-after-resume/20160919-180644 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-randconfig-x008-201638 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All warnings (new ones prefixed by >>): In file included from drivers/gpu/drm/i915/intel_drv.h:32:0, from drivers/gpu/drm/i915/intel_panel.c:36: drivers/gpu/drm/i915/intel_panel.c: In function 'lpt_enable_backlight': >> drivers/gpu/drm/i915/intel_panel.c:874:78: warning: left shift count >= >> width of type [-Wshift-count-overflow] I915_WRITE(SOUTH_CHICKEN2, mul | (panel->backlight.pwm_alternate_increment << LPT_PWM_GRANULARITY)); ^ drivers/gpu/drm/i915/i915_drv.h:3735:83: note: in definition of macro 'I915_WRITE' #define I915_WRITE(reg, val) dev_priv->uncore.funcs.mmio_writel(dev_priv, (reg), (val), true) ^~~ vim +874 drivers/gpu/drm/i915/intel_panel.c 858 pch_ctl1 |= BLM_PCH_POLARITY; 859 860 /* After LPT, override is the default. */ 861 if (HAS_PCH_LPT(dev_priv)) 862 pch_ctl1 |= BLM_PCH_OVERRIDE_ENABLE; 863 864 I915_WRITE(BLC_PWM_PCH_CTL1, pch_ctl1); 865 POSTING_READ(BLC_PWM_PCH_CTL1); 866 I915_WRITE(BLC_PWM_PCH_CTL1, pch_ctl1 | BLM_PCH_PWM_ENABLE); 867 868 /* This won't stick until the above enable. */ 869 intel_panel_actually_set_backlight(connector, panel->backlight.level); 870 871 if (HAS_PCH_LPT(dev_priv)) { 872 mul = I915_READ(SOUTH_CHICKEN2); 873 mul &= ~LPT_PWM_GRANULARITY; > 874 I915_WRITE(SOUTH_CHICKEN2, mul | > (panel->backlight.pwm_alternate_increment << LPT_PWM_GRANULARITY)); 875 } else { 876 mul = I915_READ(SOUTH_CHICKEN1); 877 mul &= ~SPT_PWM_GRANULARITY; 878 I915_WRITE(SOUTH_CHICKEN1, mul | (panel->backlight.pwm_alternate_increment << SPT_PWM_GRANULARITY)); 879 } 880 } 881 882 static void pch_enable_backlight(struct intel_connector *connector) --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915 : Restore PWM_GRANULARITY after resume (rev3)
== Series Details == Series: drm/i915 : Restore PWM_GRANULARITY after resume (rev3) URL : https://patchwork.freedesktop.org/series/12165/ State : success == Summary == Series 12165v3 drm/i915 : Restore PWM_GRANULARITY after resume https://patchwork.freedesktop.org/api/1.0/series/12165/revisions/3/mbox/ Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: dmesg-warn -> PASS (fi-skl-6700k) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:202 dwarn:0 dfail:0 fail:0 skip:42 fi-byt-n2820 total:244 pass:208 dwarn:0 dfail:0 fail:1 skip:35 fi-hsw-4770k total:244 pass:226 dwarn:0 dfail:0 fail:0 skip:18 fi-hsw-4770r total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ilk-650 total:244 pass:183 dwarn:0 dfail:0 fail:1 skip:60 fi-ivb-3520m total:244 pass:219 dwarn:0 dfail:0 fail:0 skip:25 fi-ivb-3770 total:244 pass:207 dwarn:0 dfail:0 fail:0 skip:37 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:221 dwarn:0 dfail:0 fail:1 skip:22 fi-skl-6700k total:244 pass:219 dwarn:1 dfail:0 fail:0 skip:24 fi-skl-6770hqtotal:244 pass:228 dwarn:1 dfail:0 fail:1 skip:14 fi-snb-2520m total:244 pass:208 dwarn:0 dfail:0 fail:0 skip:36 fi-snb-2600 total:244 pass:207 dwarn:0 dfail:0 fail:0 skip:37 Results at /archive/results/CI_IGT_test/Patchwork_2552/ 0d6fa72a8c18ec6ab4dbabf5202b8d1cad840e04 drm-intel-nightly: 2016y-09m-19d-09h-28m-11s UTC integration manifest 887b9f7 drm/i915 : Restore PWM_GRANULARITY after resume ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915 : Restore PWM_GRANULARITY after resume
Understood. Thanks! -Original Message- From: Nikula, Jani Sent: Monday, September 19, 2016 5:43 PM To: Lee, Shawn C; intel-gfx@lists.freedesktop.org Cc: Lee, Shawn C Subject: Re: [PATCH] drm/i915 : Restore PWM_GRANULARITY after resume On Mon, 19 Sep 2016, "Lee, Shawn C" wrote: > From: "Lee, Shawn C" > > SPT_PWM_GRANULARITY (SOUTH_CHICKEN1, bit 0) controls the granularity > (minimum increment) of the PWM backlight control counter. PWM > frequency adjustment on 128 clock increments when this bit was 1. And > 16 clock increments when it was 0. > > PWM frequency multiple octuple (from 200Hz to 1.6KHz) due to > SPT_PWM_GRANULARITY was clear to 0 after S3. This patch save > SOUTH_CHICKEN1 register value before suspend. And will restore it > after i915 resume. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486 Shawn, I already updated the patch. Perhaps I jumped the gun but I was expecting an update and didn't get one and wanted to move this forward. That patch still has your authorship [1]. This one still has issues. BR, Jani. [1] http://patchwork.freedesktop.org/patch/msgid/1474273457-31680-2-git-send-email-jani.nik...@intel.com > > Cc: Jani Nikula > Reviewed-by: Cooper Chiou > Reviewed-by: Wei Shun Chen > Reviewed-by: Gary C Wang > Signed-off-by: Shawn Lee > --- > drivers/gpu/drm/i915/intel_drv.h |1 + > drivers/gpu/drm/i915/intel_panel.c | 30 -- > 2 files changed, 29 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_drv.h > b/drivers/gpu/drm/i915/intel_drv.h > index 570a7ca..c4bc690 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_drv.h > @@ -256,6 +256,7 @@ struct intel_panel { > u32 level; > u32 min; > u32 max; > + bool pwm_alternate_increment; > bool enabled; > bool combination_mode; /* gen 2/4 only */ > bool active_low_pwm; > diff --git a/drivers/gpu/drm/i915/intel_panel.c > b/drivers/gpu/drm/i915/intel_panel.c > index c10e9b0..6f8469b 100644 > --- a/drivers/gpu/drm/i915/intel_panel.c > +++ b/drivers/gpu/drm/i915/intel_panel.c > @@ -841,7 +841,7 @@ static void lpt_enable_backlight(struct > intel_connector *connector) { > struct drm_i915_private *dev_priv = to_i915(connector->base.dev); > struct intel_panel *panel = >panel; > - u32 pch_ctl1, pch_ctl2; > + u32 pch_ctl1, pch_ctl2, mul; > > pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1); > if (pch_ctl1 & BLM_PCH_PWM_ENABLE) { @@ -867,6 +867,22 @@ static > void lpt_enable_backlight(struct intel_connector *connector) > > /* This won't stick until the above enable. */ > intel_panel_actually_set_backlight(connector, > panel->backlight.level); > + > + if (HAS_PCH_LPT(dev_priv)) { > + mul = I915_READ(SOUTH_CHICKEN2); > + if (panel->backlight.pwm_alternate_increment) > + mul |= LPT_PWM_GRANULARITY; > + else > + mul &= ~LPT_PWM_GRANULARITY; > + I915_WRITE(SOUTH_CHICKEN2, mul); > + } else { > + mul = I915_READ(SOUTH_CHICKEN1); > + if (panel->backlight.pwm_alternate_increment) > + mul |= SPT_PWM_GRANULARITY; > + else > + mul &= ~SPT_PWM_GRANULARITY; > + I915_WRITE(SOUTH_CHICKEN1, mul); > + } > } > > static void pch_enable_backlight(struct intel_connector *connector) > @@ -1413,7 +1429,7 @@ static int lpt_setup_backlight(struct > intel_connector *connector, enum pipe unus { > struct drm_i915_private *dev_priv = to_i915(connector->base.dev); > struct intel_panel *panel = >panel; > - u32 pch_ctl1, pch_ctl2, val; > + u32 pch_ctl1, pch_ctl2, val, mul; > > pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1); > panel->backlight.active_low_pwm = pch_ctl1 & BLM_PCH_POLARITY; @@ > -1436,6 +1452,16 @@ static int lpt_setup_backlight(struct > intel_connector *connector, enum pipe unus > > panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE; > > + if (HAS_PCH_LPT(dev_priv)) > + mul = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY; > + else > + mul = I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY; > + > + if ( mul ) > + panel->backlight.pwm_alternate_increment = true; > + else > + panel->backlight.pwm_alternate_increment = false; > + > return 0; > } -- 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: [Intel-gfx] [PATCH v4] drm/i915/skl: New ddb allocation algorithm
Op 14-09-16 om 14:36 schreef Mahesh Kumar: > Hi, > There was an issue with transition WM, it was getting enabled & causing fifo > underrun. > I fixed the condition, After that tested kms_plane & not getting any underrun. > Please let me know if you see any other issue. > > Regards, > -Mahesh > > On Tuesday 13 September 2016 06:10 PM, Maarten Lankhorst wrote: >> Op 13-09-16 om 14:15 schreef Kumar, Mahesh: >>> From: Mahesh Kumar>>> >>> This patch implements new DDB allocation algorithm as per HW team >>> suggestion. This algo takecare of scenario where we allocate less DDB >>> for the planes with lower relative pixel rate, but they require more DDB >>> to work. >>> It also takes care of enabling same watermark level for each >>> plane, for efficient power saving. >>> >>> Changes since v1: >>> - Rebase on top of Paulo's patch series >>> >>> Changes since v2: >>> - Fix the for loop condition to enable WM >>> >>> Signed-off-by: Mahesh Kumar >> I'm still getting underrun issues when running the entire patch series >> against kms_atomic_transition and kms_plane. >> Can you confirm? >> >> ~Maarten > Found it.. During the test run: # cat /sys/kernel/debug/dri/0/i915_ddb_info Start EndSize Pipe A Plane1 0 0 0 Plane2 30 890 860 Cursor860 892 32 Pretty sure the start value here is bogus, and plane2 wm's end up overlapping with cursor. ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915 : Restore PWM_GRANULARITY after resume
On Mon, 19 Sep 2016, "Lee, Shawn C"wrote: > From: "Lee, Shawn C" > > SPT_PWM_GRANULARITY (SOUTH_CHICKEN1, bit 0) controls the granularity > (minimum increment) of the PWM backlight control counter. PWM frequency > adjustment on 128 clock increments when this bit was 1. And 16 clock > increments when it was 0. > > PWM frequency multiple octuple (from 200Hz to 1.6KHz) due to > SPT_PWM_GRANULARITY was clear to 0 after S3. This patch save > SOUTH_CHICKEN1 register value before suspend. And will restore > it after i915 resume. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486 Shawn, I already updated the patch. Perhaps I jumped the gun but I was expecting an update and didn't get one and wanted to move this forward. That patch still has your authorship [1]. This one still has issues. BR, Jani. [1] http://patchwork.freedesktop.org/patch/msgid/1474273457-31680-2-git-send-email-jani.nik...@intel.com > > Cc: Jani Nikula > Reviewed-by: Cooper Chiou > Reviewed-by: Wei Shun Chen > Reviewed-by: Gary C Wang > Signed-off-by: Shawn Lee > --- > drivers/gpu/drm/i915/intel_drv.h |1 + > drivers/gpu/drm/i915/intel_panel.c | 30 -- > 2 files changed, 29 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_drv.h > b/drivers/gpu/drm/i915/intel_drv.h > index 570a7ca..c4bc690 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_drv.h > @@ -256,6 +256,7 @@ struct intel_panel { > u32 level; > u32 min; > u32 max; > + bool pwm_alternate_increment; > bool enabled; > bool combination_mode; /* gen 2/4 only */ > bool active_low_pwm; > diff --git a/drivers/gpu/drm/i915/intel_panel.c > b/drivers/gpu/drm/i915/intel_panel.c > index c10e9b0..6f8469b 100644 > --- a/drivers/gpu/drm/i915/intel_panel.c > +++ b/drivers/gpu/drm/i915/intel_panel.c > @@ -841,7 +841,7 @@ static void lpt_enable_backlight(struct intel_connector > *connector) > { > struct drm_i915_private *dev_priv = to_i915(connector->base.dev); > struct intel_panel *panel = >panel; > - u32 pch_ctl1, pch_ctl2; > + u32 pch_ctl1, pch_ctl2, mul; > > pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1); > if (pch_ctl1 & BLM_PCH_PWM_ENABLE) { > @@ -867,6 +867,22 @@ static void lpt_enable_backlight(struct intel_connector > *connector) > > /* This won't stick until the above enable. */ > intel_panel_actually_set_backlight(connector, panel->backlight.level); > + > + if (HAS_PCH_LPT(dev_priv)) { > + mul = I915_READ(SOUTH_CHICKEN2); > + if (panel->backlight.pwm_alternate_increment) > + mul |= LPT_PWM_GRANULARITY; > + else > + mul &= ~LPT_PWM_GRANULARITY; > + I915_WRITE(SOUTH_CHICKEN2, mul); > + } else { > + mul = I915_READ(SOUTH_CHICKEN1); > + if (panel->backlight.pwm_alternate_increment) > + mul |= SPT_PWM_GRANULARITY; > + else > + mul &= ~SPT_PWM_GRANULARITY; > + I915_WRITE(SOUTH_CHICKEN1, mul); > + } > } > > static void pch_enable_backlight(struct intel_connector *connector) > @@ -1413,7 +1429,7 @@ static int lpt_setup_backlight(struct intel_connector > *connector, enum pipe unus > { > struct drm_i915_private *dev_priv = to_i915(connector->base.dev); > struct intel_panel *panel = >panel; > - u32 pch_ctl1, pch_ctl2, val; > + u32 pch_ctl1, pch_ctl2, val, mul; > > pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1); > panel->backlight.active_low_pwm = pch_ctl1 & BLM_PCH_POLARITY; > @@ -1436,6 +1452,16 @@ static int lpt_setup_backlight(struct intel_connector > *connector, enum pipe unus > > panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE; > > + if (HAS_PCH_LPT(dev_priv)) > + mul = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY; > + else > + mul = I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY; > + > + if ( mul ) > + panel->backlight.pwm_alternate_increment = true; > + else > + panel->backlight.pwm_alternate_increment = false; > + > return 0; > } -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915 : Restore PWM_GRANULARITY after resume
From: "Lee, Shawn C"SPT_PWM_GRANULARITY (SOUTH_CHICKEN1, bit 0) controls the granularity (minimum increment) of the PWM backlight control counter. PWM frequency adjustment on 128 clock increments when this bit was 1. And 16 clock increments when it was 0. PWM frequency multiple octuple (from 200Hz to 1.6KHz) due to SPT_PWM_GRANULARITY was clear to 0 after S3. This patch save SOUTH_CHICKEN1 register value before suspend. And will restore it after i915 resume. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486 Cc: Jani Nikula Reviewed-by: Cooper Chiou Reviewed-by: Wei Shun Chen Reviewed-by: Gary C Wang Signed-off-by: Shawn Lee --- drivers/gpu/drm/i915/intel_drv.h |1 + drivers/gpu/drm/i915/intel_panel.c | 30 -- 2 files changed, 29 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 570a7ca..c4bc690 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -256,6 +256,7 @@ struct intel_panel { u32 level; u32 min; u32 max; + bool pwm_alternate_increment; bool enabled; bool combination_mode; /* gen 2/4 only */ bool active_low_pwm; diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index c10e9b0..6f8469b 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -841,7 +841,7 @@ static void lpt_enable_backlight(struct intel_connector *connector) { struct drm_i915_private *dev_priv = to_i915(connector->base.dev); struct intel_panel *panel = >panel; - u32 pch_ctl1, pch_ctl2; + u32 pch_ctl1, pch_ctl2, mul; pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1); if (pch_ctl1 & BLM_PCH_PWM_ENABLE) { @@ -867,6 +867,22 @@ static void lpt_enable_backlight(struct intel_connector *connector) /* This won't stick until the above enable. */ intel_panel_actually_set_backlight(connector, panel->backlight.level); + + if (HAS_PCH_LPT(dev_priv)) { + mul = I915_READ(SOUTH_CHICKEN2); + if (panel->backlight.pwm_alternate_increment) + mul |= LPT_PWM_GRANULARITY; + else + mul &= ~LPT_PWM_GRANULARITY; + I915_WRITE(SOUTH_CHICKEN2, mul); + } else { + mul = I915_READ(SOUTH_CHICKEN1); + if (panel->backlight.pwm_alternate_increment) + mul |= SPT_PWM_GRANULARITY; + else + mul &= ~SPT_PWM_GRANULARITY; + I915_WRITE(SOUTH_CHICKEN1, mul); + } } static void pch_enable_backlight(struct intel_connector *connector) @@ -1413,7 +1429,7 @@ static int lpt_setup_backlight(struct intel_connector *connector, enum pipe unus { struct drm_i915_private *dev_priv = to_i915(connector->base.dev); struct intel_panel *panel = >panel; - u32 pch_ctl1, pch_ctl2, val; + u32 pch_ctl1, pch_ctl2, val, mul; pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1); panel->backlight.active_low_pwm = pch_ctl1 & BLM_PCH_POLARITY; @@ -1436,6 +1452,16 @@ static int lpt_setup_backlight(struct intel_connector *connector, enum pipe unus panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE; + if (HAS_PCH_LPT(dev_priv)) + mul = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY; + else + mul = I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY; + + if ( mul ) + panel->backlight.pwm_alternate_increment = true; + else + panel->backlight.pwm_alternate_increment = false; + return 0; } -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/backlight: setup and cache pwm alternate increment value
On Mon, 19 Sep 2016, "Lee, Shawn C"wrote: > PWM was enabled in bios. i915 driver will save max duty to > panel->backlight.max. > So *_hz_to_pwm will not be called if backlight.max not zero. And what difference does it make? BR, Jani. > > pch_ctl2 = I915_READ(BLC_PWM_PCH_CTL2); > panel->backlight.max = pch_ctl2 >> 16; > > if (!panel->backlight.max) > panel->backlight.max = get_backlight_max_vbt(connector); > > -Original Message- > From: Nikula, Jani > Sent: Monday, September 19, 2016 4:24 PM > To: intel-gfx@lists.freedesktop.org > Cc: Nikula, Jani ; Lee, Shawn C > Subject: [PATCH v2 1/2] drm/i915/backlight: setup and cache pwm alternate > increment value > > This will also be needed later on when setting up the alternate increment in > backlight enable. > > Cc: Shawn Lee > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_drv.h | 1 + > drivers/gpu/drm/i915/intel_panel.c | 14 +++--- > 2 files changed, 12 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_drv.h > b/drivers/gpu/drm/i915/intel_drv.h > index 8fd16adf069b..c3e65e515c9d 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_drv.h > @@ -263,6 +263,7 @@ struct intel_panel { > bool enabled; > bool combination_mode; /* gen 2/4 only */ > bool active_low_pwm; > + bool alternate_pwm_increment; /* lpt+ */ > > /* PWM chip */ > bool util_pin_active_low; /* bxt+ */ > diff --git a/drivers/gpu/drm/i915/intel_panel.c > b/drivers/gpu/drm/i915/intel_panel.c > index c10e9b0405e8..8bc43205d6a0 100644 > --- a/drivers/gpu/drm/i915/intel_panel.c > +++ b/drivers/gpu/drm/i915/intel_panel.c > @@ -1242,10 +1242,10 @@ static u32 bxt_hz_to_pwm(struct intel_connector > *connector, u32 pwm_freq_hz) > */ > static u32 spt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz) > { > - struct drm_i915_private *dev_priv = to_i915(connector->base.dev); > + struct intel_panel *panel = >panel; > u32 mul; > > - if (I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY) > + if (panel->backlight.alternate_pwm_increment) > mul = 128; > else > mul = 16; > @@ -1261,9 +1261,10 @@ static u32 spt_hz_to_pwm(struct intel_connector > *connector, u32 pwm_freq_hz) static u32 lpt_hz_to_pwm(struct intel_connector > *connector, u32 pwm_freq_hz) { > struct drm_i915_private *dev_priv = to_i915(connector->base.dev); > + struct intel_panel *panel = >panel; > u32 mul, clock; > > - if (I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY) > + if (panel->backlight.alternate_pwm_increment) > mul = 16; > else > mul = 128; > @@ -1414,6 +1415,13 @@ static int lpt_setup_backlight(struct intel_connector > *connector, enum pipe unus > struct drm_i915_private *dev_priv = to_i915(connector->base.dev); > struct intel_panel *panel = >panel; > u32 pch_ctl1, pch_ctl2, val; > + bool alt; > + > + if (HAS_PCH_LPT(dev_priv)) > + alt = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY; > + else > + alt = I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY; > + panel->backlight.alternate_pwm_increment = alt; > > pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1); > panel->backlight.active_low_pwm = pch_ctl1 & BLM_PCH_POLARITY; > -- > 2.1.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: [Intel-gfx] [PATCH v2 1/2] drm/i915/backlight: setup and cache pwm alternate increment value
PWM was enabled in bios. i915 driver will save max duty to panel->backlight.max. So *_hz_to_pwm will not be called if backlight.max not zero. pch_ctl2 = I915_READ(BLC_PWM_PCH_CTL2); panel->backlight.max = pch_ctl2 >> 16; if (!panel->backlight.max) panel->backlight.max = get_backlight_max_vbt(connector); -Original Message- From: Nikula, Jani Sent: Monday, September 19, 2016 4:24 PM To: intel-gfx@lists.freedesktop.org Cc: Nikula, Jani; Lee, Shawn C Subject: [PATCH v2 1/2] drm/i915/backlight: setup and cache pwm alternate increment value This will also be needed later on when setting up the alternate increment in backlight enable. Cc: Shawn Lee Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_panel.c | 14 +++--- 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 8fd16adf069b..c3e65e515c9d 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -263,6 +263,7 @@ struct intel_panel { bool enabled; bool combination_mode; /* gen 2/4 only */ bool active_low_pwm; + bool alternate_pwm_increment; /* lpt+ */ /* PWM chip */ bool util_pin_active_low; /* bxt+ */ diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index c10e9b0405e8..8bc43205d6a0 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -1242,10 +1242,10 @@ static u32 bxt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz) */ static u32 spt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz) { - struct drm_i915_private *dev_priv = to_i915(connector->base.dev); + struct intel_panel *panel = >panel; u32 mul; - if (I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY) + if (panel->backlight.alternate_pwm_increment) mul = 128; else mul = 16; @@ -1261,9 +1261,10 @@ static u32 spt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz) static u32 lpt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz) { struct drm_i915_private *dev_priv = to_i915(connector->base.dev); + struct intel_panel *panel = >panel; u32 mul, clock; - if (I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY) + if (panel->backlight.alternate_pwm_increment) mul = 16; else mul = 128; @@ -1414,6 +1415,13 @@ static int lpt_setup_backlight(struct intel_connector *connector, enum pipe unus struct drm_i915_private *dev_priv = to_i915(connector->base.dev); struct intel_panel *panel = >panel; u32 pch_ctl1, pch_ctl2, val; + bool alt; + + if (HAS_PCH_LPT(dev_priv)) + alt = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY; + else + alt = I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY; + panel->backlight.alternate_pwm_increment = alt; pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1); panel->backlight.active_low_pwm = pch_ctl1 & BLM_PCH_POLARITY; -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-next
Hi Dave, drm-intel-next-2016-09-19: - refactor the sseu code (Imre) - refine guc dmesg output (Dave Gordon) - more vgpu work - more skl wm fixes (Lyude) - refactor dpll code in prep for upfront link training (Jim Bride et al) - consolidate all platform feature checks into intel_device_info (Carlos Santa) - refactor elsp/execlist submission as prep for re-submission after hang recovery and eventually scheduling (Chris Wilson) - allow synchronous gpu reset handling, to remove tricky/impossible/fragile error recovery code (Chris Wilson) - prep work for nonblocking (execlist) submission, using fences to track depencies and drive elsp submission (Chris Wilson) - partial error recover/resubmission of non-guilty batches after hangs (Chris Wilson) - full dma-buf implicit fencing support (Chris Wilson) - dp link training fixes (Jim, Dhinkaran, Navare, ...) - obey dp branch device pixel rate/bpc/clock limits (Mika Kahola), needed for many vga dongles - bunch of small cleanups and polish all over, as usual drm-intel-next-2016-09-02: - skl wm fixes (Lyude, Matt, Maarten) - cleanup of kdev/drm_dev/i915_dev handling (David Weinehall) - make (most) encoders take advantage of atomic states (Maarten) - MMAP_GTT_VERSION driver param to announce that gtt mmaps are reliable (Chris) - allow contexts on all rings (Chris) - a few fixes (around diagnostic messages) to make BAT less noisy - misc fixes and cleanups all over, as usual Since you're on vacation I figured I'll just combine the pull from before my vacations, and the final 4.9 feature pile I just assembled. With this 4.9 is now for Jani. Tomeu just pinged me about the crc drm patches, and David made some noises about cleanup patches he has pending, so I guess there'll be a few stragglers for 4.9 for -misc still. But if Linus tags final 4.8 (against excpectations) this w/e already I'll postpone them I think. Cheers, Daniel The following changes since commit d5d0804f8f6d0c89913f6a2de5348adef8ec33e4: drm/i915: Update DRIVER_DATE to 20160822 (2016-08-22 08:35:48 +0200) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2016-09-19 for you to fetch changes up to 6e05f3d3b9298a56d6f1acb474a75cf14a17c31e: drm/i915: Update DRIVER_DATE to 20160919 (2016-09-19 09:26:08 +0200) - refactor the sseu code (Imre) - refine guc dmesg output (Dave Gordon) - more vgpu work - more skl wm fixes (Lyude) - refactor dpll code in prep for upfront link training (Jim Bride et al) - consolidate all platform feature checks into intel_device_info (Carlos Santa) - refactor elsp/execlist submission as prep for re-submission after hang recovery and eventually scheduling (Chris Wilson) - allow synchronous gpu reset handling, to remove tricky/impossible/fragile error recovery code (Chris Wilson) - prep work for nonblocking (execlist) submission, using fences to track depencies and drive elsp submission (Chris Wilson) - partial error recover/resubmission of non-guilty batches after hangs (Chris Wilson) - full dma-buf implicit fencing support (Chris Wilson) - dp link training fixes (Jim, Dhinkaran, Navare, ...) - obey dp branch device pixel rate/bpc/clock limits (Mika Kahola), needed for many vga dongles - bunch of small cleanups and polish all over, as usual Ander Conselvan de Oliveira (2): drm/i915: Don't pass crtc_state to intel_dp_set_link_params() drm/i915: Remove ddi_pll_sel from intel_crtc_state Carlos Santa (22): drm/i915: Move HAS_PSR definition to platform struct definition drm/i915: Remove .is_mobile field from platform struct drm/i915: Introduce GEN6_FEATURES for device info drm/i915: Move HAS_RUNTIME_PM definition to platform drm/i915: Remove runtime PM for SNB drm/i915: Get rid of HAS_CORE_RING_FREQ drm/i915 Move HAS_CSR definition to platform definition drm/i915: Move HAS_RESOURCE_STREAMER definition to platform definition drm/i915: Move HAS_RC6 definition to platform definition drm/i915: Move HAS_RC6p definition to platform definition drm/i915: Move HAS_DP_MST definition to platform definition drm/i915: Introduce GEN5_FEATURES for device info drm/i915: Move HAS_GMBUS_IRQ definition to platform definition drm/i915: Introduce GEN4_FEATURES for device info drm/i915: Introduce GEN3_FEATURES for device info drm/i915: Introduce GEN2_FEATURES for device info drm/i915: Move HAS_HW_CONTEXTS definition to platform drm/i915: Move HAS_LOGICAL_RING_CONTEXTS definition to platform drm/i915: Move HAS_L3_DPF definition to platform definition drm/i915: Move HAS_GMCH_DISPLAY definition to platform drm/i915: Make HWS_NEEDS_PHYSICAL the exception drm/i915: Move HAS_GUC definition to platform definition Chris Wilson (46): drm/i915: Restore debugfs
[Intel-gfx] Updated drm-intel-testing
Hi all, New -testing cycle with cool stuff: - refactor the sseu code (Imre) - refine guc dmesg output (Dave Gordon) - more vgpu work - more skl wm fixes (Lyude) - refactor dpll code in prep for upfront link training (Jim Bride et al) - consolidate all platform feature checks into intel_device_info (Carlos Santa) - refactor elsp/execlist submission as prep for re-submission after hang recovery and eventually scheduling (Chris Wilson) - allow synchronous gpu reset handling, to remove tricky/impossible/fragile error recovery code (Chris Wilson) - prep work for nonblocking (execlist) submission, using fences to track depencies and drive elsp submission (Chris Wilson) - partial error recover/resubmission of non-guilty batches after hangs (Chris Wilson) - full dma-buf implicit fencing support (Chris Wilson) - dp link training fixes (Jim, Dhinkaran, Navare, ...) - obey dp branch device pixel rate/bpc/clock limits (Mika Kahola), needed for many vga dongles - bunch of small cleanups and polish all over, as usual Happy testing! Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/18] drm/i915: Wait first for submission, before waiting for request completion
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > +static long > +__i915_request_wait_for_submit(struct drm_i915_gem_request *request, > + unsigned int flags, > + long timeout) > +{ > + const int state = flags & I915_WAIT_INTERRUPTIBLE ? > + TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE; const bool wait_locked = flags & I915_WAIT_LOCKED; Reviewed-by: Joonas LahtinenRegards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915 : Restore PWM_GRANULARITY after resume
On Mon, 19 Sep 2016, "Lee, Shawn C"wrote: > + if (HAS_PCH_LPT(dev_priv)) { > + mul = I915_READ(SOUTH_CHICKEN2); > + mul &= ~LPT_PWM_GRANULARITY; > + I915_WRITE(SOUTH_CHICKEN2, mul | > (panel->backlight.pwm_alternate_increment << LPT_PWM_GRANULARITY)); > + } else { > + mul = I915_READ(SOUTH_CHICKEN1); > + mul &= ~SPT_PWM_GRANULARITY; > + I915_WRITE(SOUTH_CHICKEN1, mul | > (panel->backlight.pwm_alternate_increment << SPT_PWM_GRANULARITY)); > + } Also, both of the shifts are wrong here. The *_PWM_GRANULARITY macros already contain the shifts. 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: [Intel-gfx] [PATCH 1/2] drm/i915: Only shrink the unbound objects during freeze
On Mon, Sep 19, 2016 at 11:31:37AM +0300, Joonas Lahtinen wrote: > On pe, 2016-09-16 at 20:23 +0100, Chris Wilson wrote: > > int i915_gem_freeze_late(struct drm_i915_private *dev_priv) > > { > > > struct drm_i915_gem_object *obj; > > @@ -4692,7 +4705,8 @@ int i915_gem_freeze_late(struct drm_i915_private > > *dev_priv) > > > * the objects as well. > > > */ > > > > > - i915_gem_shrink_all(dev_priv); > > + mutex_lock(_priv->drm.struct_mutex); > > Previously the shrinking here was without a mutex. And the new > shrinking during _freeze is also mutex protected, any specific reason? Silencing lockdep. We know we are single threaded here, but lockdep doesn't. This version of i915_gem_shrink() doesn't automagically take the struct_mutex (later versions do). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915 : Restore PWM_GRANULARITY after resume
On Mon, 19 Sep 2016, "Lee, Shawn C"wrote: > From: "Lee, Shawn C" > > SPT_PWM_GRANULARITY (SOUTH_CHICKEN1, bit 0) controls the granularity > (minimum increment) of the PWM backlight control counter. PWM frequency > adjustment on 128 clock increments when this bit was 1. And 16 clock > increments when it was 0. > > PWM frequency multiple octuple (from 200Hz to 1.6KHz) due to > SPT_PWM_GRANULARITY was clear to 0 after S3. This patch save > SOUTH_CHICKEN1 register value before suspend. And will restore > it after i915 resume. Sorry, I updated the patch already https://patchwork.freedesktop.org/patch/28/ https://patchwork.freedesktop.org/patch/29/ BR, Jani. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486 > > Cc: Jani Nikula > Reviewed-by: Cooper Chiou > Reviewed-by: Wei Shun Chen > Reviewed-by: Gary C Wang > Signed-off-by: Shawn Lee > --- > drivers/gpu/drm/i915/intel_drv.h |1 + > drivers/gpu/drm/i915/intel_panel.c | 24 ++-- > 2 files changed, 23 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_drv.h > b/drivers/gpu/drm/i915/intel_drv.h > index 570a7ca..c4bc690 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_drv.h > @@ -256,6 +256,7 @@ struct intel_panel { > u32 level; > u32 min; > u32 max; > + bool pwm_alternate_increment; > bool enabled; > bool combination_mode; /* gen 2/4 only */ > bool active_low_pwm; > diff --git a/drivers/gpu/drm/i915/intel_panel.c > b/drivers/gpu/drm/i915/intel_panel.c > index c10e9b0..e1dc6bd 100644 > --- a/drivers/gpu/drm/i915/intel_panel.c > +++ b/drivers/gpu/drm/i915/intel_panel.c > @@ -841,7 +841,7 @@ static void lpt_enable_backlight(struct intel_connector > *connector) > { > struct drm_i915_private *dev_priv = to_i915(connector->base.dev); > struct intel_panel *panel = >panel; > - u32 pch_ctl1, pch_ctl2; > + u32 pch_ctl1, pch_ctl2, mul; > > pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1); > if (pch_ctl1 & BLM_PCH_PWM_ENABLE) { > @@ -867,6 +867,16 @@ static void lpt_enable_backlight(struct intel_connector > *connector) > > /* This won't stick until the above enable. */ > intel_panel_actually_set_backlight(connector, panel->backlight.level); > + > + if (HAS_PCH_LPT(dev_priv)) { > + mul = I915_READ(SOUTH_CHICKEN2); > + mul &= ~LPT_PWM_GRANULARITY; > + I915_WRITE(SOUTH_CHICKEN2, mul | > (panel->backlight.pwm_alternate_increment << LPT_PWM_GRANULARITY)); > + } else { > + mul = I915_READ(SOUTH_CHICKEN1); > + mul &= ~SPT_PWM_GRANULARITY; > + I915_WRITE(SOUTH_CHICKEN1, mul | > (panel->backlight.pwm_alternate_increment << SPT_PWM_GRANULARITY)); > + } > } > > static void pch_enable_backlight(struct intel_connector *connector) > @@ -1413,7 +1423,7 @@ static int lpt_setup_backlight(struct intel_connector > *connector, enum pipe unus > { > struct drm_i915_private *dev_priv = to_i915(connector->base.dev); > struct intel_panel *panel = >panel; > - u32 pch_ctl1, pch_ctl2, val; > + u32 pch_ctl1, pch_ctl2, val, mul; > > pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1); > panel->backlight.active_low_pwm = pch_ctl1 & BLM_PCH_POLARITY; > @@ -1436,6 +1446,16 @@ static int lpt_setup_backlight(struct intel_connector > *connector, enum pipe unus > > panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE; > > + if (HAS_PCH_LPT(dev_priv)) > + mul = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY; > + else > + mul = I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY; > + > + if ( mul ) > + panel->backlight.pwm_alternate_increment = true; > + else > + panel->backlight.pwm_alternate_increment = false; > + > return 0; > } -- 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: [Intel-gfx] [PATCH v2 2/2] drm/i915/backlight: setup backlight pwm alternate increment on backlight enable
On Mon, 19 Sep 2016, Jani Nikulawrote: > From: Shawn Lee > > Backlight enable is supposed to do a full setup of the backlight. We > were missing the PWM alternate increment bit in the south chicken > registers on lpt+ pch. This potentially caused a PWM frequency change > when the chicken register value was lost e.g. on suspend. > > v2 by Jani, rebase on the patch caching alt increment > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486 There's a good chance this'll also fix a bug long ago deemed NOTOURBUG... Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67454 > Cc: Cooper Chiou > Cc: Wei Shun Chen > Cc: Gary C Wang > Cc: sta...@vger.kernel.org > Signed-off-by: Shawn Lee > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_panel.c | 18 +- > 1 file changed, 17 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_panel.c > b/drivers/gpu/drm/i915/intel_panel.c > index 8bc43205d6a0..be4b4d546fd9 100644 > --- a/drivers/gpu/drm/i915/intel_panel.c > +++ b/drivers/gpu/drm/i915/intel_panel.c > @@ -841,7 +841,7 @@ static void lpt_enable_backlight(struct intel_connector > *connector) > { > struct drm_i915_private *dev_priv = to_i915(connector->base.dev); > struct intel_panel *panel = >panel; > - u32 pch_ctl1, pch_ctl2; > + u32 pch_ctl1, pch_ctl2, schicken; > > pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1); > if (pch_ctl1 & BLM_PCH_PWM_ENABLE) { > @@ -850,6 +850,22 @@ static void lpt_enable_backlight(struct intel_connector > *connector) > I915_WRITE(BLC_PWM_PCH_CTL1, pch_ctl1); > } > > + if (HAS_PCH_LPT(dev_priv)) { > + schicken = I915_READ(SOUTH_CHICKEN2); > + if (panel->backlight.alternate_pwm_increment) > + schicken |= LPT_PWM_GRANULARITY; > + else > + schicken &= ~LPT_PWM_GRANULARITY; > + I915_WRITE(SOUTH_CHICKEN2, schicken); > + } else { > + schicken = I915_READ(SOUTH_CHICKEN1); > + if (panel->backlight.alternate_pwm_increment) > + schicken |= SPT_PWM_GRANULARITY; > + else > + schicken &= ~SPT_PWM_GRANULARITY; > + I915_WRITE(SOUTH_CHICKEN1, schicken); > + } > + > pch_ctl2 = panel->backlight.max << 16; > I915_WRITE(BLC_PWM_PCH_CTL2, pch_ctl2); -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915 : Restore PWM_GRANULARITY after resume
From: "Lee, Shawn C"SPT_PWM_GRANULARITY (SOUTH_CHICKEN1, bit 0) controls the granularity (minimum increment) of the PWM backlight control counter. PWM frequency adjustment on 128 clock increments when this bit was 1. And 16 clock increments when it was 0. PWM frequency multiple octuple (from 200Hz to 1.6KHz) due to SPT_PWM_GRANULARITY was clear to 0 after S3. This patch save SOUTH_CHICKEN1 register value before suspend. And will restore it after i915 resume. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486 Cc: Jani Nikula Reviewed-by: Cooper Chiou Reviewed-by: Wei Shun Chen Reviewed-by: Gary C Wang Signed-off-by: Shawn Lee --- drivers/gpu/drm/i915/intel_drv.h |1 + drivers/gpu/drm/i915/intel_panel.c | 24 ++-- 2 files changed, 23 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 570a7ca..c4bc690 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -256,6 +256,7 @@ struct intel_panel { u32 level; u32 min; u32 max; + bool pwm_alternate_increment; bool enabled; bool combination_mode; /* gen 2/4 only */ bool active_low_pwm; diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index c10e9b0..e1dc6bd 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -841,7 +841,7 @@ static void lpt_enable_backlight(struct intel_connector *connector) { struct drm_i915_private *dev_priv = to_i915(connector->base.dev); struct intel_panel *panel = >panel; - u32 pch_ctl1, pch_ctl2; + u32 pch_ctl1, pch_ctl2, mul; pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1); if (pch_ctl1 & BLM_PCH_PWM_ENABLE) { @@ -867,6 +867,16 @@ static void lpt_enable_backlight(struct intel_connector *connector) /* This won't stick until the above enable. */ intel_panel_actually_set_backlight(connector, panel->backlight.level); + + if (HAS_PCH_LPT(dev_priv)) { + mul = I915_READ(SOUTH_CHICKEN2); + mul &= ~LPT_PWM_GRANULARITY; + I915_WRITE(SOUTH_CHICKEN2, mul | (panel->backlight.pwm_alternate_increment << LPT_PWM_GRANULARITY)); + } else { + mul = I915_READ(SOUTH_CHICKEN1); + mul &= ~SPT_PWM_GRANULARITY; + I915_WRITE(SOUTH_CHICKEN1, mul | (panel->backlight.pwm_alternate_increment << SPT_PWM_GRANULARITY)); + } } static void pch_enable_backlight(struct intel_connector *connector) @@ -1413,7 +1423,7 @@ static int lpt_setup_backlight(struct intel_connector *connector, enum pipe unus { struct drm_i915_private *dev_priv = to_i915(connector->base.dev); struct intel_panel *panel = >panel; - u32 pch_ctl1, pch_ctl2, val; + u32 pch_ctl1, pch_ctl2, val, mul; pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1); panel->backlight.active_low_pwm = pch_ctl1 & BLM_PCH_POLARITY; @@ -1436,6 +1446,16 @@ static int lpt_setup_backlight(struct intel_connector *connector, enum pipe unus panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE; + if (HAS_PCH_LPT(dev_priv)) + mul = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY; + else + mul = I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY; + + if ( mul ) + panel->backlight.pwm_alternate_increment = true; + else + panel->backlight.pwm_alternate_increment = false; + return 0; } -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Only shrink the unbound objects during freeze
On pe, 2016-09-16 at 20:23 +0100, Chris Wilson wrote: > int i915_gem_freeze_late(struct drm_i915_private *dev_priv) > { > > struct drm_i915_gem_object *obj; > @@ -4692,7 +4705,8 @@ int i915_gem_freeze_late(struct drm_i915_private > *dev_priv) > > * the objects as well. > > */ > > > - i915_gem_shrink_all(dev_priv); > + mutex_lock(_priv->drm.struct_mutex); Previously the shrinking here was without a mutex. And the new shrinking during _freeze is also mutex protected, any specific reason? Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915/skl: New ddb allocation algorithm
Hey, Op 14-09-16 om 14:36 schreef Mahesh Kumar: > Hi, > There was an issue with transition WM, it was getting enabled & causing fifo > underrun. > I fixed the condition, After that tested kms_plane & not getting any underrun. > Please let me know if you see any other issue. kms_cursor_legacy.cursorA-vs-flipA-atomic-transitions-varying-size is broken by this patch. It's easy to overlook, since cursorA-vs-flipB of the same test was already broken, but this is definitely something new introduced by this patch. ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/execlists: Reset RING registers upon resume
On pe, 2016-09-16 at 20:23 +0100, Chris Wilson wrote: > void intel_lr_context_resume(struct drm_i915_private *dev_priv) > { > > - struct i915_gem_context *ctx = dev_priv->kernel_context; > > struct intel_engine_cs *engine; > > + struct i915_gem_context *ctx; > + > > + /* Because we emit WA_TAIL_DWORDS there may be a disparity > > + * between our bookkeeping in ce->ring->head and ce->ring->tail and > + * that stored in context. As we only write new comamnds from "new commands" > + * ce->ring->tail onwards, everything before that is junk. If the GPU > > + * starts reading from its RING_HEAD from the context, it may try to > > + * execute that junk and die. > > + * > > + * So to avoid that we reset the context images upon resume. For > > + * simplicity, we just zero everything out. > > + */ > > + list_for_each_entry(ctx, _priv->context_list, link) { > > + for_each_engine(engine, dev_priv) { > > + struct intel_context *ce = >engine[engine->id]; > > + u32 *reg_state; > > > - for_each_engine(engine, dev_priv) { > > - struct intel_context *ce = >engine[engine->id]; > > - void *vaddr; > > - uint32_t *reg_state; > - > > - if (!ce->state) > > - continue; > - > > - vaddr = i915_gem_object_pin_map(ce->state->obj, I915_MAP_WB); > > - if (WARN_ON(IS_ERR(vaddr))) > > - continue; > > + if (!ce->state) > > + continue; > > > - reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE; > > + reg_state = i915_gem_object_pin_map(ce->state->obj, > > + I915_MAP_WB); > > + if (WARN_ON(IS_ERR(reg_state))) > > + continue; > > > - reg_state[CTX_RING_HEAD+1] = 0; > > - reg_state[CTX_RING_TAIL+1] = 0; > + reg_state += LRC_STATE_PN * PAGE_SIZE / sizeof(u32); / sizeof(*reg_state) I presume. Also add a newline here. With those; Reviewed-by: Joonas LahtinenRegards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/backlight: setup backlight pwm alternate increment on backlight enable
On Mon, 19 Sep 2016, Jani Nikulawrote: > From: Shawn Lee > > Backlight enable is supposed to do a full setup of the backlight. We > were missing the PWM alternate increment bit in the south chicken > registers on lpt+ pch. This potentially caused a PWM frequency change > when the chicken register value was lost e.g. on suspend. > > v2 by Jani, rebase on the patch caching alt increment Fat fingered this one, please ignore, and look at the two patches in reply to this one. Sorry. 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
[Intel-gfx] [PATCH v2 2/2] drm/i915/backlight: setup backlight pwm alternate increment on backlight enable
From: Shawn LeeBacklight enable is supposed to do a full setup of the backlight. We were missing the PWM alternate increment bit in the south chicken registers on lpt+ pch. This potentially caused a PWM frequency change when the chicken register value was lost e.g. on suspend. v2 by Jani, rebase on the patch caching alt increment Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486 Cc: Cooper Chiou Cc: Wei Shun Chen Cc: Gary C Wang Cc: sta...@vger.kernel.org Signed-off-by: Shawn Lee Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_panel.c | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index 8bc43205d6a0..be4b4d546fd9 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -841,7 +841,7 @@ static void lpt_enable_backlight(struct intel_connector *connector) { struct drm_i915_private *dev_priv = to_i915(connector->base.dev); struct intel_panel *panel = >panel; - u32 pch_ctl1, pch_ctl2; + u32 pch_ctl1, pch_ctl2, schicken; pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1); if (pch_ctl1 & BLM_PCH_PWM_ENABLE) { @@ -850,6 +850,22 @@ static void lpt_enable_backlight(struct intel_connector *connector) I915_WRITE(BLC_PWM_PCH_CTL1, pch_ctl1); } + if (HAS_PCH_LPT(dev_priv)) { + schicken = I915_READ(SOUTH_CHICKEN2); + if (panel->backlight.alternate_pwm_increment) + schicken |= LPT_PWM_GRANULARITY; + else + schicken &= ~LPT_PWM_GRANULARITY; + I915_WRITE(SOUTH_CHICKEN2, schicken); + } else { + schicken = I915_READ(SOUTH_CHICKEN1); + if (panel->backlight.alternate_pwm_increment) + schicken |= SPT_PWM_GRANULARITY; + else + schicken &= ~SPT_PWM_GRANULARITY; + I915_WRITE(SOUTH_CHICKEN1, schicken); + } + pch_ctl2 = panel->backlight.max << 16; I915_WRITE(BLC_PWM_PCH_CTL2, pch_ctl2); -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915/backlight: setup and cache pwm alternate increment value
This will also be needed later on when setting up the alternate increment in backlight enable. Cc: Shawn LeeSigned-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_panel.c | 14 +++--- 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 8fd16adf069b..c3e65e515c9d 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -263,6 +263,7 @@ struct intel_panel { bool enabled; bool combination_mode; /* gen 2/4 only */ bool active_low_pwm; + bool alternate_pwm_increment; /* lpt+ */ /* PWM chip */ bool util_pin_active_low; /* bxt+ */ diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index c10e9b0405e8..8bc43205d6a0 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -1242,10 +1242,10 @@ static u32 bxt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz) */ static u32 spt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz) { - struct drm_i915_private *dev_priv = to_i915(connector->base.dev); + struct intel_panel *panel = >panel; u32 mul; - if (I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY) + if (panel->backlight.alternate_pwm_increment) mul = 128; else mul = 16; @@ -1261,9 +1261,10 @@ static u32 spt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz) static u32 lpt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz) { struct drm_i915_private *dev_priv = to_i915(connector->base.dev); + struct intel_panel *panel = >panel; u32 mul, clock; - if (I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY) + if (panel->backlight.alternate_pwm_increment) mul = 16; else mul = 128; @@ -1414,6 +1415,13 @@ static int lpt_setup_backlight(struct intel_connector *connector, enum pipe unus struct drm_i915_private *dev_priv = to_i915(connector->base.dev); struct intel_panel *panel = >panel; u32 pch_ctl1, pch_ctl2, val; + bool alt; + + if (HAS_PCH_LPT(dev_priv)) + alt = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY; + else + alt = I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY; + panel->backlight.alternate_pwm_increment = alt; pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1); panel->backlight.active_low_pwm = pch_ctl1 & BLM_PCH_POLARITY; -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/backlight: setup backlight pwm alternate increment on backlight enable
From: Shawn LeeBacklight enable is supposed to do a full setup of the backlight. We were missing the PWM alternate increment bit in the south chicken registers on lpt+ pch. This potentially caused a PWM frequency change when the chicken register value was lost e.g. on suspend. v2 by Jani, rebase on the patch caching alt increment Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486 Cc: Cooper Chiou Cc: Wei Shun Chen Cc: Gary C Wang Cc: sta...@vger.kernel.org Signed-off-by: Shawn Lee Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_panel.c | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index 8bc43205d6a0..be4b4d546fd9 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -841,7 +841,7 @@ static void lpt_enable_backlight(struct intel_connector *connector) { struct drm_i915_private *dev_priv = to_i915(connector->base.dev); struct intel_panel *panel = >panel; - u32 pch_ctl1, pch_ctl2; + u32 pch_ctl1, pch_ctl2, schicken; pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1); if (pch_ctl1 & BLM_PCH_PWM_ENABLE) { @@ -850,6 +850,22 @@ static void lpt_enable_backlight(struct intel_connector *connector) I915_WRITE(BLC_PWM_PCH_CTL1, pch_ctl1); } + if (HAS_PCH_LPT(dev_priv)) { + schicken = I915_READ(SOUTH_CHICKEN2); + if (panel->backlight.alternate_pwm_increment) + schicken |= LPT_PWM_GRANULARITY; + else + schicken &= ~LPT_PWM_GRANULARITY; + I915_WRITE(SOUTH_CHICKEN2, schicken); + } else { + schicken = I915_READ(SOUTH_CHICKEN1); + if (panel->backlight.alternate_pwm_increment) + schicken |= SPT_PWM_GRANULARITY; + else + schicken &= ~SPT_PWM_GRANULARITY; + I915_WRITE(SOUTH_CHICKEN1, schicken); + } + pch_ctl2 = panel->backlight.max << 16; I915_WRITE(BLC_PWM_PCH_CTL2, pch_ctl2); -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915/skl: drop workarounds for A0 and B0 revisions
On Mon, 19 Sep 2016, Mika Kaholawrote: > On Fri, 2016-09-16 at 16:59 +0300, Jani Nikula wrote: >> Pre-production hardware is not supported. >> >> Signed-off-by: Jani Nikula >> --- >> drivers/gpu/drm/i915/intel_dp.c | 4 >> drivers/gpu/drm/i915/intel_dp_link_training.c | 3 --- >> drivers/gpu/drm/i915/intel_guc_loader.c | 5 ++--- >> drivers/gpu/drm/i915/intel_lrc.c | 8 +++- >> drivers/gpu/drm/i915/intel_ringbuffer.c | 21 ++--- >> >> 5 files changed, 11 insertions(+), 30 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c >> b/drivers/gpu/drm/i915/intel_dp.c >> index acd0c51f74d5..b2a9eb82ac4b 100644 >> --- a/drivers/gpu/drm/i915/intel_dp.c >> +++ b/drivers/gpu/drm/i915/intel_dp.c >> @@ -1299,10 +1299,6 @@ bool intel_dp_source_supports_hbr2(struct >> intel_dp *intel_dp) >> struct intel_digital_port *dig_port = >> dp_to_dig_port(intel_dp); >> struct drm_device *dev = dig_port->base.base.dev; >> >> -/* WaDisableHBR2:skl */ >> -if (IS_SKL_REVID(dev, 0, SKL_REVID_B0)) >> -return false; >> - >> if ((IS_HASWELL(dev) && !IS_HSW_ULX(dev)) || >> IS_BROADWELL(dev) || >> (INTEL_INFO(dev)->gen >= 9)) >> return true; >> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c >> b/drivers/gpu/drm/i915/intel_dp_link_training.c >> index c438b02184cb..0048b520baf7 100644 >> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c >> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c >> @@ -225,9 +225,6 @@ static u32 intel_dp_training_pattern(struct >> intel_dp *intel_dp) >> * Intel platforms that support HBR2 also support TPS3. TPS3 >> support is >> * also mandatory for downstream devices that support HBR2. >> However, not >> * all sinks follow the spec. >> - * >> - * Due to WaDisableHBR2 SKL < B0 is the only exception where >> TPS3 is >> - * supported in source but still not enabled. >> */ >> source_tps3 = intel_dp_source_supports_hbr2(intel_dp); >> sink_tps3 = drm_dp_tps3_supported(intel_dp->dpcd); >> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c >> b/drivers/gpu/drm/i915/intel_guc_loader.c >> index 6fd39efb7894..acc1dbdd024e 100644 >> --- a/drivers/gpu/drm/i915/intel_guc_loader.c >> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c >> @@ -375,9 +375,8 @@ static int guc_ucode_xfer(struct drm_i915_private >> *dev_priv) >> /* Enable MIA caching. GuC clock gating is disabled. */ >> I915_WRITE(GUC_SHIM_CONTROL, GUC_SHIM_CONTROL_VALUE); >> >> -/* WaDisableMinuteIaClockGating:skl,bxt */ >> -if (IS_SKL_REVID(dev, 0, SKL_REVID_B0) || >> -IS_BXT_REVID(dev, 0, BXT_REVID_A1)) { >> +/* WaDisableMinuteIaClockGating:bxt */ >> +if (IS_BXT_REVID(dev, 0, BXT_REVID_A1)) { >> I915_WRITE(GUC_SHIM_CONTROL, >> (I915_READ(GUC_SHIM_CONTROL) & >> ~GUC_ENABLE_MIA_CLOCK_ >> GATING)); >> } >> diff --git a/drivers/gpu/drm/i915/intel_lrc.c >> b/drivers/gpu/drm/i915/intel_lrc.c >> index 251143361f31..4bfa3c015e25 100644 >> --- a/drivers/gpu/drm/i915/intel_lrc.c >> +++ b/drivers/gpu/drm/i915/intel_lrc.c >> @@ -269,8 +269,7 @@ logical_ring_init_platform_invariants(struct >> intel_engine_cs *engine) >> struct drm_i915_private *dev_priv = engine->i915; >> >> engine->disable_lite_restore_wa = >> -(IS_SKL_REVID(dev_priv, 0, SKL_REVID_B0) || >> - IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1)) && >> +IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1) && >> (engine->id == VCS || engine->id == VCS2); >> >> engine->ctx_desc_template = GEN8_CTX_VALID; >> @@ -1068,9 +1067,8 @@ static int gen9_init_perctx_bb(struct >> intel_engine_cs *engine, >> { >> uint32_t index = wa_ctx_start(wa_ctx, *offset, >> CACHELINE_DWORDS); >> >> -/* >> WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken:skl,bxt */ >> -if (IS_SKL_REVID(engine->i915, 0, SKL_REVID_B0) || >> -IS_BXT_REVID(engine->i915, 0, BXT_REVID_A1)) { >> +/* WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken:bxt >> */ >> +if (IS_BXT_REVID(engine->i915, 0, BXT_REVID_A1)) { >> wa_ctx_emit(batch, index, MI_LOAD_REGISTER_IMM(1)); >> wa_ctx_emit_reg(batch, index, >> GEN9_SLICE_COMMON_ECO_CHICKEN0); >> wa_ctx_emit(batch, index, >> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c >> b/drivers/gpu/drm/i915/intel_ringbuffer.c >> index 7a74750076c5..2faf64f9f256 100644 >> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c >> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c >> @@ -851,15 +851,13 @@ static int gen9_init_workarounds(struct >> intel_engine_cs *engine) >> WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3, >> GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC); >> >> -/* WaDisableDgMirrorFixInHalfSliceChicken5:skl,bxt */ >> -if (IS_SKL_REVID(dev_priv, 0,
Re: [Intel-gfx] [PATCH 1/5] drm/i915/skl: drop workarounds for A0 and B0 revisions
On Fri, 2016-09-16 at 16:59 +0300, Jani Nikula wrote: > Pre-production hardware is not supported. > > Signed-off-by: Jani Nikula> --- > drivers/gpu/drm/i915/intel_dp.c | 4 > drivers/gpu/drm/i915/intel_dp_link_training.c | 3 --- > drivers/gpu/drm/i915/intel_guc_loader.c | 5 ++--- > drivers/gpu/drm/i915/intel_lrc.c | 8 +++- > drivers/gpu/drm/i915/intel_ringbuffer.c | 21 ++--- > > 5 files changed, 11 insertions(+), 30 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > b/drivers/gpu/drm/i915/intel_dp.c > index acd0c51f74d5..b2a9eb82ac4b 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -1299,10 +1299,6 @@ bool intel_dp_source_supports_hbr2(struct > intel_dp *intel_dp) > struct intel_digital_port *dig_port = > dp_to_dig_port(intel_dp); > struct drm_device *dev = dig_port->base.base.dev; > > - /* WaDisableHBR2:skl */ > - if (IS_SKL_REVID(dev, 0, SKL_REVID_B0)) > - return false; > - > if ((IS_HASWELL(dev) && !IS_HSW_ULX(dev)) || > IS_BROADWELL(dev) || > (INTEL_INFO(dev)->gen >= 9)) > return true; > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c > b/drivers/gpu/drm/i915/intel_dp_link_training.c > index c438b02184cb..0048b520baf7 100644 > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c > @@ -225,9 +225,6 @@ static u32 intel_dp_training_pattern(struct > intel_dp *intel_dp) > * Intel platforms that support HBR2 also support TPS3. TPS3 > support is > * also mandatory for downstream devices that support HBR2. > However, not > * all sinks follow the spec. > - * > - * Due to WaDisableHBR2 SKL < B0 is the only exception where > TPS3 is > - * supported in source but still not enabled. > */ > source_tps3 = intel_dp_source_supports_hbr2(intel_dp); > sink_tps3 = drm_dp_tps3_supported(intel_dp->dpcd); > diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c > b/drivers/gpu/drm/i915/intel_guc_loader.c > index 6fd39efb7894..acc1dbdd024e 100644 > --- a/drivers/gpu/drm/i915/intel_guc_loader.c > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c > @@ -375,9 +375,8 @@ static int guc_ucode_xfer(struct drm_i915_private > *dev_priv) > /* Enable MIA caching. GuC clock gating is disabled. */ > I915_WRITE(GUC_SHIM_CONTROL, GUC_SHIM_CONTROL_VALUE); > > - /* WaDisableMinuteIaClockGating:skl,bxt */ > - if (IS_SKL_REVID(dev, 0, SKL_REVID_B0) || > - IS_BXT_REVID(dev, 0, BXT_REVID_A1)) { > + /* WaDisableMinuteIaClockGating:bxt */ > + if (IS_BXT_REVID(dev, 0, BXT_REVID_A1)) { > I915_WRITE(GUC_SHIM_CONTROL, > (I915_READ(GUC_SHIM_CONTROL) & > ~GUC_ENABLE_MIA_CLOCK_ > GATING)); > } > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > b/drivers/gpu/drm/i915/intel_lrc.c > index 251143361f31..4bfa3c015e25 100644 > --- a/drivers/gpu/drm/i915/intel_lrc.c > +++ b/drivers/gpu/drm/i915/intel_lrc.c > @@ -269,8 +269,7 @@ logical_ring_init_platform_invariants(struct > intel_engine_cs *engine) > struct drm_i915_private *dev_priv = engine->i915; > > engine->disable_lite_restore_wa = > - (IS_SKL_REVID(dev_priv, 0, SKL_REVID_B0) || > - IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1)) && > + IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1) && > (engine->id == VCS || engine->id == VCS2); > > engine->ctx_desc_template = GEN8_CTX_VALID; > @@ -1068,9 +1067,8 @@ static int gen9_init_perctx_bb(struct > intel_engine_cs *engine, > { > uint32_t index = wa_ctx_start(wa_ctx, *offset, > CACHELINE_DWORDS); > > - /* > WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken:skl,bxt */ > - if (IS_SKL_REVID(engine->i915, 0, SKL_REVID_B0) || > - IS_BXT_REVID(engine->i915, 0, BXT_REVID_A1)) { > + /* WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken:bxt > */ > + if (IS_BXT_REVID(engine->i915, 0, BXT_REVID_A1)) { > wa_ctx_emit(batch, index, MI_LOAD_REGISTER_IMM(1)); > wa_ctx_emit_reg(batch, index, > GEN9_SLICE_COMMON_ECO_CHICKEN0); > wa_ctx_emit(batch, index, > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c > b/drivers/gpu/drm/i915/intel_ringbuffer.c > index 7a74750076c5..2faf64f9f256 100644 > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c > @@ -851,15 +851,13 @@ static int gen9_init_workarounds(struct > intel_engine_cs *engine) > WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3, > GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC); > > - /* WaDisableDgMirrorFixInHalfSliceChicken5:skl,bxt */ > - if (IS_SKL_REVID(dev_priv, 0, SKL_REVID_B0) || > - IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1)) > + /* WaDisableDgMirrorFixInHalfSliceChicken5:bxt */ > +