Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP

[Dhinakaran Pandiyan]

On Thursday, August 17, 2017 1:44:14 PM PDT Rodrigo Vivi wrote:
> On Thu, Aug 17, 2017 at 1:11 PM, Pandiyan, Dhinakaran
> 
>  wrote:
> > On Thu, 2017-08-17 at 12:46 -0700, Manasi Navare wrote:
> >> On Thu, Aug 17, 2017 at 07:01:05AM +, Rodrigo Vivi wrote:
> >> >On Wed, Aug 16, 2017 at 11:51 PM Manasi Navare
> >> >
> >> ><[1]manasi.d.nav...@intel.com> wrote:
> >> >  In case of eDP because the panel has a fixed mode we cannot
> >> >  link train fallback and prune modes since this results in
> >> >  no modes available for eDP connector.
> >> >
> >> >What about downclock modes?!
> >> 
> >> What are the downclock modes? We have seen an issue with pruning modes
> >> in case of eDP panel where we end up pruning the mode due to link train
> >> fallback and then we get an error saying "No modes available for the
> >> connector"
> > 
> > fwiw I've got two laptops with eDP's having more than ten modes.
> 
> those ten are probably a list of modes with scaler right?!

Yeah, Clint very graciously explained that to me after I sent the email.
___
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/dp: Fix the channel equalization failure condition during Link Training

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Fix the channel equalization failure condition during Link 
Training
URL   : https://patchwork.freedesktop.org/series/28960/
State : success

== Summary ==

Series 28960v1 drm/i915/dp: Fix the channel equalization failure condition 
during Link Training
https://patchwork.freedesktop.org/api/1.0/series/28960/revisions/1/mbox/

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:453s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:435s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:361s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:557s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:520s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:519s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:611s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:447s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:421s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:424s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:503s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:480s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:478s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:602s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:599s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:523s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:477s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:479s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:485s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:439s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:477s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:540s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:405s

cdafe36f7b6f8fa0ae1a90babce68cbd8ccc98cb drm-tip: 2017y-08m-17d-21h-02m-32s UTC 
integration manifest
48c01fe55f07 drm/i915/dp: Fix the channel equalization failure condition during 
Link Training

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5432/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/dp: Fix the channel equalization failure condition during Link Training

[Manasi Navare]

In the channel EQ retry loop, we break from the loop in case
of failure to get link status or failure in clock recovery or
failure to update link training. In these cases channel_eq_status
is still false even though the retry loop has not reached max retries.
So we need to consider this as a failure condition.

Signed-off-by: Manasi Navare 
Cc: Jim Bride 
Cc: Jani Nikula 
Cc: Ville Syrjala 
---
 drivers/gpu/drm/i915/intel_dp_link_training.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 05907fa..3fef219 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -294,9 +294,9 @@ intel_dp_link_training_channel_equalization(struct intel_dp 
*intel_dp)
}
 
/* Try 5 times, else fail and try at lower BW */
-   if (tries == 5) {
+   if (tries == 5 || !intel_dp->channel_eq_status) {
intel_dp_dump_link_status(link_status);
-   DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
+   DRM_DEBUG_KMS("Channel equalization failed\n");
}
 
intel_dp_set_idle_link_train(intel_dp);
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM enablement from DMC presence

[Stéphane Marchesin]

On Mon, Jun 19, 2017 at 11:45 AM, Jani Nikula
 wrote:
>
> On Thu, 15 Jun 2017, Imre Deak  wrote:
> > On Thu, Jun 15, 2017 at 10:20:57AM -0700, Rodrigo Vivi wrote:
> >> I believe it is worth allowing RPM to work without requiring DMC, no?!
> >
> > Not if there is no good reason for not using DMC. It was decided early
> > on that we won't support that configuration since if you care about the
> > power saving provided by partially disabling things you probably also
> > care about the bigger power saving provided by DMC. So that is the
> > current state of the driver, enabling runtime PM without having DMC
> > loaded is not supported. Proper support for that would need to be added
> > after a justification why not to use the firmware.
>
> Agreed. We already have too many configurations to support, and we
> already struggle with our testing coverage as-is. Adding new
> configurations to be tested is not to be taken lightly.
>

For context, we are seeing GPU hangs at suspend/resume with DMC
enabled (feel free to email me if you want to be added to the internal
bug) which is the reason for this patch. If those GPU hangs can be
fixed instead, then that would be an even better solution, IMO. Is
there someone on your side who could help with these hangs?

Stéphane

>
> 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 v2 8/8] drm/i915: Constify states passed to enable/disable/etc. encoder hooks

[Rodrigo Vivi]

On Fri, May 19, 2017 at 04:17:25PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> The enable/disable/etc. encoder hooks aren't supposed to alter the
> state(s), so pass them as const. Unfortunately C lacks any kind of deep
> const thingy, so this can't catch all abuses. But at least it acts as a
> hint to the reader telling them not to mess about with the state(s).

That makes total sense. I didn't check all functions to see if no one
is ofending them though.

Acked-by: Rodrigo Vivi 


> 
> v2: Update intel_tv_mode_find() and ironlake_edp_pll_on() as well
> 
> Signed-off-by: Ville Syrjälä 



> ---
>  drivers/gpu/drm/i915/intel_crt.c| 22 ++--
>  drivers/gpu/drm/i915/intel_ddi.c| 30 
>  drivers/gpu/drm/i915/intel_dp.c | 64 -
>  drivers/gpu/drm/i915/intel_dp_mst.c | 16 -
>  drivers/gpu/drm/i915/intel_drv.h| 32 -
>  drivers/gpu/drm/i915/intel_dsi.c| 22 ++--
>  drivers/gpu/drm/i915/intel_dvo.c| 12 +++
>  drivers/gpu/drm/i915/intel_hdmi.c   | 70 
> ++---
>  drivers/gpu/drm/i915/intel_lvds.c   | 24 ++---
>  drivers/gpu/drm/i915/intel_sdvo.c   | 24 ++---
>  drivers/gpu/drm/i915/intel_tv.c | 14 
>  11 files changed, 165 insertions(+), 165 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_crt.c 
> b/drivers/gpu/drm/i915/intel_crt.c
> index 84a1f5e85153..94b9a2eeb0b2 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -143,7 +143,7 @@ static void hsw_crt_get_config(struct intel_encoder 
> *encoder,
>  /* Note: The caller is required to filter out dpms modes not supported by the
>   * platform. */
>  static void intel_crt_set_dpms(struct intel_encoder *encoder,
> -struct intel_crtc_state *crtc_state,
> +const struct intel_crtc_state *crtc_state,
>  int mode)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> @@ -194,28 +194,28 @@ static void intel_crt_set_dpms(struct intel_encoder 
> *encoder,
>  }
>  
>  static void intel_disable_crt(struct intel_encoder *encoder,
> -   struct intel_crtc_state *old_crtc_state,
> -   struct drm_connector_state *old_conn_state)
> +   const struct intel_crtc_state *old_crtc_state,
> +   const struct drm_connector_state *old_conn_state)
>  {
>   intel_crt_set_dpms(encoder, old_crtc_state, DRM_MODE_DPMS_OFF);
>  }
>  
>  static void pch_disable_crt(struct intel_encoder *encoder,
> - struct intel_crtc_state *old_crtc_state,
> - struct drm_connector_state *old_conn_state)
> + const struct intel_crtc_state *old_crtc_state,
> + const struct drm_connector_state *old_conn_state)
>  {
>  }
>  
>  static void pch_post_disable_crt(struct intel_encoder *encoder,
> -  struct intel_crtc_state *old_crtc_state,
> -  struct drm_connector_state *old_conn_state)
> +  const struct intel_crtc_state *old_crtc_state,
> +  const struct drm_connector_state 
> *old_conn_state)
>  {
>   intel_disable_crt(encoder, old_crtc_state, old_conn_state);
>  }
>  
>  static void hsw_post_disable_crt(struct intel_encoder *encoder,
> -  struct intel_crtc_state *old_crtc_state,
> -  struct drm_connector_state *old_conn_state)
> +  const struct intel_crtc_state *old_crtc_state,
> +  const struct drm_connector_state 
> *old_conn_state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>  
> @@ -228,8 +228,8 @@ static void hsw_post_disable_crt(struct intel_encoder 
> *encoder,
>  }
>  
>  static void intel_enable_crt(struct intel_encoder *encoder,
> -  struct intel_crtc_state *pipe_config,
> -  struct drm_connector_state *conn_state)
> +  const struct intel_crtc_state *pipe_config,
> +  const struct drm_connector_state *conn_state)
>  {
>   intel_crt_set_dpms(encoder, pipe_config, DRM_MODE_DPMS_ON);
>  }
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 6203c2da3daf..21aa5eab292c 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -644,7 +644,7 @@ static void intel_wait_ddi_buf_idle(struct 
> drm_i915_private *dev_priv,
>   DRM_ERROR("Timeout waiting for DDI BUF %c idle bit\n", port_name(port));
>  }
>  
> -static uint32_t hsw_pll_to_ddi_pll_sel(struct 

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Remove mostly duplicated video DIP handling from PSR code

[Rodrigo Vivi]

On Fri, May 19, 2017 at 04:17:24PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Now that the infoframe hooks are part of the intel_dig_port, we can use
> the normal .write_infoframe() hook to update the VSC SDP. We do need to
> deal with the size difference between the VSC DIP and the others though.
> 
> Another minor snag is that the compiler will complain to use if we keep
> using enum hdmi_infoframe_type type and passing in the DP define instead,
> so et's just change to unsigned int all over for the inforframe type.
> 
> Signed-off-by: Ville Syrjälä 

how didn't we have this before?! :)

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/intel_drv.h  |  2 +-
>  drivers/gpu/drm/i915/intel_hdmi.c | 26 --
>  drivers/gpu/drm/i915/intel_psr.c  | 39 
> ++-
>  3 files changed, 23 insertions(+), 44 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index a3d66ccafa5e..534a5bfb273e 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1067,7 +1067,7 @@ struct intel_digital_port {
>  
>   void (*write_infoframe)(struct drm_encoder *encoder,
>   const struct intel_crtc_state *crtc_state,
> - enum hdmi_infoframe_type type,
> + unsigned int type,
>   const void *frame, ssize_t len);
>   void (*set_infoframes)(struct drm_encoder *encoder,
>  bool enable,
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 6b1c3f998a63..47a9f7f98a62 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -70,7 +70,7 @@ static struct intel_hdmi *intel_attached_hdmi(struct 
> drm_connector *connector)
>   return enc_to_intel_hdmi(_attached_encoder(connector)->base);
>  }
>  
> -static u32 g4x_infoframe_index(enum hdmi_infoframe_type type)
> +static u32 g4x_infoframe_index(unsigned int type)
>  {
>   switch (type) {
>   case HDMI_INFOFRAME_TYPE_AVI:
> @@ -85,7 +85,7 @@ static u32 g4x_infoframe_index(enum hdmi_infoframe_type 
> type)
>   }
>  }
>  
> -static u32 g4x_infoframe_enable(enum hdmi_infoframe_type type)
> +static u32 g4x_infoframe_enable(unsigned int type)
>  {
>   switch (type) {
>   case HDMI_INFOFRAME_TYPE_AVI:
> @@ -100,9 +100,11 @@ static u32 g4x_infoframe_enable(enum hdmi_infoframe_type 
> type)
>   }
>  }
>  
> -static u32 hsw_infoframe_enable(enum hdmi_infoframe_type type)
> +static u32 hsw_infoframe_enable(unsigned int type)
>  {
>   switch (type) {
> + case DP_SDP_VSC:
> + return VIDEO_DIP_ENABLE_VSC_HSW;
>   case HDMI_INFOFRAME_TYPE_AVI:
>   return VIDEO_DIP_ENABLE_AVI_HSW;
>   case HDMI_INFOFRAME_TYPE_SPD:
> @@ -118,10 +120,12 @@ static u32 hsw_infoframe_enable(enum 
> hdmi_infoframe_type type)
>  static i915_reg_t
>  hsw_dip_data_reg(struct drm_i915_private *dev_priv,
>enum transcoder cpu_transcoder,
> -  enum hdmi_infoframe_type type,
> +  unsigned int type,
>int i)
>  {
>   switch (type) {
> + case DP_SDP_VSC:
> + return HSW_TVIDEO_DIP_VSC_DATA(cpu_transcoder, i);
>   case HDMI_INFOFRAME_TYPE_AVI:
>   return HSW_TVIDEO_DIP_AVI_DATA(cpu_transcoder, i);
>   case HDMI_INFOFRAME_TYPE_SPD:
> @@ -136,7 +140,7 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
>  
>  static void g4x_write_infoframe(struct drm_encoder *encoder,
>   const struct intel_crtc_state *crtc_state,
> - enum hdmi_infoframe_type type,
> + unsigned int type,
>   const void *frame, ssize_t len)
>  {
>   const uint32_t *data = frame;
> @@ -191,7 +195,7 @@ static bool g4x_infoframe_enabled(struct drm_encoder 
> *encoder,
>  
>  static void ibx_write_infoframe(struct drm_encoder *encoder,
>   const struct intel_crtc_state *crtc_state,
> - enum hdmi_infoframe_type type,
> + unsigned int type,
>   const void *frame, ssize_t len)
>  {
>   const uint32_t *data = frame;
> @@ -251,7 +255,7 @@ static bool ibx_infoframe_enabled(struct drm_encoder 
> *encoder,
>  
>  static void cpt_write_infoframe(struct drm_encoder *encoder,
>   const struct intel_crtc_state *crtc_state,
> - enum hdmi_infoframe_type type,
> + unsigned int type,
>   const void *frame, ssize_t len)
>  {
>   const uint32_t *data = frame;
> @@ -309,7 +313,7 @@ static bool 

Re: [Intel-gfx] [PATCH 6/8] drm/i915: Plumb crtc_state to PSR enable/disable

[Rodrigo Vivi]

On Fri, May 19, 2017 at 04:17:23PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> The PSR enable/disable need to know things about the crtc state, so
> plumb it through. This will become even more important when we start
> to reuse the generic infoframe code for the VSC DIP programming as the
> infoframe code wants the crtc state as well.
> 
> Signed-off-by: Ville Syrjälä 


Reviewed-by: Rodrigo Vivi 



> ---
>  drivers/gpu/drm/i915/intel_ddi.c |  4 +--
>  drivers/gpu/drm/i915/intel_dp.c  |  4 +--
>  drivers/gpu/drm/i915/intel_drv.h |  6 ++--
>  drivers/gpu/drm/i915/intel_psr.c | 77 
> +---
>  4 files changed, 48 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 5dbbfedfbb06..6203c2da3daf 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1847,7 +1847,7 @@ static void intel_enable_ddi(struct intel_encoder 
> *intel_encoder,
>   intel_dp_stop_link_train(intel_dp);
>  
>   intel_edp_backlight_on(intel_dp);
> - intel_psr_enable(intel_dp);
> + intel_psr_enable(intel_dp, pipe_config);
>   intel_edp_drrs_enable(intel_dp, pipe_config);
>   }
>  
> @@ -1875,7 +1875,7 @@ static void intel_disable_ddi(struct intel_encoder 
> *intel_encoder,
>   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>  
>   intel_edp_drrs_disable(intel_dp, old_crtc_state);
> - intel_psr_disable(intel_dp);
> + intel_psr_disable(intel_dp, old_crtc_state);
>   intel_edp_backlight_off(intel_dp);
>   }
>  }
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 62084e350f58..1784989ca478 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2669,7 +2669,7 @@ static void intel_disable_dp(struct intel_encoder 
> *encoder,
>   intel_audio_codec_disable(encoder);
>  
>   if (HAS_PSR(dev_priv) && !HAS_DDI(dev_priv))
> - intel_psr_disable(intel_dp);
> + intel_psr_disable(intel_dp, old_crtc_state);
>  
>   /* Make sure the panel is off before trying to change the mode. But also
>* ensure that we have vdd while we switch off the panel. */
> @@ -2901,7 +2901,7 @@ static void vlv_enable_dp(struct intel_encoder *encoder,
>   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
>  
>   intel_edp_backlight_on(intel_dp);
> - intel_psr_enable(intel_dp);
> + intel_psr_enable(intel_dp, pipe_config);
>  }
>  
>  static void g4x_pre_enable_dp(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index de2288f78961..a3d66ccafa5e 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1740,8 +1740,10 @@ static inline void 
> intel_backlight_device_unregister(struct intel_connector *con
>  
>  
>  /* intel_psr.c */
> -void intel_psr_enable(struct intel_dp *intel_dp);
> -void intel_psr_disable(struct intel_dp *intel_dp);
> +void intel_psr_enable(struct intel_dp *intel_dp,
> +   const struct intel_crtc_state *crtc_state);
> +void intel_psr_disable(struct intel_dp *intel_dp,
> +   const struct intel_crtc_state *old_crtc_state);
>  void intel_psr_invalidate(struct drm_i915_private *dev_priv,
> unsigned frontbuffer_bits);
>  void intel_psr_flush(struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index c3780d0d2baf..f976aa865ef9 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -103,28 +103,26 @@ static void intel_psr_write_vsc(struct intel_dp 
> *intel_dp,
>   POSTING_READ(ctl_reg);
>  }
>  
> -static void vlv_psr_setup_vsc(struct intel_dp *intel_dp)
> +static void vlv_psr_setup_vsc(struct intel_dp *intel_dp,
> +   const struct intel_crtc_state *crtc_state)
>  {
> - struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> - struct drm_device *dev = intel_dig_port->base.base.dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - struct drm_crtc *crtc = intel_dig_port->base.base.crtc;
> - enum pipe pipe = to_intel_crtc(crtc)->pipe;
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   uint32_t val;
>  
>   /* VLV auto-generate VSC package as per EDP 1.3 spec, Table 3.10 */
> - val  = I915_READ(VLV_VSCSDP(pipe));
> + val  = I915_READ(VLV_VSCSDP(crtc->pipe));
>   val &= ~VLV_EDP_PSR_SDP_FREQ_MASK;
>   val |= VLV_EDP_PSR_SDP_FREQ_EVFRAME;
> - I915_WRITE(VLV_VSCSDP(pipe), val);

Re: [Intel-gfx] [PATCH 2/8] drm/i915: Check has_infoframes when enabling infoframes

[Rodrigo Vivi]

On Fri, May 19, 2017 at 04:17:19PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> has_infoframe is what tells us whether infoframes should be enabled, so
> let's pass that instead of has_hdmi_sink to .set_infoframes().

makes sense

Reviewed-by: Rodrigo Vivi 



> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c  | 6 +++---
>  drivers/gpu/drm/i915/intel_hdmi.c | 6 +++---
>  2 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 0914ad96a71b..8ab0f34d8de9 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1673,7 +1673,7 @@ static void intel_ddi_pre_enable_dp(struct 
> intel_encoder *encoder,
>  }
>  
>  static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
> -   bool has_hdmi_sink,
> +   bool has_infoframe,
> const struct intel_crtc_state *crtc_state,
> const struct drm_connector_state 
> *conn_state,
> struct intel_shared_dpll *pll)
> @@ -1698,7 +1698,7 @@ static void intel_ddi_pre_enable_hdmi(struct 
> intel_encoder *encoder,
>   INTEL_OUTPUT_HDMI);
>  
>   intel_hdmi->set_infoframes(drm_encoder,
> -has_hdmi_sink,
> +has_infoframe,
>  crtc_state, conn_state);
>  }
>  
> @@ -1718,7 +1718,7 @@ static void intel_ddi_pre_enable(struct intel_encoder 
> *encoder,
>   }
>   if (type == INTEL_OUTPUT_HDMI) {
>   intel_ddi_pre_enable_hdmi(encoder,
> -   pipe_config->has_hdmi_sink,
> +   pipe_config->has_infoframe,
> pipe_config, conn_state,
> pipe_config->shared_dpll);
>   }
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 58d690393b29..b586d9782109 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1676,7 +1676,7 @@ static void intel_hdmi_pre_enable(struct intel_encoder 
> *encoder,
>   intel_hdmi_prepare(encoder, pipe_config);
>  
>   intel_hdmi->set_infoframes(>base,
> -pipe_config->has_hdmi_sink,
> +pipe_config->has_infoframe,
>  pipe_config, conn_state);
>  }
>  
> @@ -1696,7 +1696,7 @@ static void vlv_hdmi_pre_enable(struct intel_encoder 
> *encoder,
>0x2b247878);
>  
>   intel_hdmi->set_infoframes(>base,
> -pipe_config->has_hdmi_sink,
> +pipe_config->has_infoframe,
>  pipe_config, conn_state);
>  
>   g4x_enable_hdmi(encoder, pipe_config, conn_state);
> @@ -1768,7 +1768,7 @@ static void chv_hdmi_pre_enable(struct intel_encoder 
> *encoder,
>   chv_set_phy_signal_level(encoder, 128, 102, false);
>  
>   intel_hdmi->set_infoframes(>base,
> -pipe_config->has_hdmi_sink,
> +pipe_config->has_infoframe,
>  pipe_config, conn_state);
>  
>   g4x_enable_hdmi(encoder, pipe_config, conn_state);
> -- 
> 2.10.2
> 
> ___
> 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] [RFC 2/2] drm/i915/pmu: serve global events and support perf stat

[Rogozhkin, Dmitry V]

On Tue, 2017-08-15 at 10:56 -0700, Dmitry Rogozhkin wrote:
> This patch should probably be squashed with Tvrtko's PMU enabling
> patch...
> 
> i915 events don't have a CPU context to work with, so i915
> PMU should work in global mode, i.e. expose perf_invalid_context.
> This will make the following call to perf:
>perf stat workload.sh
> to error out with "failed to read counter". Correct usage would be:
>perf stat -a -C0 workload.sh
> And we will get expected output:
> 
> Another change required to make perf stat happy is properly support
> pmu->del(): comments in del() declaration says that del() is required
> to call stop(event, PERF_EF_UPDATE) and perf stat implicitly gets
> event count thru this.
> 
> Finally, if perf stat will be ran as follows:
>perf stat -a workload.sh
> i.e. without '-C0' option, then event will be initilized as many times
> as there are CPUs. Thus, patch adds PMU refcounting support to avoid
> multiple init/close of internal things. The issue which I did not
> overcome is that in this case counters will be multiplied on number
> of CPUs. Not sure whether it is possible to have some event enabling
> CPU mask or rather I need to simply error out.
> 
> Change-Id: I7d1abe747a4399196e72253f7b66441a6528dbee
> Signed-off-by: Dmitry Rogozhkin 
> Cc: Tvrtko Ursulin 
> Cc: Peter Zijlstra 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |   1 +
>  drivers/gpu/drm/i915/i915_pmu.c | 106 
> ++--
>  2 files changed, 60 insertions(+), 47 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index b59da2c..215d47b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2663,6 +2663,7 @@ struct drm_i915_private {
>   struct {
>   struct pmu base;
>   spinlock_t lock;
> + unsigned int ref;
>   struct hrtimer timer;
>   bool timer_enabled;
>   u64 enable;
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index bcdf2bc..0972203 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -451,34 +451,39 @@ static void i915_pmu_enable(struct perf_event *event)
>   container_of(event->pmu, typeof(*i915), pmu.base);
>   struct intel_engine_cs *engine = NULL;
>   unsigned long flags;
> + bool start_timer = false;
>  
>   spin_lock_irqsave(>pmu.lock, flags);
>  
> - if (is_engine_event(event)) {
> - engine = intel_engine_lookup_user(i915,
> -   engine_event_class(event),
> -   engine_event_instance(event));
> - GEM_BUG_ON(!engine);
> - engine->pmu.enable |= BIT(engine_event_sample(event));
> - }
> -
> - i915->pmu.enable |= event_enabled_mask(event);
> + if (i915->pmu.ref++ == 0) {
This was a stupid me: with this I support single busy_stat event only.
Correct way to do that is to make busy_stats a refcount. I did that in
the updated patch which I just sent. I wonder whether timer staff should
be updated with the similar way, but I am not yet tried this part of the
code to judge.
> + if (is_engine_event(event)) {
> + engine = intel_engine_lookup_user(i915,
> + 
> engine_event_class(event),
> + 
> engine_event_instance(event));
> + GEM_BUG_ON(!engine);
> + engine->pmu.enable |= BIT(engine_event_sample(event));
> + }
>  
> - if (pmu_needs_timer(i915, true) && !i915->pmu.timer_enabled) {
> - hrtimer_start_range_ns(>pmu.timer,
> -ns_to_ktime(PERIOD), 0,
> -HRTIMER_MODE_REL_PINNED);
> - i915->pmu.timer_enabled = true;
> - } else if (is_engine_event(event) && engine_needs_busy_stats(engine) &&
> -!engine->pmu.busy_stats) {
> - engine->pmu.busy_stats = true;
> - if (!cancel_delayed_work(>pmu.disable_busy_stats))
> - queue_work(i915->wq, >pmu.enable_busy_stats);
> + i915->pmu.enable |= event_enabled_mask(event);
> +
> + if (pmu_needs_timer(i915, true) && !i915->pmu.timer_enabled) {
> + hrtimer_start_range_ns(>pmu.timer,
> + ns_to_ktime(PERIOD), 0,
> + HRTIMER_MODE_REL_PINNED);
> + i915->pmu.timer_enabled = true;
> + } else if (is_engine_event(event) && 
> engine_needs_busy_stats(engine) &&
> + !engine->pmu.busy_stats) {
> + engine->pmu.busy_stats = true;
> + 

[Intel-gfx] [RFC v1 1/2] drm/i915/pmu: reorder function to suite next patch

[Dmitry Rogozhkin]

This patch is doing nover except reordering functions to highlight
changes in the next patch.

Change-Id: I0cd298780503ae8f6f8035b86c59fc8b5191356b
Signed-off-by: Dmitry Rogozhkin 
Cc: Tvrtko Ursulin 
Cc: Peter Zijlstra 
---
 drivers/gpu/drm/i915/i915_pmu.c | 180 
 1 file changed, 90 insertions(+), 90 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 3272ec0..bcdf2bc 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -363,6 +363,88 @@ static bool engine_needs_busy_stats(struct intel_engine_cs 
*engine)
   (engine->pmu.enable & BIT(I915_SAMPLE_BUSY));
 }
 
+static u64 count_interrupts(struct drm_i915_private *i915)
+{
+   /* open-coded kstat_irqs() */
+   struct irq_desc *desc = irq_to_desc(i915->drm.pdev->irq);
+   u64 sum = 0;
+   int cpu;
+
+   if (!desc || !desc->kstat_irqs)
+   return 0;
+
+   for_each_possible_cpu(cpu)
+   sum += *per_cpu_ptr(desc->kstat_irqs, cpu);
+
+   return sum;
+}
+
+static void i915_pmu_event_read(struct perf_event *event)
+{
+   struct drm_i915_private *i915 =
+   container_of(event->pmu, typeof(*i915), pmu.base);
+   u64 val = 0;
+
+   if (is_engine_event(event)) {
+   u8 sample = engine_event_sample(event);
+   struct intel_engine_cs *engine;
+
+   engine = intel_engine_lookup_user(i915,
+ engine_event_class(event),
+ engine_event_instance(event));
+
+   if (WARN_ON_ONCE(!engine)) {
+   /* Do nothing */
+   } else if (sample == I915_SAMPLE_BUSY &&
+  engine->pmu.busy_stats) {
+   val = ktime_to_ns(intel_engine_get_busy_time(engine));
+   } else {
+   val = engine->pmu.sample[sample];
+   }
+   } else switch (event->attr.config) {
+   case I915_PMU_ACTUAL_FREQUENCY:
+   val = i915->pmu.sample[__I915_SAMPLE_FREQ_ACT];
+   break;
+   case I915_PMU_REQUESTED_FREQUENCY:
+   val = i915->pmu.sample[__I915_SAMPLE_FREQ_REQ];
+   break;
+   case I915_PMU_ENERGY:
+   val = intel_energy_uJ(i915);
+   break;
+   case I915_PMU_INTERRUPTS:
+   val = count_interrupts(i915);
+   break;
+
+   case I915_PMU_RC6_RESIDENCY:
+   if (!i915->gt.awake)
+   return;
+
+   val = intel_rc6_residency_ns(i915,
+IS_VALLEYVIEW(i915) ?
+VLV_GT_RENDER_RC6 :
+GEN6_GT_GFX_RC6);
+   break;
+
+   case I915_PMU_RC6p_RESIDENCY:
+   if (!i915->gt.awake)
+   return;
+
+   if (!IS_VALLEYVIEW(i915))
+   val = intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6p);
+   break;
+
+   case I915_PMU_RC6pp_RESIDENCY:
+   if (!i915->gt.awake)
+   return;
+
+   if (!IS_VALLEYVIEW(i915))
+   val = intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6pp);
+   break;
+   }
+
+   local64_set(>count, val);
+}
+
 static void i915_pmu_enable(struct perf_event *event)
 {
struct drm_i915_private *i915 =
@@ -440,23 +522,6 @@ static void i915_pmu_disable(struct perf_event *event)
i915_pmu_timer_cancel(event);
 }
 
-static int i915_pmu_event_add(struct perf_event *event, int flags)
-{
-   struct hw_perf_event *hwc = >hw;
-
-   if (flags & PERF_EF_START)
-   i915_pmu_enable(event);
-
-   hwc->state = !(flags & PERF_EF_START);
-
-   return 0;
-}
-
-static void i915_pmu_event_del(struct perf_event *event, int flags)
-{
-   i915_pmu_disable(event);
-}
-
 static void i915_pmu_event_start(struct perf_event *event, int flags)
 {
i915_pmu_enable(event);
@@ -467,86 +532,21 @@ static void i915_pmu_event_stop(struct perf_event *event, 
int flags)
i915_pmu_disable(event);
 }
 
-static u64 count_interrupts(struct drm_i915_private *i915)
+static int i915_pmu_event_add(struct perf_event *event, int flags)
 {
-   /* open-coded kstat_irqs() */
-   struct irq_desc *desc = irq_to_desc(i915->drm.pdev->irq);
-   u64 sum = 0;
-   int cpu;
+   struct hw_perf_event *hwc = >hw;
 
-   if (!desc || !desc->kstat_irqs)
-   return 0;
+   if (flags & PERF_EF_START)
+   i915_pmu_enable(event);
 
-   for_each_possible_cpu(cpu)
-   sum += *per_cpu_ptr(desc->kstat_irqs, cpu);
+   hwc->state = !(flags & PERF_EF_START);
 
-   return sum;
+ 

[Intel-gfx] [RFC v1 0/2] Support perf stat with i915 PMU

[Dmitry Rogozhkin]

These patches depend on the RFC patches enabling i915 PMU from Tvrtko:
  https://patchwork.freedesktop.org/series/27488/
Thus, CI failure to build them is expected. I think that my patches should
be squeashed in Tvrtko's one actually.

The first patch simply reorders functions and does nothing now comparing to
Tvrtko's patches. Next patches adds fixes according to PMU API comments
and clarifications from PMU aware engineers.

v1: make busy_stats refcounted instead of the whole pmu

Dmitry Rogozhkin (2):
  drm/i915/pmu: reorder function to suite next patch
  drm/i915/pmu: serve global events and support perf stat

 drivers/gpu/drm/i915/i915_pmu.c | 215 +---
 drivers/gpu/drm/i915/intel_ringbuffer.h |   2 +-
 2 files changed, 112 insertions(+), 105 deletions(-)

-- 
1.8.3.1

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

[Intel-gfx] [RFC v1 2/2] drm/i915/pmu: serve global events and support perf stat

[Dmitry Rogozhkin]

This patch should probably be squashed with Tvrtko's PMU enabling
patch...

i915 events don't have a CPU context to work with, so i915
PMU should work in global mode, i.e. expose perf_invalid_context.
This will make the following call to perf:
   perf stat -e i915/rcs0-busy/ workload.sh
to error out with "failed to read counter". Correct usage would be:
   perf stat -e i915/rcs0-busy/ -a -C0 workload.sh
And we will get expected output:

Another change required to make perf-stat happy is properly support
pmu->del(): comments in del() declaration says that del() is required
to call stop(event, PERF_EF_UPDATE) and perf stat implicitly gets
event count thru this.

Finally, if perf stat will be ran as follows:
   perf stat -e i915/rcs0-busy/ -a workload.sh
i.e. without '-C0' option, then event will be initilized as many times
as there are CPUs. Thus, patch adds PMU refcounting support to avoid
multiple init/close of internal things. The issue which I did not
overcome is that in this case counters will be multiplied on number
of CPUs. Not sure whether it is possible to have some event enabling
CPU mask or rather I need to simply error out.

v1: Make pmu.busy_stats a refcounter to avoid busy stats going away
with some deleted event.

Change-Id: I7d1abe747a4399196e72253f7b66441a6528dbee
Signed-off-by: Dmitry Rogozhkin 
Cc: Tvrtko Ursulin 
Cc: Peter Zijlstra 
---
 drivers/gpu/drm/i915/i915_pmu.c | 37 -
 drivers/gpu/drm/i915/intel_ringbuffer.h |  2 +-
 2 files changed, 23 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index bcdf2bc..fc29c75 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -469,11 +469,16 @@ static void i915_pmu_enable(struct perf_event *event)
   ns_to_ktime(PERIOD), 0,
   HRTIMER_MODE_REL_PINNED);
i915->pmu.timer_enabled = true;
-   } else if (is_engine_event(event) && engine_needs_busy_stats(engine) &&
-  !engine->pmu.busy_stats) {
-   engine->pmu.busy_stats = true;
-   if (!cancel_delayed_work(>pmu.disable_busy_stats))
-   queue_work(i915->wq, >pmu.enable_busy_stats);
+   } else if (is_engine_event(event) && engine_needs_busy_stats(engine)) {
+   /* Enable busy stats for the first event demanding it, next
+* events just reference counter. So, if some events will go
+* away, we will still have busy stats enabled till remaining
+* events still use them.
+*/
+   if (engine->pmu.busy_stats++ == 0) {
+   if 
(!cancel_delayed_work(>pmu.disable_busy_stats))
+   queue_work(i915->wq, 
>pmu.enable_busy_stats);
+   }
}
 
spin_unlock_irqrestore(>pmu.lock, flags);
@@ -495,16 +500,16 @@ static void i915_pmu_disable(struct perf_event *event)
enum intel_engine_id id;
 
engine = intel_engine_lookup_user(i915,
- engine_event_class(event),
- engine_event_instance(event));
+   engine_event_class(event),
+   engine_event_instance(event));
GEM_BUG_ON(!engine);
engine->pmu.enable &= ~BIT(engine_event_sample(event));
-   if (engine->pmu.busy_stats &&
-   !engine_needs_busy_stats(engine)) {
-   engine->pmu.busy_stats = false;
-   queue_delayed_work(i915->wq,
-  >pmu.disable_busy_stats,
-  round_jiffies_up_relative(2 * HZ));
+   if (!engine_needs_busy_stats(engine)) {
+   if (engine->pmu.busy_stats && --engine->pmu.busy_stats 
== 0) {
+   queue_delayed_work(i915->wq,
+   >pmu.disable_busy_stats,
+   round_jiffies_up_relative(2 * 
HZ));
+   }
}
mask = 0;
for_each_engine(engine, i915, id)
@@ -529,6 +534,8 @@ static void i915_pmu_event_start(struct perf_event *event, 
int flags)
 
 static void i915_pmu_event_stop(struct perf_event *event, int flags)
 {
+   if (flags & PERF_EF_UPDATE)
+   i915_pmu_event_read(event);
i915_pmu_disable(event);
 }
 
@@ -546,7 +553,7 @@ static int i915_pmu_event_add(struct perf_event *event, int 
flags)
 
 static void i915_pmu_event_del(struct perf_event *event, int flags)
 {
-   i915_pmu_disable(event);
+   

Re: [Intel-gfx] [PATCH v2 1/8] drm/dp: Add defines for DP SDP types

[Rodrigo Vivi]

On Fri, May 19, 2017 at 04:17:18PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Add defines for the secondary data packet (SDP) types from the spec.
> These are the DP specific ones, and in addition HDMI infoframe types
> (see enum hdmi_infoframe_type) are also valid SDP types.
> 
> v2: Add more SDP types
> 
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Ville Syrjälä 
> ---
>  include/drm/drm_dp_helper.h | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index f7007e544f29..8db4513b9195 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -869,6 +869,17 @@ void drm_dp_link_train_channel_eq_delay(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE]);
>  u8 drm_dp_link_rate_to_bw_code(int link_rate);
>  int drm_dp_bw_code_to_link_rate(u8 link_bw);
>  
> +#define DP_SDP_AUDIO_TIMESTAMP   0x01
> +#define DP_SDP_AUDIO_STREAM  0x02
> +#define DP_SDP_EXTENSION 0x04
> +#define DP_SDP_AUDIO_COPYMANAGEMENT  0x05
> +#define DP_SDP_ISRC  0x06
> +#define DP_SDP_VSC   0x07
> +#define DP_SDP_CAMERA_GENERIC(i) (0x08 + (i)) /* 0-7 */
> +#define DP_SDP_PPS   0x10

for a moment I couldn't find this and others below, so
I checked DP 1.4 instead of the DP 1.3 and could verify that.
maybe deserves a comment /* DP 1.4 */ ?

Anyways:

Reviewed-by: Rodrigo Vivi 

> +#define DP_SDP_VSC_EXT_VESA  0x20
> +#define DP_SDP_VSC_EXT_CEA   0x21
> +
>  struct edp_sdp_header {
>   u8 HB0; /* Secondary Data Packet ID */
>   u8 HB1; /* Secondary Data Packet Type */
> -- 
> 2.10.2
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP

[Manasi Navare]

On Thu, Aug 17, 2017 at 01:44:14PM -0700, Rodrigo Vivi wrote:
> On Thu, Aug 17, 2017 at 1:11 PM, Pandiyan, Dhinakaran
>  wrote:
> > On Thu, 2017-08-17 at 12:46 -0700, Manasi Navare wrote:
> >> On Thu, Aug 17, 2017 at 07:01:05AM +, Rodrigo Vivi wrote:
> >> >On Wed, Aug 16, 2017 at 11:51 PM Manasi Navare
> >> ><[1]manasi.d.nav...@intel.com> wrote:
> >> >
> >> >  In case of eDP because the panel has a fixed mode we cannot
> >> >  link train fallback and prune modes since this results in
> >> >  no modes available for eDP connector.
> >> >
> >> >What about downclock modes?!
> >>
> >> What are the downclock modes? We have seen an issue with pruning modes
> >> in case of eDP panel where we end up pruning the mode due to link train
> >> fallback and then we get an error saying "No modes available for the
> >> connector"
> >>
> >
> > fwiw I've got two laptops with eDP's having more than ten modes.
> 
> those ten are probably a list of modes with scaler right?!
> 
> Anyways, there are eDP panels that supports multiple modes like same
> resolution but different clocks.
> Like the ones with 60Hz and 48Hz where we cannot get PSR on 60 and can
> get on 48 one.
> 
> This made Jim to do this patch:
> https://patchwork.freedesktop.org/patch/msgid/1502308133-26892-1-git-send-email-jim.br...@linux.intel.com
> 
> that now is merged already and allow we select different modes on eDP
> per request.
> 
> this case proves that there are eDP panels out there where this bug
> wouldn't occur.
> 
> So I think we need to find a different way to handle this case where
> there is no other mode
> or fix the link status somehow
>

Thanks Rodrigo for this explanation. Yes those modes advertised to the
userspace would be the modes with scalar. But the HW would still only
support the fixed mode ot the alternate DRRS mode. Infact in case of link 
training
fallback, when the userspace triggers a new modeset, it will call mode_valid() 
hook
where if the requested mode's hdisplay or vdisplay are greater than the fixed 
mode's
hdisplay or vdisplay then it returns error MODE_PANEL instead of MODE_OK.
Also Jim brought up a point that for some eDP panels only 2 lanes could be 
wired in
which case we do want link train fallback in order to retry modeset with fewer 
lanes.
So we need fallback I suppose but handle this no mode situation differently.

Daniel, Jani any thoughts on how this could be handled?

Regards
Manasi

> >
> >> >
> >> >  Also since its a panel, link training should not fail dynamically
> >> >  based on cable conditions like in  case of DP.
> >> >
> >> >Is there any bug associated with this patch?
> >>
> >> Yes this is the bug:
> >> https://bugs.freedesktop.org/show_bug.cgi?id=101518
> 
> Please add this for reference in a future patch or version:
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101518
> 
> >> But the reason I didnt have this in the Fixes tab is because
> >> this patch will not fix the bug, it will just isolate to it being
> >> a bug with AUX Timeouts warning.
> >>
> >> Regards
> >> Manasi
> >>
> >> >
> >> >  Cc: Jani Nikula <[2]jani.nik...@linux.intel.com>
> >> >  Cc: Jim Bride <[3]jim.br...@linux.intel.com>
> >> >  Cc: Ville Syrjälä <[4]ville.syrj...@linux.intel.com>
> >> >  Cc: Daniel Vetter <[5]daniel.vet...@intel.com>
> >> >  Signed-off-by: Manasi Navare <[6]manasi.d.nav...@intel.com>
> >> >  ---
> >> >   drivers/gpu/drm/i915/intel_dp.c   | 2 +-
> >> >   drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++-
> >> >   drivers/gpu/drm/i915/intel_drv.h  | 1 +
> >> >   3 files changed, 4 insertions(+), 2 deletions(-)
> >> >  diff --git a/drivers/gpu/drm/i915/intel_dp.c
> >> >  b/drivers/gpu/drm/i915/intel_dp.c
> >> >  index 4fd4853..edac0c8 100644
> >> >  --- a/drivers/gpu/drm/i915/intel_dp.c
> >> >  +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> >  @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000,
> >> >  27, 54 };
> >> >* If a CPU or PCH DP output is attached to an eDP panel, this
> >> >  function
> >> >* will return true, and false otherwise.
> >> >*/
> >> >  -static bool is_edp(struct intel_dp *intel_dp)
> >> >  +bool is_edp(struct intel_dp *intel_dp)
> >> >   {
> >> >  struct intel_digital_port *intel_dig_port =
> >> >  dp_to_dig_port(intel_dp);
> >> >  diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> >> >  b/drivers/gpu/drm/i915/intel_dp_link_training.c
> >> >  index 05907fa..18ec61f 100644
> >> >  --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> >> >  +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> >> >  @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp
> >> >  *intel_dp)
> >> >intel_connector->[7]base.base.id,
> >> >

Re: [Intel-gfx] [PATCH] drm/i915: Split pin mapping into per platform functions

[Srivatsa, Anusha]

>-Original Message-
>From: Zanoni, Paulo R
>Sent: Thursday, August 17, 2017 1:24 PM
>To: Srivatsa, Anusha ; intel-
>g...@lists.freedesktop.org
>Cc: Ville Syrjala ; Vivi, Rodrigo
>; Taylor, Clinton A 
>Subject: Re: [PATCH] drm/i915: Split pin mapping into per platform functions
>
>Em Qua, 2017-08-16 às 16:45 -0700, Anusha Srivatsa escreveu:
>> Cleanup the code. Map the pins in accordance to individual platforms
>> rather than according to ports.
>> Create separate functions for platforms.
>>
>> v2:
>>  - Add missing condition for CoffeeLake. Make platform
>>  specific functions static. Add function
>>  i915_ddc_pin_mapping().
>>
>> v3:
>>  - Rename functions to x_port_to_ddc_pin() which directly
>>    indicates the purpose. Correct default return values on CNP
>>    and BXT. Rename i915_port_to_ to g4x_port_to since that was
>>    the first platform to run this. Correct code style. (Paulo)
>>
>
>Reviewed-by: Paulo Zanoni 
>
Thanks for the review Paulo! 

Anusha 
>> Sugested-by Ville Syrjala 
>> Cc: Ville Syrjala 
>> Cc: Paulo Zanoni 
>> Cc: Rodrigo Vivi 
>> Cc: Clinton Tayloe 
>> Signed-off-by: Anusha Srivatsa 
>> ---
>>  drivers/gpu/drm/i915/intel_hdmi.c | 113
>> ++
>>  1 file changed, 91 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
>> b/drivers/gpu/drm/i915/intel_hdmi.c
>> index e30c27a..e8abea7 100644
>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>> @@ -1843,45 +1843,114 @@ void
>> intel_hdmi_handle_sink_scrambling(struct intel_encoder *encoder,
>>  DRM_DEBUG_KMS("sink scrambling handled\n");
>>  }
>>
>> -static u8 intel_hdmi_ddc_pin(struct drm_i915_private *dev_priv,
>> - enum port port)
>> +static u8 chv_port_to_ddc_pin(struct drm_i915_private *dev_priv,
>> enum port port)
>>  {
>> -const struct ddi_vbt_port_info *info =
>> -_priv->vbt.ddi_port_info[port];
>>  u8 ddc_pin;
>>
>> -if (info->alternate_ddc_pin) {
>> -DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c
>> (VBT)\n",
>> -  info->alternate_ddc_pin,
>> port_name(port));
>> -return info->alternate_ddc_pin;
>> +switch (port) {
>> +case PORT_B:
>> +ddc_pin = GMBUS_PIN_DPB;
>> +break;
>> +case PORT_C:
>> +ddc_pin = GMBUS_PIN_DPC;
>> +break;
>> +case PORT_D:
>> +ddc_pin = GMBUS_PIN_DPD_CHV;
>> +break;
>> +default:
>> +MISSING_CASE(port);
>> +ddc_pin = GMBUS_PIN_DPB;
>> +break;
>>  }
>> +return ddc_pin;
>> +}
>> +
>> +static u8 bxt_port_to_ddc_pin(struct drm_i915_private *dev_priv,
>> enum port port)
>> +{
>> +u8 ddc_pin;
>>
>>  switch (port) {
>>  case PORT_B:
>> -if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
>> -ddc_pin = GMBUS_PIN_1_BXT;
>> -else
>> -ddc_pin = GMBUS_PIN_DPB;
>> +ddc_pin = GMBUS_PIN_1_BXT;
>>  break;
>>  case PORT_C:
>> -if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
>> -ddc_pin = GMBUS_PIN_2_BXT;
>> -else
>> -ddc_pin = GMBUS_PIN_DPC;
>> +ddc_pin = GMBUS_PIN_2_BXT;
>> +break;
>> +default:
>> +MISSING_CASE(port);
>> +ddc_pin = GMBUS_PIN_1_BXT;
>> +break;
>> +}
>> +return ddc_pin;
>> +}
>> +
>> +static u8 cnp_port_to_ddc_pin(struct drm_i915_private *dev_priv,
>> +  enum port port)
>> +{
>> +u8 ddc_pin;
>> +
>> +switch (port) {
>> +case PORT_B:
>> +ddc_pin = GMBUS_PIN_1_BXT;
>> +break;
>> +case PORT_C:
>> +ddc_pin = GMBUS_PIN_2_BXT;
>>  break;
>>  case PORT_D:
>> -if (HAS_PCH_CNP(dev_priv))
>> -ddc_pin = GMBUS_PIN_4_CNP;
>> -else if (IS_CHERRYVIEW(dev_priv))
>> -ddc_pin = GMBUS_PIN_DPD_CHV;
>> -else
>> -ddc_pin = GMBUS_PIN_DPD;
>> +ddc_pin = GMBUS_PIN_4_CNP;
>> +break;
>> +default:
>> +MISSING_CASE(port);
>> +ddc_pin = GMBUS_PIN_1_BXT;
>> +break;
>> +}
>> +return ddc_pin;
>> +}
>> +
>> +static u8 g4x_port_to_ddc_pin(struct drm_i915_private *dev_priv,
>> +  enum port port)
>> +{
>> +u8 ddc_pin;
>> +
>> +switch (port) {
>> +case PORT_B:
>> +ddc_pin = GMBUS_PIN_DPB;
>> +break;
>> +case PORT_C:
>> +ddc_pin = 

Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP

[Manasi Navare]

On Thu, Aug 17, 2017 at 02:01:05PM -0700, Manasi Navare wrote:
> On Thu, Aug 17, 2017 at 01:11:00PM -0700, Pandiyan, Dhinakaran wrote:
> > On Thu, 2017-08-17 at 12:46 -0700, Manasi Navare wrote:
> > > On Thu, Aug 17, 2017 at 07:01:05AM +, Rodrigo Vivi wrote:
> > > >On Wed, Aug 16, 2017 at 11:51 PM Manasi Navare
> > > ><[1]manasi.d.nav...@intel.com> wrote:
> > > > 
> > > >  In case of eDP because the panel has a fixed mode we cannot
> > > >  link train fallback and prune modes since this results in
> > > >  no modes available for eDP connector.
> > > > 
> > > >What about downclock modes?!
> > > 
> > > What are the downclock modes? We have seen an issue with pruning modes
> > > in case of eDP panel where we end up pruning the mode due to link train
> > > fallback and then we get an error saying "No modes available for the
> > > connector"
> > > 
> > 
> > fwiw I've got two laptops with eDP's having more than ten modes.
> >

Hmm, I have always dealt with laptops with eDPs with a fixed mode
and so are the systems in CI which are giving this "no mode
left on the connector error".

Manasi

> 
> Yes but link training is not supposed to fail for eDP since its a
> fixed connection and so after discussing with Daniel and Jani, this is
> the consensus that we shouldnt be falling back and retraining in case
> of eDP since most eDP panels are going to have 1 or 2 modes.
> 
> Manasi
>  
> > > > 
> > > >  Also since its a panel, link training should not fail dynamically
> > > >  based on cable conditions like in  case of DP.
> > > > 
> > > >Is there any bug associated with this patch?
> > > 
> > > Yes this is the bug:
> > > https://bugs.freedesktop.org/show_bug.cgi?id=101518
> > > But the reason I didnt have this in the Fixes tab is because
> > > this patch will not fix the bug, it will just isolate to it being
> > > a bug with AUX Timeouts warning.
> > > 
> > > Regards
> > > Manasi
> > > 
> > > > 
> > > >  Cc: Jani Nikula <[2]jani.nik...@linux.intel.com>
> > > >  Cc: Jim Bride <[3]jim.br...@linux.intel.com>
> > > >  Cc: Ville Syrjälä <[4]ville.syrj...@linux.intel.com>
> > > >  Cc: Daniel Vetter <[5]daniel.vet...@intel.com>
> > > >  Signed-off-by: Manasi Navare <[6]manasi.d.nav...@intel.com>
> > > >  ---
> > > >   drivers/gpu/drm/i915/intel_dp.c   | 2 +-
> > > >   drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++-
> > > >   drivers/gpu/drm/i915/intel_drv.h  | 1 +
> > > >   3 files changed, 4 insertions(+), 2 deletions(-)
> > > >  diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > >  b/drivers/gpu/drm/i915/intel_dp.c
> > > >  index 4fd4853..edac0c8 100644
> > > >  --- a/drivers/gpu/drm/i915/intel_dp.c
> > > >  +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > >  @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000,
> > > >  27, 54 };
> > > >* If a CPU or PCH DP output is attached to an eDP panel, this
> > > >  function
> > > >* will return true, and false otherwise.
> > > >*/
> > > >  -static bool is_edp(struct intel_dp *intel_dp)
> > > >  +bool is_edp(struct intel_dp *intel_dp)
> > > >   {
> > > >  struct intel_digital_port *intel_dig_port =
> > > >  dp_to_dig_port(intel_dp);
> > > >  diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > >  b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > >  index 05907fa..18ec61f 100644
> > > >  --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > >  +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > >  @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp
> > > >  *intel_dp)
> > > >intel_connector->[7]base.base.id,
> > > >intel_connector->[8]base.name,
> > > >intel_dp->link_rate, intel_dp->lane_count);
> > > >  -   if (!intel_dp_get_link_train_fallback_values(intel_dp,
> > > >  +   /* Dont fallback and prune modes if its eDP */
> > > >  +   if (!is_edp(intel_dp) &&
> > > >  !intel_dp_get_link_train_fallback_values(intel_dp,
> > > > 
> > > >  intel_dp->link_rate,
> > > > 
> > > >  intel_dp->lane_count))
> > > >  /* Schedule a Hotplug Uevent to userspace to start
> > > >  modeset */
> > > >  diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > >  b/drivers/gpu/drm/i915/intel_drv.h
> > > >  index fa47285..9800a15 100644
> > > >  --- a/drivers/gpu/drm/i915/intel_drv.h
> > > >  +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > >  @@ -1548,6 +1548,7 @@ static inline unsigned int
> > > >  intel_dp_unused_lane_mask(int lane_count)
> > > >   }
> > > >   bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > > >  +bool is_edp(struct intel_dp *intel_dp);
> > > >   int intel_dp_link_required(int pixel_clock, int bpp);
> > > >   int 

Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP

[Manasi Navare]

On Thu, Aug 17, 2017 at 01:11:00PM -0700, Pandiyan, Dhinakaran wrote:
> On Thu, 2017-08-17 at 12:46 -0700, Manasi Navare wrote:
> > On Thu, Aug 17, 2017 at 07:01:05AM +, Rodrigo Vivi wrote:
> > >On Wed, Aug 16, 2017 at 11:51 PM Manasi Navare
> > ><[1]manasi.d.nav...@intel.com> wrote:
> > > 
> > >  In case of eDP because the panel has a fixed mode we cannot
> > >  link train fallback and prune modes since this results in
> > >  no modes available for eDP connector.
> > > 
> > >What about downclock modes?!
> > 
> > What are the downclock modes? We have seen an issue with pruning modes
> > in case of eDP panel where we end up pruning the mode due to link train
> > fallback and then we get an error saying "No modes available for the
> > connector"
> > 
> 
> fwiw I've got two laptops with eDP's having more than ten modes.
>

Yes but link training is not supposed to fail for eDP since its a
fixed connection and so after discussing with Daniel and Jani, this is
the consensus that we shouldnt be falling back and retraining in case
of eDP since most eDP panels are going to have 1 or 2 modes.

Manasi
 
> > > 
> > >  Also since its a panel, link training should not fail dynamically
> > >  based on cable conditions like in  case of DP.
> > > 
> > >Is there any bug associated with this patch?
> > 
> > Yes this is the bug:
> > https://bugs.freedesktop.org/show_bug.cgi?id=101518
> > But the reason I didnt have this in the Fixes tab is because
> > this patch will not fix the bug, it will just isolate to it being
> > a bug with AUX Timeouts warning.
> > 
> > Regards
> > Manasi
> > 
> > > 
> > >  Cc: Jani Nikula <[2]jani.nik...@linux.intel.com>
> > >  Cc: Jim Bride <[3]jim.br...@linux.intel.com>
> > >  Cc: Ville Syrjälä <[4]ville.syrj...@linux.intel.com>
> > >  Cc: Daniel Vetter <[5]daniel.vet...@intel.com>
> > >  Signed-off-by: Manasi Navare <[6]manasi.d.nav...@intel.com>
> > >  ---
> > >   drivers/gpu/drm/i915/intel_dp.c   | 2 +-
> > >   drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++-
> > >   drivers/gpu/drm/i915/intel_drv.h  | 1 +
> > >   3 files changed, 4 insertions(+), 2 deletions(-)
> > >  diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > >  b/drivers/gpu/drm/i915/intel_dp.c
> > >  index 4fd4853..edac0c8 100644
> > >  --- a/drivers/gpu/drm/i915/intel_dp.c
> > >  +++ b/drivers/gpu/drm/i915/intel_dp.c
> > >  @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000,
> > >  27, 54 };
> > >* If a CPU or PCH DP output is attached to an eDP panel, this
> > >  function
> > >* will return true, and false otherwise.
> > >*/
> > >  -static bool is_edp(struct intel_dp *intel_dp)
> > >  +bool is_edp(struct intel_dp *intel_dp)
> > >   {
> > >  struct intel_digital_port *intel_dig_port =
> > >  dp_to_dig_port(intel_dp);
> > >  diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > >  b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > >  index 05907fa..18ec61f 100644
> > >  --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > >  +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > >  @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp
> > >  *intel_dp)
> > >intel_connector->[7]base.base.id,
> > >intel_connector->[8]base.name,
> > >intel_dp->link_rate, intel_dp->lane_count);
> > >  -   if (!intel_dp_get_link_train_fallback_values(intel_dp,
> > >  +   /* Dont fallback and prune modes if its eDP */
> > >  +   if (!is_edp(intel_dp) &&
> > >  !intel_dp_get_link_train_fallback_values(intel_dp,
> > > 
> > >  intel_dp->link_rate,
> > > 
> > >  intel_dp->lane_count))
> > >  /* Schedule a Hotplug Uevent to userspace to start
> > >  modeset */
> > >  diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > >  b/drivers/gpu/drm/i915/intel_drv.h
> > >  index fa47285..9800a15 100644
> > >  --- a/drivers/gpu/drm/i915/intel_drv.h
> > >  +++ b/drivers/gpu/drm/i915/intel_drv.h
> > >  @@ -1548,6 +1548,7 @@ static inline unsigned int
> > >  intel_dp_unused_lane_mask(int lane_count)
> > >   }
> > >   bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > >  +bool is_edp(struct intel_dp *intel_dp);
> > >   int intel_dp_link_required(int pixel_clock, int bpp);
> > >   int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> > >   bool intel_digital_port_connected(struct drm_i915_private
> > >  *dev_priv,
> > >  --
> > >  2.1.4
> > >  ___
> > >  Intel-gfx mailing list
> > >  [9]Intel-gfx@lists.freedesktop.org
> > >  [10]https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > 
> > > References
> > > 
> > >1. 

Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP

[Rodrigo Vivi]

On Thu, Aug 17, 2017 at 1:11 PM, Pandiyan, Dhinakaran
 wrote:
> On Thu, 2017-08-17 at 12:46 -0700, Manasi Navare wrote:
>> On Thu, Aug 17, 2017 at 07:01:05AM +, Rodrigo Vivi wrote:
>> >On Wed, Aug 16, 2017 at 11:51 PM Manasi Navare
>> ><[1]manasi.d.nav...@intel.com> wrote:
>> >
>> >  In case of eDP because the panel has a fixed mode we cannot
>> >  link train fallback and prune modes since this results in
>> >  no modes available for eDP connector.
>> >
>> >What about downclock modes?!
>>
>> What are the downclock modes? We have seen an issue with pruning modes
>> in case of eDP panel where we end up pruning the mode due to link train
>> fallback and then we get an error saying "No modes available for the
>> connector"
>>
>
> fwiw I've got two laptops with eDP's having more than ten modes.

those ten are probably a list of modes with scaler right?!

Anyways, there are eDP panels that supports multiple modes like same
resolution but different clocks.
Like the ones with 60Hz and 48Hz where we cannot get PSR on 60 and can
get on 48 one.

This made Jim to do this patch:
https://patchwork.freedesktop.org/patch/msgid/1502308133-26892-1-git-send-email-jim.br...@linux.intel.com

that now is merged already and allow we select different modes on eDP
per request.

this case proves that there are eDP panels out there where this bug
wouldn't occur.

So I think we need to find a different way to handle this case where
there is no other mode
or fix the link status somehow

>
>> >
>> >  Also since its a panel, link training should not fail dynamically
>> >  based on cable conditions like in  case of DP.
>> >
>> >Is there any bug associated with this patch?
>>
>> Yes this is the bug:
>> https://bugs.freedesktop.org/show_bug.cgi?id=101518

Please add this for reference in a future patch or version:

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101518

>> But the reason I didnt have this in the Fixes tab is because
>> this patch will not fix the bug, it will just isolate to it being
>> a bug with AUX Timeouts warning.
>>
>> Regards
>> Manasi
>>
>> >
>> >  Cc: Jani Nikula <[2]jani.nik...@linux.intel.com>
>> >  Cc: Jim Bride <[3]jim.br...@linux.intel.com>
>> >  Cc: Ville Syrjälä <[4]ville.syrj...@linux.intel.com>
>> >  Cc: Daniel Vetter <[5]daniel.vet...@intel.com>
>> >  Signed-off-by: Manasi Navare <[6]manasi.d.nav...@intel.com>
>> >  ---
>> >   drivers/gpu/drm/i915/intel_dp.c   | 2 +-
>> >   drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++-
>> >   drivers/gpu/drm/i915/intel_drv.h  | 1 +
>> >   3 files changed, 4 insertions(+), 2 deletions(-)
>> >  diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> >  b/drivers/gpu/drm/i915/intel_dp.c
>> >  index 4fd4853..edac0c8 100644
>> >  --- a/drivers/gpu/drm/i915/intel_dp.c
>> >  +++ b/drivers/gpu/drm/i915/intel_dp.c
>> >  @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000,
>> >  27, 54 };
>> >* If a CPU or PCH DP output is attached to an eDP panel, this
>> >  function
>> >* will return true, and false otherwise.
>> >*/
>> >  -static bool is_edp(struct intel_dp *intel_dp)
>> >  +bool is_edp(struct intel_dp *intel_dp)
>> >   {
>> >  struct intel_digital_port *intel_dig_port =
>> >  dp_to_dig_port(intel_dp);
>> >  diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
>> >  b/drivers/gpu/drm/i915/intel_dp_link_training.c
>> >  index 05907fa..18ec61f 100644
>> >  --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
>> >  +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
>> >  @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp
>> >  *intel_dp)
>> >intel_connector->[7]base.base.id,
>> >intel_connector->[8]base.name,
>> >intel_dp->link_rate, intel_dp->lane_count);
>> >  -   if (!intel_dp_get_link_train_fallback_values(intel_dp,
>> >  +   /* Dont fallback and prune modes if its eDP */
>> >  +   if (!is_edp(intel_dp) &&
>> >  !intel_dp_get_link_train_fallback_values(intel_dp,
>> >
>> >  intel_dp->link_rate,
>> >
>> >  intel_dp->lane_count))
>> >  /* Schedule a Hotplug Uevent to userspace to start
>> >  modeset */
>> >  diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> >  b/drivers/gpu/drm/i915/intel_drv.h
>> >  index fa47285..9800a15 100644
>> >  --- a/drivers/gpu/drm/i915/intel_drv.h
>> >  +++ b/drivers/gpu/drm/i915/intel_drv.h
>> >  @@ -1548,6 +1548,7 @@ static inline unsigned int
>> >  intel_dp_unused_lane_mask(int lane_count)
>> >   }
>> >   bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
>> >  +bool is_edp(struct intel_dp *intel_dp);
>> >   int intel_dp_link_required(int pixel_clock, int bpp);
>> >   int 

Re: [Intel-gfx] [PATCH] drm/i915: Split pin mapping into per platform functions

[Paulo Zanoni]

Em Qua, 2017-08-16 às 16:45 -0700, Anusha Srivatsa escreveu:
> Cleanup the code. Map the pins in accordance to
> individual platforms rather than according to ports.
> Create separate functions for platforms.
> 
> v2:
>  - Add missing condition for CoffeeLake. Make platform
>  specific functions static. Add function
>  i915_ddc_pin_mapping().
> 
> v3:
>  - Rename functions to x_port_to_ddc_pin() which directly
>    indicates the purpose. Correct default return values on CNP
>    and BXT. Rename i915_port_to_ to g4x_port_to since that was
>    the first platform to run this. Correct code style. (Paulo)
> 

Reviewed-by: Paulo Zanoni 


> Sugested-by Ville Syrjala 
> Cc: Ville Syrjala 
> Cc: Paulo Zanoni 
> Cc: Rodrigo Vivi 
> Cc: Clinton Tayloe 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/intel_hdmi.c | 113
> ++
>  1 file changed, 91 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index e30c27a..e8abea7 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1843,45 +1843,114 @@ void
> intel_hdmi_handle_sink_scrambling(struct intel_encoder *encoder,
>   DRM_DEBUG_KMS("sink scrambling handled\n");
>  }
>  
> -static u8 intel_hdmi_ddc_pin(struct drm_i915_private *dev_priv,
> -  enum port port)
> +static u8 chv_port_to_ddc_pin(struct drm_i915_private *dev_priv,
> enum port port)
>  {
> - const struct ddi_vbt_port_info *info =
> - _priv->vbt.ddi_port_info[port];
>   u8 ddc_pin;
>  
> - if (info->alternate_ddc_pin) {
> - DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c
> (VBT)\n",
> -   info->alternate_ddc_pin,
> port_name(port));
> - return info->alternate_ddc_pin;
> + switch (port) {
> + case PORT_B:
> + ddc_pin = GMBUS_PIN_DPB;
> + break;
> + case PORT_C:
> + ddc_pin = GMBUS_PIN_DPC;
> + break;
> + case PORT_D:
> + ddc_pin = GMBUS_PIN_DPD_CHV;
> + break;
> + default:
> + MISSING_CASE(port);
> + ddc_pin = GMBUS_PIN_DPB;
> + break;
>   }
> + return ddc_pin;
> +}
> +
> +static u8 bxt_port_to_ddc_pin(struct drm_i915_private *dev_priv,
> enum port port)
> +{
> + u8 ddc_pin;
>  
>   switch (port) {
>   case PORT_B:
> - if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
> - ddc_pin = GMBUS_PIN_1_BXT;
> - else
> - ddc_pin = GMBUS_PIN_DPB;
> + ddc_pin = GMBUS_PIN_1_BXT;
>   break;
>   case PORT_C:
> - if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
> - ddc_pin = GMBUS_PIN_2_BXT;
> - else
> - ddc_pin = GMBUS_PIN_DPC;
> + ddc_pin = GMBUS_PIN_2_BXT;
> + break;
> + default:
> + MISSING_CASE(port);
> + ddc_pin = GMBUS_PIN_1_BXT;
> + break;
> + }
> + return ddc_pin;
> +}
> +
> +static u8 cnp_port_to_ddc_pin(struct drm_i915_private *dev_priv,
> +   enum port port)
> +{
> + u8 ddc_pin;
> +
> + switch (port) {
> + case PORT_B:
> + ddc_pin = GMBUS_PIN_1_BXT;
> + break;
> + case PORT_C:
> + ddc_pin = GMBUS_PIN_2_BXT;
>   break;
>   case PORT_D:
> - if (HAS_PCH_CNP(dev_priv))
> - ddc_pin = GMBUS_PIN_4_CNP;
> - else if (IS_CHERRYVIEW(dev_priv))
> - ddc_pin = GMBUS_PIN_DPD_CHV;
> - else
> - ddc_pin = GMBUS_PIN_DPD;
> + ddc_pin = GMBUS_PIN_4_CNP;
> + break;
> + default:
> + MISSING_CASE(port);
> + ddc_pin = GMBUS_PIN_1_BXT;
> + break;
> + }
> + return ddc_pin;
> +}
> +
> +static u8 g4x_port_to_ddc_pin(struct drm_i915_private *dev_priv,
> +   enum port port)
> +{
> + u8 ddc_pin;
> +
> + switch (port) {
> + case PORT_B:
> + ddc_pin = GMBUS_PIN_DPB;
> + break;
> + case PORT_C:
> + ddc_pin = GMBUS_PIN_DPC;
> + break;
> + case PORT_D:
> + ddc_pin = GMBUS_PIN_DPD;
>   break;
>   default:
>   MISSING_CASE(port);
>   ddc_pin = GMBUS_PIN_DPB;
>   break;
>   }
> + return ddc_pin;
> +}
> +
> +static u8 intel_hdmi_ddc_pin(struct drm_i915_private *dev_priv,
> +  enum port port)
> +{
> + const struct ddi_vbt_port_info *info =
> + _priv->vbt.ddi_port_info[port];
> +   

Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP

[Pandiyan, Dhinakaran]

On Thu, 2017-08-17 at 12:46 -0700, Manasi Navare wrote:
> On Thu, Aug 17, 2017 at 07:01:05AM +, Rodrigo Vivi wrote:
> >On Wed, Aug 16, 2017 at 11:51 PM Manasi Navare
> ><[1]manasi.d.nav...@intel.com> wrote:
> > 
> >  In case of eDP because the panel has a fixed mode we cannot
> >  link train fallback and prune modes since this results in
> >  no modes available for eDP connector.
> > 
> >What about downclock modes?!
> 
> What are the downclock modes? We have seen an issue with pruning modes
> in case of eDP panel where we end up pruning the mode due to link train
> fallback and then we get an error saying "No modes available for the
> connector"
> 

fwiw I've got two laptops with eDP's having more than ten modes.

> > 
> >  Also since its a panel, link training should not fail dynamically
> >  based on cable conditions like in  case of DP.
> > 
> >Is there any bug associated with this patch?
> 
> Yes this is the bug:
> https://bugs.freedesktop.org/show_bug.cgi?id=101518
> But the reason I didnt have this in the Fixes tab is because
> this patch will not fix the bug, it will just isolate to it being
> a bug with AUX Timeouts warning.
> 
> Regards
> Manasi
> 
> > 
> >  Cc: Jani Nikula <[2]jani.nik...@linux.intel.com>
> >  Cc: Jim Bride <[3]jim.br...@linux.intel.com>
> >  Cc: Ville Syrjälä <[4]ville.syrj...@linux.intel.com>
> >  Cc: Daniel Vetter <[5]daniel.vet...@intel.com>
> >  Signed-off-by: Manasi Navare <[6]manasi.d.nav...@intel.com>
> >  ---
> >   drivers/gpu/drm/i915/intel_dp.c   | 2 +-
> >   drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++-
> >   drivers/gpu/drm/i915/intel_drv.h  | 1 +
> >   3 files changed, 4 insertions(+), 2 deletions(-)
> >  diff --git a/drivers/gpu/drm/i915/intel_dp.c
> >  b/drivers/gpu/drm/i915/intel_dp.c
> >  index 4fd4853..edac0c8 100644
> >  --- a/drivers/gpu/drm/i915/intel_dp.c
> >  +++ b/drivers/gpu/drm/i915/intel_dp.c
> >  @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000,
> >  27, 54 };
> >* If a CPU or PCH DP output is attached to an eDP panel, this
> >  function
> >* will return true, and false otherwise.
> >*/
> >  -static bool is_edp(struct intel_dp *intel_dp)
> >  +bool is_edp(struct intel_dp *intel_dp)
> >   {
> >  struct intel_digital_port *intel_dig_port =
> >  dp_to_dig_port(intel_dp);
> >  diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> >  b/drivers/gpu/drm/i915/intel_dp_link_training.c
> >  index 05907fa..18ec61f 100644
> >  --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> >  +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> >  @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp
> >  *intel_dp)
> >intel_connector->[7]base.base.id,
> >intel_connector->[8]base.name,
> >intel_dp->link_rate, intel_dp->lane_count);
> >  -   if (!intel_dp_get_link_train_fallback_values(intel_dp,
> >  +   /* Dont fallback and prune modes if its eDP */
> >  +   if (!is_edp(intel_dp) &&
> >  !intel_dp_get_link_train_fallback_values(intel_dp,
> > 
> >  intel_dp->link_rate,
> > 
> >  intel_dp->lane_count))
> >  /* Schedule a Hotplug Uevent to userspace to start
> >  modeset */
> >  diff --git a/drivers/gpu/drm/i915/intel_drv.h
> >  b/drivers/gpu/drm/i915/intel_drv.h
> >  index fa47285..9800a15 100644
> >  --- a/drivers/gpu/drm/i915/intel_drv.h
> >  +++ b/drivers/gpu/drm/i915/intel_drv.h
> >  @@ -1548,6 +1548,7 @@ static inline unsigned int
> >  intel_dp_unused_lane_mask(int lane_count)
> >   }
> >   bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> >  +bool is_edp(struct intel_dp *intel_dp);
> >   int intel_dp_link_required(int pixel_clock, int bpp);
> >   int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> >   bool intel_digital_port_connected(struct drm_i915_private
> >  *dev_priv,
> >  --
> >  2.1.4
> >  ___
> >  Intel-gfx mailing list
> >  [9]Intel-gfx@lists.freedesktop.org
> >  [10]https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > References
> > 
> >1. mailto:manasi.d.nav...@intel.com
> >2. mailto:jani.nik...@linux.intel.com
> >3. mailto:jim.br...@linux.intel.com
> >4. mailto:ville.syrj...@linux.intel.com
> >5. mailto:daniel.vet...@intel.com
> >6. mailto:manasi.d.nav...@intel.com
> >7. http://base.base.id/
> >8. http://base.name/
> >9. mailto:Intel-gfx@lists.freedesktop.org
> >   10. https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> 

Re: [Intel-gfx] [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP

[Jim Bride]

On Thu, Aug 17, 2017 at 12:20:03PM -0700, Manasi Navare wrote:
> On Thu, Aug 17, 2017 at 10:50:04AM -0700, Jim Bride wrote:
> > On Wed, Aug 16, 2017 at 03:13:06PM -0700, Manasi Navare wrote:
> > > On Wed, Aug 09, 2017 at 02:21:07PM -0700, Jim Bride wrote:
> > > > This set of changes has some history to them.  There were several 
> > > > attempts
> > > > to add what was called "fast link training" to i915, which actually 
> > > > wasn't
> > > > fast link training as per the DP spec.  These changes were:
> > > > 
> > > > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > > > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > > 
> > > > which were eventually hand-reverted by:
> > > > 
> > > > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> > > >  feature")
> > > > 
> > > > in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had 
> > > > some
> > > > very bad side-effects on PSR functionality on Skylake. The issue at
> > > > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> > > > (depending on the original link configuration) in order to quickly get
> > > > the source and sink back in synchronization across the link before 
> > > > handing
> > > > control back to the i915.  There's an assumption that none of the link
> > > > configuration information has changed (and thus it's still valid) since 
> > > > the
> > > > last full link training operation.  The revert above was identified via 
> > > > a
> > > > bisect as the cause of some of Skylake's PSR woes.  This patch, largely
> > > > based on commit 4e96c97742f4 ("drm/i915: eDP link training 
> > > > optimization")
> > > > puts the eDP portions of this patch back in place.  None of the 
> > > > flickering
> > > > issues that spurred the revert have been seen, and I suspect the real
> > > > culprits here were addressed by some of the recent link training changes
> > > > that Manasi has implemented, and PSR on Skylake is definitely more happy
> > > > with these changes in-place.
> > > > 
> > > > v2 and v3: Rebase
> > > > v4: * Clean up accesses to train_set_valid a bit for easier
> > > >   reading. (Chris)
> > > > * Rebase
> > > > v5: * Checkpatch cleanup
> > > > * Rebase
> > > > 
> > > > Cc: Chris Wilson 
> > > > Cc: Rodrigo Vivi 
> > > > Cc: Paulo Zanoni 
> > > > Cc: Manasi D Navare 
> > > > Cc: Mika Kahola 
> > > > Cc: Jani Nikula 
> > > > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training 
> > > > feature")
> > > > Signed-off-by: Jim Bride 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp.c   |  4 +++-
> > > >  drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++-
> > > >  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
> > > >  3 files changed, 19 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 76c8a0b..4bd409c 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 
> > > > 27, 54 };
> > > >   * If a CPU or PCH DP output is attached to an eDP panel, this function
> > > >   * will return true, and false otherwise.
> > > >   */
> > > > -static bool is_edp(struct intel_dp *intel_dp)
> > > > +bool is_edp(struct intel_dp *intel_dp)
> > > >  {
> > > > struct intel_digital_port *intel_dig_port = 
> > > > dp_to_dig_port(intel_dp);
> > > >  
> > > > @@ -4711,6 +4711,7 @@ intel_dp_long_pulse(struct intel_connector 
> > > > *intel_connector)
> > > > intel_dp->max_link_rate = 
> > > > intel_dp_max_common_rate(intel_dp);
> > > >  
> > > > intel_dp->reset_link_params = false;
> > > > +   intel_dp->train_set_valid = false;
> > > > }
> > > >  
> > > > intel_dp_print_rates(intel_dp);
> > > > @@ -5979,6 +5980,7 @@ intel_dp_init_connector(struct intel_digital_port 
> > > > *intel_dig_port,
> > > > intel_dp_set_source_rates(intel_dp);
> > > >  
> > > > intel_dp->reset_link_params = true;
> > > > +   intel_dp->train_set_valid = false;
> > > > intel_dp->pps_pipe = INVALID_PIPE;
> > > > intel_dp->active_pipe = INVALID_PIPE;
> > > >  
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> > > > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > index 05907fa..67032cf 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > @@ -94,7 +94,8 @@ static bool
> > > >  intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > > > uint8_t dp_train_pat)
> > > >  {
> > > > -   

Re: [Intel-gfx] [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict harder

[Wolfram Sang]

> > > Signed-off-by: Lyude 
> > 
> > No full name? Or is it your full name?
> Looks like I forgot to change my desktop's S-B identity to full name,
> but it shouldn't be a big deal. I've got tons of other patches already
> upstream like this.

I'd much prefer a full name. But more importantly, what I definately
need is some review/ack/whatever because I don't know enough about this
stuff (other than knowing it is a fragile area).

Maybe you could resend with full name and the acpi list on CC?

Regards,

   Wolfram



signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP

[Manasi Navare]

On Thu, Aug 17, 2017 at 12:20:03PM -0700, Manasi Navare wrote:
> On Thu, Aug 17, 2017 at 10:50:04AM -0700, Jim Bride wrote:
> > On Wed, Aug 16, 2017 at 03:13:06PM -0700, Manasi Navare wrote:
> > > On Wed, Aug 09, 2017 at 02:21:07PM -0700, Jim Bride wrote:
> > > > This set of changes has some history to them.  There were several 
> > > > attempts
> > > > to add what was called "fast link training" to i915, which actually 
> > > > wasn't
> > > > fast link training as per the DP spec.  These changes were:
> > > > 
> > > > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > > > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > > 
> > > > which were eventually hand-reverted by:
> > > > 
> > > > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> > > >  feature")
> > > > 
> > > > in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had 
> > > > some
> > > > very bad side-effects on PSR functionality on Skylake. The issue at
> > > > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> > > > (depending on the original link configuration) in order to quickly get
> > > > the source and sink back in synchronization across the link before 
> > > > handing
> > > > control back to the i915.  There's an assumption that none of the link
> > > > configuration information has changed (and thus it's still valid) since 
> > > > the
> > > > last full link training operation.  The revert above was identified via 
> > > > a
> > > > bisect as the cause of some of Skylake's PSR woes.  This patch, largely
> > > > based on commit 4e96c97742f4 ("drm/i915: eDP link training 
> > > > optimization")
> > > > puts the eDP portions of this patch back in place.  None of the 
> > > > flickering
> > > > issues that spurred the revert have been seen, and I suspect the real
> > > > culprits here were addressed by some of the recent link training changes
> > > > that Manasi has implemented, and PSR on Skylake is definitely more happy
> > > > with these changes in-place.
> > > > 
> > > > v2 and v3: Rebase
> > > > v4: * Clean up accesses to train_set_valid a bit for easier
> > > >   reading. (Chris)
> > > > * Rebase
> > > > v5: * Checkpatch cleanup
> > > > * Rebase
> > > > 
> > > > Cc: Chris Wilson 
> > > > Cc: Rodrigo Vivi 
> > > > Cc: Paulo Zanoni 
> > > > Cc: Manasi D Navare 
> > > > Cc: Mika Kahola 
> > > > Cc: Jani Nikula 
> > > > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training 
> > > > feature")
> > > > Signed-off-by: Jim Bride 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp.c   |  4 +++-
> > > >  drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++-
> > > >  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
> > > >  3 files changed, 19 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 76c8a0b..4bd409c 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 
> > > > 27, 54 };
> > > >   * If a CPU or PCH DP output is attached to an eDP panel, this function
> > > >   * will return true, and false otherwise.
> > > >   */
> > > > -static bool is_edp(struct intel_dp *intel_dp)
> > > > +bool is_edp(struct intel_dp *intel_dp)

I also need this function to be exposed to files outside of intel_dp.c
for the patch:
https://patchwork.freedesktop.org/series/28900/
But one of the review comments I got is to prefix the name of this function 
with intel_dp
when exposing it to outside of intel_dp.c which makes sense as per the naming 
conventions
of the other functions. But we already have a function intel_dp_is_edp() used 
to get VBT information.
Any suggestions for the name? And do you want to make this change as part of 
your series so
I can rebase my patch on top of this?

Regards
Manasi

> > > >  {
> > > > struct intel_digital_port *intel_dig_port = 
> > > > dp_to_dig_port(intel_dp);
> > > >  
> > > > @@ -4711,6 +4711,7 @@ intel_dp_long_pulse(struct intel_connector 
> > > > *intel_connector)
> > > > intel_dp->max_link_rate = 
> > > > intel_dp_max_common_rate(intel_dp);
> > > >  
> > > > intel_dp->reset_link_params = false;
> > > > +   intel_dp->train_set_valid = false;
> > > > }
> > > >  
> > > > intel_dp_print_rates(intel_dp);
> > > > @@ -5979,6 +5980,7 @@ intel_dp_init_connector(struct intel_digital_port 
> > > > *intel_dig_port,
> > > > intel_dp_set_source_rates(intel_dp);
> > > >  
> > > > intel_dp->reset_link_params = true;
> > > > +   intel_dp->train_set_valid = false;
> > > > 

Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP

[Manasi Navare]

On Thu, Aug 17, 2017 at 07:01:05AM +, Rodrigo Vivi wrote:
>On Wed, Aug 16, 2017 at 11:51 PM Manasi Navare
><[1]manasi.d.nav...@intel.com> wrote:
> 
>  In case of eDP because the panel has a fixed mode we cannot
>  link train fallback and prune modes since this results in
>  no modes available for eDP connector.
> 
>What about downclock modes?!

What are the downclock modes? We have seen an issue with pruning modes
in case of eDP panel where we end up pruning the mode due to link train
fallback and then we get an error saying "No modes available for the
connector"

> 
>  Also since its a panel, link training should not fail dynamically
>  based on cable conditions like in  case of DP.
> 
>Is there any bug associated with this patch?

Yes this is the bug:
https://bugs.freedesktop.org/show_bug.cgi?id=101518
But the reason I didnt have this in the Fixes tab is because
this patch will not fix the bug, it will just isolate to it being
a bug with AUX Timeouts warning.

Regards
Manasi

> 
>  Cc: Jani Nikula <[2]jani.nik...@linux.intel.com>
>  Cc: Jim Bride <[3]jim.br...@linux.intel.com>
>  Cc: Ville Syrjälä <[4]ville.syrj...@linux.intel.com>
>  Cc: Daniel Vetter <[5]daniel.vet...@intel.com>
>  Signed-off-by: Manasi Navare <[6]manasi.d.nav...@intel.com>
>  ---
>   drivers/gpu/drm/i915/intel_dp.c   | 2 +-
>   drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++-
>   drivers/gpu/drm/i915/intel_drv.h  | 1 +
>   3 files changed, 4 insertions(+), 2 deletions(-)
>  diff --git a/drivers/gpu/drm/i915/intel_dp.c
>  b/drivers/gpu/drm/i915/intel_dp.c
>  index 4fd4853..edac0c8 100644
>  --- a/drivers/gpu/drm/i915/intel_dp.c
>  +++ b/drivers/gpu/drm/i915/intel_dp.c
>  @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000,
>  27, 54 };
>* If a CPU or PCH DP output is attached to an eDP panel, this
>  function
>* will return true, and false otherwise.
>*/
>  -static bool is_edp(struct intel_dp *intel_dp)
>  +bool is_edp(struct intel_dp *intel_dp)
>   {
>  struct intel_digital_port *intel_dig_port =
>  dp_to_dig_port(intel_dp);
>  diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
>  b/drivers/gpu/drm/i915/intel_dp_link_training.c
>  index 05907fa..18ec61f 100644
>  --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
>  +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
>  @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp
>  *intel_dp)
>intel_connector->[7]base.base.id,
>intel_connector->[8]base.name,
>intel_dp->link_rate, intel_dp->lane_count);
>  -   if (!intel_dp_get_link_train_fallback_values(intel_dp,
>  +   /* Dont fallback and prune modes if its eDP */
>  +   if (!is_edp(intel_dp) &&
>  !intel_dp_get_link_train_fallback_values(intel_dp,
> 
>  intel_dp->link_rate,
> 
>  intel_dp->lane_count))
>  /* Schedule a Hotplug Uevent to userspace to start
>  modeset */
>  diff --git a/drivers/gpu/drm/i915/intel_drv.h
>  b/drivers/gpu/drm/i915/intel_drv.h
>  index fa47285..9800a15 100644
>  --- a/drivers/gpu/drm/i915/intel_drv.h
>  +++ b/drivers/gpu/drm/i915/intel_drv.h
>  @@ -1548,6 +1548,7 @@ static inline unsigned int
>  intel_dp_unused_lane_mask(int lane_count)
>   }
>   bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
>  +bool is_edp(struct intel_dp *intel_dp);
>   int intel_dp_link_required(int pixel_clock, int bpp);
>   int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
>   bool intel_digital_port_connected(struct drm_i915_private
>  *dev_priv,
>  --
>  2.1.4
>  ___
>  Intel-gfx mailing list
>  [9]Intel-gfx@lists.freedesktop.org
>  [10]https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> References
> 
>1. mailto:manasi.d.nav...@intel.com
>2. mailto:jani.nik...@linux.intel.com
>3. mailto:jim.br...@linux.intel.com
>4. mailto:ville.syrj...@linux.intel.com
>5. mailto:daniel.vet...@intel.com
>6. mailto:manasi.d.nav...@intel.com
>7. http://base.base.id/
>8. http://base.name/
>9. mailto:Intel-gfx@lists.freedesktop.org
>   10. 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] drm/i915: Do not do link training fallback or prune modes for eDP

[Manasi Navare]

On Thu, Aug 17, 2017 at 12:28:56PM -0700, Pandiyan, Dhinakaran wrote:
> On Thu, 2017-08-17 at 12:29 -0700, Manasi Navare wrote:
> > On Thu, Aug 17, 2017 at 12:51:27PM +0300, Jani Nikula wrote:
> > > On Wed, 16 Aug 2017, Manasi Navare  wrote:
> > > > In case of eDP because the panel has a fixed mode we cannot
> > > > link train fallback and prune modes since this results in
> > > > no modes available for eDP connector.
> > > > Also since its a panel, link training should not fail dynamically
> > > > based on cable conditions like in  case of DP.
> > > >
> > > > Cc: Jani Nikula 
> > > > Cc: Jim Bride 
> > > > Cc: Ville Syrjälä 
> > > > Cc: Daniel Vetter 
> > > > Signed-off-by: Manasi Navare 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp.c   | 2 +-
> > > >  drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++-
> > > >  drivers/gpu/drm/i915/intel_drv.h  | 1 +
> > > >  3 files changed, 4 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 4fd4853..edac0c8 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000, 
> > > > 27, 54 };
> > > >   * If a CPU or PCH DP output is attached to an eDP panel, this function
> > > >   * will return true, and false otherwise.
> > > >   */
> > > > -static bool is_edp(struct intel_dp *intel_dp)
> > > > +bool is_edp(struct intel_dp *intel_dp)
> > > 
> > > Make that intel_dp_is_edp when you expose it outside of intel_dp.c
> > > 
> > > BR,
> > > Jani
> > > 
> > 
> > Yea renaming it as intel_dp_is_edp() makes sense after making it a non 
> > static function.
> > So should I make a seperate patch for this change and changing the name at 
> > all places
> > that call is_edp() currently?
> > 
> > Regards
> > Manasi
> > 
> 
> Don't we already have a intel_dp_is_edp() that checks VBT? That'll need
> to be renamed if is_edp() is going to become intel_dp_is_edp() 
>

Yes just noticed we do have that intel_dp_is_edp().
But I agree that we need to add intel_dp prefix if we are going
to expose the is_edp() function.
Do you have any suggestions for the name?
 
> Btw I remember seeing Jim's psr patch making this function
> global(non-static?) too.
>

Yes I have looked at it and that patch is still in review, 
so this review comment applies to his patch as well.
So either he makes this change in his or it happens here.
I plan to add this comment to Jim's PSR patch review too.

Regards
Manasi
> 
> > > >  {
> > > > struct intel_digital_port *intel_dig_port = 
> > > > dp_to_dig_port(intel_dp);
> > > >  
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> > > > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > index 05907fa..18ec61f 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
> > > >   intel_connector->base.base.id,
> > > >   intel_connector->base.name,
> > > >   intel_dp->link_rate, intel_dp->lane_count);
> > > > -   if (!intel_dp_get_link_train_fallback_values(intel_dp,
> > > > +   /* Dont fallback and prune modes if its eDP */
> > > > +   if (!is_edp(intel_dp) && 
> > > > !intel_dp_get_link_train_fallback_values(intel_dp,
> > > >  
> > > > intel_dp->link_rate,
> > > >  
> > > > intel_dp->lane_count))
> > > > /* Schedule a Hotplug Uevent to userspace to start 
> > > > modeset */
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > index fa47285..9800a15 100644
> > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > @@ -1548,6 +1548,7 @@ static inline unsigned int 
> > > > intel_dp_unused_lane_mask(int lane_count)
> > > >  }
> > > >  
> > > >  bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > > > +bool is_edp(struct intel_dp *intel_dp);
> > > >  int intel_dp_link_required(int pixel_clock, int bpp);
> > > >  int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> > > >  bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
> > > 
> > > -- 
> > > 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 mailing list
Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP

[Pandiyan, Dhinakaran]

On Thu, 2017-08-17 at 12:29 -0700, Manasi Navare wrote:
> On Thu, Aug 17, 2017 at 12:51:27PM +0300, Jani Nikula wrote:
> > On Wed, 16 Aug 2017, Manasi Navare  wrote:
> > > In case of eDP because the panel has a fixed mode we cannot
> > > link train fallback and prune modes since this results in
> > > no modes available for eDP connector.
> > > Also since its a panel, link training should not fail dynamically
> > > based on cable conditions like in  case of DP.
> > >
> > > Cc: Jani Nikula 
> > > Cc: Jim Bride 
> > > Cc: Ville Syrjälä 
> > > Cc: Daniel Vetter 
> > > Signed-off-by: Manasi Navare 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c   | 2 +-
> > >  drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++-
> > >  drivers/gpu/drm/i915/intel_drv.h  | 1 +
> > >  3 files changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 4fd4853..edac0c8 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000, 27, 
> > > 54 };
> > >   * If a CPU or PCH DP output is attached to an eDP panel, this function
> > >   * will return true, and false otherwise.
> > >   */
> > > -static bool is_edp(struct intel_dp *intel_dp)
> > > +bool is_edp(struct intel_dp *intel_dp)
> > 
> > Make that intel_dp_is_edp when you expose it outside of intel_dp.c
> > 
> > BR,
> > Jani
> > 
> 
> Yea renaming it as intel_dp_is_edp() makes sense after making it a non static 
> function.
> So should I make a seperate patch for this change and changing the name at 
> all places
> that call is_edp() currently?
> 
> Regards
> Manasi
> 

Don't we already have a intel_dp_is_edp() that checks VBT? That'll need
to be renamed if is_edp() is going to become intel_dp_is_edp() 

Btw I remember seeing Jim's psr patch making this function
global(non-static?) too.


> > >  {
> > >   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > >  
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> > > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > index 05907fa..18ec61f 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
> > > intel_connector->base.base.id,
> > > intel_connector->base.name,
> > > intel_dp->link_rate, intel_dp->lane_count);
> > > - if (!intel_dp_get_link_train_fallback_values(intel_dp,
> > > + /* Dont fallback and prune modes if its eDP */
> > > + if (!is_edp(intel_dp) && 
> > > !intel_dp_get_link_train_fallback_values(intel_dp,
> > >intel_dp->link_rate,
> > >intel_dp->lane_count))
> > >   /* Schedule a Hotplug Uevent to userspace to start modeset */
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index fa47285..9800a15 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -1548,6 +1548,7 @@ static inline unsigned int 
> > > intel_dp_unused_lane_mask(int lane_count)
> > >  }
> > >  
> > >  bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > > +bool is_edp(struct intel_dp *intel_dp);
> > >  int intel_dp_link_required(int pixel_clock, int bpp);
> > >  int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> > >  bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
> > 
> > -- 
> > 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 mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP

[Manasi Navare]

On Thu, Aug 17, 2017 at 12:51:27PM +0300, Jani Nikula wrote:
> On Wed, 16 Aug 2017, Manasi Navare  wrote:
> > In case of eDP because the panel has a fixed mode we cannot
> > link train fallback and prune modes since this results in
> > no modes available for eDP connector.
> > Also since its a panel, link training should not fail dynamically
> > based on cable conditions like in  case of DP.
> >
> > Cc: Jani Nikula 
> > Cc: Jim Bride 
> > Cc: Ville Syrjälä 
> > Cc: Daniel Vetter 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c   | 2 +-
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++-
> >  drivers/gpu/drm/i915/intel_drv.h  | 1 +
> >  3 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 4fd4853..edac0c8 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000, 27, 
> > 54 };
> >   * If a CPU or PCH DP output is attached to an eDP panel, this function
> >   * will return true, and false otherwise.
> >   */
> > -static bool is_edp(struct intel_dp *intel_dp)
> > +bool is_edp(struct intel_dp *intel_dp)
> 
> Make that intel_dp_is_edp when you expose it outside of intel_dp.c
> 
> BR,
> Jani
> 

Yea renaming it as intel_dp_is_edp() makes sense after making it a non static 
function.
So should I make a seperate patch for this change and changing the name at all 
places
that call is_edp() currently?

Regards
Manasi

> >  {
> > struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 05907fa..18ec61f 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
> >   intel_connector->base.base.id,
> >   intel_connector->base.name,
> >   intel_dp->link_rate, intel_dp->lane_count);
> > -   if (!intel_dp_get_link_train_fallback_values(intel_dp,
> > +   /* Dont fallback and prune modes if its eDP */
> > +   if (!is_edp(intel_dp) && 
> > !intel_dp_get_link_train_fallback_values(intel_dp,
> >  intel_dp->link_rate,
> >  intel_dp->lane_count))
> > /* Schedule a Hotplug Uevent to userspace to start modeset */
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index fa47285..9800a15 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1548,6 +1548,7 @@ static inline unsigned int 
> > intel_dp_unused_lane_mask(int lane_count)
> >  }
> >  
> >  bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > +bool is_edp(struct intel_dp *intel_dp);
> >  int intel_dp_link_required(int pixel_clock, int bpp);
> >  int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> >  bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
> 
> -- 
> 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 v5] drm/i915/edp: Be less aggressive about changing link config on eDP

[Manasi Navare]

On Thu, Aug 17, 2017 at 10:50:04AM -0700, Jim Bride wrote:
> On Wed, Aug 16, 2017 at 03:13:06PM -0700, Manasi Navare wrote:
> > On Wed, Aug 09, 2017 at 02:21:07PM -0700, Jim Bride wrote:
> > > This set of changes has some history to them.  There were several attempts
> > > to add what was called "fast link training" to i915, which actually wasn't
> > > fast link training as per the DP spec.  These changes were:
> > > 
> > > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > 
> > > which were eventually hand-reverted by:
> > > 
> > > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> > >  feature")
> > > 
> > > in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had some
> > > very bad side-effects on PSR functionality on Skylake. The issue at
> > > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> > > (depending on the original link configuration) in order to quickly get
> > > the source and sink back in synchronization across the link before handing
> > > control back to the i915.  There's an assumption that none of the link
> > > configuration information has changed (and thus it's still valid) since 
> > > the
> > > last full link training operation.  The revert above was identified via a
> > > bisect as the cause of some of Skylake's PSR woes.  This patch, largely
> > > based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > puts the eDP portions of this patch back in place.  None of the flickering
> > > issues that spurred the revert have been seen, and I suspect the real
> > > culprits here were addressed by some of the recent link training changes
> > > that Manasi has implemented, and PSR on Skylake is definitely more happy
> > > with these changes in-place.
> > > 
> > > v2 and v3: Rebase
> > > v4: * Clean up accesses to train_set_valid a bit for easier
> > >   reading. (Chris)
> > > * Rebase
> > > v5: * Checkpatch cleanup
> > > * Rebase
> > > 
> > > Cc: Chris Wilson 
> > > Cc: Rodrigo Vivi 
> > > Cc: Paulo Zanoni 
> > > Cc: Manasi D Navare 
> > > Cc: Mika Kahola 
> > > Cc: Jani Nikula 
> > > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training 
> > > feature")
> > > Signed-off-by: Jim Bride 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c   |  4 +++-
> > >  drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++-
> > >  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
> > >  3 files changed, 19 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 76c8a0b..4bd409c 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 27, 
> > > 54 };
> > >   * If a CPU or PCH DP output is attached to an eDP panel, this function
> > >   * will return true, and false otherwise.
> > >   */
> > > -static bool is_edp(struct intel_dp *intel_dp)
> > > +bool is_edp(struct intel_dp *intel_dp)
> > >  {
> > >   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > >  
> > > @@ -4711,6 +4711,7 @@ intel_dp_long_pulse(struct intel_connector 
> > > *intel_connector)
> > >   intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> > >  
> > >   intel_dp->reset_link_params = false;
> > > + intel_dp->train_set_valid = false;
> > >   }
> > >  
> > >   intel_dp_print_rates(intel_dp);
> > > @@ -5979,6 +5980,7 @@ intel_dp_init_connector(struct intel_digital_port 
> > > *intel_dig_port,
> > >   intel_dp_set_source_rates(intel_dp);
> > >  
> > >   intel_dp->reset_link_params = true;
> > > + intel_dp->train_set_valid = false;
> > >   intel_dp->pps_pipe = INVALID_PIPE;
> > >   intel_dp->active_pipe = INVALID_PIPE;
> > >  
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> > > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > index 05907fa..67032cf 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > @@ -94,7 +94,8 @@ static bool
> > >  intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > >   uint8_t dp_train_pat)
> > >  {
> > > - memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > > + if (!intel_dp->train_set_valid)
> > > + memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > >   intel_dp_set_signal_levels(intel_dp);
> > >   return intel_dp_set_link_train(intel_dp, dp_train_pat);
> > >  }
> > > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct 
> > > intel_dp *intel_dp)
> > >  

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Enable Audio Pin Buffer.

[Pandiyan, Dhinakaran]

On Thu, 2017-08-17 at 18:55 +, Vivi, Rodrigo wrote:
> On Thu, 2017-08-17 at 09:26 +0530, Sanyog Kale wrote:
> > On Wed, Aug 16, 2017 at 06:46:26PM -0500, Pandiyan, Dhinakaran wrote:
> > > On Thu, 2017-07-06 at 14:03 -0700, Rodrigo Vivi wrote:
> > > > Starting on CNL, we need to enable Audio Pin Buffer.
> > > > 
> > > > By the spec it seems that this is part of audio programming,
> > > 
> > > I am not very clear where the pin buffer enabling/disabling step falls
> > > in the audio programming sequence. From what I understand, audio codec
> > > enable/disable is controlled by i915, if pin buffer enable/disable is
> > > part of that, then we don't need a call back. It's difficult to know
> > > where this function is going to be used without seeing the audio driver
> > > patch that makes of use of this.
> 
> Sanyog, I couldn't find all the old emails with spec pointing out the
> time that we needed to set this bit. Do you still have?
> Anything you could share when publishing the patches?
> 
> > >
> > 
> > From audio point of view, we are working on correct sequence where this ops
> > will be called. However during CNL Power-ON we enabled the pin buf using ops
> > as part of azx_reset.
> 
> Ok, so let's put this on hold while audio drivers are not ready.
> It will be on internal branch anyways.
> When audio driver gets ready we re-submit all together.
> 

That makes a lot of sense to me.

> >  
> > > > so let's give them the hability to set/unset this as needed.
> > > 
> > > typo s/hability/ability
> > > > 
> > > > v2: With a hook so audio driver can control it.
> > > > v3: Put back reg definition lost on v2.
> > > > 
> > > > Cc: Dhinakaran Pandiyan 
> > > > Cc: Jani Nikula 
> > > > Cc: Sanyog Kale 
> > > > Signed-off-by: Rodrigo Vivi 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_reg.h|  3 +++
> > > >  drivers/gpu/drm/i915/intel_audio.c | 16 
> > > >  include/drm/i915_component.h   |  6 ++
> > > >  3 files changed, 25 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > index 64cc674..aab38da 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -2643,6 +2643,9 @@ enum skl_disp_power_wells {
> > > >  #define I915_HDMI_LPE_AUDIO_BASE   (VLV_DISPLAY_BASE + 0x65000)
> > > >  #define I915_HDMI_LPE_AUDIO_SIZE   0x1000
> > > >  
> > > > +#define AUDIO_PIN_BUF_CTL  _MMIO(0x48414)
> > > > +#define AUDIO_PIN_BUF_ENABLE   (1 << 31)
> > > > +
> > > >  /* DisplayPort Audio w/ LPE */
> > > >  #define VLV_AUD_CHICKEN_BIT_REG_MMIO(VLV_DISPLAY_BASE 
> > > > + 0x62F38)
> > > >  #define VLV_CHICKEN_BIT_DBG_ENABLE (1 << 0)
> > > > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > > > b/drivers/gpu/drm/i915/intel_audio.c
> > > > index d805b6e..0c83254 100644
> > > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > > @@ -865,6 +865,21 @@ static int i915_audio_component_get_eld(struct 
> > > > device *kdev, int port,
> > > > return ret;
> > > >  }
> > > >  
> > > > +static void i915_audio_component_pin_buf(struct device *kdev, bool 
> > > > enable)
> > > > +{
> > > 
> > > Does it matter whether the audio codec is enabled or disabled when this
> > > call comes in? i.e., do we need some sort of check here? Or do we assume
> > > the audio driver knows exactly when to enable or disable pin buffer?
> > > 
> > > 
> > > 
> > > > +   struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
> > > > +
> > > > +   if (!IS_CANNONLAKE(dev_priv))
> > > 
> > > Should this be a INTEL_GEN() < 10 since the register is gen10+? I am not
> > > particular about either of the options.
> > > 
> > > > +   return;
> > > > +
> > > > +   if (enable)
> > > > +   I915_WRITE(AUDIO_PIN_BUF_CTL, 
> > > > I915_READ(AUDIO_PIN_BUF_CTL) |
> > > > +  AUDIO_PIN_BUF_ENABLE);
> > > > +   else
> > > > +   I915_WRITE(AUDIO_PIN_BUF_CTL, 
> > > > I915_READ(AUDIO_PIN_BUF_CTL) &
> > > > +  ~AUDIO_PIN_BUF_ENABLE);
> > > > +}
> > > > +
> > > >  static const struct i915_audio_component_ops i915_audio_component_ops 
> > > > = {
> > > > .owner  = THIS_MODULE,
> > > > .get_power  = i915_audio_component_get_power,
> > > > @@ -873,6 +888,7 @@ static int i915_audio_component_get_eld(struct 
> > > > device *kdev, int port,
> > > > .get_cdclk_freq = i915_audio_component_get_cdclk_freq,
> > > > .sync_audio_rate = i915_audio_component_sync_audio_rate,
> > > > .get_eld= i915_audio_component_get_eld,
> > > > +   .pin_buf= i915_audio_component_pin_buf,
> > > >  };
> > > >  
> > > >  static int i915_audio_component_bind(struct device *i915_kdev,
> > > > diff 

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Enable Audio Pin Buffer.

[Vivi, Rodrigo]

On Thu, 2017-08-17 at 09:26 +0530, Sanyog Kale wrote:
> On Wed, Aug 16, 2017 at 06:46:26PM -0500, Pandiyan, Dhinakaran wrote:
> > On Thu, 2017-07-06 at 14:03 -0700, Rodrigo Vivi wrote:
> > > Starting on CNL, we need to enable Audio Pin Buffer.
> > > 
> > > By the spec it seems that this is part of audio programming,
> > 
> > I am not very clear where the pin buffer enabling/disabling step falls
> > in the audio programming sequence. From what I understand, audio codec
> > enable/disable is controlled by i915, if pin buffer enable/disable is
> > part of that, then we don't need a call back. It's difficult to know
> > where this function is going to be used without seeing the audio driver
> > patch that makes of use of this.

Sanyog, I couldn't find all the old emails with spec pointing out the
time that we needed to set this bit. Do you still have?
Anything you could share when publishing the patches?

> >
> 
> From audio point of view, we are working on correct sequence where this ops
> will be called. However during CNL Power-ON we enabled the pin buf using ops
> as part of azx_reset.

Ok, so let's put this on hold while audio drivers are not ready.
It will be on internal branch anyways.
When audio driver gets ready we re-submit all together.

>  
> > > so let's give them the hability to set/unset this as needed.
> > 
> > typo s/hability/ability
> > > 
> > > v2: With a hook so audio driver can control it.
> > > v3: Put back reg definition lost on v2.
> > > 
> > > Cc: Dhinakaran Pandiyan 
> > > Cc: Jani Nikula 
> > > Cc: Sanyog Kale 
> > > Signed-off-by: Rodrigo Vivi 
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h|  3 +++
> > >  drivers/gpu/drm/i915/intel_audio.c | 16 
> > >  include/drm/i915_component.h   |  6 ++
> > >  3 files changed, 25 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 64cc674..aab38da 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -2643,6 +2643,9 @@ enum skl_disp_power_wells {
> > >  #define I915_HDMI_LPE_AUDIO_BASE (VLV_DISPLAY_BASE + 0x65000)
> > >  #define I915_HDMI_LPE_AUDIO_SIZE 0x1000
> > >  
> > > +#define AUDIO_PIN_BUF_CTL_MMIO(0x48414)
> > > +#define AUDIO_PIN_BUF_ENABLE (1 << 31)
> > > +
> > >  /* DisplayPort Audio w/ LPE */
> > >  #define VLV_AUD_CHICKEN_BIT_REG  _MMIO(VLV_DISPLAY_BASE + 
> > > 0x62F38)
> > >  #define VLV_CHICKEN_BIT_DBG_ENABLE   (1 << 0)
> > > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > > b/drivers/gpu/drm/i915/intel_audio.c
> > > index d805b6e..0c83254 100644
> > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > @@ -865,6 +865,21 @@ static int i915_audio_component_get_eld(struct 
> > > device *kdev, int port,
> > >   return ret;
> > >  }
> > >  
> > > +static void i915_audio_component_pin_buf(struct device *kdev, bool 
> > > enable)
> > > +{
> > 
> > Does it matter whether the audio codec is enabled or disabled when this
> > call comes in? i.e., do we need some sort of check here? Or do we assume
> > the audio driver knows exactly when to enable or disable pin buffer?
> > 
> > 
> > 
> > > + struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
> > > +
> > > + if (!IS_CANNONLAKE(dev_priv))
> > 
> > Should this be a INTEL_GEN() < 10 since the register is gen10+? I am not
> > particular about either of the options.
> > 
> > > + return;
> > > +
> > > + if (enable)
> > > + I915_WRITE(AUDIO_PIN_BUF_CTL, I915_READ(AUDIO_PIN_BUF_CTL) |
> > > +AUDIO_PIN_BUF_ENABLE);
> > > + else
> > > + I915_WRITE(AUDIO_PIN_BUF_CTL, I915_READ(AUDIO_PIN_BUF_CTL) &
> > > +~AUDIO_PIN_BUF_ENABLE);
> > > +}
> > > +
> > >  static const struct i915_audio_component_ops i915_audio_component_ops = {
> > >   .owner  = THIS_MODULE,
> > >   .get_power  = i915_audio_component_get_power,
> > > @@ -873,6 +888,7 @@ static int i915_audio_component_get_eld(struct device 
> > > *kdev, int port,
> > >   .get_cdclk_freq = i915_audio_component_get_cdclk_freq,
> > >   .sync_audio_rate = i915_audio_component_sync_audio_rate,
> > >   .get_eld= i915_audio_component_get_eld,
> > > + .pin_buf= i915_audio_component_pin_buf,
> > >  };
> > >  
> > >  static int i915_audio_component_bind(struct device *i915_kdev,
> > > diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
> > > index 545c6e0..b8875d4 100644
> > > --- a/include/drm/i915_component.h
> > > +++ b/include/drm/i915_component.h
> > > @@ -79,6 +79,12 @@ struct i915_audio_component_ops {
> > >*/
> > >   int (*get_eld)(struct device *, int port, int pipe, bool *enabled,
> > >  unsigned char *buf, int max_bytes);
> > > + /**
> > > +  * @pin_buf: Enable or disable pin 

Re: [Intel-gfx] [PATCH 3/3] drm/i915/cnl: Avoid old DDI translation functions on Cannonlake.

[Vivi, Rodrigo]

On Thu, 2017-08-17 at 15:59 +0300, Mika Kahola wrote:
> On Thu, 2017-07-06 at 13:54 -0700, Rodrigo Vivi wrote:
> > Cannonlake uses a different swing voltage initalization
> > sequence scheme that doesn't require these old functions.
> > 
> > All other DDI, voltage swing and PLLs initialialization
> > and configuration are already in place for Cannonlake.
> > This patch only removes unecessary steps probably saving
> > us from some useless warnings.
> > 
> > Cc: Clint Taylor 
> > Cc: Mika Kahola 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 80e96f1..9e9bfbe 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -596,7 +596,7 @@ static int intel_ddi_hdmi_level(struct
> > drm_i915_private *dev_priv, enum port por
> >  
> > hdmi_level = dev_priv-
> > >vbt.ddi_port_info[port].hdmi_level_shift;
> >  
> > -   if (IS_GEN9_LP(dev_priv))
> > +   if (IS_GEN9_LP(dev_priv) || INTEL_GEN(dev_priv) >= 10)
> Can we assume that this holds always for GEN10 and above platforms?

Hi Mika, thanks for looking, but please ignore this patch here.

I should have told earlier, sorry, but this patch should be replaced by:

https://patchwork.freedesktop.org/series/28883/

reviews and suggestions there are welcome...

Thanks,
Rodrigo.

>  
> > return hdmi_level;
> >  
> > if (IS_GEN9_BC(dev_priv)) {
> > @@ -688,7 +688,7 @@ static void intel_prepare_dp_ddi_buffers(struct
> > intel_encoder *encoder)
> > enum port port = intel_ddi_get_encoder_port(encoder);
> > const struct ddi_buf_trans *ddi_translations;
> >  
> > -   if (IS_GEN9_LP(dev_priv))
> > +   if (IS_GEN9_LP(dev_priv) || INTEL_GEN(dev_priv) >= 10)
> > return;
> >  
> > switch (encoder->type) {
> > @@ -741,7 +741,7 @@ static void intel_prepare_hdmi_ddi_buffers(struct
> > intel_encoder *encoder)
> > enum port port = intel_ddi_get_encoder_port(encoder);
> > const struct ddi_buf_trans *ddi_translations_hdmi;
> >  
> > -   if (IS_GEN9_LP(dev_priv))
> > +   if (IS_GEN9_LP(dev_priv) || INTEL_GEN(dev_priv) >= 10)
> > return;
> >  
> > hdmi_level = intel_ddi_hdmi_level(dev_priv, port);

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

Re: [Intel-gfx] [maintainer-tools PATCH] dim.rst: Document aliases extension on dimrc.

[Rodrigo Vivi]

On Thu, Aug 17, 2017 at 10:33 AM, Jani Nikula  wrote:
> On Thu, 17 Aug 2017, Rodrigo Vivi  wrote:
>> On my own workflow I was missing a way to download mboxes
>> directly from patchwork with the patchwork id. So my first
>> reflex was to modify dim to fulfil my needs. However that
>> was increasing dim in complexity and dependencies and leaving
>> that messy.
>>
>> That was when Jani suggested me the dimrc extension with the
>> example that is now part of this spec.
>>
>> That was clean and simple enough to understand, so Daniel
>> suggested me to add it to the spec.
>>
>> For record let's put my final local solution that lays now on
>> my own ~/.dimrc
>>
>> dim_pwaq()
>> {
>>   if [ -n "$1" ]; then
>>   curl https://patchwork.freedesktop.org/patch/$1/mbox/ | 
>> dim_apply_queued
>>   else
>>   echo "Give me a patchwork id"
>>   fi
>> }
>>
>> Cc: Jani Nikula 
>> Cc: Daniel Vetter 
>> Signed-off-by: Rodrigo Vivi 
>> ---
>>  dim.rst | 16 
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/dim.rst b/dim.rst
>> index 802c776e03f9..c6728d186554 100644
>> --- a/dim.rst
>> +++ b/dim.rst
>> @@ -441,6 +441,22 @@ usage
>>  Short form usage help listing all subcommands. Run by default or if an 
>> unknown
>>  subcommand was passed on the cmdline.
>>
>> +ALIASES
>> +===
>> +
>> +Extending **dim** functionalities
>> +-
>> +
>> +It is possible to create your own dim helper and aliases by adding them to 
>> \$HOME/.dimrc
>> +
>> +dim_my_fancy_list_aliases()
>> +{
>> + echo "Hello world!"
>> + dim_list_aliases
>> +}
>> +
>> +dim_alias_list_aliases=my-fancy-list-aliases
>> +
>
> Naughty, naughty:
>
> $ make check
> shellcheck -e SC2001 -e SC2034 -e SC2046 -e SC2086 -e SC2115 -e SC2119 -e 
> SC2120 -e SC2143 dim bash_completion
> rst2man --strict --no-raw dim.rst >/dev/null
> dim.rst:453: (INFO/1) Possible title underline, too short for the title.
> Treating it as ordinary text because it's so short.
> Exiting due to level-1 (INFO) system message.
> Makefile:49: recipe for target 'mancheck' failed
> make: *** [mancheck] Error 1

hm... it seems I need to update my shellcheck package... what version
do you use?
here shellcheck complains in non-sense stuff and make check doesn't
proceed to that point...


>
>
> BR,
> Jani.
>
>
>>  ENVIRONMENT
>>  ===
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [maintainer-tools PATCH] dim: Properly handle series on apply_branch

[Rodrigo Vivi]

So far we could use *dim* to apply a whole series
in a mbox, but only the very last patch was receiving
all the checks and patchwork link.

So this patch remove this limitation by using git mailsplit
to split the mbox and than use git am and checks individually
on each patch.

Cc: Jani Nikula 
Cc: Daniel Vetter 
Signed-off-by: Rodrigo Vivi 
---
 dim | 45 +
 1 file changed, 25 insertions(+), 20 deletions(-)

diff --git a/dim b/dim
index 11aa675cc3bc..5457006631d6 100755
--- a/dim
+++ b/dim
@@ -767,38 +767,43 @@ function dim_apply_branch
branch=${1:?$usage}
shift
file=$(mktemp)
+   dir=$(mktemp -d)
 
assert_branch $branch
assert_repo_clean
 
+   committer_email=$(git_committer_email)
+
cat > $file
+   git mailsplit -o$dir $file > /dev/null
 
-   message_id=$(message_get_id $file)
+   for patch in `ls $dir`; do
 
-   committer_email=$(git_committer_email)
+   message_id=$(message_get_id $dir/$patch)
 
-   patch_from=$(grep "From:" "$file" | head -1)
-   if [[ "$patch_from" != *"$committer_email"* ]] ; then
-   sob=-s
-   fi
+   patch_from=$(grep "From:" "$dir/$patch" | head -1)
+   if [[ "$patch_from" != *"$committer_email"* ]] ; then
+   sob=-s
+   fi
 
-   git am --scissors -3 $sob "$@" $file
+   git am --scissors -3 $sob "$@" $dir/$patch
 
-   if [ -n "$message_id" ]; then
-   dim_commit_add_tag "Link: 
https://patchwork.freedesktop.org/patch/msgid/$message_id;
-   else
-   echoerr "WARNING: No message-id found in the patch file."
-   rv=1
-   fi
+   if [ -n "$message_id" ]; then
+   dim_commit_add_tag "Link: 
https://patchwork.freedesktop.org/patch/msgid/$message_id;
+   else
+   echoerr "WARNING: No message-id found in the patch 
file."
+   rv=1
+   fi
 
-   if ! checkpatch_commit HEAD; then
-   rv=1
-   fi
-   if ! check_maintainer $branch HEAD; then
-   rv=1
-   fi
+   if ! checkpatch_commit HEAD; then
+   rv=1
+   fi
+   if ! check_maintainer $branch HEAD; then
+   rv=1
+   fi
 
-   eval $DRY $DIM_POST_APPLY_ACTION
+   eval $DRY $DIM_POST_APPLY_ACTION
+   done
 
return $rv
 }
-- 
2.13.2

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

Re: [Intel-gfx] [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP

[Jim Bride]

On Wed, Aug 16, 2017 at 03:13:06PM -0700, Manasi Navare wrote:
> On Wed, Aug 09, 2017 at 02:21:07PM -0700, Jim Bride wrote:
> > This set of changes has some history to them.  There were several attempts
> > to add what was called "fast link training" to i915, which actually wasn't
> > fast link training as per the DP spec.  These changes were:
> > 
> > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > 
> > which were eventually hand-reverted by:
> > 
> > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> >  feature")
> > 
> > in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had some
> > very bad side-effects on PSR functionality on Skylake. The issue at
> > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> > (depending on the original link configuration) in order to quickly get
> > the source and sink back in synchronization across the link before handing
> > control back to the i915.  There's an assumption that none of the link
> > configuration information has changed (and thus it's still valid) since the
> > last full link training operation.  The revert above was identified via a
> > bisect as the cause of some of Skylake's PSR woes.  This patch, largely
> > based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > puts the eDP portions of this patch back in place.  None of the flickering
> > issues that spurred the revert have been seen, and I suspect the real
> > culprits here were addressed by some of the recent link training changes
> > that Manasi has implemented, and PSR on Skylake is definitely more happy
> > with these changes in-place.
> > 
> > v2 and v3: Rebase
> > v4: * Clean up accesses to train_set_valid a bit for easier
> >   reading. (Chris)
> > * Rebase
> > v5: * Checkpatch cleanup
> > * Rebase
> > 
> > Cc: Chris Wilson 
> > Cc: Rodrigo Vivi 
> > Cc: Paulo Zanoni 
> > Cc: Manasi D Navare 
> > Cc: Mika Kahola 
> > Cc: Jani Nikula 
> > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> > Signed-off-by: Jim Bride 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c   |  4 +++-
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++-
> >  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
> >  3 files changed, 19 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 76c8a0b..4bd409c 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 27, 
> > 54 };
> >   * If a CPU or PCH DP output is attached to an eDP panel, this function
> >   * will return true, and false otherwise.
> >   */
> > -static bool is_edp(struct intel_dp *intel_dp)
> > +bool is_edp(struct intel_dp *intel_dp)
> >  {
> > struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> >  
> > @@ -4711,6 +4711,7 @@ intel_dp_long_pulse(struct intel_connector 
> > *intel_connector)
> > intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> >  
> > intel_dp->reset_link_params = false;
> > +   intel_dp->train_set_valid = false;
> > }
> >  
> > intel_dp_print_rates(intel_dp);
> > @@ -5979,6 +5980,7 @@ intel_dp_init_connector(struct intel_digital_port 
> > *intel_dig_port,
> > intel_dp_set_source_rates(intel_dp);
> >  
> > intel_dp->reset_link_params = true;
> > +   intel_dp->train_set_valid = false;
> > intel_dp->pps_pipe = INVALID_PIPE;
> > intel_dp->active_pipe = INVALID_PIPE;
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 05907fa..67032cf 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -94,7 +94,8 @@ static bool
> >  intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > uint8_t dp_train_pat)
> >  {
> > -   memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > +   if (!intel_dp->train_set_valid)
> > +   memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > intel_dp_set_signal_levels(intel_dp);
> > return intel_dp_set_link_train(intel_dp, dp_train_pat);
> >  }
> > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp 
> > *intel_dp)
> >DP_TRAINING_PATTERN_1 |
> >DP_LINK_SCRAMBLING_DISABLE)) {
> > DRM_ERROR("failed to enable link training\n");
> > +   intel_dp->train_set_valid = false;
> > return false;
> >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Stop touching forcewake following a gen6+ engine reset

[Patchwork]

== Series Details ==

Series: drm/i915: Stop touching forcewake following a gen6+ engine reset
URL   : https://patchwork.freedesktop.org/series/28936/
State : success

== Summary ==

Series 28936v1 drm/i915: Stop touching forcewake following a gen6+ engine reset
https://patchwork.freedesktop.org/api/1.0/series/28936/revisions/1/mbox/

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:458s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:437s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:358s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:545s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:523s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:529s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:619s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:445s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:426s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:421s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:509s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:478s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:475s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:601s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:597s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:531s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:471s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:477s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:490s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:444s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:484s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:541s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:409s

e1b18fbd4daecb1c1cf31ca101f64e29a8933bcf drm-tip: 2017y-08m-17d-14h-58m-23s UTC 
integration manifest
289f21608f26 drm/i915: Stop touching forcewake following a gen6+ engine reset

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5431/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Stop touching forcewake following a gen6+ engine reset

[Michel Thierry]

On 17/08/17 10:32, Chris Wilson wrote:

Forcewake is not affected by the engine reset on gen6+. Indeed the
reason why we added intel_uncore_forcewake_reset() to
gen6_reset_engines() was to keep the bookkeeping intact because the
reset did not touch the forcewake bit (yet we cancelled the forcewake
consumers)!  This was done in commit 521198a2e7095:
 Author: Mika Kuoppala 
 Date:   Fri Aug 23 16:52:30 2013 +0300

drm/i915: sanitize forcewake registers on reset

In reset we try to restore the forcewake state to
pre reset state, using forcewake_count. The reset
doesn't seem to clear the forcewake bits so we
get warn on forcewake ack register not clearing.

That futzing of the forcewake bookkeeping was dropped in commit
0294ae7b44bb ("drm/i915: Consolidate forcewake resetting to a single
function"), but it did not make the realisation that the remaining
intel_uncore_forcewake_reset() was redundant.

The new danger with using intel_uncore_forcewake_reset() with per-engine
resets is that the driver and hw are still in an active state as we
perform the reset. We may be using the forcewake to read protected
registers elsewhere and those results may be clobbered by the concurrent
dropping of forcewake.

Reported-by: Michel Thierry 
Fixes: 142bc7d99bcf ("drm/i915: Modify error handler for per engine hang 
recovery")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
---
  drivers/gpu/drm/i915/intel_uncore.c | 7 +--
  1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index deb4430541cf..1d7b879cc68c 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1497,7 +1497,6 @@ static int gen6_reset_engines(struct drm_i915_private 
*dev_priv,
[VECS] = GEN6_GRDOM_VECS,
};
u32 hw_mask;
-   int ret;
  
  	if (engine_mask == ALL_ENGINES) {

hw_mask = GEN6_GRDOM_FULL;
@@ -1509,11 +1508,7 @@ static int gen6_reset_engines(struct drm_i915_private 
*dev_priv,
hw_mask |= hw_engine_mask[engine->id];
}
  
-	ret = gen6_hw_domain_reset(dev_priv, hw_mask);

-
-   intel_uncore_forcewake_reset(dev_priv, true);
-
-   return ret;
+   return gen6_hw_domain_reset(dev_priv, hw_mask);
  }
  
  /**




Thanks for digging out the commit history.

Reviewed-by Michel Thierry 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [maintainer-tools PATCH] dim.rst: Document aliases extension on dimrc.

[Jani Nikula]

On Thu, 17 Aug 2017, Rodrigo Vivi  wrote:
> On my own workflow I was missing a way to download mboxes
> directly from patchwork with the patchwork id. So my first
> reflex was to modify dim to fulfil my needs. However that
> was increasing dim in complexity and dependencies and leaving
> that messy.
>
> That was when Jani suggested me the dimrc extension with the
> example that is now part of this spec.
>
> That was clean and simple enough to understand, so Daniel
> suggested me to add it to the spec.
>
> For record let's put my final local solution that lays now on
> my own ~/.dimrc
>
> dim_pwaq()
> {
>   if [ -n "$1" ]; then
>   curl https://patchwork.freedesktop.org/patch/$1/mbox/ | 
> dim_apply_queued
>   else
>   echo "Give me a patchwork id"
>   fi
> }
>
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Signed-off-by: Rodrigo Vivi 
> ---
>  dim.rst | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/dim.rst b/dim.rst
> index 802c776e03f9..c6728d186554 100644
> --- a/dim.rst
> +++ b/dim.rst
> @@ -441,6 +441,22 @@ usage
>  Short form usage help listing all subcommands. Run by default or if an 
> unknown
>  subcommand was passed on the cmdline.
>  
> +ALIASES
> +===
> +
> +Extending **dim** functionalities
> +-
> +
> +It is possible to create your own dim helper and aliases by adding them to 
> \$HOME/.dimrc
> +
> +dim_my_fancy_list_aliases()
> +{
> + echo "Hello world!"
> + dim_list_aliases
> +}
> +
> +dim_alias_list_aliases=my-fancy-list-aliases
> +

Naughty, naughty:

$ make check
shellcheck -e SC2001 -e SC2034 -e SC2046 -e SC2086 -e SC2115 -e SC2119 -e 
SC2120 -e SC2143 dim bash_completion
rst2man --strict --no-raw dim.rst >/dev/null
dim.rst:453: (INFO/1) Possible title underline, too short for the title.
Treating it as ordinary text because it's so short.
Exiting due to level-1 (INFO) system message.
Makefile:49: recipe for target 'mancheck' failed
make: *** [mancheck] Error 1


BR,
Jani.


>  ENVIRONMENT
>  ===

-- 
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: Stop touching forcewake following a gen6+ engine reset

[Chris Wilson]

Forcewake is not affected by the engine reset on gen6+. Indeed the
reason why we added intel_uncore_forcewake_reset() to
gen6_reset_engines() was to keep the bookkeeping intact because the
reset did not touch the forcewake bit (yet we cancelled the forcewake
consumers)!  This was done in commit 521198a2e7095:
Author: Mika Kuoppala 
Date:   Fri Aug 23 16:52:30 2013 +0300

drm/i915: sanitize forcewake registers on reset

In reset we try to restore the forcewake state to
pre reset state, using forcewake_count. The reset
doesn't seem to clear the forcewake bits so we
get warn on forcewake ack register not clearing.

That futzing of the forcewake bookkeeping was dropped in commit
0294ae7b44bb ("drm/i915: Consolidate forcewake resetting to a single
function"), but it did not make the realisation that the remaining
intel_uncore_forcewake_reset() was redundant.

The new danger with using intel_uncore_forcewake_reset() with per-engine
resets is that the driver and hw are still in an active state as we
perform the reset. We may be using the forcewake to read protected
registers elsewhere and those results may be clobbered by the concurrent
dropping of forcewake.

Reported-by: Michel Thierry 
Fixes: 142bc7d99bcf ("drm/i915: Modify error handler for per engine hang 
recovery")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
---
 drivers/gpu/drm/i915/intel_uncore.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index deb4430541cf..1d7b879cc68c 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1497,7 +1497,6 @@ static int gen6_reset_engines(struct drm_i915_private 
*dev_priv,
[VECS] = GEN6_GRDOM_VECS,
};
u32 hw_mask;
-   int ret;
 
if (engine_mask == ALL_ENGINES) {
hw_mask = GEN6_GRDOM_FULL;
@@ -1509,11 +1508,7 @@ static int gen6_reset_engines(struct drm_i915_private 
*dev_priv,
hw_mask |= hw_engine_mask[engine->id];
}
 
-   ret = gen6_hw_domain_reset(dev_priv, hw_mask);
-
-   intel_uncore_forcewake_reset(dev_priv, true);
-
-   return ret;
+   return gen6_hw_domain_reset(dev_priv, hw_mask);
 }
 
 /**
-- 
2.14.1

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

[Intel-gfx] [maintainer-tools PATCH] dim.rst: Document aliases extension on dimrc.

[Rodrigo Vivi]

On my own workflow I was missing a way to download mboxes
directly from patchwork with the patchwork id. So my first
reflex was to modify dim to fulfil my needs. However that
was increasing dim in complexity and dependencies and leaving
that messy.

That was when Jani suggested me the dimrc extension with the
example that is now part of this spec.

That was clean and simple enough to understand, so Daniel
suggested me to add it to the spec.

For record let's put my final local solution that lays now on
my own ~/.dimrc

dim_pwaq()
{
if [ -n "$1" ]; then
curl https://patchwork.freedesktop.org/patch/$1/mbox/ | 
dim_apply_queued
else
echo "Give me a patchwork id"
fi
}

Cc: Jani Nikula 
Cc: Daniel Vetter 
Signed-off-by: Rodrigo Vivi 
---
 dim.rst | 16 
 1 file changed, 16 insertions(+)

diff --git a/dim.rst b/dim.rst
index 802c776e03f9..c6728d186554 100644
--- a/dim.rst
+++ b/dim.rst
@@ -441,6 +441,22 @@ usage
 Short form usage help listing all subcommands. Run by default or if an unknown
 subcommand was passed on the cmdline.
 
+ALIASES
+===
+
+Extending **dim** functionalities
+-
+
+It is possible to create your own dim helper and aliases by adding them to 
\$HOME/.dimrc
+
+dim_my_fancy_list_aliases()
+{
+   echo "Hello world!"
+   dim_list_aliases
+}
+
+dim_alias_list_aliases=my-fancy-list-aliases
+
 ENVIRONMENT
 ===
 
-- 
2.13.2

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

Re: [Intel-gfx] [maintainer-tools PATCH 2/2] dim: Accept patchwork URLs as apply-branch optional argument.

[Rodrigo Vivi]

On Thu, Aug 17, 2017 at 9:18 AM, Rodrigo Vivi  wrote:
> On Thu, Aug 17, 2017 at 12:45 AM, Jani Nikula  wrote:
>> On Wed, 16 Aug 2017, Rodrigo Vivi  wrote:
>>> On Wed, Aug 16, 2017 at 11:13 AM, Rodrigo Vivi  
>>> wrote:
 Instead of having to manually download mbox from patchwork
 let's make dim to do it directly.

 Cc: Daniel Vetter 
 Cc: Jani Nikula 
 Signed-off-by: Rodrigo Vivi 
 ---
  dim | 18 ++
  1 file changed, 18 insertions(+)

 diff --git a/dim b/dim
 index e98d23b24ec0..73b48da7f436 100755
 --- a/dim
 +++ b/dim
 @@ -756,6 +756,16 @@ function dim_push
 dim_push_branch $(git_current_branch) "$@"
  }

 +function download_mbox
 +{
 +   wget -q --spider ${1}
 +   if [ $? -ne "0" ]; then
 +   echoerr "URL ${1} not found."
 +   exit 1
 +   fi
 +   wget -q ${1} -O $2
 +}
 +
  # ensure we're on branch $1, and apply patches. the rest of the arguments 
 are
  # passed to git am.
  dim_alias_ab=apply-branch
 @@ -772,6 +782,14 @@ function dim_apply_branch
 assert_repo_clean

 case $1 in
 +   *"patchwork.freedesktop.org"*"mbox")
 +   download_mbox $1 $file
 +   shift
 +   ;;
 +   *"patchwork.freedesktop.org"*)
>>>
>>> Another thing that I'd like to do is to be able to give the patchwork
>>> id directly, but I don't want to mess with the $@ going to git
>>> directly so I'm not sure which way would be better...
>>
>> Personally I prefer using message-id based patchwork references:
>>
>> http://patchwork.freedesktop.org/patch/msgid/2017083907.6716-1-jani.nik...@intel.com
>
> well remembered...
> in the end it gets converted to
> https://patchwork.freedesktop.org/patch/171432/
>
> so we can get
> https://patchwork.freedesktop.org/patch/171432/mbox
>
>>
>>> maybe parse for something like
>>> "pw="*)
>>> download_mbox ${1#pw=} $file
>>> so we could use
>>> dim aq pw=170802
>>>
>>> ?
>>> suggestions?
>>
>> The ways around this are argument parsing in apply-branch or adding
>> another dim subcommand.
>
> Usage: dim apply-branch [apply-branch options] branch [--] [git options]
>
> -i  
> -m 
> -u 
>
> hmm but not sure it goes well with the aliases were we would need to convert
>
> dim aq -m 2017083907.6716-1-jani.nik...@intel.com [git options]
> to
> dim apply-branch -m 2017083907.6716-1-jani.nik...@intel.com
> drm-intel-next-queued [git options]

nevermind... please entirely ignore this..

I solved my own needs with:

dim_pwaq()
{
if [ -n "$1" ]; then
curl https://patchwork.freedesktop.org/patch/$1/mbox/
| dim_apply_queued
else
echo "Give me a patchwork id"
fi
}

using as:
$ dim pwaq 172141

>
>>
>> Btw one missing piece is handling series mboxes, which do apply, but
>> only the last commit from an mbox gets all the checks and Link: tags
>> etc.
>
> yeap! well remembered! I suffered from this behaviour already and seen
> other folks also complaining about it.
>
> So, for this should we iterate over patches inside mbox somehow and
> git apply one by one or should we apply and then rebase && amend ?
> not sure how to deal whit this in a cleaner way...

this part is still valid..

>
>>
>>
>> BR,
>> Jani.
>>
>>
>>>
>>>
 +   download_mbox $1/mbox $file
 +   shift
 +   ;;
 *".patch" | *".mbox")
 cat $1 > $file
 shift
 --
 2.13.2

 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>> --
>> Jani Nikula, Intel Open Source Technology Center
>
>
>
> --
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [maintainer-tools PATCH 1/2] dim: Accept .mbox and .patch files as apply-branch optional argument.

[Rodrigo Vivi]

On Thu, Aug 17, 2017 at 12:57 AM, Daniel Vetter  wrote:
> On Thu, Aug 17, 2017 at 10:30:02AM +0300, Jani Nikula wrote:
>> On Wed, 16 Aug 2017, Rodrigo Vivi  wrote:
>> > Instead of forcing users to cat .patch or .mbox let's accept them
>> > as optional argument for dim apply-branches.
>>
>> Well, that's a useless use of cat anyway. You could do
>>
>> $ dim apply-branch branch < patch.mbox
>>
>> > Cc: Daniel Vetter 
>> > Cc: Jani Nikula 
>> > Signed-off-by: Rodrigo Vivi 
>> > ---
>> >  dim | 10 +-
>> >  dim.rst |  2 +-
>> >  2 files changed, 10 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/dim b/dim
>> > index 11aa675cc3bc..e98d23b24ec0 100755
>> > --- a/dim
>> > +++ b/dim
>> > @@ -771,7 +771,15 @@ function dim_apply_branch
>> > assert_branch $branch
>> > assert_repo_clean
>> >
>> > -   cat > $file
>> > +   case $1 in
>> > +   *".patch" | *".mbox")
>> > +   cat $1 > $file
>> > +   shift
>> > +   ;;
>> > +   *)
>> > +   cat > $file
>> > +   ;;
>> > +   esac
>>
>> This would really be a surprising interface, argument parsing based on
>> file suffixes. I don't approve.
>>
>> You'll need to make this handle options before the branch argument,
>> something like:
>>
>> Usage: dim apply-branch [apply-branch options] branch [--] [git options]
>>
>> Is stdin redirection really such a bad thing?
>
> +1 on that. If I pick it from patchwork or an mbox, I just < patch.mbox or
> curl patchwork.url | dim apply. I don't see the value in baking that into
> the script ...

oh, I had missed this before I commented on the other one.
good idea to use curl...

>
> What we could do (and we have a jira for that already) is to check
> patchwork for the updated .mbox with all the r-b/t-b/a-b tags auto-added.
> That would greatly improve at least my workflow.
>
> And I also agree with Jani on keeping the dim design clean. We can add
> stuff where it makes sense, and where dim really can add value (with
> additional safety checks and convenience features).

agree!

>
> One thing we maybe could be doing is a more fancy aliasing feature, along
> the lines of git aliases, where you can do whatever you want. Then you
> could do a dim apply-curl alias which resolves to curl $arg | dim apply.
> Not sure how to implement that though ...

I will try to use and to create my own alias and document it..



> -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



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] lib: Add audio library with dedicated helpers

[Patchwork]

== Series Details ==

Series: series starting with [1/3] lib: Add audio library with dedicated helpers
URL   : https://patchwork.freedesktop.org/series/28929/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
5a17ee2c8f9013f5db852d27564b837f9f2c5a9f tools/intel_vbt_decode: Fix decoding 
of child device structure

with latest DRM-Tip kernel build CI_DRM_2971
e1b18fbd4dae drm-tip: 2017y-08m-17d-14h-58m-23s UTC integration manifest

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test kms_flip:
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-skl-x1585l) fdo#101781

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:451s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:440s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:357s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:555s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:533s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:527s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:610s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:443s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:420s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:419s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:498s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:480s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:477s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:595s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:604s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:463s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:473s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:487s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:445s
fi-skl-x1585ltotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:508s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:546s
fi-snb-2600  total:279  pass:249  dwarn:0   dfail:0   fail:1   skip:29  
time:414s

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_72/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [maintainer-tools PATCH 2/2] dim: Accept patchwork URLs as apply-branch optional argument.

[Rodrigo Vivi]

On Thu, Aug 17, 2017 at 12:45 AM, Jani Nikula  wrote:
> On Wed, 16 Aug 2017, Rodrigo Vivi  wrote:
>> On Wed, Aug 16, 2017 at 11:13 AM, Rodrigo Vivi  
>> wrote:
>>> Instead of having to manually download mbox from patchwork
>>> let's make dim to do it directly.
>>>
>>> Cc: Daniel Vetter 
>>> Cc: Jani Nikula 
>>> Signed-off-by: Rodrigo Vivi 
>>> ---
>>>  dim | 18 ++
>>>  1 file changed, 18 insertions(+)
>>>
>>> diff --git a/dim b/dim
>>> index e98d23b24ec0..73b48da7f436 100755
>>> --- a/dim
>>> +++ b/dim
>>> @@ -756,6 +756,16 @@ function dim_push
>>> dim_push_branch $(git_current_branch) "$@"
>>>  }
>>>
>>> +function download_mbox
>>> +{
>>> +   wget -q --spider ${1}
>>> +   if [ $? -ne "0" ]; then
>>> +   echoerr "URL ${1} not found."
>>> +   exit 1
>>> +   fi
>>> +   wget -q ${1} -O $2
>>> +}
>>> +
>>>  # ensure we're on branch $1, and apply patches. the rest of the arguments 
>>> are
>>>  # passed to git am.
>>>  dim_alias_ab=apply-branch
>>> @@ -772,6 +782,14 @@ function dim_apply_branch
>>> assert_repo_clean
>>>
>>> case $1 in
>>> +   *"patchwork.freedesktop.org"*"mbox")
>>> +   download_mbox $1 $file
>>> +   shift
>>> +   ;;
>>> +   *"patchwork.freedesktop.org"*)
>>
>> Another thing that I'd like to do is to be able to give the patchwork
>> id directly, but I don't want to mess with the $@ going to git
>> directly so I'm not sure which way would be better...
>
> Personally I prefer using message-id based patchwork references:
>
> http://patchwork.freedesktop.org/patch/msgid/2017083907.6716-1-jani.nik...@intel.com

well remembered...
in the end it gets converted to
https://patchwork.freedesktop.org/patch/171432/

so we can get
https://patchwork.freedesktop.org/patch/171432/mbox

>
>> maybe parse for something like
>> "pw="*)
>> download_mbox ${1#pw=} $file
>> so we could use
>> dim aq pw=170802
>>
>> ?
>> suggestions?
>
> The ways around this are argument parsing in apply-branch or adding
> another dim subcommand.

Usage: dim apply-branch [apply-branch options] branch [--] [git options]

-i  
-m 
-u 

hmm but not sure it goes well with the aliases were we would need to convert

dim aq -m 2017083907.6716-1-jani.nik...@intel.com [git options]
to
dim apply-branch -m 2017083907.6716-1-jani.nik...@intel.com
drm-intel-next-queued [git options]

>
> Btw one missing piece is handling series mboxes, which do apply, but
> only the last commit from an mbox gets all the checks and Link: tags
> etc.

yeap! well remembered! I suffered from this behaviour already and seen
other folks also complaining about it.

So, for this should we iterate over patches inside mbox somehow and
git apply one by one or should we apply and then rebase && amend ?
not sure how to deal whit this in a cleaner way...

>
>
> BR,
> Jani.
>
>
>>
>>
>>> +   download_mbox $1/mbox $file
>>> +   shift
>>> +   ;;
>>> *".patch" | *".mbox")
>>> cat $1 > $file
>>> shift
>>> --
>>> 2.13.2
>>>
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [maintainer-tools PATCH 2/2] dim: Accept patchwork URLs as apply-branch optional argument.

[Rodrigo Vivi]

On Thu, Aug 17, 2017 at 12:37 AM, Jani Nikula  wrote:
> On Wed, 16 Aug 2017, Rodrigo Vivi  wrote:
>> Instead of having to manually download mbox from patchwork
>> let's make dim to do it directly.
>>
>> Cc: Daniel Vetter 
>> Cc: Jani Nikula 
>> Signed-off-by: Rodrigo Vivi 
>> ---
>>  dim | 18 ++
>>  1 file changed, 18 insertions(+)
>>
>> diff --git a/dim b/dim
>> index e98d23b24ec0..73b48da7f436 100755
>> --- a/dim
>> +++ b/dim
>> @@ -756,6 +756,16 @@ function dim_push
>>   dim_push_branch $(git_current_branch) "$@"
>>  }
>>
>> +function download_mbox
>> +{
>> + wget -q --spider ${1}
>
> What's the benefit of doing this first?

it check if links exist before trying to download anything.
at least it returns fast when link is not valid

>
>> + if [ $? -ne "0" ]; then
>> + echoerr "URL ${1} not found."
>> + exit 1
>
> Always just return 1 on errors, and set -e will handle the abort. This
> way the caller can decide to use foo || true to ignore the error.

oh of course!

>
>> + fi
>> + wget -q ${1} -O $2
>> +}
>> +
>>  # ensure we're on branch $1, and apply patches. the rest of the arguments 
>> are
>>  # passed to git am.
>>  dim_alias_ab=apply-branch
>> @@ -772,6 +782,14 @@ function dim_apply_branch
>>   assert_repo_clean
>>
>>   case $1 in
>> + *"patchwork.freedesktop.org"*"mbox")
>> + download_mbox $1 $file
>> + shift
>> + ;;
>> + *"patchwork.freedesktop.org"*)
>> + download_mbox $1/mbox $file
>> + shift
>> + ;;
>
> Really, the interface gets worse and worse here!

actually was the other way around...
I made this bad one and decided to extend to files :P

>
> ---
>
> I may sound like a pedant looking after style and consistency in a shell
> script, but this one has grown beyond the size where we can just ignore
> its maintenance. I've put in quite a bit of effort since the user base
> went from 1 to 2 to keep it together.

you are absolutely right. it is not just a shell script... it is our
tool and we should care!

>
>
> BR,
> Jani.
>
>
>>   *".patch" | *".mbox")
>>   cat $1 > $file
>>   shift
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 3/3] tests: Introduce audio tests, starting with HDMI signal integrity

[Paul Kocialkowski]

This introduces a new test for audio going through display connectors.
It currently contains a single subtest for HDMI signal integrity, but
other test cases will be added later on.

The test setup consists in using an HDMI-VGA bridge that separates the
audio out (via a 3.5 mm jack) and feeding this back to the DUT's line-in
where it can be recorded by ALSA with controls correctly configured.

The audio test makes use of the audio and ALSA igt libraries helpers.

Signed-off-by: Paul Kocialkowski 
---
 tests/Makefile.am |  12 
 tests/audio.c | 170 ++
 2 files changed, 182 insertions(+)
 create mode 100644 tests/audio.c

diff --git a/tests/Makefile.am b/tests/Makefile.am
index f9d11e6c..471f3818 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -20,6 +20,15 @@ TESTS_progs += \
$(NULL)
 endif
 
+if HAVE_ALSA
+if HAVE_GSL
+TESTS_progs += \
+   audio \
+   $(NULL)
+endif
+endif
+
+
 if BUILD_TESTS
 test-list.txt: Makefile.sources
@echo TESTLIST > $@
@@ -134,6 +143,9 @@ vc4_wait_seqno_LDADD = $(LDADD) $(DRM_VC4_LIBS)
 chamelium_CFLAGS = $(AM_CFLAGS) $(XMLRPC_CFLAGS) $(LIBUDEV_CFLAGS)
 chamelium_LDADD = $(LDADD) $(XMLRPC_LIBS) $(LIBUDEV_LIBS)
 
+audio_CFLAGS = $(AM_CFLAGS) $(ALSA_CFLAGS)
+audio_LDADD = $(LDADD) $(ALSA_LIBS)
+
 amdgpu_amd_basic_CFLAGS = $(AM_CFLAGS) $(DRM_AMDGPU_CFLAGS)
 amdgpu_amd_basic_LDADD = $(LDADD) $(DRM_AMDGPU_LIBS)
 amdgpu_amd_cs_nop_CFLAGS = $(AM_CFLAGS) $(DRM_AMDGPU_CFLAGS)
diff --git a/tests/audio.c b/tests/audio.c
new file mode 100644
index ..7099dd99
--- /dev/null
+++ b/tests/audio.c
@@ -0,0 +1,170 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *  Paul Kocialkowski 
+ */
+
+#include "config.h"
+#include "igt.h"
+
+#define PLAYBACK_CHANNELS  2
+#define PLAYBACK_FRAMES1024
+
+#define CAPTURE_SAMPLE_RATE48000
+#define CAPTURE_CHANNELS   2
+#define CAPTURE_DEVICE_NAME"default"
+#define CAPTURE_FRAMES 2048
+
+#define RUN_TIMEOUT2000
+
+struct test_data {
+   struct alsa *alsa;
+   struct audio_signal *signal;
+
+   int streak;
+};
+
+static int sampling_rates[] = {
+   32000,
+   44100,
+   48000,
+   88200,
+   96000,
+   176400,
+   192000,
+};
+
+static int sampling_rates_count = sizeof(sampling_rates) / sizeof(int);
+
+static int test_frequencies[] = {
+   300,
+   600,
+   1200,
+   8,
+   1,
+};
+
+static int test_frequencies_count = sizeof(test_frequencies) / sizeof(int);
+
+static int output_callback(void *data, short *buffer, int frames)
+{
+   struct test_data *test_data = (struct test_data *) data;
+
+   audio_signal_fill(test_data->signal, buffer, frames);
+
+   return 0;
+}
+
+static int input_callback(void *data, short *buffer, int frames)
+{
+   struct test_data *test_data = (struct test_data *) data;
+   bool detect;
+
+   detect = audio_signal_detect(test_data->signal, CAPTURE_CHANNELS,
+CAPTURE_SAMPLE_RATE, buffer, frames);
+   if (detect)
+   test_data->streak++;
+   else
+   test_data->streak = 0;
+
+   /* A streak of 3 gives confidence that the signal is good. */
+   if (test_data->streak == 3)
+   return 1;
+
+   return 0;
+}
+
+static void test_integrity(const char *device_name)
+{
+   struct test_data data;
+   int sampling_rate;
+   bool run = false;
+   bool test;
+   int i, j;
+   int ret;
+
+   data.alsa = alsa_init();
+   igt_assert(data.alsa);
+
+   ret = alsa_open_output(data.alsa, device_name);
+   igt_assert(ret >= 0);
+
+   ret = alsa_open_input(data.alsa, CAPTURE_DEVICE_NAME);
+   

[Intel-gfx] [PATCH i-g-t 2/3] lib: Add ALSA library with dedicated helpers

[Paul Kocialkowski]

This introduces an ALSA library, with dedicated helpers for handling
playback and capture. It handles ALSA device identification and
configuration as well as a run loop with callback mechanisms for feeding
output data and handling input data.

This library paves the way for testing audio going through display
connectors, such as HDMI.

Signed-off-by: Paul Kocialkowski 
---
 configure.ac   |   3 +
 .../intel-gpu-tools/intel-gpu-tools-docs.xml   |   1 +
 lib/Makefile.am|   7 +
 lib/igt.h  |   1 +
 lib/igt_alsa.c | 624 +
 lib/igt_alsa.h |  60 ++
 6 files changed, 696 insertions(+)
 create mode 100644 lib/igt_alsa.c
 create mode 100644 lib/igt_alsa.h

diff --git a/configure.ac b/configure.ac
index 50aa86b5..e66273a4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -219,6 +219,9 @@ if test "x$enable_chamelium" = xyes; then
AC_DEFINE(HAVE_CHAMELIUM, 1, [Enable Chamelium support])
 fi
 
+PKG_CHECK_MODULES(ALSA, [alsa], [alsa=yes], [alsa=no])
+AM_CONDITIONAL(HAVE_ALSA, [test "x$alsa" = xyes])
+
 # -
 #  Configuration options
 # -
diff --git a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml 
b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
index c77159cf..0c34e4a5 100644
--- a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
+++ b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
@@ -16,6 +16,7 @@
   
 API Reference
 
+
 
 
 
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 5ea08314..3ff14f66 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -38,6 +38,13 @@ lib_source_list +=   \
$(NULL)
 endif
 
+if HAVE_ALSA
+lib_source_list += \
+   igt_alsa.c  \
+   igt_alsa.h  \
+   $(NULL)
+endif
+
 AM_CPPFLAGS = -I$(top_srcdir)
 AM_CFLAGS = \
$(CWARNFLAGS) \
diff --git a/lib/igt.h b/lib/igt.h
index a75d2db7..ebf92349 100644
--- a/lib/igt.h
+++ b/lib/igt.h
@@ -35,6 +35,7 @@
 #include "igt_dummyload.h"
 #include "igt_fb.h"
 #include "igt_frame.h"
+#include "igt_alsa.h"
 #include "igt_audio.h"
 #include "igt_gt.h"
 #include "igt_kms.h"
diff --git a/lib/igt_alsa.c b/lib/igt_alsa.c
new file mode 100644
index ..d8bd0873
--- /dev/null
+++ b/lib/igt_alsa.c
@@ -0,0 +1,624 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *  Paul Kocialkowski 
+ */
+
+#include "config.h"
+
+#include 
+
+#include "igt.h"
+
+#define HANDLES_MAX8
+
+/**
+ * SECTION:igt_alsa
+ * @short_description: Library with ALSA helpers
+ * @title: ALSA
+ * @include: igt_alsa.h
+ *
+ * This library contains helpers for ALSA playback and capture.
+ */
+
+struct alsa {
+   snd_pcm_t *output_handles[HANDLES_MAX];
+   int output_handles_count;
+   int output_sampling_rate;
+   int output_channels;
+
+   int (*output_callback)(void *data, short *buffer, int samples);
+   void *output_callback_data;
+   int output_samples_trigger;
+
+   snd_pcm_t *input_handle;
+   int input_sampling_rate;
+   int input_channels;
+
+   int (*input_callback)(void *data, short *buffer, int samples);
+   void *input_callback_data;
+   int input_samples_trigger;
+};
+
+static void alsa_error_handler(const char *file, int line, const char 
*function,
+  int err, const char *fmt, ...)
+{
+   if (err)
+   igt_debug("[ALSA] %s: %s\n", function, snd_strerror(err));
+}
+
+/**
+ * 

[Intel-gfx] [PATCH i-g-t 1/3] lib: Add audio library with dedicated helpers

[Paul Kocialkowski]

This introduces an audio library, with dedicated helpers for both
generating signals and detecting peak frequencies in a signal.

This library paves the way for testing audio going through display
connectors, such as HDMI.

Signed-off-by: Paul Kocialkowski 
---
 .../intel-gpu-tools/intel-gpu-tools-docs.xml   |   1 +
 lib/Makefile.am|   2 +
 lib/igt.h  |   1 +
 lib/igt_audio.c| 326 +
 lib/igt_audio.h|  47 +++
 5 files changed, 377 insertions(+)
 create mode 100644 lib/igt_audio.c
 create mode 100644 lib/igt_audio.h

diff --git a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml 
b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
index f88afd2a..c77159cf 100644
--- a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
+++ b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
@@ -16,6 +16,7 @@
   
 API Reference
 
+
 
 
 
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 9c932d6f..5ea08314 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -33,6 +33,8 @@ if HAVE_GSL
 lib_source_list += \
igt_frame.c \
igt_frame.h \
+   igt_audio.c \
+   igt_audio.h \
$(NULL)
 endif
 
diff --git a/lib/igt.h b/lib/igt.h
index d16a4991..a75d2db7 100644
--- a/lib/igt.h
+++ b/lib/igt.h
@@ -35,6 +35,7 @@
 #include "igt_dummyload.h"
 #include "igt_fb.h"
 #include "igt_frame.h"
+#include "igt_audio.h"
 #include "igt_gt.h"
 #include "igt_kms.h"
 #include "igt_pm.h"
diff --git a/lib/igt_audio.c b/lib/igt_audio.c
new file mode 100644
index ..527a4930
--- /dev/null
+++ b/lib/igt_audio.c
@@ -0,0 +1,326 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *  Paul Kocialkowski 
+ */
+
+#include "config.h"
+
+#include 
+#include 
+
+#include "igt.h"
+
+#define FREQS_MAX  8
+
+/**
+ * SECTION:igt_audio
+ * @short_description: Library for audio-related tests
+ * @title: Audio
+ * @include: igt_audio.h
+ *
+ * This library contains helpers for audio-related tests. More specifically,
+ * it allows generating additions of sine signals as well as detecting them.
+ */
+
+struct audio_signal_freq {
+   int freq;
+
+   short *period;
+   int frames;
+   int offset;
+};
+
+struct audio_signal {
+   int channels;
+   int sampling_rate;
+
+   struct audio_signal_freq freqs[FREQS_MAX];
+   int freqs_count;
+};
+
+/**
+ * audio_signal_init:
+ * @channels: The number of channels to use for the signal 
+ * @sampling_rate: The sampling rate to use for the signal
+ *
+ * Allocate and initialize an audio signal structure with the given parameters.
+ *
+ * Returns: A newly-allocated audio signal structure
+ */
+struct audio_signal *audio_signal_init(int channels, int sampling_rate)
+{
+   struct audio_signal *signal;
+
+   signal = malloc(sizeof(struct audio_signal));
+   memset(signal, 0, sizeof(struct audio_signal));
+
+   signal->sampling_rate = sampling_rate;
+   signal->channels = channels;
+
+   return signal;
+}
+
+/**
+ * audio_signal_add_frequency:
+ * @signal: The target signal structure
+ * @frequency: The frequency to add to the signal
+ *
+ * Add a frequency to the signal.
+ *
+ * Returns: An integer equal to zero for success and negative for failure
+ */
+int audio_signal_add_frequency(struct audio_signal *signal, int frequency)
+{
+   int index = signal->freqs_count;
+
+   if (index == FREQS_MAX)
+   return -1;
+
+   /* Stay within the Nyquist–Shannon sampling theorem. */
+   if (frequency > signal->sampling_rate / 2)
+   return -1;
+
+   

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Beef up the IPS vs. CRC workaround (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Beef up the IPS vs. CRC workaround (rev3)
URL   : https://patchwork.freedesktop.org/series/17084/
State : warning

== Summary ==

Series 17084v3 drm/i915: Beef up the IPS vs. CRC workaround
https://patchwork.freedesktop.org/api/1.0/series/17084/revisions/3/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> DMESG-WARN (fi-bdw-5557u)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-byt-n2820) fdo#101705

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u total:279  pass:267  dwarn:1   dfail:0   fail:0   skip:11  
time:455s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:443s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:359s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:535s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:531s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:525s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:511s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:607s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:443s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:421s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:428s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:506s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:477s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:474s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:595s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:596s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:530s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:468s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:488s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:438s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:485s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:550s
fi-snb-2600  total:279  pass:249  dwarn:0   dfail:0   fail:1   skip:29  
time:403s

e1b18fbd4daecb1c1cf31ca101f64e29a8933bcf drm-tip: 2017y-08m-17d-14h-58m-23s UTC 
integration manifest
568266b967eb drm/i915: Beef up the IPS vs. CRC workaround

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5430/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt 2/3] igt/gem_exec_schedule: Basic tests for preemption

[Chris Wilson]

Quoting Michał Winiarski (2017-08-17 15:39:12)
> On Thu, Aug 03, 2017 at 01:30:28PM +0100, Chris Wilson wrote:
> > We queue N low priority hanging batches across the engines
> > and check that out high priority write over takes them.
> 
> s/out/our
> 
> > 
> > Signed-off-by: Chris Wilson 
> 
> I'm getting stuck on throttle when spawning 10+ spin_batch instances.

Which throttle? <100 spin batches and we won't be blocking on the ring.
Hmm, a different of this test will create a new low-prio context for
each spinner. The first variant will allow the low-prio requests to be
merged together, so we should always be occupying 2 slots. Then if we
add a spinner from a new context, we increase the number of slots the
high prio has to bypass. The intention was to make sure that for
whatever configuration of elsp we could preempt successfully.

> Other than that - the tests look good, simple and quick to execute.
> (cross-engine failing in my tree... but that's a good thing!)
> I thought about adding different spin_batch variants rather than adding
> MI_ARB_CHK by default, but I guess it shouldn't matter (and if it does, we
> should notice something in other tests).

I was surprised that MI_BB_START wasn't a preemption point. The only
downside is that we don't have a non-preemption variant. If need be we
add flags to spin_batch. There are still a few users who could be
converted to spin_batch if the interface were a little more flexible -
including igt_hang.
-Chris
___
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: Check context status before looking up our obj/vma

[Chris Wilson]

Quoting Mika Kuoppala (2017-08-17 15:10:02)
> Chris Wilson  writes:
> 
> > Since we keep the context around across the slow lookup where we may
> > drop the struct_mutex, we should double check that the context is still
> > valid upon reacquisition.
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > Cc: Joonas Lahtinen 
> > Cc: Mika Kuoppala 
> > ---
> >  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 ++---
> >  1 file changed, 6 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 359d5dc6d8df..044fb1205554 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -679,13 +679,6 @@ static int eb_select_context(struct i915_execbuffer 
> > *eb)
> >   if (unlikely(!ctx))
> >   return -ENOENT;
> >  
> > - if (unlikely(i915_gem_context_is_banned(ctx))) {
> > - DRM_DEBUG("Context %u tried to submit while banned\n",
> > -   ctx->user_handle);
> > - i915_gem_context_put(ctx);
> > - return -EIO;
> > - }
> > -
> >   eb->ctx = ctx;
> >   eb->vm = ctx->ppgtt ? >ppgtt->base : >i915->ggtt.base;
> >  
> > @@ -707,6 +700,12 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
> >   int slow_pass = -1;
> >   int err;
> >  
> > + if (unlikely(i915_gem_context_is_closed(eb->ctx)))
> > + return -ENOENT;
> > +
> > + if (unlikely(i915_gem_context_is_banned(eb->ctx)))
> > + return -EIO;
> > +
> 
> We are referring the lut before the context has been validated.
> Not that it matters but for style, please consider assigning
> the lut after the context check.

~o~ Not feeling it. If it was checking for an invalid pointer, then yes
rearranging the code to avoid the appearance of the early dereference
makes sense, but as it is we are just creating an alias for part of the
ctx. Should look at whether gcc likes a few more locals...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC i-g-t] igt/gem_ringfill: Adds full ringbuffer preemption test

[Chris Wilson]

Quoting Antonio Argenziano (2017-08-17 16:14:04)
> 
> 
> On 15/08/17 15:35, Chris Wilson wrote:
> > Quoting Antonio Argenziano (2017-08-15 22:44:21)
> >> Sending as RFC to get feedback on what would be the correct behaviour of
> >> the driver and, therefore, if the test is valid.
> > 
> > It's not a preemption specific bug. It is fair to say that any client
> > blocking any other client over a non-contended resource is an issue.
> > Skip to end for a really easy way to demonstrate this.
> 
> Ok, I'll push a patch then.
> 
> > 
> >> We do a wait while holding the mutex if we are adding a request and figure
> >> out that there is no more space in the ring buffer.
> >> Is that considered a bug?
> > 
> > Yes, but it is one of many priority inversion problems we have because
> > we have a BKL. Timeframe for fixing it is a few more years.
> > 
> >> +static void wait_batch(int fd, uint32_t handle)
> >> +{
> >> +   int64_t timeout = 1ull * NSEC_PER_SEC; //1 sec
> >> +
> >> +   if(gem_wait(fd, handle, ) != 0) {
> >> +   //Force reset and fail the test
> >> +   igt_force_gpu_reset(fd);
> > 
> > Just terminate the spin batches.
> > 
> >> +   igt_assert_f(0, "[0x%x] batch did not complete!", handle);
> >> +   }
> >> +}
> >> +
> >> +/*
> >> + * This test checks that is possible for a high priority request to 
> >> trigger a
> >> + * preemption if another context has filled its ringbuffer.
> >> + * The aim of the test is to make sure that high priority requests cannot 
> >> be
> >> + * stalled by low priority tasks.
> >> + * */
> >> +static void preempt_while_ringbuffer_full(int fd, uint32_t engine)
> >> +{
> >> +   uint32_t hp_ctx, lp_ctx;
> >> +   uint32_t hp_batch;
> >> +   igt_spin_t *lp_batch;
> >> +
> >> +   struct drm_i915_gem_exec_object2 obj[2];
> >> +   struct drm_i915_gem_relocation_entry reloc[1024];
> > 
> > That's a bit excessive for this pi test, no ?
> 
> Just wanted to reuse the utility functions in the test with minimal changes.
> 
> > 
> >> +   struct drm_i915_gem_execbuffer2 execbuf;
> >> +   const unsigned timeout = 10;
> >> +
> >> +   lp_ctx = gem_context_create(fd);
> >> +   ctx_set_priority(fd, lp_ctx, -MAX_PRIO);
> >> +
> >> +   hp_ctx = gem_context_create(fd);
> >> +   ctx_set_priority(fd, hp_ctx, MAX_PRIO);
> >> +
> >> +   igt_require(setup_execbuf(fd, , obj, reloc, engine) == 0);
> >> +   execbuf.rsvd1 = lp_ctx;
> >> +
> >> +   /*Stall execution and fill ring*/
> >> +   lp_batch = igt_spin_batch_new(fd, lp_ctx, engine, 0);
> >> +   igt_fork(child_no, 1) {
> >> +   fill_ring(fd, , 0, timeout);
> >> +   }
> >> +
> >> +   /*We don't know when the ring will be full so keep sending in a 
> >> loop*/
> > 
> > Yes we do. See measure_ring_size.
> > 
> > static void bind_to_cpu(int cpu)
> > {
> >   const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
> >   struct sched_param rt = {.sched_priority = 99 };
> >   cpu_set_t allowed;
> > 
> >   igt_assert(sched_setscheduler(getpid(), SCHED_RR | 
> > SCHED_RESET_ON_FORK, ) == 0);
> > 
> >   CPU_ZERO();
> >   CPU_SET(cpu % ncpus, );
> >   igt_assert(sched_setaffinity(getpid(), sizeof(cpu_set_t), ) 
> > == 0);
> > }
> > 
> > setup timer
> > execbuf.rsvd1 = ctx_lo;
> > while (__raw_gem_execbuf(fd, ) == 0)
> >   ;
> > 
> > /* steal cpu */
> > bind_to_cpu(0);
> > igt_fork(child, 1) {
> >   /* this child is forced to wait for parent to sleep */
> >   execbuf.rsvd1 = ctx_hi;
> >   setup timer;
> >   *success = __raw_gem_execbuf(fd, ) == 0;
> > }
> > setup 2*timer
> > __raw_gem_execbuf(fd, ); /* sleeps under mutex, releasing child
> > */
> > 
> > igt_terminate_spin_batches();
> > igt_waitchildren();
> > 
> > igt_assert(*success);
> > 
> > Timer can be safely 10ms.
> 
> Isn't this a bit too complicated? Wouldn't a "keep poking at it for a 
> while" approach just do the same while being more readable?

Be explicit and use fine control to exactly describe the behaviour you
want. This case is one client exhausts their ring, it will block not
only itself but all users.

Please don't add this to gem_ringfill, if you consider it a scheduling /
priority inversion issue, add it to gem_exec_scheduler. If you want to
tackle more generally as being just one of many, many ways a client can
block another client, start a new test. Considering just how general
this problem is, I'd rather we tackle the problem of modelling the
driver and a system to find all such contention points.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/7] drm/i915: Don't use MI_STORE_DWORD_IMM on Sandybridge/vcs (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/7] drm/i915: Don't use MI_STORE_DWORD_IMM on 
Sandybridge/vcs (rev2)
URL   : https://patchwork.freedesktop.org/series/28859/
State : success

== Summary ==

Series 28859v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/28859/revisions/2/mbox/

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:455s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:445s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:556s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:526s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:526s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:512s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:610s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:448s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:423s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:419s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:507s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:477s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:475s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:595s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:604s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:527s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:471s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:466s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:492s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:443s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:484s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:547s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:408s

e1b18fbd4daecb1c1cf31ca101f64e29a8933bcf drm-tip: 2017y-08m-17d-14h-58m-23s UTC 
integration manifest
7c0a37b11bd0 drm/i915: Mark the GT as busy before idling the previous request
0e4845519fbb drm/i915: Trivial grammar fix s/opt of/opt out of/ in comment
6928515da09d drm/i915: Replace execbuf vma ht with an idr
dca8988c612a drm/i915: Simplify eb_lookup_vmas()
84ca392b85e3 drm/i915: Convert execbuf to use struct-of-array packing for 
critical fields
a9902e0bff38 drm/i915: Check context status before looking up our obj/vma
155bcaa01da6 drm/i915: Don't use MI_STORE_DWORD_IMM on Sandybridge/vcs

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5429/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC i-g-t] igt/gem_ringfill: Adds full ringbuffer preemption test

[Antonio Argenziano]

On 15/08/17 15:35, Chris Wilson wrote:

Quoting Antonio Argenziano (2017-08-15 22:44:21)

Sending as RFC to get feedback on what would be the correct behaviour of
the driver and, therefore, if the test is valid.


It's not a preemption specific bug. It is fair to say that any client
blocking any other client over a non-contended resource is an issue.
Skip to end for a really easy way to demonstrate this.


Ok, I'll push a patch then.




We do a wait while holding the mutex if we are adding a request and figure
out that there is no more space in the ring buffer.
Is that considered a bug?


Yes, but it is one of many priority inversion problems we have because
we have a BKL. Timeframe for fixing it is a few more years.


+static void wait_batch(int fd, uint32_t handle)
+{
+   int64_t timeout = 1ull * NSEC_PER_SEC; //1 sec
+
+   if(gem_wait(fd, handle, ) != 0) {
+   //Force reset and fail the test
+   igt_force_gpu_reset(fd);


Just terminate the spin batches.


+   igt_assert_f(0, "[0x%x] batch did not complete!", handle);
+   }
+}
+
+/*
+ * This test checks that is possible for a high priority request to trigger a
+ * preemption if another context has filled its ringbuffer.
+ * The aim of the test is to make sure that high priority requests cannot be
+ * stalled by low priority tasks.
+ * */
+static void preempt_while_ringbuffer_full(int fd, uint32_t engine)
+{
+   uint32_t hp_ctx, lp_ctx;
+   uint32_t hp_batch;
+   igt_spin_t *lp_batch;
+
+   struct drm_i915_gem_exec_object2 obj[2];
+   struct drm_i915_gem_relocation_entry reloc[1024];


That's a bit excessive for this pi test, no ?


Just wanted to reuse the utility functions in the test with minimal changes.




+   struct drm_i915_gem_execbuffer2 execbuf;
+   const unsigned timeout = 10;
+
+   lp_ctx = gem_context_create(fd);
+   ctx_set_priority(fd, lp_ctx, -MAX_PRIO);
+
+   hp_ctx = gem_context_create(fd);
+   ctx_set_priority(fd, hp_ctx, MAX_PRIO);
+
+   igt_require(setup_execbuf(fd, , obj, reloc, engine) == 0);
+   execbuf.rsvd1 = lp_ctx;
+
+   /*Stall execution and fill ring*/
+   lp_batch = igt_spin_batch_new(fd, lp_ctx, engine, 0);
+   igt_fork(child_no, 1) {
+   fill_ring(fd, , 0, timeout);
+   }
+
+   /*We don't know when the ring will be full so keep sending in a loop*/


Yes we do. See measure_ring_size.

static void bind_to_cpu(int cpu)
{
const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
struct sched_param rt = {.sched_priority = 99 };
cpu_set_t allowed;

igt_assert(sched_setscheduler(getpid(), SCHED_RR | SCHED_RESET_ON_FORK, 
) == 0);

CPU_ZERO();
CPU_SET(cpu % ncpus, );
igt_assert(sched_setaffinity(getpid(), sizeof(cpu_set_t), ) == 
0);
}

setup timer
execbuf.rsvd1 = ctx_lo;
while (__raw_gem_execbuf(fd, ) == 0)
;

/* steal cpu */
bind_to_cpu(0);
igt_fork(child, 1) {
/* this child is forced to wait for parent to sleep */
execbuf.rsvd1 = ctx_hi;
setup timer;
*success = __raw_gem_execbuf(fd, ) == 0;
}
setup 2*timer
__raw_gem_execbuf(fd, ); /* sleeps under mutex, releasing child
*/

igt_terminate_spin_batches();
igt_waitchildren();

igt_assert(*success);

Timer can be safely 10ms.


Isn't this a bit too complicated? Wouldn't a "keep poking at it for a 
while" approach just do the same while being more readable?


-Antonio



Similarly:

race set-domain (pretty much any GEM ioctl ends up in set-domain) vs
spin-batch, when successful then try any set-domain ioctl from a second
client and observe that it too is blocked on the first client hogging.

end:
For the purpose of testing, just create a debugfs that acquires
struct_mutex on opening. Then test every ioctl and trap from a second
client.
-Chris


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

Re: [Intel-gfx] [PATCH 0/8] Fixed16.16 wrapper cleanup & wm optimization

[Mahesh Kumar]

Hi,

My bad, I forgot to modify cover-letter before sending series to intel-gfx.

yes this is for upstream consideration.

-Mahesh


On Thursday 17 August 2017 08:10 PM, Jani Nikula wrote:

On Thu, 17 Aug 2017, Mahesh Kumar  wrote:

This is a Trybot Version of series.

What do you mean? Is this for upstream consideration or not?

BR,
Jani.




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

[Intel-gfx] [PATCH v3] drm/i915: Beef up the IPS vs. CRC workaround

[ville . syrjala]

From: Ville Syrjälä 

Oneshot disabling of IPS when CRC capturing is started is insufficient.
IPS may get re-enabled by any plane update, and hence tests that keep
CRC capturing on across plane updates will start to see inconsistent
results as soon as IPS kicks back in. Add a new knob into the crtc state
to make sure IPS stays disabled as long as CRC capturing is enabled.

Forcing a modeset is the easiest way to handle this since that's already
how we do the panel fitter workaround. It's a little heavy handed just
for IPS, but seeing as we might already do the panel fitter workaround
I think it's better to follow that. We migth want to optimize both cases
later if someone gets too upset by the extra delay from the modeset.

v2: Check the right thing when deciding whether to force a modeset
v3: Rebase, check HAS_IPS before forcing a modeset,
move ips_force_disable check into pipe_config_supports_ips()

Cc: Paulo Zanoni 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Marta Lofstedt 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101664
Reviewed-by: Paulo Zanoni 
Tested-by: Marta Lofsted  #v2
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c  |  7 +++-
 drivers/gpu/drm/i915/intel_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_pipe_crc.c | 62 ---
 3 files changed, 36 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0e93ec201fe3..e8a24b59c91c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6263,6 +6263,9 @@ static int ironlake_fdi_compute_config(struct intel_crtc 
*intel_crtc,
 static bool pipe_config_supports_ips(struct drm_i915_private *dev_priv,
 struct intel_crtc_state *pipe_config)
 {
+   if (pipe_config->ips_force_disable)
+   return false;
+
if (pipe_config->pipe_bpp > 24)
return false;
 
@@ -10830,7 +10833,7 @@ clear_intel_crtc_state(struct intel_crtc_state 
*crtc_state)
struct intel_dpll_hw_state dpll_hw_state;
struct intel_shared_dpll *shared_dpll;
struct intel_crtc_wm_state wm_state;
-   bool force_thru;
+   bool force_thru, ips_force_disable;
 
/* FIXME: before the switch to atomic started, a new pipe_config was
 * kzalloc'd. Code that depends on any field being zero should be
@@ -10841,6 +10844,7 @@ clear_intel_crtc_state(struct intel_crtc_state 
*crtc_state)
shared_dpll = crtc_state->shared_dpll;
dpll_hw_state = crtc_state->dpll_hw_state;
force_thru = crtc_state->pch_pfit.force_thru;
+   ips_force_disable = crtc_state->ips_force_disable;
if (IS_G4X(dev_priv) ||
IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
wm_state = crtc_state->wm;
@@ -10854,6 +10858,7 @@ clear_intel_crtc_state(struct intel_crtc_state 
*crtc_state)
crtc_state->shared_dpll = shared_dpll;
crtc_state->dpll_hw_state = dpll_hw_state;
crtc_state->pch_pfit.force_thru = force_thru;
+   crtc_state->ips_force_disable = ips_force_disable;
if (IS_G4X(dev_priv) ||
IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
crtc_state->wm = wm_state;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index fa47285918f4..8a9db2279bbd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -753,6 +753,7 @@ struct intel_crtc_state {
struct intel_link_m_n fdi_m_n;
 
bool ips_enabled;
+   bool ips_force_disable;
 
bool enable_fbc;
 
diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c 
b/drivers/gpu/drm/i915/intel_pipe_crc.c
index 8fbd2bd0877f..4e22bb927fed 100644
--- a/drivers/gpu/drm/i915/intel_pipe_crc.c
+++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
@@ -506,8 +506,8 @@ static int ilk_pipe_crc_ctl_reg(enum intel_pipe_crc_source 
*source,
return 0;
 }
 
-static void hsw_trans_edp_pipe_A_crc_wa(struct drm_i915_private *dev_priv,
-   bool enable)
+static void hsw_pipe_A_crc_wa(struct drm_i915_private *dev_priv,
+ bool enable)
 {
struct drm_device *dev = _priv->drm;
struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, PIPE_A);
@@ -533,10 +533,24 @@ static void hsw_trans_edp_pipe_A_crc_wa(struct 
drm_i915_private *dev_priv,
goto put_state;
}
 
-   pipe_config->pch_pfit.force_thru = enable;
-   if (pipe_config->cpu_transcoder == TRANSCODER_EDP &&
-   pipe_config->pch_pfit.enabled != enable)
-   pipe_config->base.connectors_changed = true;
+   if (HAS_IPS(dev_priv)) 

Re: [Intel-gfx] [PATCH v3 RESEND] drm/i915/opregion: let user specify override VBT via firmware load

[Jani Nikula]

On Thu, 17 Aug 2017, Jani Nikula  wrote:
> Sometimes it would be most enlightening to debug systems by replacing
> the VBT to be used. For example, in the referenced bug the BIOS provides
> different VBT depending on the boot mode (UEFI vs. legacy). It would be
> interesting to try the failing boot mode with the VBT from the working
> boot, and see if that makes a difference.
>
> Add a module parameter to load the VBT using the firmware loader, not
> unlike the EDID firmware mechanism.
>
> As a starting point for experimenting, one can pick up the BIOS provided
> VBT from /sys/kernel/debug/dri/0/i915_opregion/i915_vbt.
>
> v2: clarify firmware load return value check (Bob)
>
> v3: kfree the loaded firmware blob
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97822#c83
> Reviewed-by: Bob Paauwe 
> Signed-off-by: Jani Nikula 

And pushed, with Daniel's additional irc ack.

BR,
Jani.


> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  drivers/gpu/drm/i915/i915_params.c|  4 
>  drivers/gpu/drm/i915/i915_params.h|  1 +
>  drivers/gpu/drm/i915/intel_opregion.c | 45 
> +++
>  4 files changed, 51 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 6c25c8520c87..3ee4fd2a9b41 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -646,6 +646,7 @@ struct intel_opregion {
>   u32 swsci_sbcb_sub_functions;
>   struct opregion_asle *asle;
>   void *rvda;
> + void *vbt_firmware;
>   const void *vbt;
>   u32 vbt_size;
>   u32 *lid_state;
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index 14e2c2e57f96..8ab003dca113 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -118,6 +118,10 @@ MODULE_PARM_DESC(vbt_sdvo_panel_type,
>  module_param_named_unsafe(reset, i915.reset, int, 0600);
>  MODULE_PARM_DESC(reset, "Attempt GPU resets (0=disabled, 1=full gpu reset, 
> 2=engine reset [default])");
>  
> +module_param_named_unsafe(vbt_firmware, i915.vbt_firmware, charp, 0400);
> +MODULE_PARM_DESC(vbt_firmware,
> +  "Load VBT from specified file under /lib/firmware");
> +
>  #if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
>  module_param_named(error_capture, i915.error_capture, bool, 0600);
>  MODULE_PARM_DESC(error_capture,
> diff --git a/drivers/gpu/drm/i915/i915_params.h 
> b/drivers/gpu/drm/i915/i915_params.h
> index febbfdbd30bd..ac844709c97e 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -28,6 +28,7 @@
>  #include  /* for __read_mostly */
>  
>  #define I915_PARAMS_FOR_EACH(func) \
> + func(char *, vbt_firmware); \
>   func(int, modeset); \
>   func(int, panel_ignore_lid); \
>   func(int, semaphores); \
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> b/drivers/gpu/drm/i915/intel_opregion.c
> index 2bd03001cc70..98154efcb2f4 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -27,6 +27,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -829,6 +830,10 @@ void intel_opregion_unregister(struct drm_i915_private 
> *dev_priv)
>   memunmap(opregion->rvda);
>   opregion->rvda = NULL;
>   }
> + if (opregion->vbt_firmware) {
> + kfree(opregion->vbt_firmware);
> + opregion->vbt_firmware = NULL;
> + }
>   opregion->header = NULL;
>   opregion->acpi = NULL;
>   opregion->swsci = NULL;
> @@ -912,6 +917,43 @@ static const struct dmi_system_id 
> intel_no_opregion_vbt[] = {
>   { }
>  };
>  
> +static int intel_load_vbt_firmware(struct drm_i915_private *dev_priv)
> +{
> + struct intel_opregion *opregion = _priv->opregion;
> + const struct firmware *fw = NULL;
> + const char *name = i915.vbt_firmware;
> + int ret;
> +
> + if (!name || !*name)
> + return -ENOENT;
> +
> + ret = request_firmware(, name, _priv->drm.pdev->dev);
> + if (ret) {
> + DRM_ERROR("Requesting VBT firmware \"%s\" failed (%d)\n",
> +   name, ret);
> + return ret;
> + }
> +
> + if (intel_bios_is_valid_vbt(fw->data, fw->size)) {
> + opregion->vbt_firmware = kmemdup(fw->data, fw->size, 
> GFP_KERNEL);
> + if (opregion->vbt_firmware) {
> + DRM_DEBUG_KMS("Found valid VBT firmware \"%s\"\n", 
> name);
> + opregion->vbt = opregion->vbt_firmware;
> + opregion->vbt_size = fw->size;
> + ret = 0;
> + } else {
> + ret = -ENOMEM;
> + }
> + } else {
> + DRM_DEBUG_KMS("Invalid VBT firmware \"%s\"\n", name);
> + ret = -EINVAL;
> + }
> +
> + 

Re: [Intel-gfx] [PATCH i-g-t] intel-ci: Add fast-feedback-simulation.testlist

[Kelvin Gardiner]

On 17/08/17 00:50, Daniel Vetter wrote:

On Wed, Aug 16, 2017 at 05:30:08PM -0700, Kelvin Gardiner wrote:



On 16/08/17 07:04, Daniel Vetter wrote:

On Wed, Aug 16, 2017 at 11:33 AM, Petri Latvala  wrote:

On Tue, Jun 27, 2017 at 02:04:51PM -0700, Kelvin Gardiner wrote:

Added an initial list of fast feedback tests for simulation
environments.


Merged, thanks.


Yes I'm a bit late, just noticed this fly by: How does this interact
wit igt_skip_on_simulation? What's the significance of this list, are
we going to see CI run these? Have platform owners acked this as the
PO list?


This is a list of tests seen to be good in a simulation environment. It is
meant as a starting point to have a reference list, to which we can add.


seen by whom? That was pretty much my question/concern here. I chatted
with Petri, and apparently this list is also used by the helsinki CI, and
that should have been noted.

But just today I've seen a mail fly by that e.g. Rodrigo has a power-on
testlist. Which I guess is again something else, but doesn't help making
things less confusing.

I mean you can add whatever you want to igt and let it rot there, but if
you expect platform owners, test engineers and developers to support it,
we need a consensus. Otherwise it won't really happen, and this patch here
looked like that consensus engineering work wasn't done (and that's really
the hard work, not the patch itself).


With regards to igt_skip_on_simulation, some times this is erroneously
included in a test, other times it is missing, some tests need to reduce
iterations etc, (where this still give a valid test) when this is set (as
some already do). In short some work is needed to clean up the use of this
flag.


So ... who's doing that work? Or are we just going to let 2 half-solutions
rot side-by-side?
-Daniel


We have this on our to do list. I was thinking if we create a list of 
tests that need attention the 2 val teams can work through the list to 
make the fixes.






VPG validation is just one team here, imo adding something like this
needs a lot more buy-in. Or we're just once again adding a list no one
is actually using, which is pointless. Imo if we can't get acks from
platform owners that they are actively using this list, and CI that
they are also actively using this list, then it should be removed
again.

Thanks, Daniel




--
Petri Latvala
___
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

[Intel-gfx] [PATCH v2] drm/i915: Mark the GT as busy before idling the previous request

[Chris Wilson]

In a synchronous setup, we may retire the last request before we
complete allocating the next request. As the last request is retired, we
queue a timer to mark the device as idle, and promptly have to execute
ad cancel that timer once we complete allocating the request and need to
keep the device awake. If we rearrange the mark_busy() to occur before
we retire the previous request, we can skip this ping-pong.

v2: Joonas pointed out that unreserve_seqno() was now doing more than
doing seqno handling and should be renamed to reflect its wider purpose.
That also highlighted the new asymmetry with reserve_seqno(), so fixup
that and rename both to [un]reserve_seqno().

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 87 +
 1 file changed, 44 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 9eedd33eb524..5716b6d78e8e 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -244,27 +244,59 @@ int i915_gem_set_global_seqno(struct drm_device *dev, u32 
seqno)
return reset_all_global_seqno(dev_priv, seqno - 1);
 }
 
-static int reserve_seqno(struct intel_engine_cs *engine)
+static void mark_busy(struct drm_i915_private *i915)
 {
+   if (i915->gt.awake)
+   return;
+
+   GEM_BUG_ON(!i915->gt.active_requests);
+
+   intel_runtime_pm_get_noresume(i915);
+   i915->gt.awake = true;
+
+   intel_enable_gt_powersave(i915);
+   i915_update_gfx_val(i915);
+   if (INTEL_GEN(i915) >= 6)
+   gen6_rps_busy(i915);
+
+   queue_delayed_work(i915->wq,
+  >gt.retire_work,
+  round_jiffies_up_relative(HZ));
+}
+
+static int reserve_engine(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *i915 = engine->i915;
u32 active = ++engine->timeline->inflight_seqnos;
u32 seqno = engine->timeline->seqno;
int ret;
 
/* Reservation is fine until we need to wrap around */
-   if (likely(!add_overflows(seqno, active)))
-   return 0;
-
-   ret = reset_all_global_seqno(engine->i915, 0);
-   if (ret) {
-   engine->timeline->inflight_seqnos--;
-   return ret;
+   if (unlikely(add_overflows(seqno, active))) {
+   ret = reset_all_global_seqno(i915, 0);
+   if (ret) {
+   engine->timeline->inflight_seqnos--;
+   return ret;
+   }
}
 
+   if (!i915->gt.active_requests++)
+   mark_busy(i915);
+
return 0;
 }
 
-static void unreserve_seqno(struct intel_engine_cs *engine)
+static void unreserve_engine(struct intel_engine_cs *engine)
 {
+   struct drm_i915_private *i915 = engine->i915;
+
+   if (!--i915->gt.active_requests) {
+   GEM_BUG_ON(!i915->gt.awake);
+   mod_delayed_work(i915->wq,
+>gt.idle_work,
+msecs_to_jiffies(100));
+   }
+
GEM_BUG_ON(!engine->timeline->inflight_seqnos);
engine->timeline->inflight_seqnos--;
 }
@@ -333,13 +365,7 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
list_del_init(>link);
spin_unlock_irq(>timeline->lock);
 
-   if (!--request->i915->gt.active_requests) {
-   GEM_BUG_ON(!request->i915->gt.awake);
-   mod_delayed_work(request->i915->wq,
->i915->gt.idle_work,
-msecs_to_jiffies(100));
-   }
-   unreserve_seqno(request->engine);
+   unreserve_engine(request->engine);
advance_ring(request);
 
free_capture_list(request);
@@ -575,7 +601,7 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
return ERR_CAST(ring);
GEM_BUG_ON(!ring);
 
-   ret = reserve_seqno(engine);
+   ret = reserve_engine(engine);
if (ret)
goto err_unpin;
 
@@ -681,7 +707,7 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
 
kmem_cache_free(dev_priv->requests, req);
 err_unreserve:
-   unreserve_seqno(engine);
+   unreserve_engine(engine);
 err_unpin:
engine->context_unpin(engine, ctx);
return ERR_PTR(ret);
@@ -863,28 +889,6 @@ i915_gem_request_await_object(struct drm_i915_gem_request 
*to,
return ret;
 }
 
-static void i915_gem_mark_busy(const struct intel_engine_cs *engine)
-{
-   struct drm_i915_private *dev_priv = engine->i915;
-
-   if (dev_priv->gt.awake)
-   return;
-
-   GEM_BUG_ON(!dev_priv->gt.active_requests);
-
-   intel_runtime_pm_get_noresume(dev_priv);
-   dev_priv->gt.awake = true;
-
-   intel_enable_gt_powersave(dev_priv);
-   

Re: [Intel-gfx] [PATCH igt 2/3] igt/gem_exec_schedule: Basic tests for preemption

[Michał Winiarski]

On Thu, Aug 03, 2017 at 01:30:28PM +0100, Chris Wilson wrote:
> We queue N low priority hanging batches across the engines
> and check that out high priority write over takes them.

s/out/our

> 
> Signed-off-by: Chris Wilson 

I'm getting stuck on throttle when spawning 10+ spin_batch instances.
Other than that - the tests look good, simple and quick to execute.
(cross-engine failing in my tree... but that's a good thing!)
I thought about adding different spin_batch variants rather than adding
MI_ARB_CHK by default, but I guess it shouldn't matter (and if it does, we
should notice something in other tests).

Reviewed-by: Michał Winiarski 

Note that we still don't have preemption or API for context priority merged, so
we probably should hold on with this one?

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

Re: [Intel-gfx] [PATCH 0/8] Fixed16.16 wrapper cleanup & wm optimization

[Jani Nikula]

On Thu, 17 Aug 2017, Mahesh Kumar  wrote:
> This is a Trybot Version of series.

What do you mean? Is this for upstream consideration or not?

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] drm/i915: Fix integer overflow tests

[Dan Carpenter]

On Thu, Aug 17, 2017 at 07:16:03AM -0700, Jason Ekstrand wrote:
> On Thu, Aug 17, 2017 at 2:56 AM, Imre Deak  wrote:
> 
> > On Thu, Aug 17, 2017 at 12:50:37PM +0300, Dan Carpenter wrote:
> > > On Thu, Aug 17, 2017 at 12:37:00PM +0300, Imre Deak wrote:
> > > > On Thu, Aug 17, 2017 at 09:23:10AM +0300, Dan Carpenter wrote:
> > > > > There are some potential integer overflows here on 64 bit systems.
> > > > >
> > > > > The condition "if (nfences > SIZE_MAX / sizeof(*fences))" can only be
> > > > > true on 32 bit systems, it's a no-op on 64 bit, so let's ignore the
> > > > > check for now and look a couple lines after:
> > > > >
> > > > >   if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32)))
> > > > >   ^^^
> > > > > "nfences" is an unsigned int, so if we set it to UINT_MAX and
> > multiply
> > > > > by two, it's going to have an integer overflow.
> > > >
> > > > AFAICS it wouldn't overflow due the promotion to unsigned long
> > > > by '* sizeof(u32)'.
> > > >
> > >
> > > It first multplies "nfences * 2" as unsigned int, then it type promotes
> > > to size_t and multiplies by sizeof().  Only the first multiplication has
> > > an integer overflow bug.
> >
> > Err, that's correct. Sorry for the noise.
> >
> 
> Why not just replace the "2 * sizeof(u32)" with a "sizeof(*user)".  That's
> what we really want to check.  I have no idea how it ended up being "2 *
> sizeof(u32)"

Yeah.  That's more readable.  I will resend.

regards,
dan carpenter


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

Re: [Intel-gfx] [PATCH] drm/i915: Fix integer overflow tests

[Jason Ekstrand]

On Thu, Aug 17, 2017 at 2:56 AM, Imre Deak  wrote:

> On Thu, Aug 17, 2017 at 12:50:37PM +0300, Dan Carpenter wrote:
> > On Thu, Aug 17, 2017 at 12:37:00PM +0300, Imre Deak wrote:
> > > On Thu, Aug 17, 2017 at 09:23:10AM +0300, Dan Carpenter wrote:
> > > > There are some potential integer overflows here on 64 bit systems.
> > > >
> > > > The condition "if (nfences > SIZE_MAX / sizeof(*fences))" can only be
> > > > true on 32 bit systems, it's a no-op on 64 bit, so let's ignore the
> > > > check for now and look a couple lines after:
> > > >
> > > >   if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32)))
> > > >   ^^^
> > > > "nfences" is an unsigned int, so if we set it to UINT_MAX and
> multiply
> > > > by two, it's going to have an integer overflow.
> > >
> > > AFAICS it wouldn't overflow due the promotion to unsigned long
> > > by '* sizeof(u32)'.
> > >
> >
> > It first multplies "nfences * 2" as unsigned int, then it type promotes
> > to size_t and multiplies by sizeof().  Only the first multiplication has
> > an integer overflow bug.
>
> Err, that's correct. Sorry for the noise.
>

Why not just replace the "2 * sizeof(u32)" with a "sizeof(*user)".  That's
what we really want to check.  I have no idea how it ended up being "2 *
sizeof(u32)"

--Jason
___
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: Check context status before looking up our obj/vma

[Mika Kuoppala]

Chris Wilson  writes:

> Since we keep the context around across the slow lookup where we may
> drop the struct_mutex, we should double check that the context is still
> valid upon reacquisition.
>
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Joonas Lahtinen 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 359d5dc6d8df..044fb1205554 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -679,13 +679,6 @@ static int eb_select_context(struct i915_execbuffer *eb)
>   if (unlikely(!ctx))
>   return -ENOENT;
>  
> - if (unlikely(i915_gem_context_is_banned(ctx))) {
> - DRM_DEBUG("Context %u tried to submit while banned\n",
> -   ctx->user_handle);
> - i915_gem_context_put(ctx);
> - return -EIO;
> - }
> -
>   eb->ctx = ctx;
>   eb->vm = ctx->ppgtt ? >ppgtt->base : >i915->ggtt.base;
>  
> @@ -707,6 +700,12 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
>   int slow_pass = -1;
>   int err;
>  
> + if (unlikely(i915_gem_context_is_closed(eb->ctx)))
> + return -ENOENT;
> +
> + if (unlikely(i915_gem_context_is_banned(eb->ctx)))
> + return -EIO;
> +

We are referring the lut before the context has been validated.
Not that it matters but for style, please consider assigning
the lut after the context check.

Reviewed-by: Mika Kuoppala 

>   INIT_LIST_HEAD(>relocs);
>   INIT_LIST_HEAD(>unbound);
>  
> -- 
> 2.13.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Add has_psr-flag to gen9lp

[David Weinehall]

On Tue, Aug 08, 2017 at 12:50:51PM -0700, Rodrigo Vivi wrote:
> a long time ago I had agreed with Daniel that we would only add new
> platforms after it was enabled by default on previous platforms.
> a big reason for that is that we was willing to reduce the platforms
> to validate and do better validation one by one before enabling.
> 
> However now I believe it would be beneficial to have that supported
> added so we can get more brave people using in different platforms so
> we could capture more corner cases before we enable it by default.
> Also we can still enable by default one platform at time if needed.
> 
> So:
> 
> Acked-by: Rodrigo Vivi 
> 
> I also checked the spec to see if there was anything else new or
> different for these platforms and didn't find anything so:
> 
> Reviewed-by: Rodrigo Vivi 
> 
> But let's wait a bit to merge to give Daniel or others a time to nack ;)

A bit more testing shows that while our GLK systems work perfectly fine
with PSR (and gets the expected power savings), the BXT system we tested
on didn't cope quite so well.  I'll have to dig into this a bit to see
if there's something Broxton-related info on PSR in Bspec I missed,
or if it's just our BXT-P RVP that's buggy.


Kind regards, David

> Cheers,
> Rodrigo.
> 
> 
> On Tue, Aug 8, 2017 at 3:09 AM, David Weinehall
>  wrote:
> > While testing Jim Bride's latest batch of PSR patches I noticed
> > that gen9lp doesn't include the has_psr flag, and that our GLK
> > system thus reported PSR as unsupported.
> >
> > This patch simply adds has_psr.
> >
> > Signed-off-by: David Weinehall 
> > ---
> >  drivers/gpu/drm/i915/i915_pci.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index 09d97e0990b7..11f0e8aa1fe4 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -377,6 +377,7 @@ static const struct intel_device_info 
> > intel_skylake_gt3_info = {
> > .has_ddi = 1, \
> > .has_fpga_dbg = 1, \
> > .has_fbc = 1, \
> > +   .has_psr = 1, \
> > .has_runtime_pm = 1, \
> > .has_pooled_eu = 0, \
> > .has_csr = 1, \
> > --
> > 2.14.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> 
> 
> -- 
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for Fixed16.16 wrapper cleanup & wm optimization (rev7)

[Patchwork]

== Series Details ==

Series: Fixed16.16 wrapper cleanup & wm optimization (rev7)
URL   : https://patchwork.freedesktop.org/series/25692/
State : warning

== Summary ==

Series 25692v7 Fixed16.16 wrapper cleanup & wm optimization
https://patchwork.freedesktop.org/api/1.0/series/25692/revisions/7/mbox/

Test kms_cursor_legacy:
Subgroup basic-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-glk-2a)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-byt-n2820) fdo#101705

fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:453s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:433s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:357s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:549s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:516s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:525s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:514s
fi-glk-2atotal:279  pass:259  dwarn:1   dfail:0   fail:0   skip:19  
time:603s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:443s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:421s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:426s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:504s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:478s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:477s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:595s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:604s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:524s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:470s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:477s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:488s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:438s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:500s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:550s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:408s

ada53b43f81fe618f3f0f1dfbd3dd776bb277323 drm-tip: 2017y-08m-16d-15h-18m-56s UTC 
integration manifest
e0e32e4ac1e2 drm/i915/skl+: debugfs entry to control IPC
12f5253026e1 drm/i915/bxt+: Enable IPC support
3e79e9613276 drm/i915/gen9+: Add has_ipc flag in device info structure
410b43002f50 drm/i915/cnl: Extend WM workaround with IPC for CNL
2a11f5bc0617 drm/i915/glk: IPC linetime watermark workaround for GLK
0a852b3adca3 drm/i915/gen10: Calculate and enable transition WM
cf509cd38a16 drm/i915/skl+: Optimize WM calculation
930e260ada22 drm/i915: Fixed point fixed16 wrapper cleanup

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5428/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 5/8] drm/i915/cnl: Extend WM workaround with IPC for CNL

[Mahesh Kumar]

From: "Kumar, Mahesh" 

CNL:A & CNL:B have same workaround as KBL to increase wm level latency
by 4us if IPC is enabled.

Signed-off-by: Mahesh Kumar 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_pm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5dcf76217f7d..aee1a387a65a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4486,7 +4486,8 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
}
 
/* Display WA #1141: kbl,cfl */
-   if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) &&
+   if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) ||
+   IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0)) &&
dev_priv->ipc_enabled)
latency += 4;
 
-- 
2.13.0

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

[Intel-gfx] [PATCH 6/8] drm/i915/gen9+: Add has_ipc flag in device info structure

[Mahesh Kumar]

From: "Kumar, Mahesh" 

New Isochronous Priority Control (IPC) capability is introduced in newer
GEN platforms. This patch adds a device info flag to indicate if platform
supports IPC. Patch also sets this flag in supported platforms.

Signed-off-by: Mahesh Kumar 
Cc: Chris Wilson 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_drv.h | 5 -
 drivers/gpu/drm/i915/i915_pci.c | 4 
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 320da875d7e0..de79ea3e066e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -779,7 +779,8 @@ struct intel_csr {
func(cursor_needs_physical); \
func(hws_needs_physical); \
func(overlay_needs_physical); \
-   func(supports_tv);
+   func(supports_tv); \
+   func(has_ipc);
 
 struct sseu_dev_info {
u8 slice_mask;
@@ -3077,6 +3078,8 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define HAS_RUNTIME_PM(dev_priv) ((dev_priv)->info.has_runtime_pm)
 #define HAS_64BIT_RELOC(dev_priv) ((dev_priv)->info.has_64bit_reloc)
 
+#define HAS_IPC(dev_priv)   ((dev_priv)->info.has_ipc)
+
 /*
  * For now, anything with a GuC requires uCode loading, and then supports
  * command submission once loaded. But these are logically independent
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 09d97e0990b7..572c01924334 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -390,6 +390,7 @@ static const struct intel_device_info 
intel_skylake_gt3_info = {
.has_full_ppgtt = 1, \
.has_full_48bit_ppgtt = 1, \
.has_reset_engine = 1, \
+   .has_ipc = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
IVB_CURSOR_OFFSETS, \
BDW_COLORS
@@ -414,6 +415,7 @@ static const struct intel_device_info intel_geminilake_info 
= {
.platform = INTEL_KABYLAKE, \
.has_csr = 1, \
.has_guc = 1, \
+   .has_ipc = 1, \
.ddb_size = 896
 
 static const struct intel_device_info intel_kabylake_info = {
@@ -432,6 +434,7 @@ static const struct intel_device_info 
intel_kabylake_gt3_info = {
.platform = INTEL_COFFEELAKE, \
.has_csr = 1, \
.has_guc = 1, \
+   .has_ipc = 1, \
.ddb_size = 896
 
 static const struct intel_device_info intel_coffeelake_info = {
@@ -450,6 +453,7 @@ static const struct intel_device_info intel_cannonlake_info 
= {
.gen = 10,
.ddb_size = 1024,
.has_csr = 1,
+   .has_ipc = 1,
.color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
 };
 
-- 
2.13.0

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

[Intel-gfx] [PATCH 2/8] drm/i915/skl+: Optimize WM calculation

[Mahesh Kumar]

From: "Kumar, Mahesh" 

Plane configuration parameters doesn't change for each WM-level
calculation. Currently we compute same parameters 8 times for each
wm-level.
This patch optimizes it by calculating these parameters in beginning
& reuse during each level-wm calculation.

Changes since V1:
 - rebase on top of Rodrigo's series for CNL

Signed-off-by: Mahesh Kumar 
Acked-by: Maarten Lankhorst 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_drv.h |  14 +++
 drivers/gpu/drm/i915/intel_pm.c | 190 ++--
 2 files changed, 119 insertions(+), 85 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fa5858da2ca0..320da875d7e0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1811,6 +1811,20 @@ struct skl_wm_level {
uint8_t plane_res_l;
 };
 
+/* Stores plane specific WM parameters */
+struct skl_wm_params {
+   bool x_tiled, y_tiled;
+   bool rc_surface;
+   uint32_t width;
+   uint8_t cpp;
+   uint32_t plane_pixel_rate;
+   uint32_t y_min_scanlines;
+   uint32_t plane_bytes_per_line;
+   uint_fixed_16_16_t plane_blocks_per_line;
+   uint_fixed_16_16_t y_tile_minimum;
+   uint32_t linetime_us;
+};
+
 /*
  * This struct helps tracking the state needed for runtime PM, which puts the
  * device in PCI D3 state. Notice that when this happens, nothing on the
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ed662937ec3c..47c01da2e109 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4370,134 +4370,146 @@ skl_adjusted_plane_pixel_rate(const struct 
intel_crtc_state *cstate,
downscale_amount);
 }
 
-static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
-   struct intel_crtc_state *cstate,
-   const struct intel_plane_state *intel_pstate,
-   uint16_t ddb_allocation,
-   int level,
-   uint16_t *out_blocks, /* out */
-   uint8_t *out_lines, /* out */
-   bool *enabled /* out */)
+static int
+skl_compute_plane_wm_params(const struct drm_i915_private *dev_priv,
+   struct intel_crtc_state *cstate,
+   const struct intel_plane_state *intel_pstate,
+   struct skl_wm_params *wp)
 {
struct intel_plane *plane = to_intel_plane(intel_pstate->base.plane);
const struct drm_plane_state *pstate = _pstate->base;
const struct drm_framebuffer *fb = pstate->fb;
-   uint32_t latency = dev_priv->wm.skl_latency[level];
-   uint_fixed_16_16_t method1, method2;
-   uint_fixed_16_16_t plane_blocks_per_line;
-   uint_fixed_16_16_t selected_result;
uint32_t interm_pbpl;
-   uint32_t plane_bytes_per_line;
-   uint32_t res_blocks, res_lines;
-   uint8_t cpp;
-   uint32_t width = 0;
-   uint32_t plane_pixel_rate;
-   uint_fixed_16_16_t y_tile_minimum;
-   uint32_t y_min_scanlines;
struct intel_atomic_state *state =
to_intel_atomic_state(cstate->base.state);
bool apply_memory_bw_wa = skl_needs_memory_bw_wa(state);
-   bool y_tiled, x_tiled;
 
-   if (latency == 0 ||
-   !intel_wm_plane_visible(cstate, intel_pstate)) {
-   *enabled = false;
+   if (!intel_wm_plane_visible(cstate, intel_pstate))
return 0;
-   }
 
-   y_tiled = fb->modifier == I915_FORMAT_MOD_Y_TILED ||
- fb->modifier == I915_FORMAT_MOD_Yf_TILED ||
- fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
- fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
-   x_tiled = fb->modifier == I915_FORMAT_MOD_X_TILED;
-
-   /* Display WA #1141: kbl,cfl */
-   if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) &&
-   dev_priv->ipc_enabled)
-   latency += 4;
-
-   if (apply_memory_bw_wa && x_tiled)
-   latency += 15;
+   wp->y_tiled = fb->modifier == I915_FORMAT_MOD_Y_TILED ||
+ fb->modifier == I915_FORMAT_MOD_Yf_TILED ||
+ fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
+ fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
+   wp->x_tiled = fb->modifier == I915_FORMAT_MOD_X_TILED;
+   wp->rc_surface = fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
+fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
 
if (plane->id == PLANE_CURSOR) {
-   width = intel_pstate->base.crtc_w;
+   wp->width = intel_pstate->base.crtc_w;
} else {
 

[Intel-gfx] [PATCH 4/8] drm/i915/glk: IPC linetime watermark workaround for GLK

[Mahesh Kumar]

From: "Kumar, Mahesh" 

IF IPC is enabled LINETIME_WM value should be half of calculated value
 line time = ROUNDDOWN(1/2 * Calculated Line Time)

Earlier code was rounding-up the value, But updated Bspec says we should
take the ROUNDDOWN. This patch corrects that as well.

Signed-off-by: Mahesh Kumar 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_pm.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6face465ae48..5dcf76217f7d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4616,9 +4616,10 @@ skl_compute_linetime_wm(struct intel_crtc_state *cstate)
 
linetime_wm = fixed16_to_u32_round_up(mul_u32_fixed16(8, linetime_us));
 
-   /* Display WA #1135: bxt. */
-   if (IS_BROXTON(dev_priv) && dev_priv->ipc_enabled)
-   linetime_wm = DIV_ROUND_UP(linetime_wm, 2);
+   /* Display WA #1135: bxt:ALL GLK:ALL */
+   if ((IS_BROXTON(dev_priv) || IS_GEMINILAKE(dev_priv)) &&
+   dev_priv->ipc_enabled)
+   linetime_wm /= 2;
 
return linetime_wm;
 }
-- 
2.13.0

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

[Intel-gfx] [PATCH 8/8] drm/i915/skl+: debugfs entry to control IPC

[Mahesh Kumar]

From: "Kumar, Mahesh" 

This patch creates an entry in debugfs to check the status of IPC.
This can also be used to enable/disable IPC in supported platforms.

Changes since V1:
 - fix use of HAS_IPC
 - use kstrtobool_from_user (Maarten)
 - drm_info log, while enabling IPC (Maarten)

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 54 -
 1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 329fb3649dc3..b6f38802219b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3528,6 +3528,57 @@ static int i915_wa_registers(struct seq_file *m, void 
*unused)
return 0;
 }
 
+static int i915_ipc_status_show(struct seq_file *m, void *data)
+{
+   struct drm_i915_private *dev_priv = m->private;
+
+   seq_printf(m, "Isochronous Priority Control: %s\n",
+   enableddisabled(dev_priv->ipc_enabled));
+   return 0;
+}
+
+static int i915_ipc_status_open(struct inode *inode, struct file *file)
+{
+   struct drm_i915_private *dev_priv = inode->i_private;
+
+   if (!HAS_IPC(dev_priv))
+   return -ENODEV;
+
+   return single_open(file, i915_ipc_status_show, dev_priv);
+}
+
+static ssize_t i915_ipc_status_write(struct file *file, const char __user 
*ubuf,
+size_t len, loff_t *offp)
+{
+   struct seq_file *m = file->private_data;
+   struct drm_i915_private *dev_priv = m->private;
+   int ret;
+   bool enable;
+
+   ret = kstrtobool_from_user(ubuf, len, );
+   if (ret < 0)
+   return ret;
+
+   intel_runtime_pm_get(dev_priv);
+   if (!dev_priv->ipc_enabled && enable)
+   DRM_INFO("Enabling IPC: WM will be proper only after next 
commit\n");
+   dev_priv->wm.distrust_bios_wm = true;
+   dev_priv->ipc_enabled = enable;
+   intel_enable_ipc(dev_priv);
+   intel_runtime_pm_put(dev_priv);
+
+   return len;
+}
+
+static const struct file_operations i915_ipc_status_fops = {
+   .owner = THIS_MODULE,
+   .open = i915_ipc_status_open,
+   .read = seq_read,
+   .llseek = seq_lseek,
+   .release = single_release,
+   .write = i915_ipc_status_write
+};
+
 static int i915_ddb_info(struct seq_file *m, void *unused)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -4864,7 +4915,8 @@ static const struct i915_debugfs_files {
{"i915_dp_test_type", _displayport_test_type_fops},
{"i915_dp_test_active", _displayport_test_active_fops},
{"i915_guc_log_control", _guc_log_control_fops},
-   {"i915_hpd_storm_ctl", _hpd_storm_ctl_fops}
+   {"i915_hpd_storm_ctl", _hpd_storm_ctl_fops},
+   {"i915_ipc_status", _ipc_status_fops}
 };
 
 int i915_debugfs_register(struct drm_i915_private *dev_priv)
-- 
2.13.0

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

[Intel-gfx] [PATCH 7/8] drm/i915/bxt+: Enable IPC support

[Mahesh Kumar]

From: "Kumar, Mahesh" 

This patch adds IPC support. This patch also enables IPC in all supported
platforms based on has_ipc flag.
IPC (Isochronous Priority Control) is the hardware feature, which
dynamically controls the memory read priority of Display.

When IPC is enabled, plane read requests are sent at high priority until
filling above the transition watermark, then the requests are sent at
lower priority until dropping below the level 0 watermark.
The lower priority requests allow other memory clients to have better
memory access. When IPC is disabled, all plane read requests are sent at
high priority.

Changes since V1:
 - Remove commandline parameter to disable ipc
 - Address Paulo's comments
Changes since V2:
 - Address review comments
 - Set ipc_enabled flag
Changes since V3:
 - move ipc_enabled flag assignment inside intel_ipc_enable function
Changes since V4:
 - Re-enable IPC after suspend/resume
Changes since V5:
 - Enable IPC for all gen >=9 except SKL
Changes since V6:
 - fix commit msg
 - after resume program IPC based on SW state.
Changes since V7:
 - Modify IPC support check based on HAS_IPC macro (suggested by Chris)

Signed-off-by: Mahesh Kumar 
Cc: Chris Wilson 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_drv.c  |  4 +++-
 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 drivers/gpu/drm/i915/intel_display.c |  1 +
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_pm.c  | 24 
 5 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 43100229613c..f655973bcb26 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1340,7 +1340,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
intel_runtime_pm_enable(dev_priv);
 
-   dev_priv->ipc_enabled = false;
+   intel_init_ipc(dev_priv);
 
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG))
DRM_INFO("DRM_I915_DEBUG enabled\n");
@@ -2602,6 +2602,8 @@ static int intel_runtime_resume(struct device *kdev)
if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
intel_hpd_init(dev_priv);
 
+   intel_enable_ipc(dev_priv);
+
enable_rpm_wakeref_asserts(dev_priv);
 
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ed7cd9ee2c2a..7240c0a3641c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6934,6 +6934,7 @@ enum {
 #define  DISP_FBC_WM_DIS   (1<<15)
 #define DISP_ARB_CTL2  _MMIO(0x45004)
 #define  DISP_DATA_PARTITION_5_6   (1<<6)
+#define  DISP_IPC_ENABLE   (1<<3)
 #define DBUF_CTL   _MMIO(0x45008)
 #define  DBUF_POWER_REQUEST(1<<31)
 #define  DBUF_POWER_STATE  (1<<30)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0e93ec201fe3..e11bb3b430a2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15164,6 +15164,7 @@ void intel_display_resume(struct drm_device *dev)
if (!ret)
ret = __intel_display_resume(dev, state, );
 
+   intel_enable_ipc(dev_priv);
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index fa47285918f4..a17c602319eb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1867,6 +1867,8 @@ bool ilk_disable_lp_wm(struct drm_device *dev);
 int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
 int skl_check_pipe_max_pixel_rate(struct intel_crtc *intel_crtc,
  struct intel_crtc_state *cstate);
+void intel_init_ipc(struct drm_i915_private *dev_priv);
+void intel_enable_ipc(struct drm_i915_private *dev_priv);
 static inline int intel_enable_rc6(void)
 {
return i915.enable_rc6;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index aee1a387a65a..8d7af30ed0b0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5818,6 +5818,30 @@ void intel_update_watermarks(struct intel_crtc *crtc)
dev_priv->display.update_wm(crtc);
 }
 
+void intel_enable_ipc(struct drm_i915_private *dev_priv)
+{
+   u32 val;
+
+   val = I915_READ(DISP_ARB_CTL2);
+
+   if (dev_priv->ipc_enabled)
+   val |= DISP_IPC_ENABLE;
+   else
+   val &= ~DISP_IPC_ENABLE;
+
+   I915_WRITE(DISP_ARB_CTL2, val);
+}
+
+void intel_init_ipc(struct drm_i915_private *dev_priv)
+{
+   dev_priv->ipc_enabled = false;
+   if (!HAS_IPC(dev_priv))
+   return;
+
+   dev_priv->ipc_enabled = true;
+   

[Intel-gfx] [PATCH 3/8] drm/i915/gen10: Calculate and enable transition WM

[Mahesh Kumar]

From: "Kumar, Mahesh" 

GEN > 9 require transition WM to be programmed if IPC is enabled.
This patch calculates & enable transition WM for supported platforms.
If transition WM is enabled, Plane read requests are sent at high
priority until filling above the transition watermark, then the
requests are sent at lower priority until dropping below the level-0 WM.
The lower priority requests allow other memory clients to have better
memory access.

transition minimum is the minimum amount needed for trans_wm to work to
ensure  the demote does not happen before enough data has been read to
meet the level 0 watermark requirements.

transition amount is configurable value. Higher values will
tend to cause longer periods of high priority reads followed by longer
periods of lower priority reads. Tuning to lower values will tend to
cause shorter periods of high and lower priority reads.

Keeping transition amount to 10 in this patch, as suggested by HW team.

Changes since V1:
 - Address review comments from Maarten

Signed-off-by: Mahesh Kumar 
Acked-by: Maarten Lankhorst 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_pm.c | 52 +++--
 1 file changed, 50 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 47c01da2e109..6face465ae48 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4624,12 +4624,56 @@ skl_compute_linetime_wm(struct intel_crtc_state *cstate)
 }
 
 static void skl_compute_transition_wm(struct intel_crtc_state *cstate,
+ struct skl_wm_params *wp,
+ struct skl_wm_level *wm_l0,
+ uint16_t ddb_allocation,
  struct skl_wm_level *trans_wm /* out */)
 {
+   struct drm_device *dev = cstate->base.crtc->dev;
+   const struct drm_i915_private *dev_priv = to_i915(dev);
+   uint16_t trans_min, trans_y_tile_min;
+   const uint16_t trans_amount = 10; /* This is configurable amount */
+   uint16_t trans_offset_b, res_blocks;
+
if (!cstate->base.active)
+   goto exit;
+
+   /* Transition WM are not recommended by HW team for GEN9 */
+   if (INTEL_GEN(dev_priv) <= 9)
+   goto exit;
+
+   /* Transition WM don't make any sense if ipc is disabled */
+   if (!dev_priv->ipc_enabled)
+   goto exit;
+
+   if (INTEL_GEN(dev_priv) >= 10)
+   trans_min = 4;
+
+   trans_offset_b = trans_min + trans_amount;
+
+   if (wp->y_tiled) {
+   trans_y_tile_min = (uint16_t) mul_round_up_u32_fixed16(2,
+   wp->y_tile_minimum);
+   res_blocks = max(wm_l0->plane_res_b, trans_y_tile_min) +
+   trans_offset_b;
+   } else {
+   res_blocks = wm_l0->plane_res_b + trans_offset_b;
+
+   /* WA BUG:1938466 add one block for non y-tile planes */
+   if (IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_A0))
+   res_blocks += 1;
+
+   }
+
+   res_blocks += 1;
+
+   if (res_blocks < ddb_allocation) {
+   trans_wm->plane_res_b = res_blocks;
+   trans_wm->plane_en = true;
return;
+   }
 
-   /* Until we know more, just disable transition WMs */
+exit:
trans_wm->plane_en = false;
 }
 
@@ -4656,8 +4700,11 @@ static int skl_build_pipe_wm(struct intel_crtc_state 
*cstate,
to_intel_plane_state(pstate);
enum plane_id plane_id = to_intel_plane(plane)->id;
struct skl_wm_params wm_params;
+   enum pipe pipe = to_intel_crtc(cstate->base.crtc)->pipe;
+   uint16_t ddb_blocks;
 
wm = _wm->planes[plane_id];
+   ddb_blocks = skl_ddb_entry_size(>plane[pipe][plane_id]);
memset(_params, 0, sizeof(struct skl_wm_params));
 
ret = skl_compute_plane_wm_params(dev_priv, cstate,
@@ -4669,7 +4716,8 @@ static int skl_build_pipe_wm(struct intel_crtc_state 
*cstate,
intel_pstate, _params, wm);
if (ret)
return ret;
-   skl_compute_transition_wm(cstate, >trans_wm);
+   skl_compute_transition_wm(cstate, _params, >wm[0],
+ ddb_blocks, >trans_wm);
}
pipe_wm->linetime = skl_compute_linetime_wm(cstate);
 
-- 
2.13.0

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

[Intel-gfx] [PATCH 0/8] Fixed16.16 wrapper cleanup & wm optimization

[Mahesh Kumar]

This is a Trybot Version of series.

This series Include patches for:
clean fixed16.16 wrappers
optimize wm calculation code
enable/Implement trans wm calculation
create a DebugFS entry for IPC status

Kumar, Mahesh (8):
  drm/i915: Fixed point fixed16 wrapper cleanup
  drm/i915/skl+: Optimize WM calculation
  drm/i915/gen10: Calculate and enable transition WM
  drm/i915/glk: IPC linetime watermark workaround for GLK
  drm/i915/cnl: Extend WM workaround with IPC for CNL
  drm/i915/gen9+: Add has_ipc flag in device info structure
  drm/i915/bxt+: Enable IPC support
  drm/i915/skl+: debugfs entry to control IPC

 drivers/gpu/drm/i915/i915_debugfs.c  |  54 ++-
 drivers/gpu/drm/i915/i915_drv.c  |   4 +-
 drivers/gpu/drm/i915/i915_drv.h  |  33 -
 drivers/gpu/drm/i915/i915_pci.c  |   4 +
 drivers/gpu/drm/i915/i915_reg.h  |   1 +
 drivers/gpu/drm/i915/intel_display.c |   1 +
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_pm.c  | 274 +++
 8 files changed, 273 insertions(+), 100 deletions(-)

-- 
2.13.0

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

[Intel-gfx] [PATCH 1/8] drm/i915: Fixed point fixed16 wrapper cleanup

[Mahesh Kumar]

From: "Kumar, Mahesh" 

As per suggestion from Jani, cleanup the code. Cleanup includes
 - Instead of left shifting & check, compare with U32/16_MAX
 - Use typecast instead of clamp_t

Signed-off-by: Mahesh Kumar 
Cc: Jani Nikula 
Reviewed-by: Jani Nikula 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_drv.h | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6c25c8520c87..fa5858da2ca0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -126,7 +126,7 @@ static inline uint_fixed_16_16_t u32_to_fixed16(uint32_t 
val)
 {
uint_fixed_16_16_t fp;
 
-   WARN_ON(val >> 16);
+   WARN_ON(val > U16_MAX);
 
fp.val = val << 16;
return fp;
@@ -163,8 +163,8 @@ static inline uint_fixed_16_16_t 
max_fixed16(uint_fixed_16_16_t max1,
 static inline uint_fixed_16_16_t clamp_u64_to_fixed16(uint64_t val)
 {
uint_fixed_16_16_t fp;
-   WARN_ON(val >> 32);
-   fp.val = clamp_t(uint32_t, val, 0, ~0);
+   WARN_ON(val > U32_MAX);
+   fp.val = (uint32_t) val;
return fp;
 }
 
@@ -181,8 +181,8 @@ static inline uint32_t mul_round_up_u32_fixed16(uint32_t 
val,
 
intermediate_val = (uint64_t) val * mul.val;
intermediate_val = DIV_ROUND_UP_ULL(intermediate_val, 1 << 16);
-   WARN_ON(intermediate_val >> 32);
-   return clamp_t(uint32_t, intermediate_val, 0, ~0);
+   WARN_ON(intermediate_val > U32_MAX);
+   return (uint32_t) intermediate_val;
 }
 
 static inline uint_fixed_16_16_t mul_fixed16(uint_fixed_16_16_t val,
@@ -211,8 +211,8 @@ static inline uint32_t div_round_up_u32_fixed16(uint32_t 
val,
 
interm_val = (uint64_t)val << 16;
interm_val = DIV_ROUND_UP_ULL(interm_val, d.val);
-   WARN_ON(interm_val >> 32);
-   return clamp_t(uint32_t, interm_val, 0, ~0);
+   WARN_ON(interm_val > U32_MAX);
+   return (uint32_t) interm_val;
 }
 
 static inline uint_fixed_16_16_t mul_u32_fixed16(uint32_t val,
-- 
2.13.0

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

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Trivial grammar fix s/opt of/opt out of/ in comment

[Joonas Lahtinen]

On Wed, 2017-08-16 at 09:52 +0100, Chris Wilson wrote:
> The word out was dropped from the sentence across the line break, put it
> back.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

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 7/7] drm/i915: Mark the GT as busy before idling the previous request

[Joonas Lahtinen]

On Wed, 2017-08-16 at 09:52 +0100, Chris Wilson wrote:
> In a synchronous setup, we may retire the last request before we
> complete allocating the next request. As the last request is retired, we
> queue a timer to mark the device as idle, and promptly have to execute
> ad cancel that timer once we complete allocating the request and need to
> keep the device awake. If we rearrange the mark_busy() to occur before
> we retire the previous request, we can skip this ping-pong.
> 
> Signed-off-by: Chris Wilson 



> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -265,6 +265,13 @@ static int reserve_seqno(struct intel_engine_cs *engine)
>  
>  static void unreserve_seqno(struct intel_engine_cs *engine)
>  {
> + if (!--engine->i915->gt.active_requests) {
> + GEM_BUG_ON(!engine->i915->gt.awake);
> + mod_delayed_work(engine->i915->wq,
> +  >i915->gt.idle_work,
> +  msecs_to_jiffies(100));
> + }

This function could use a better name, now it seems to tightly tie to
seqno only, and idle work is very unexpected. How about just
unreserve_engine vs. reserve_engine?

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Boost GPU clocks if we miss the pageflip's vblank

[Patchwork]

== Series Details ==

Series: drm/i915: Boost GPU clocks if we miss the pageflip's vblank
URL   : https://patchwork.freedesktop.org/series/28921/
State : failure

== Summary ==

Series 28921v1 drm/i915: Boost GPU clocks if we miss the pageflip's vblank
https://patchwork.freedesktop.org/api/1.0/series/28921/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-skl-6260u)

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:456s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:361s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:548s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:524s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:524s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:608s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:446s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:422s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:422s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:511s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:478s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:476s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:596s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:596s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:532s
fi-skl-6260u total:237  pass:229  dwarn:0   dfail:0   fail:0   skip:7  
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:478s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:483s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:444s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:484s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:551s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:411s

ada53b43f81fe618f3f0f1dfbd3dd776bb277323 drm-tip: 2017y-08m-16d-15h-18m-56s UTC 
integration manifest
87e8bf68f70d drm/i915: Boost GPU clocks if we miss the pageflip's vblank

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5427/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915/cnl: Avoid old DDI translation functions on Cannonlake.

[Mika Kahola]

On Thu, 2017-07-06 at 13:54 -0700, Rodrigo Vivi wrote:
> Cannonlake uses a different swing voltage initalization
> sequence scheme that doesn't require these old functions.
> 
> All other DDI, voltage swing and PLLs initialialization
> and configuration are already in place for Cannonlake.
> This patch only removes unecessary steps probably saving
> us from some useless warnings.
> 
> Cc: Clint Taylor 
> Cc: Mika Kahola 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 80e96f1..9e9bfbe 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -596,7 +596,7 @@ static int intel_ddi_hdmi_level(struct
> drm_i915_private *dev_priv, enum port por
>  
>   hdmi_level = dev_priv-
> >vbt.ddi_port_info[port].hdmi_level_shift;
>  
> - if (IS_GEN9_LP(dev_priv))
> + if (IS_GEN9_LP(dev_priv) || INTEL_GEN(dev_priv) >= 10)
Can we assume that this holds always for GEN10 and above platforms?
 
>   return hdmi_level;
>  
>   if (IS_GEN9_BC(dev_priv)) {
> @@ -688,7 +688,7 @@ static void intel_prepare_dp_ddi_buffers(struct
> intel_encoder *encoder)
>   enum port port = intel_ddi_get_encoder_port(encoder);
>   const struct ddi_buf_trans *ddi_translations;
>  
> - if (IS_GEN9_LP(dev_priv))
> + if (IS_GEN9_LP(dev_priv) || INTEL_GEN(dev_priv) >= 10)
>   return;
>  
>   switch (encoder->type) {
> @@ -741,7 +741,7 @@ static void intel_prepare_hdmi_ddi_buffers(struct
> intel_encoder *encoder)
>   enum port port = intel_ddi_get_encoder_port(encoder);
>   const struct ddi_buf_trans *ddi_translations_hdmi;
>  
> - if (IS_GEN9_LP(dev_priv))
> + if (IS_GEN9_LP(dev_priv) || INTEL_GEN(dev_priv) >= 10)
>   return;
>  
>   hdmi_level = intel_ddi_hdmi_level(dev_priv, port);
-- 
Mika Kahola - Intel OTC

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

[Intel-gfx] [PATCH] drm/i915: Boost GPU clocks if we miss the pageflip's vblank

[Chris Wilson]

If we miss the current vblank because the gpu was busy, that may cause a
jitter as the frame rate temporarily drops. We try to limit the impact
of this by then boosting the GPU clock to deliver the frame as quickly
as possible. Originally done in commit 6ad790c0f5ac ("drm/i915: Boost GPU
frequency if we detect outstanding pageflips") but was never forward
ported to atomic and finally dropped in commit fd3a40242e87 ("drm/i915:
Rip out legacy page_flip completion/irq handling").

References: https://bugs.freedesktop.org/show_bug.cgi?id=102199
Signed-off-by: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 59 
 drivers/gpu/drm/i915/intel_drv.h |  1 -
 drivers/gpu/drm/i915/intel_pm.c  | 42 ++---
 3 files changed, 62 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0e93ec201fe3..7d5b19553637 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12636,6 +12636,55 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.set_crc_source = intel_crtc_set_crc_source,
 };
 
+struct wait_rps_boost {
+   struct wait_queue_entry wait;
+
+   struct drm_crtc *crtc;
+   struct drm_i915_gem_request *request;
+};
+
+static int do_rps_boost(struct wait_queue_entry *_wait,
+   unsigned mode, int sync, void *key)
+{
+   struct wait_rps_boost *wait = container_of(_wait, typeof(*wait), wait);
+   struct drm_i915_gem_request *rq = wait->request;
+
+   gen6_rps_boost(rq, NULL);
+   i915_gem_request_put(rq);
+
+   drm_crtc_vblank_put(wait->crtc);
+
+   list_del(>wait.entry);
+   kfree(wait);
+   return 1;
+}
+
+static void add_rps_boost_after_vblank(struct drm_crtc *crtc,
+  struct dma_fence *fence)
+{
+   struct wait_rps_boost *wait;
+
+   if (!dma_fence_is_i915(fence))
+   return;
+
+   if (drm_crtc_vblank_get(crtc))
+   return;
+
+   wait = kmalloc(sizeof(*wait), GFP_KERNEL);
+   if (!wait) {
+   drm_crtc_vblank_put(crtc);
+   return;
+   }
+
+   wait->request = to_request(dma_fence_get(fence));
+   wait->crtc = crtc;
+
+   wait->wait.func = do_rps_boost;
+   wait->wait.flags = 0;
+
+   add_wait_queue(drm_crtc_vblank_waitqueue(crtc), >wait);
+}
+
 /**
  * intel_prepare_plane_fb - Prepare fb for usage on plane
  * @plane: drm plane to prepare for
@@ -12733,12 +12782,22 @@ intel_prepare_plane_fb(struct drm_plane *plane,
return ret;
 
if (!new_state->fence) { /* implicit fencing */
+   struct dma_fence *fence;
+
ret = 
i915_sw_fence_await_reservation(_state->commit_ready,
  obj->resv, NULL,
  false, I915_FENCE_TIMEOUT,
  GFP_KERNEL);
if (ret < 0)
return ret;
+
+   fence = reservation_object_get_excl_rcu(obj->resv);
+   if (fence) {
+   add_rps_boost_after_vblank(new_state->crtc, fence);
+   dma_fence_put(fence);
+   }
+   } else {
+   add_rps_boost_after_vblank(new_state->crtc, new_state->fence);
}
 
return 0;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index fa47285918f4..e092354b4d63 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1844,7 +1844,6 @@ void gen6_rps_reset_ei(struct drm_i915_private *dev_priv);
 void gen6_rps_idle(struct drm_i915_private *dev_priv);
 void gen6_rps_boost(struct drm_i915_gem_request *rq,
struct intel_rps_client *rps);
-void intel_queue_rps_boost_for_request(struct drm_i915_gem_request *req);
 void g4x_wm_get_hw_state(struct drm_device *dev);
 void vlv_wm_get_hw_state(struct drm_device *dev);
 void ilk_wm_get_hw_state(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ed662937ec3c..c9fa2eb1903c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6169,6 +6169,7 @@ void gen6_rps_boost(struct drm_i915_gem_request *rq,
struct intel_rps_client *rps)
 {
struct drm_i915_private *i915 = rq->i915;
+   unsigned long flags;
bool boost;
 
/* This is intentionally racy! We peek at the state here, then
@@ -6178,13 +6179,13 @@ void gen6_rps_boost(struct drm_i915_gem_request *rq,
return;
 
boost = false;
-   spin_lock_irq(>lock);
+   

Re: [Intel-gfx] [PATCH v2] drm/i915: Beef up the IPS vs. CRC workaround

[Ville Syrjälä]

On Thu, Aug 17, 2017 at 03:16:46PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 17, 2017 at 10:00:52AM +0200, Maarten Lankhorst wrote:
> > Op 16-08-17 om 16:39 schreef ville.syrj...@linux.intel.com:
> > > From: Ville Syrjälä 
> > >
> > > Oneshot disabling of IPS when CRC capturing is started is insufficient.
> > > IPS may get re-enabled by any plane update, and hence tests that keep
> > > CRC capturing on across plane updates will start to see inconsistent
> > > results as soon as IPS kicks back in. Add a new knob into the crtc state
> > > to make sure IPS stays disabled as long as CRC capturing is enabled.
> > >
> > > Forcing a modeset is the easiest way to handle this since that's already
> > > how we do the panel fitter workaround. It's a little heavy handed just
> > > for IPS, but seeing as we might already do the panel fitter workaround
> > > I think it's better to follow that. We migth want to optimize both cases
> > > later if someone gets too upset by the extra delay from the modeset.
> > >
> > > v2: Check the right thing when deciding whether to force a modeset
> > >
> > > Cc: Paulo Zanoni 
> > > Cc: Daniel Vetter 
> > > Cc: Maarten Lankhorst 
> > > Cc: Marta Lofstedt 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101664
> > > Reviewed-by: Paulo Zanoni 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c  |  5 +++-
> > >  drivers/gpu/drm/i915/intel_drv.h  |  1 +
> > >  drivers/gpu/drm/i915/intel_pipe_crc.c | 43 
> > > +++
> > >  3 files changed, 28 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index ef5dde5ab1cf..1ce479614f52 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -7189,6 +7189,7 @@ static void hsw_compute_ips_config(struct 
> > > intel_crtc *crtc,
> > >   struct drm_i915_private *dev_priv = to_i915(dev);
> > >  
> > >   pipe_config->ips_enabled = i915.enable_ips &&
> > > + !pipe_config->ips_force_disable &&
> > >   hsw_crtc_supports_ips(crtc) &&
> > >   pipe_config_supports_ips(dev_priv, pipe_config);
> > >  }
> > > @@ -12958,7 +12959,7 @@ clear_intel_crtc_state(struct intel_crtc_state 
> > > *crtc_state)
> > >   struct intel_crtc_scaler_state scaler_state;
> > >   struct intel_dpll_hw_state dpll_hw_state;
> > >   struct intel_shared_dpll *shared_dpll;
> > > - bool force_thru;
> > > + bool force_thru, ips_force_disable;
> > >  
> > >   /* FIXME: before the switch to atomic started, a new pipe_config was
> > >* kzalloc'd. Code that depends on any field being zero should be
> > > @@ -12970,6 +12971,7 @@ clear_intel_crtc_state(struct intel_crtc_state 
> > > *crtc_state)
> > >   shared_dpll = crtc_state->shared_dpll;
> > >   dpll_hw_state = crtc_state->dpll_hw_state;
> > >   force_thru = crtc_state->pch_pfit.force_thru;
> > > + ips_force_disable = crtc_state->ips_force_disable;
> > >  
> > >   memset(crtc_state, 0, sizeof *crtc_state);
> > >  
> > > @@ -12978,6 +12980,7 @@ clear_intel_crtc_state(struct intel_crtc_state 
> > > *crtc_state)
> > >   crtc_state->shared_dpll = shared_dpll;
> > >   crtc_state->dpll_hw_state = dpll_hw_state;
> > >   crtc_state->pch_pfit.force_thru = force_thru;
> > > + crtc_state->ips_force_disable = ips_force_disable;
> > >  }
> > >  
> > >  static int
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index 025e4c8b3e63..cadba9b92cc9 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -651,6 +651,7 @@ struct intel_crtc_state {
> > >   struct intel_link_m_n fdi_m_n;
> > >  
> > >   bool ips_enabled;
> > > + bool ips_force_disable;
> > Could we rename this to collecting_crc throughout the patch?
> 
> If we do, then we should probably kill off the separate pfit
> force_thru boolean as well and just use 'collecting_crc' for
> the pipe A routing decisions as well.

On further thought that name would be somewhat misleading if we only
set it for HSW/BDW+pipe A.

> 
> > 
> > And as Marta noted, intel_crtc_set_crc_source also needs fixing. :)
> 
> Doh. I thought I retipped the patch, but apparently I didn't.
> 
> > >  
> > >   bool enable_fbc;
> > >  
> > > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c 
> > > b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > index ef0c0e195164..74780b090d1e 100644
> > > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > @@ -547,8 +547,8 @@ static int ilk_pipe_crc_ctl_reg(enum 
> > > intel_pipe_crc_source *source,
> > >   return 0;
> > >  }
> > >  
> > > -static void hsw_trans_edp_pipe_A_crc_wa(struct drm_i915_private 

Re: [Intel-gfx] [PATCH v3 4/4] drm/i915: Acquire PUNIT->PMIC bus for intel_uncore_forcewake_reset()

[Imre Deak]

On Mon, Aug 14, 2017 at 09:58:32PM +0200, Hans de Goede wrote:
> intel_uncore_forcewake_reset() does forcewake puts and gets as such
> we need to make sure that no-one tries to access the PUNIT->PMIC bus
> (on systems where this bus is shared) while it runs, otherwise bad
> things happen.
> 
> Normally this is taken care of by the i915_pmic_bus_access_notifier()
> which does an intel_uncore_forcewake_get(FORCEWAKE_ALL) when some other
> driver tries to access the PMIC bus, so that later forcewake gets are
> no-ops (for the duration of the bus access).
> 
> But intel_uncore_forcewake_reset gets called in 3 cases:
> 1) Before registering the pmic_bus_access_notifier
> 2) After unregistering the pmic_bus_access_notifier
> 3) To reset forcewake state on a GPU reset
> 
> In all 3 cases the i915_pmic_bus_access_notifier() protection is
> insufficient.
> 
> This commit fixes this race by calling iosf_mbi_punit_acquire() before
> calling intel_uncore_forcewake_reset(). In the case where it is called
> directly after unregistering the pmic_bus_access_notifier, we need to
> hold the punit-lock over both calls to avoid a race where
> intel_uncore_fw_release_timer() may execute between the 2 calls.
> 
> To allow holding the lock over both calls we need an unlocked
> variant of iosf_mbi_unregister_pmic_bus_access_notifier. Since
> intel_uncore.c is the only user of this function, we simply
> modify it in this commit. Doing this in a separate commit would
> require first adding an unlocked variant, then this commit and
> then removing the unused normal variant.
> 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -Rebase on current (July 6th 2017) drm-next
> 
> Changes in v3:
> -Keep punit acquired / locked over the unregister + forcewake_reset
>  call combo to avoid a race hitting between the 2 calls
> -This requires modifying iosf_mbi_unregister_pmic_bus_access_notifier
>  to not take the lock itself, since we are the only users this is done
>  in this same commit
> ---
>  arch/x86/include/asm/iosf_mbi.h | 10 --
>  arch/x86/platform/intel/iosf_mbi.c  | 14 +-
>  drivers/gpu/drm/i915/intel_uncore.c | 17 +
>  3 files changed, 26 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/x86/include/asm/iosf_mbi.h b/arch/x86/include/asm/iosf_mbi.h
> index c313cac36f56..f8841bb06d98 100644
> --- a/arch/x86/include/asm/iosf_mbi.h
> +++ b/arch/x86/include/asm/iosf_mbi.h
> @@ -141,9 +141,14 @@ int iosf_mbi_register_pmic_bus_access_notifier(struct 
> notifier_block *nb);
>  /**
>   * iosf_mbi_register_pmic_bus_access_notifier - Unregister PMIC bus notifier

You missed the rename in the doc.

>   *
> + * Note the caller must call iosf_mbi_punit_acquire() before calling this
> + * to ensure the bus is inactive before unregistering (and call
> + * iosf_mbi_punit_release() afterwards).
> + *
>   * @nb: notifier_block to unregister
>   */
> -int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb);
> +int iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(
> + struct notifier_block *nb);
>  
>  /**
>   * iosf_mbi_call_pmic_bus_access_notifier_chain - Call PMIC bus notifier 
> chain
> @@ -191,7 +196,8 @@ int iosf_mbi_register_pmic_bus_access_notifier(struct 
> notifier_block *nb)
>  }
>  
>  static inline
> -int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb)
> +int iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(
> + struct notifier_block *nb)
>  {
>   return 0;
>  }
> diff --git a/arch/x86/platform/intel/iosf_mbi.c 
> b/arch/x86/platform/intel/iosf_mbi.c
> index a952ac199741..5596a3ec1b89 100644
> --- a/arch/x86/platform/intel/iosf_mbi.c
> +++ b/arch/x86/platform/intel/iosf_mbi.c
> @@ -218,19 +218,15 @@ int iosf_mbi_register_pmic_bus_access_notifier(struct 
> notifier_block *nb)
>  }
>  EXPORT_SYMBOL(iosf_mbi_register_pmic_bus_access_notifier);
>  
> -int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb)
> +int iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(
> + struct notifier_block *nb)
>  {
> - int ret;
> + WARN_ON(!mutex_is_locked(_mbi_punit_mutex));
>  
> - /* Wait for the bus to go inactive before unregistering */
> - mutex_lock(_mbi_punit_mutex);
> - ret = blocking_notifier_chain_unregister(
> + return blocking_notifier_chain_unregister(
>   _mbi_pmic_bus_access_notifier, nb);
> - mutex_unlock(_mbi_punit_mutex);
> -
> - return ret;
>  }
> -EXPORT_SYMBOL(iosf_mbi_unregister_pmic_bus_access_notifier);
> +EXPORT_SYMBOL(iosf_mbi_unregister_pmic_bus_access_notifier_unlocked);
>  
>  int iosf_mbi_call_pmic_bus_access_notifier_chain(unsigned long val, void *v)
>  {
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 569d115918eb..7be6150520ed 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -229,6 +229,7 @@ 

Re: [Intel-gfx] [PATCH v2] drm/i915: Beef up the IPS vs. CRC workaround

[Ville Syrjälä]

On Thu, Aug 17, 2017 at 10:00:52AM +0200, Maarten Lankhorst wrote:
> Op 16-08-17 om 16:39 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä 
> >
> > Oneshot disabling of IPS when CRC capturing is started is insufficient.
> > IPS may get re-enabled by any plane update, and hence tests that keep
> > CRC capturing on across plane updates will start to see inconsistent
> > results as soon as IPS kicks back in. Add a new knob into the crtc state
> > to make sure IPS stays disabled as long as CRC capturing is enabled.
> >
> > Forcing a modeset is the easiest way to handle this since that's already
> > how we do the panel fitter workaround. It's a little heavy handed just
> > for IPS, but seeing as we might already do the panel fitter workaround
> > I think it's better to follow that. We migth want to optimize both cases
> > later if someone gets too upset by the extra delay from the modeset.
> >
> > v2: Check the right thing when deciding whether to force a modeset
> >
> > Cc: Paulo Zanoni 
> > Cc: Daniel Vetter 
> > Cc: Maarten Lankhorst 
> > Cc: Marta Lofstedt 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101664
> > Reviewed-by: Paulo Zanoni 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c  |  5 +++-
> >  drivers/gpu/drm/i915/intel_drv.h  |  1 +
> >  drivers/gpu/drm/i915/intel_pipe_crc.c | 43 
> > +++
> >  3 files changed, 28 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index ef5dde5ab1cf..1ce479614f52 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -7189,6 +7189,7 @@ static void hsw_compute_ips_config(struct intel_crtc 
> > *crtc,
> > struct drm_i915_private *dev_priv = to_i915(dev);
> >  
> > pipe_config->ips_enabled = i915.enable_ips &&
> > +   !pipe_config->ips_force_disable &&
> > hsw_crtc_supports_ips(crtc) &&
> > pipe_config_supports_ips(dev_priv, pipe_config);
> >  }
> > @@ -12958,7 +12959,7 @@ clear_intel_crtc_state(struct intel_crtc_state 
> > *crtc_state)
> > struct intel_crtc_scaler_state scaler_state;
> > struct intel_dpll_hw_state dpll_hw_state;
> > struct intel_shared_dpll *shared_dpll;
> > -   bool force_thru;
> > +   bool force_thru, ips_force_disable;
> >  
> > /* FIXME: before the switch to atomic started, a new pipe_config was
> >  * kzalloc'd. Code that depends on any field being zero should be
> > @@ -12970,6 +12971,7 @@ clear_intel_crtc_state(struct intel_crtc_state 
> > *crtc_state)
> > shared_dpll = crtc_state->shared_dpll;
> > dpll_hw_state = crtc_state->dpll_hw_state;
> > force_thru = crtc_state->pch_pfit.force_thru;
> > +   ips_force_disable = crtc_state->ips_force_disable;
> >  
> > memset(crtc_state, 0, sizeof *crtc_state);
> >  
> > @@ -12978,6 +12980,7 @@ clear_intel_crtc_state(struct intel_crtc_state 
> > *crtc_state)
> > crtc_state->shared_dpll = shared_dpll;
> > crtc_state->dpll_hw_state = dpll_hw_state;
> > crtc_state->pch_pfit.force_thru = force_thru;
> > +   crtc_state->ips_force_disable = ips_force_disable;
> >  }
> >  
> >  static int
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 025e4c8b3e63..cadba9b92cc9 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -651,6 +651,7 @@ struct intel_crtc_state {
> > struct intel_link_m_n fdi_m_n;
> >  
> > bool ips_enabled;
> > +   bool ips_force_disable;
> Could we rename this to collecting_crc throughout the patch?

If we do, then we should probably kill off the separate pfit
force_thru boolean as well and just use 'collecting_crc' for
the pipe A routing decisions as well.

> 
> And as Marta noted, intel_crtc_set_crc_source also needs fixing. :)

Doh. I thought I retipped the patch, but apparently I didn't.

> >  
> > bool enable_fbc;
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c 
> > b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > index ef0c0e195164..74780b090d1e 100644
> > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > @@ -547,8 +547,8 @@ static int ilk_pipe_crc_ctl_reg(enum 
> > intel_pipe_crc_source *source,
> > return 0;
> >  }
> >  
> > -static void hsw_trans_edp_pipe_A_crc_wa(struct drm_i915_private *dev_priv,
> > -   bool enable)
> > +static void hsw_pipe_A_crc_wa(struct drm_i915_private *dev_priv,
> > + bool enable)
> >  {
> > struct drm_device *dev = _priv->drm;
> > struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, PIPE_A);
> > @@ -570,11 +570,23 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/opregion: let user specify override VBT via firmware load (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/opregion: let user specify override VBT via firmware load 
(rev2)
URL   : https://patchwork.freedesktop.org/series/25105/
State : success

== Summary ==

Series 25105v2 drm/i915/opregion: let user specify override VBT via firmware 
load
https://patchwork.freedesktop.org/api/1.0/series/25105/revisions/2/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-byt-n2820) fdo#101705

fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:451s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:441s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:358s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:552s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:524s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:525s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:519s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:609s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:444s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:423s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:421s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:506s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:476s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:471s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:595s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:599s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:527s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:470s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:475s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:488s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:444s
fi-skl-x1585ltotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:515s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:544s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:404s

ada53b43f81fe618f3f0f1dfbd3dd776bb277323 drm-tip: 2017y-08m-16d-15h-18m-56s UTC 
integration manifest
e3823ff65946 drm/i915/opregion: let user specify override VBT via firmware load

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5426/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 RESEND] drm/i915/opregion: let user specify override VBT via firmware load

[Jani Nikula]

Sometimes it would be most enlightening to debug systems by replacing
the VBT to be used. For example, in the referenced bug the BIOS provides
different VBT depending on the boot mode (UEFI vs. legacy). It would be
interesting to try the failing boot mode with the VBT from the working
boot, and see if that makes a difference.

Add a module parameter to load the VBT using the firmware loader, not
unlike the EDID firmware mechanism.

As a starting point for experimenting, one can pick up the BIOS provided
VBT from /sys/kernel/debug/dri/0/i915_opregion/i915_vbt.

v2: clarify firmware load return value check (Bob)

v3: kfree the loaded firmware blob

References: https://bugs.freedesktop.org/show_bug.cgi?id=97822#c83
Reviewed-by: Bob Paauwe 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/i915_params.c|  4 
 drivers/gpu/drm/i915/i915_params.h|  1 +
 drivers/gpu/drm/i915/intel_opregion.c | 45 +++
 4 files changed, 51 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6c25c8520c87..3ee4fd2a9b41 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -646,6 +646,7 @@ struct intel_opregion {
u32 swsci_sbcb_sub_functions;
struct opregion_asle *asle;
void *rvda;
+   void *vbt_firmware;
const void *vbt;
u32 vbt_size;
u32 *lid_state;
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 14e2c2e57f96..8ab003dca113 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -118,6 +118,10 @@ MODULE_PARM_DESC(vbt_sdvo_panel_type,
 module_param_named_unsafe(reset, i915.reset, int, 0600);
 MODULE_PARM_DESC(reset, "Attempt GPU resets (0=disabled, 1=full gpu reset, 
2=engine reset [default])");
 
+module_param_named_unsafe(vbt_firmware, i915.vbt_firmware, charp, 0400);
+MODULE_PARM_DESC(vbt_firmware,
+"Load VBT from specified file under /lib/firmware");
+
 #if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
 module_param_named(error_capture, i915.error_capture, bool, 0600);
 MODULE_PARM_DESC(error_capture,
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index febbfdbd30bd..ac844709c97e 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -28,6 +28,7 @@
 #include  /* for __read_mostly */
 
 #define I915_PARAMS_FOR_EACH(func) \
+   func(char *, vbt_firmware); \
func(int, modeset); \
func(int, panel_ignore_lid); \
func(int, semaphores); \
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 2bd03001cc70..98154efcb2f4 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -27,6 +27,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -829,6 +830,10 @@ void intel_opregion_unregister(struct drm_i915_private 
*dev_priv)
memunmap(opregion->rvda);
opregion->rvda = NULL;
}
+   if (opregion->vbt_firmware) {
+   kfree(opregion->vbt_firmware);
+   opregion->vbt_firmware = NULL;
+   }
opregion->header = NULL;
opregion->acpi = NULL;
opregion->swsci = NULL;
@@ -912,6 +917,43 @@ static const struct dmi_system_id intel_no_opregion_vbt[] 
= {
{ }
 };
 
+static int intel_load_vbt_firmware(struct drm_i915_private *dev_priv)
+{
+   struct intel_opregion *opregion = _priv->opregion;
+   const struct firmware *fw = NULL;
+   const char *name = i915.vbt_firmware;
+   int ret;
+
+   if (!name || !*name)
+   return -ENOENT;
+
+   ret = request_firmware(, name, _priv->drm.pdev->dev);
+   if (ret) {
+   DRM_ERROR("Requesting VBT firmware \"%s\" failed (%d)\n",
+ name, ret);
+   return ret;
+   }
+
+   if (intel_bios_is_valid_vbt(fw->data, fw->size)) {
+   opregion->vbt_firmware = kmemdup(fw->data, fw->size, 
GFP_KERNEL);
+   if (opregion->vbt_firmware) {
+   DRM_DEBUG_KMS("Found valid VBT firmware \"%s\"\n", 
name);
+   opregion->vbt = opregion->vbt_firmware;
+   opregion->vbt_size = fw->size;
+   ret = 0;
+   } else {
+   ret = -ENOMEM;
+   }
+   } else {
+   DRM_DEBUG_KMS("Invalid VBT firmware \"%s\"\n", name);
+   ret = -EINVAL;
+   }
+
+   release_firmware(fw);
+
+   return ret;
+}
+
 int intel_opregion_setup(struct drm_i915_private *dev_priv)
 {
struct intel_opregion *opregion = _priv->opregion;
@@ -974,6 +1016,9 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
if (mboxes & MBOX_ASLE_EXT)

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bxt: use NULL for GPIO connection ID (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/bxt: use NULL for GPIO connection ID (rev2)
URL   : https://patchwork.freedesktop.org/series/20011/
State : success

== Summary ==

Series 20011v2 drm/i915/bxt: use NULL for GPIO connection ID
https://patchwork.freedesktop.org/api/1.0/series/20011/revisions/2/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-byt-n2820) fdo#101705

fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:454s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:452s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:364s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:552s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:524s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:531s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:518s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:617s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:447s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:426s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:425s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:511s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:476s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:479s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:596s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:595s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:524s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:478s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:482s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:493s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:437s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:489s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:548s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:409s

ada53b43f81fe618f3f0f1dfbd3dd776bb277323 drm-tip: 2017y-08m-16d-15h-18m-56s UTC 
integration manifest
9920a7e829ce drm/i915/bxt: use NULL for GPIO connection ID

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5425/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/bxt: use NULL for GPIO connection ID

[Mika Kahola]

Tested with GLK + MIPI/DSI panel (AU Optronics B101UAN01)

Tested-by: Mika Kahola 

On Thu, 2017-08-17 at 13:55 +0300, Andy Shevchenko wrote:
> The commit 213e08ad60ba
>   ("drm/i915/bxt: add bxt dsi gpio element support")
> enables GPIO support for Broxton based platforms.
> 
> While using that API we might get into troubles in the future,
> because
> we can't rely on label name in the driver since vendor firmware might
> provide any GPIO pin there, e.g. "reset", and even mark it in _DSD
> (in
> which case the request will fail).
> 
> To avoid inconsistency and potential issues we have two options:
> a) generate GPIO ACPI mapping table and supply it via
>    acpi_dev_add_driver_gpios(), or
> b) just pass NULL as connection ID.
> 
> The b) approach is much simpler and would work since the driver
> relies
> on GPIO indices only. Moreover, the _CRS fallback mechanism, when
> requesting GPIO, has been made stricter, and supplying non-NULL
> connection ID when neither _DSD, nor GPIO ACPI mapping is present, is
> making request fail.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101921
> Fixes: f10e4bf6632b ("gpio: acpi: Even more tighten up ACPI GPIO
> lookups")
> Cc: Mika Kahola 
> Cc: Jani Nikula 
> Signed-off-by: Andy Shevchenko 
> ---
> v2:
>  - adjust commit message for proper time tenses
>  - add Fixes: and Bugzilla: tags
>  drivers/gpu/drm/i915/intel_dsi_vbt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> index 7158c7ce9c09..91c07b0c8db9 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> @@ -306,7 +306,7 @@ static void bxt_exec_gpio(struct drm_i915_private
> *dev_priv,
>  
>   if (!gpio_desc) {
>   gpio_desc = devm_gpiod_get_index(dev_priv->drm.dev,
> -  "panel",
> gpio_index,
> +  NULL, gpio_index,
>    value ?
> GPIOD_OUT_LOW :
>    GPIOD_OUT_HIGH);
>  
___
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: Fix integer overflow tests (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix integer overflow tests (rev3)
URL   : https://patchwork.freedesktop.org/series/28898/
State : success

== Summary ==

Series 28898v3 drm/i915: Fix integer overflow tests
https://patchwork.freedesktop.org/api/1.0/series/28898/revisions/3/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:449s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:434s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:362s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:545s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:521s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:523s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:514s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:607s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:444s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:422s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:424s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:502s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:473s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:483s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:590s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:599s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:528s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:475s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:476s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:483s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:444s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:486s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:542s
fi-snb-2600  total:279  pass:249  dwarn:0   dfail:0   fail:1   skip:29  
time:407s

ada53b43f81fe618f3f0f1dfbd3dd776bb277323 drm-tip: 2017y-08m-16d-15h-18m-56s UTC 
integration manifest
777232c3b82a drm/i915: Prevent overflow of execbuf.buffer_count and 
num_cliprects

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5424/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915/bxt: use NULL for GPIO connection ID

[Andy Shevchenko]

The commit 213e08ad60ba
("drm/i915/bxt: add bxt dsi gpio element support")
enables GPIO support for Broxton based platforms.

While using that API we might get into troubles in the future, because
we can't rely on label name in the driver since vendor firmware might
provide any GPIO pin there, e.g. "reset", and even mark it in _DSD (in
which case the request will fail).

To avoid inconsistency and potential issues we have two options:
a) generate GPIO ACPI mapping table and supply it via
   acpi_dev_add_driver_gpios(), or
b) just pass NULL as connection ID.

The b) approach is much simpler and would work since the driver relies
on GPIO indices only. Moreover, the _CRS fallback mechanism, when
requesting GPIO, has been made stricter, and supplying non-NULL
connection ID when neither _DSD, nor GPIO ACPI mapping is present, is
making request fail.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101921
Fixes: f10e4bf6632b ("gpio: acpi: Even more tighten up ACPI GPIO lookups")
Cc: Mika Kahola 
Cc: Jani Nikula 
Signed-off-by: Andy Shevchenko 
---
v2:
 - adjust commit message for proper time tenses
 - add Fixes: and Bugzilla: tags
 drivers/gpu/drm/i915/intel_dsi_vbt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 7158c7ce9c09..91c07b0c8db9 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -306,7 +306,7 @@ static void bxt_exec_gpio(struct drm_i915_private *dev_priv,
 
if (!gpio_desc) {
gpio_desc = devm_gpiod_get_index(dev_priv->drm.dev,
-"panel", gpio_index,
+NULL, gpio_index,
 value ? GPIOD_OUT_LOW :
 GPIOD_OUT_HIGH);
 
-- 
2.14.1

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

[Intel-gfx] [PATCH v2] drm/i915: Prevent overflow of execbuf.buffer_count and num_cliprects

[Chris Wilson]

We check whether the multiplies will overflow prior to calling
kmalloc_array so that we can respond with -EINVAL for the invalid user
arguments rather than treating it as an -ENOMEM that would otherwise
occur. However, as Dan Carpenter pointed out, we did an addition on the
unsigned int prior to passing to kmalloc_array where it would be
promoted to size_t for the calculation, thereby allowing it to overflow
and underallocate.

v2: buffer_count is currently limited to INT_MAX because we treat it as
signaled variable for LUT_HANDLE in eb_lookup_vma

Reported-by: Dan Carpenter 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 33 --
 1 file changed, 18 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 8e8bc7aefd9c..b1cfbe3ae959 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2143,7 +2143,7 @@ static struct drm_syncobj **
 get_fence_array(struct drm_i915_gem_execbuffer2 *args,
struct drm_file *file)
 {
-   const unsigned int nfences = args->num_cliprects;
+   const size_t nfences = args->num_cliprects;
struct drm_i915_gem_exec_fence __user *user;
struct drm_syncobj **fences;
unsigned int n;
@@ -2152,14 +2152,14 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args,
if (!(args->flags & I915_EXEC_FENCE_ARRAY))
return NULL;
 
-   if (nfences > SIZE_MAX / sizeof(*fences))
+   if (nfences > SIZE_MAX / max(sizeof(*fences), 2*sizeof(u32)))
return ERR_PTR(-EINVAL);
 
user = u64_to_user_ptr(args->cliprects_ptr);
if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32)))
return ERR_PTR(-EFAULT);
 
-   fences = kvmalloc_array(args->num_cliprects, sizeof(*fences),
+   fences = kvmalloc_array(nfences, sizeof(*fences),
__GFP_NOWARN | GFP_TEMPORARY);
if (!fences)
return ERR_PTR(-ENOMEM);
@@ -2517,11 +2517,13 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
struct drm_i915_gem_execbuffer2 exec2;
struct drm_i915_gem_exec_object *exec_list = NULL;
struct drm_i915_gem_exec_object2 *exec2_list = NULL;
+   const size_t count = args->buffer_count;
unsigned int i;
int err;
 
-   if (args->buffer_count < 1 || args->buffer_count > SIZE_MAX / sz - 1) {
-   DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count);
+   /* Lookups via HANDLE_LUT are limited to INT_MAX (see eb_create()) */
+   if (count < 1 || count > INT_MAX || count > SIZE_MAX / sz - 1) {
+   DRM_DEBUG("execbuf2 with %zd buffers\n", count);
return -EINVAL;
}
 
@@ -2540,9 +2542,9 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
return -EINVAL;
 
/* Copy in the exec list from userland */
-   exec_list = kvmalloc_array(args->buffer_count, sizeof(*exec_list),
+   exec_list = kvmalloc_array(count, sizeof(*exec_list),
   __GFP_NOWARN | GFP_TEMPORARY);
-   exec2_list = kvmalloc_array(args->buffer_count + 1, sz,
+   exec2_list = kvmalloc_array(count + 1, sz,
__GFP_NOWARN | GFP_TEMPORARY);
if (exec_list == NULL || exec2_list == NULL) {
DRM_DEBUG("Failed to allocate exec list for %d buffers\n",
@@ -2553,7 +2555,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
}
err = copy_from_user(exec_list,
 u64_to_user_ptr(args->buffers_ptr),
-sizeof(*exec_list) * args->buffer_count);
+sizeof(*exec_list) * count);
if (err) {
DRM_DEBUG("copy %d exec entries failed %d\n",
  args->buffer_count, err);
@@ -2607,10 +2609,11 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data,
struct drm_i915_gem_execbuffer2 *args = data;
struct drm_i915_gem_exec_object2 *exec2_list;
struct drm_syncobj **fences = NULL;
+   const size_t count = args->buffer_count;
int err;
 
-   if (args->buffer_count < 1 || args->buffer_count > SIZE_MAX / sz - 1) {
-   DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count);
+   if (count < 1 || count > SIZE_MAX / sz - 1) {
+   DRM_DEBUG("execbuf2 with %zd buffers\n", count);
return -EINVAL;
}
 
@@ -2618,17 +2621,17 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data,
return -EINVAL;
 
/* Allocate an extra slot for use by the command parser */
-   exec2_list = kvmalloc_array(args->buffer_count + 1, sz,
+   exec2_list = kvmalloc_array(count + 1, sz,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix integer overflow tests (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix integer overflow tests (rev2)
URL   : https://patchwork.freedesktop.org/series/28898/
State : success

== Summary ==

Series 28898v2 drm/i915: Fix integer overflow tests
https://patchwork.freedesktop.org/api/1.0/series/28898/revisions/2/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-byt-n2820) fdo#101705

fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:460s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:442s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:358s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:563s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:519s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:524s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:513s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:609s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:443s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:423s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:427s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:496s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:474s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:477s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:598s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:597s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:538s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:473s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:477s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:492s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:440s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:480s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:544s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:412s

ada53b43f81fe618f3f0f1dfbd3dd776bb277323 drm-tip: 2017y-08m-16d-15h-18m-56s UTC 
integration manifest
bdc340d1c6e8 drm/i915: Prevent overflow of execbuf.buffer_count and 
num_cliprects

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5423/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Prevent overflow of execbuf.buffer_count and num_cliprects

[Chris Wilson]

We check whether the multiplies will overflow prior to calling
kmalloc_array so that we can respond with -EINVAL for the invalid user
arguments rather than treating it as an -ENOMEM that would otherwise
occur. However, as Dan Carpenter pointed out, we did an addition on the
unsigned int prior to passing to kmalloc_array where it would be
promoted to size_t for the calculation, thereby allowing it to overflow
and underallocate.

Reported-by: Dan Carpenter 
Signed-off-by: Chris Wilson 
---

I want to keep that check for reporting an attempted overflow as -EINVAL
so we can keep distinguishing rogue parameters from the excessively
large allocations. So we just need to do the promotion ourselves, right?
-Chris

---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 30 --
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 8e8bc7aefd9c..2d69af40ab68 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2143,7 +2143,7 @@ static struct drm_syncobj **
 get_fence_array(struct drm_i915_gem_execbuffer2 *args,
struct drm_file *file)
 {
-   const unsigned int nfences = args->num_cliprects;
+   const size_t nfences = args->num_cliprects;
struct drm_i915_gem_exec_fence __user *user;
struct drm_syncobj **fences;
unsigned int n;
@@ -2152,14 +2152,14 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args,
if (!(args->flags & I915_EXEC_FENCE_ARRAY))
return NULL;
 
-   if (nfences > SIZE_MAX / sizeof(*fences))
+   if (nfences > SIZE_MAX / max(sizeof(*fences), 2*sizeof(u32)))
return ERR_PTR(-EINVAL);
 
user = u64_to_user_ptr(args->cliprects_ptr);
if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32)))
return ERR_PTR(-EFAULT);
 
-   fences = kvmalloc_array(args->num_cliprects, sizeof(*fences),
+   fences = kvmalloc_array(nfences, sizeof(*fences),
__GFP_NOWARN | GFP_TEMPORARY);
if (!fences)
return ERR_PTR(-ENOMEM);
@@ -2517,10 +2517,11 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
struct drm_i915_gem_execbuffer2 exec2;
struct drm_i915_gem_exec_object *exec_list = NULL;
struct drm_i915_gem_exec_object2 *exec2_list = NULL;
+   const size_t count = args->buffer_count;
unsigned int i;
int err;
 
-   if (args->buffer_count < 1 || args->buffer_count > SIZE_MAX / sz - 1) {
+   if (count < 1 || count > SIZE_MAX / sz - 1) {
DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count);
return -EINVAL;
}
@@ -2540,9 +2541,9 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
return -EINVAL;
 
/* Copy in the exec list from userland */
-   exec_list = kvmalloc_array(args->buffer_count, sizeof(*exec_list),
+   exec_list = kvmalloc_array(count, sizeof(*exec_list),
   __GFP_NOWARN | GFP_TEMPORARY);
-   exec2_list = kvmalloc_array(args->buffer_count + 1, sz,
+   exec2_list = kvmalloc_array(count + 1, sz,
__GFP_NOWARN | GFP_TEMPORARY);
if (exec_list == NULL || exec2_list == NULL) {
DRM_DEBUG("Failed to allocate exec list for %d buffers\n",
@@ -2553,7 +2554,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
}
err = copy_from_user(exec_list,
 u64_to_user_ptr(args->buffers_ptr),
-sizeof(*exec_list) * args->buffer_count);
+sizeof(*exec_list) * count);
if (err) {
DRM_DEBUG("copy %d exec entries failed %d\n",
  args->buffer_count, err);
@@ -2607,10 +2608,11 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data,
struct drm_i915_gem_execbuffer2 *args = data;
struct drm_i915_gem_exec_object2 *exec2_list;
struct drm_syncobj **fences = NULL;
+   const size_t count = args->buffer_count;
int err;
 
-   if (args->buffer_count < 1 || args->buffer_count > SIZE_MAX / sz - 1) {
-   DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count);
+   if (count < 1 || count > SIZE_MAX / sz - 1) {
+   DRM_DEBUG("execbuf2 with %zd buffers\n", count);
return -EINVAL;
}
 
@@ -2618,17 +2620,17 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data,
return -EINVAL;
 
/* Allocate an extra slot for use by the command parser */
-   exec2_list = kvmalloc_array(args->buffer_count + 1, sz,
+   exec2_list = kvmalloc_array(count + 1, sz,
__GFP_NOWARN | GFP_TEMPORARY);
if (exec2_list == 

Re: [Intel-gfx] [PATCH] drm/i915: Fix integer overflow tests

[Imre Deak]

On Thu, Aug 17, 2017 at 12:50:37PM +0300, Dan Carpenter wrote:
> On Thu, Aug 17, 2017 at 12:37:00PM +0300, Imre Deak wrote:
> > On Thu, Aug 17, 2017 at 09:23:10AM +0300, Dan Carpenter wrote:
> > > There are some potential integer overflows here on 64 bit systems.
> > > 
> > > The condition "if (nfences > SIZE_MAX / sizeof(*fences))" can only be
> > > true on 32 bit systems, it's a no-op on 64 bit, so let's ignore the
> > > check for now and look a couple lines after:
> > > 
> > >   if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32)))
> > >   ^^^
> > > "nfences" is an unsigned int, so if we set it to UINT_MAX and multiply
> > > by two, it's going to have an integer overflow.  
> > 
> > AFAICS it wouldn't overflow due the promotion to unsigned long
> > by '* sizeof(u32)'.
> > 
> 
> It first multplies "nfences * 2" as unsigned int, then it type promotes
> to size_t and multiplies by sizeof().  Only the first multiplication has
> an integer overflow bug.

Err, that's correct. Sorry for the noise.

> 
> regards,
> dan carpenter
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix integer overflow tests

[Dan Carpenter]

On Thu, Aug 17, 2017 at 12:37:00PM +0300, Imre Deak wrote:
> On Thu, Aug 17, 2017 at 09:23:10AM +0300, Dan Carpenter wrote:
> > There are some potential integer overflows here on 64 bit systems.
> > 
> > The condition "if (nfences > SIZE_MAX / sizeof(*fences))" can only be
> > true on 32 bit systems, it's a no-op on 64 bit, so let's ignore the
> > check for now and look a couple lines after:
> > 
> > if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32)))
> >   ^^^
> > "nfences" is an unsigned int, so if we set it to UINT_MAX and multiply
> > by two, it's going to have an integer overflow.  
> 
> AFAICS it wouldn't overflow due the promotion to unsigned long
> by '* sizeof(u32)'.
> 

It first multplies "nfences * 2" as unsigned int, then it type promotes
to size_t and multiplies by sizeof().  Only the first multiplication has
an integer overflow bug.

regards,
dan carpenter

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

Re: [Intel-gfx] [patch net-next 0/3] net/sched: Improve getting objects by indexes

[Christian König]

Am 16.08.2017 um 04:12 schrieb Chris Mi:

Using current TC code, it is very slow to insert a lot of rules.

In order to improve the rules update rate in TC,
we introduced the following two changes:
 1) changed cls_flower to use IDR to manage the filters.
 2) changed all act_xxx modules to use IDR instead of
a small hash table

But IDR has a limitation that it uses int. TC handle uses u32.
To make sure there is no regression, we also changed IDR to use
unsigned long. All clients of IDR are changed to use new IDR API.


WOW, wait a second. The idr change is touching a lot of drivers and to 
be honest doesn't looks correct at all.


Just look at the first chunk of your modification:

@@ -998,8 +999,9 @@ int bsg_register_queue(struct request_queue *q, struct 
device *parent,
  
  	mutex_lock(_mutex);
  
-	ret = idr_alloc(_minor_idr, bcd, 0, BSG_MAX_DEVS, GFP_KERNEL);

-   if (ret < 0) {
+   ret = idr_alloc(_minor_idr, bcd, _index, 0, BSG_MAX_DEVS,
+   GFP_KERNEL);
+   if (ret) {
if (ret == -ENOSPC) {
printk(KERN_ERR "bsg: too many bsg devices\n");
ret = -EINVAL;
The condition "if (ret)" will now always be true after the first 
allocation and so we always run into the error handling after that.


I've never read the bsg code before, but that's certainly not correct. 
And that incorrect pattern repeats over and over again in this code.


Apart from that why the heck do you want to allocate more than 1<<31 
handles?


Regards,
Christian.



Chris Mi (3):
   idr: Use unsigned long instead of int
   net/sched: Change cls_flower to use IDR
   net/sched: Change act_api and act_xxx modules to use IDR

  block/bsg.c |   8 +-
  block/genhd.c   |  12 +-
  drivers/atm/nicstar.c   |  11 +-
  drivers/block/drbd/drbd_main.c  |  31 +--
  drivers/block/drbd/drbd_nl.c|  22 ++-
  drivers/block/drbd/drbd_proc.c  |   3 +-
  drivers/block/drbd/drbd_receiver.c  |  15 +-
  drivers/block/drbd/drbd_state.c |  34 ++--
  drivers/block/drbd/drbd_worker.c|   6 +-
  drivers/block/loop.c|  17 +-
  drivers/block/nbd.c |  20 +-
  drivers/block/zram/zram_drv.c   |   9 +-
  drivers/char/tpm/tpm-chip.c |  10 +-
  drivers/char/tpm/tpm.h  |   2 +-
  drivers/dca/dca-sysfs.c |   9 +-
  drivers/firewire/core-cdev.c|  18 +-
  drivers/firewire/core-device.c  |  15 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c |   8 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c |   9 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c |   6 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |   2 +-
  drivers/gpu/drm/drm_auth.c  |   9 +-
  drivers/gpu/drm/drm_connector.c |  10 +-
  drivers/gpu/drm/drm_context.c   |  20 +-
  drivers/gpu/drm/drm_dp_aux_dev.c|  11 +-
  drivers/gpu/drm/drm_drv.c   |   6 +-
  drivers/gpu/drm/drm_gem.c   |  19 +-
  drivers/gpu/drm/drm_info.c  |   2 +-
  drivers/gpu/drm/drm_mode_object.c   |  11 +-
  drivers/gpu/drm/drm_syncobj.c   |  18 +-
  drivers/gpu/drm/exynos/exynos_drm_ipp.c |  25 ++-
  drivers/gpu/drm/i915/gvt/display.c  |   2 +-
  drivers/gpu/drm/i915/gvt/kvmgt.c|   2 +-
  drivers/gpu/drm/i915/gvt/vgpu.c |   9 +-
  drivers/gpu/drm/i915/i915_debugfs.c |   6 +-
  drivers/gpu/drm/i915/i915_gem_context.c |   9 +-
  drivers/gpu/drm/qxl/qxl_cmd.c   |   8 +-
  drivers/gpu/drm/qxl/qxl_release.c   |  14 +-
  drivers/gpu/drm/sis/sis_mm.c|   8 +-
  drivers/gpu/drm/tegra/drm.c |  10 +-
  drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c|   3 +-
  drivers/gpu/drm/vgem/vgem_fence.c   |  12 +-
  drivers/gpu/drm/via/via_mm.c|   8 +-
  drivers/gpu/drm/virtio/virtgpu_kms.c|   5 +-
  drivers/gpu/drm/virtio/virtgpu_vq.c |   5 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c|   9 +-
  drivers/i2c/i2c-core-base.c |  19 +-
  drivers/infiniband/core/cm.c|   8 +-
  drivers/infiniband/core/cma.c   |  12 +-
  drivers/infiniband/core/rdma_core.c |   9 +-
  drivers/infiniband/core/sa_query.c  |  23 +--
  drivers/infiniband/core/ucm.c   |   7 +-
  drivers/infiniband/core/ucma.c  |  14 +-
  drivers/infiniband/hw/cxgb3/iwch.c  |   4 +-
  drivers/infiniband/hw/cxgb3/iwch.h  |   4 +-
  

Re: [Intel-gfx] [patch net-next 0/3] net/sched: Improve getting objects by indexes

[Chris Wilson]

Quoting Christian König (2017-08-16 08:49:07)
> Am 16.08.2017 um 04:12 schrieb Chris Mi:
> > Using current TC code, it is very slow to insert a lot of rules.
> >
> > In order to improve the rules update rate in TC,
> > we introduced the following two changes:
> >  1) changed cls_flower to use IDR to manage the filters.
> >  2) changed all act_xxx modules to use IDR instead of
> > a small hash table
> >
> > But IDR has a limitation that it uses int. TC handle uses u32.
> > To make sure there is no regression, we also changed IDR to use
> > unsigned long. All clients of IDR are changed to use new IDR API.
> 
> WOW, wait a second. The idr change is touching a lot of drivers and to 
> be honest doesn't looks correct at all.
> 
> Just look at the first chunk of your modification:
> > @@ -998,8 +999,9 @@ int bsg_register_queue(struct request_queue *q, struct 
> > device *parent,
> >   
> >   mutex_lock(_mutex);
> >   
> > - ret = idr_alloc(_minor_idr, bcd, 0, BSG_MAX_DEVS, GFP_KERNEL);
> > - if (ret < 0) {
> > + ret = idr_alloc(_minor_idr, bcd, _index, 0, BSG_MAX_DEVS,
> > + GFP_KERNEL);
> > + if (ret) {
> >   if (ret == -ENOSPC) {
> >   printk(KERN_ERR "bsg: too many bsg devices\n");
> >   ret = -EINVAL;
> The condition "if (ret)" will now always be true after the first 
> allocation and so we always run into the error handling after that.

ret is now purely the error code, so it doesn't look that suspicious.

> I've never read the bsg code before, but that's certainly not correct. 
> And that incorrect pattern repeats over and over again in this code.
> 
> Apart from that why the heck do you want to allocate more than 1<<31 
> handles?

And more to the point, arbitrarily changing the maximum to ULONG_MAX
where the ABI only supports U32_MAX is dangerous. Unless you do the
analysis otherwise, you have to replace all the end=0 with end=INT_MAX
to maintain existing behaviour.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP

[Jani Nikula]

On Wed, 16 Aug 2017, Manasi Navare  wrote:
> In case of eDP because the panel has a fixed mode we cannot
> link train fallback and prune modes since this results in
> no modes available for eDP connector.
> Also since its a panel, link training should not fail dynamically
> based on cable conditions like in  case of DP.
>
> Cc: Jani Nikula 
> Cc: Jim Bride 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/intel_dp.c   | 2 +-
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++-
>  drivers/gpu/drm/i915/intel_drv.h  | 1 +
>  3 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 4fd4853..edac0c8 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000, 27, 
> 54 };
>   * If a CPU or PCH DP output is attached to an eDP panel, this function
>   * will return true, and false otherwise.
>   */
> -static bool is_edp(struct intel_dp *intel_dp)
> +bool is_edp(struct intel_dp *intel_dp)

Make that intel_dp_is_edp when you expose it outside of intel_dp.c

BR,
Jani

>  {
>   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 05907fa..18ec61f 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
> intel_connector->base.base.id,
> intel_connector->base.name,
> intel_dp->link_rate, intel_dp->lane_count);
> - if (!intel_dp_get_link_train_fallback_values(intel_dp,
> + /* Dont fallback and prune modes if its eDP */
> + if (!is_edp(intel_dp) && 
> !intel_dp_get_link_train_fallback_values(intel_dp,
>intel_dp->link_rate,
>intel_dp->lane_count))
>   /* Schedule a Hotplug Uevent to userspace to start modeset */
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index fa47285..9800a15 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1548,6 +1548,7 @@ static inline unsigned int 
> intel_dp_unused_lane_mask(int lane_count)
>  }
>  
>  bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> +bool is_edp(struct intel_dp *intel_dp);
>  int intel_dp_link_required(int pixel_clock, int bpp);
>  int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
>  bool intel_digital_port_connected(struct drm_i915_private *dev_priv,

-- 
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 i-g-t] tools/intel_vbt_decode: Fix decoding of child device structure

[Jani Nikula]

On Wed, 16 Aug 2017, Clint Taylor  wrote:
> This patch fixes the alignment. I spotted another issue with teh 
> structure and will fix it once this one is merged.

I'm sure there are plenty of issues; patches welcome!

BR,
Jani.

>
> Reviewed-by: Clint Taylor 
> Tested-by: Clint Taylor 
>
>
> On 08/16/2017 07:20 AM, ville.syrj...@linux.intel.com wrote:
>> From: Ville Syrjälä 
>>
>> Fix decoding of the start of the child device structure. I had
>> accidentally duplicated the "device class/type" member and forgot to
>> include the add-in offset later. Fortunately both were two byte fields
>> so they effectively cancelled each other out and thus the remainder of
>> the child device structure was being decoded correctly. But of course
>> anything sitting between these two fieds was being decoded incorrectly.
>>
>> Fixes: 86a546f6f798 ("tools/intel_bios_reader: Dump out more information 
>> from the child device structure")
>> Signed-off-by: Ville Syrjälä 
>> ---
>>   tools/intel_bios.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/intel_bios.h b/tools/intel_bios.h
>> index ca0d2c587120..f2ccb55ab6c3 100644
>> --- a/tools/intel_bios.h
>> +++ b/tools/intel_bios.h
>> @@ -273,7 +273,6 @@ struct child_device_config {
>>   struct efp_child_device_config {
>>  uint16_t handle;
>>  uint16_t device_type;
>> -uint16_t device_class;
>>  uint8_t i2c_speed;
>>  uint8_t dp_onboard_redriver; /* 158 */
>>  uint8_t dp_ondock_redriver; /* 158 */
>> @@ -289,6 +288,7 @@ struct efp_child_device_config {
>>  uint8_t skip1:4;
>>  uint8_t slave_port; /*  202 */
>>  uint8_t skip2;
>> +uint16_t addin_offset;
>>  uint8_t port;
>>  uint8_t i2c_pin; /* for add-in card */
>>  uint8_t slave_addr; /* for add-in card */
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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] drm/i915: Fix integer overflow tests

[Imre Deak]

On Thu, Aug 17, 2017 at 09:23:10AM +0300, Dan Carpenter wrote:
> There are some potential integer overflows here on 64 bit systems.
> 
> The condition "if (nfences > SIZE_MAX / sizeof(*fences))" can only be
> true on 32 bit systems, it's a no-op on 64 bit, so let's ignore the
> check for now and look a couple lines after:
> 
>   if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32)))
>   ^^^
> "nfences" is an unsigned int, so if we set it to UINT_MAX and multiply
> by two, it's going to have an integer overflow.  

AFAICS it wouldn't overflow due the promotion to unsigned long
by '* sizeof(u32)'.

> The "args->buffer_count"
> is also an unsigned int so it could overflow if it's set to UINT_MAX
> when we do:
> 
>   exec2_list = kvmalloc_array(args->buffer_count + 1, sz,
> ^^

Yes, this could overflow.

> Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the 
> execobjects array")
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 15ab3e6792f9..f569721aad1a 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -2152,7 +2152,7 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args,
>   if (!(args->flags & I915_EXEC_FENCE_ARRAY))
>   return NULL;
>  
> - if (nfences > SIZE_MAX / sizeof(*fences))
> + if (nfences > UINT_MAX / sizeof(*fences))
>   return ERR_PTR(-EINVAL);
>  
>   user = u64_to_user_ptr(args->cliprects_ptr);
> @@ -2520,7 +2520,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
>   unsigned int i;
>   int err;
>  
> - if (args->buffer_count < 1 || args->buffer_count > SIZE_MAX / sz - 1) {
> + if (args->buffer_count < 1 || args->buffer_count > UINT_MAX / sz - 1) {
>   DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count);
>   return -EINVAL;
>   }
> @@ -2609,7 +2609,7 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data,
>   struct drm_syncobj **fences = NULL;
>   int err;
>  
> - if (args->buffer_count < 1 || args->buffer_count > SIZE_MAX / sz - 1) {
> + if (args->buffer_count < 1 || args->buffer_count > UINT_MAX / sz - 1) {
>   DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count);
>   return -EINVAL;
>   }
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [maintainer-tools PATCH 1/2] dim: Accept .mbox and .patch files as apply-branch optional argument.

[Daniel Vetter]

On Thu, Aug 17, 2017 at 10:12 AM, Jani Nikula  wrote:
> On Thu, 17 Aug 2017, Daniel Vetter  wrote:
>> One thing we maybe could be doing is a more fancy aliasing feature, along
>> the lines of git aliases, where you can do whatever you want. Then you
>> could do a dim apply-curl alias which resolves to curl $arg | dim apply.
>> Not sure how to implement that though ...
>
> We *already* have a fancy aliasing feature. You can add arbitrary
> subcommands of your own, and you can override existing subcommands. Try
> this in your ~/.dimrc:
>
> dim_my_fancy_list_aliases()
> {
> echo "Hello world!"
> dim_list_aliases
> }
>
> dim_alias_list_aliases=my-fancy-list-aliases
>
> This first part will give you a new "dim my-fancy-list-aliases"
> subcommand, and the second part will use it for "dim list-aliases".
>
> Go wild. ;)

Maybe we just need to document this better? Rodrigo, you're up for a
patch to dim.rst, with the above example in a new ALIASES sections?
I'd put it right above ENVIRONMENT.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [maintainer-tools PATCH 1/2] dim: Accept .mbox and .patch files as apply-branch optional argument.

[Jani Nikula]

On Thu, 17 Aug 2017, Daniel Vetter  wrote:
> One thing we maybe could be doing is a more fancy aliasing feature, along
> the lines of git aliases, where you can do whatever you want. Then you
> could do a dim apply-curl alias which resolves to curl $arg | dim apply.
> Not sure how to implement that though ...

We *already* have a fancy aliasing feature. You can add arbitrary
subcommands of your own, and you can override existing subcommands. Try
this in your ~/.dimrc:

dim_my_fancy_list_aliases()
{
echo "Hello world!"
dim_list_aliases
}

dim_alias_list_aliases=my-fancy-list-aliases

This first part will give you a new "dim my-fancy-list-aliases"
subcommand, and the second part will use it for "dim list-aliases".

Go wild. ;)


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