Re: [Intel-gfx] [PATCH RESEND 9/9] drm/i915: set proper N/M in modeset

2016-10-19 Thread Yang, Libin

> -Original Message-
> From: Nikula, Jani
> Sent: Wednesday, October 19, 2016 11:09 PM
> To: Yang, Libin ; Lin, Mengdong
> ; intel-gfx@lists.freedesktop.org
> Cc: libin.y...@linux.intel.com; Pandiyan, Dhinakaran
> ; Zhang, Keqiao
> ; Zhao, Juan J 
> Subject: RE: [Intel-gfx] [PATCH RESEND 9/9] drm/i915: set proper N/M in
> modeset
> 
> 
> Sorry it's taken me forever to get back to this. Some comments inline.
> 
> BR,
> Jani.
> 
> On Wed, 12 Oct 2016, "Yang, Libin"  wrote:
> >> -Original Message-
> >> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
> >> Behalf Of Lin, Mengdong
> >> Sent: Wednesday, October 12, 2016 10:46 AM
> >> To: Nikula, Jani ;
> >> intel-gfx@lists.freedesktop.org
> >> Cc: Nikula, Jani ; libin.y...@linux.intel.com;
> >> Pandiyan, Dhinakaran 
> >> Subject: Re: [Intel-gfx] [PATCH RESEND 9/9] drm/i915: set proper N/M
> >> in modeset
> >>
> >>
> >>
> >> > -Original Message-
> >> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
> >> > Behalf Of Jani Nikula
> >> > Sent: Monday, October 10, 2016 11:04 PM
> >> > To: intel-gfx@lists.freedesktop.org
> >> > Cc: Nikula, Jani ;
> >> > libin.y...@linux.intel.com; Pandiyan, Dhinakaran
> >> > 
> >> > Subject: [Intel-gfx] [PATCH RESEND 9/9] drm/i915: set proper N/M in
> >> > modeset
> >> >
> >> > When modeset occurs and the LS_CLK is set to some special values in
> >> > DP mode, the N/M need to be set manually if audio is playing.
> >> > Otherwise the first several seconds may be silent in audio playback.
> >> >
> >> > The relationship of Maud and Naud is expressed in the following
> equation:
> >> > Maud/Naud = 512 * fs / f_LS_Clk
> >> >
> >> > Please refer VESA DisplayPort Standard spec for details.
> >> >
> >> > Signed-off-by: Libin Yang 
> >> > Signed-off-by: Jani Nikula 
> >> > ---
> >> >  drivers/gpu/drm/i915/i915_reg.h|   7 +++
> >> >  drivers/gpu/drm/i915/intel_audio.c | 100
> >> > -
> >> >  2 files changed, 105 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >> > b/drivers/gpu/drm/i915/i915_reg.h index 595d196f753f..8d9dbc7d5b32
> >> > 100644
> >> > --- a/drivers/gpu/drm/i915/i915_reg.h
> >> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> > @@ -7359,6 +7359,13 @@ enum {
> >> >  #define _HSW_AUD_MISC_CTRL_B0x65110
> >> >  #define HSW_AUD_MISC_CTRL(pipe) _MMIO_PIPE(pipe,
> >> > _HSW_AUD_MISC_CTRL_A, _HSW_AUD_MISC_CTRL_B)
> >> >
> >> > +#define _HSW_AUD_M_CTS_ENABLE_A 0x65028
> >> > +#define _HSW_AUD_M_CTS_ENABLE_B 0x65128
> >> > +#define HSW_AUD_M_CTS_ENABLE(pipe)  _MMIO_PIPE(pipe,
> >> > _HSW_AUD_M_CTS_ENABLE_A, _HSW_AUD_M_CTS_ENABLE_B)
> >> > +#define   AUD_M_CTS_M_VALUE_INDEX   (1 << 21)
> >> > +#define   AUD_M_CTS_M_PROG_ENABLE   (1 << 20)
> >> > +#define   AUD_CONFIG_M_MASK 0xf
> >>
> >> The last line cause misalignment after applying the patch.
> >>
> >> > +
> >> >  #define _HSW_AUD_DIP_ELD_CTRL_ST_A  0x650b4
> >> >  #define _HSW_AUD_DIP_ELD_CTRL_ST_B  0x651b4
> >> >  #define HSW_AUD_DIP_ELD_CTRL(pipe)  _MMIO_PIPE(pipe,
> >> > _HSW_AUD_DIP_ELD_CTRL_ST_A, _HSW_AUD_DIP_ELD_CTRL_ST_B)
> diff --
> >> git
> >> > a/drivers/gpu/drm/i915/intel_audio.c
> >> > b/drivers/gpu/drm/i915/intel_audio.c
> >> > index 81df29ca4947..0bc2701b6c9c 100644
> >> > --- a/drivers/gpu/drm/i915/intel_audio.c
> >> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> >> > @@ -57,6 +57,70 @@
> >> >   * struct _audio_component_audio_ops @audio_ops is called
> >> > from
> >> > i915 driver.
> >> >   */
> >> >
> >> > +/* DP N/M table */
> >> > +#define LC_540M 54
> >> > +#define LC_270M 27
> >> > +#define LC_162M 162000
> >> > +
> >> > +struct dp_aud_n_m {
> >> > +int sample_rate;
> >> > +int clock;
> >> > +u16 n;
> >> > +u16 m;
> >> > +};
> >> > +
> >> > +static const struct dp_aud_n_m dp_aud_n_m[] = {
> >> > +{ 192000, LC_540M, 5625, 1024 },
> >> > +{ 176400, LC_540M, 9375, 1568 },
> >> > +{ 96000, LC_540M, 5625, 512 },
> >> > +{ 88200, LC_540M, 9375, 784 },
> >> > +{ 48000, LC_540M, 5625, 256 },
> >> > +{ 44100, LC_540M, 9375, 392 },
> >> > +{ 32000, LC_540M, 16875, 512 },
> 
> Any particular reason these M/N values are half of what they're in table
> 2-104 of DP 1.4 spec? (Admittedly the table is an informative example.)

For HDMI, we found only set N is enough. HW then can handle the remaining.

> 
> >> > +{ 192000, LC_270M, 5625, 2048 },
> >> > +{ 176400, LC_270M, 9375, 3136 },
> >> > +{ 96000, LC_270M, 5625, 1024 },
> >> 

Re: [Intel-gfx] gvt gem fixes

2016-10-19 Thread Zhenyu Wang
On 2016.10.19 12:02:58 +0100, Chris Wilson wrote:
> On Wed, Oct 19, 2016 at 06:45:51PM +0800, Zhenyu Wang wrote:
> > On 2016.10.19 11:11:35 +0100, Chris Wilson wrote:
> > > I think this is the set required to bring gvt into line, at least to
> > > unblock myself.
> > 
> > Thanks a lot, Chris. I'd like to merge this in next pull request,
> > or let me know you want to be picked up by drm-intel directly.
> > If 4/12 would be picked up alone, I'll skip that one in gvt tree.
> 
> If you are confident in having the pull ready in the next day or so,
> I'll just preface my series with these and they will evaporate after the
> merge.
>

I'll try to send it today.

> I'll apply 4/12 right now to get that out of the way.

ok, fine.

thanks

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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] drm/i915/dp: Debug log MST active links explicitly

2016-10-19 Thread Pandiyan, Dhinakaran
On Wed, 2016-10-19 at 08:47 +0100, Chris Wilson wrote:
> On Tue, Oct 18, 2016 at 05:18:48PM -0700, Dhinakaran Pandiyan wrote:
> > From: "Pandiyan, Dhinakaran" 
> > 
> > No functional change. Just printing the number of active links without
> > stating what the number means is not very useful. So, add relevant text.
> 
> If you are going to add information, consider also noting which
> connector/encoder you are talking about. Even before we get concurrent
> handling of multiple channels, this is useful!
> -Chris

Yeah, connector and encoder info must be included. But, now I think of
it, printing active links twice while enabling and twice while disabling
is excessive. The value we print in post_disable() is not intuitive too.

-DK 

> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > Reviewed-by: Jim Bride 
> > ---
> > No changes, sending with Jim's R-B
> > 
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 3ffbd69..62a69b5 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -86,7 +86,7 @@ static void intel_mst_disable_dp(struct intel_encoder 
> > *encoder,
> > to_intel_connector(old_conn_state->connector);
> > int ret;
> >  
> > -   DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> > +   DRM_DEBUG_KMS("active MST links: %d\n", intel_dp->active_mst_links);
> >  
> > drm_dp_mst_reset_vcpi_slots(_dp->mst_mgr, connector->port);
> >  
> > @@ -106,7 +106,7 @@ static void intel_mst_post_disable_dp(struct 
> > intel_encoder *encoder,
> > struct intel_connector *connector =
> > to_intel_connector(old_conn_state->connector);
> >  
> > -   DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> > +   DRM_DEBUG_KMS("active MST links: %d\n", intel_dp->active_mst_links);
> >  
> > /* this can fail */
> > drm_dp_check_act_status(_dp->mst_mgr);
> > @@ -147,7 +147,7 @@ static void intel_mst_pre_enable_dp(struct 
> > intel_encoder *encoder,
> > connector->encoder = encoder;
> > intel_mst->connector = connector;
> >  
> > -   DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> > +   DRM_DEBUG_KMS("active MST links: %d\n", intel_dp->active_mst_links);
> >  
> > if (intel_dp->active_mst_links == 0) {
> > intel_ddi_clk_select(_dig_port->base,
> > @@ -194,7 +194,7 @@ static void intel_mst_enable_dp(struct intel_encoder 
> > *encoder,
> > enum port port = intel_dig_port->port;
> > int ret;
> >  
> > -   DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> > +   DRM_DEBUG_KMS("active MST links: %d\n", intel_dp->active_mst_links);
> >  
> > if (intel_wait_for_register(dev_priv,
> > DP_TP_STATUS(port),
> > -- 
> > 2.7.4
> > 
> > ___
> > 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 07/12] drm/i915/gvt: Hold a reference on the request

2016-10-19 Thread Zhenyu Wang
On 2016.10.19 11:11:42 +0100, Chris Wilson wrote:
> The workload took a pointer to the request, and even waited upon,
> without holding a reference on the request. Take that reference
> explicitly and fix up the error path following request allocation that
> missed flushing the request.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/gvt/scheduler.c | 24 +---
>  1 file changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> b/drivers/gpu/drm/i915/gvt/scheduler.c
> index b15cdf5978a9..224f19ae61ab 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -163,6 +163,7 @@ static int dispatch_workload(struct intel_vgpu_workload 
> *workload)
>   int ring_id = workload->ring_id;
>   struct i915_gem_context *shadow_ctx = workload->vgpu->shadow_ctx;
>   struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
> + struct drm_i915_gem_request *rq;
>   int ret;
>  
>   gvt_dbg_sched("ring id %d prepare to dispatch workload %p\n",
> @@ -171,17 +172,16 @@ static int dispatch_workload(struct intel_vgpu_workload 
> *workload)
>   shadow_ctx->desc_template = workload->ctx_desc.addressing_mode <<
>   GEN8_CTX_ADDRESSING_MODE_SHIFT;
>  
> - workload->req = i915_gem_request_alloc(dev_priv->engine[ring_id],
> -shadow_ctx);
> - if (IS_ERR_OR_NULL(workload->req)) {
> + rq = i915_gem_request_alloc(dev_priv->engine[ring_id], shadow_ctx);
> + if (IS_ERR(rq)) {
>   gvt_err("fail to allocate gem request\n");
> - workload->status = PTR_ERR(workload->req);
> - workload->req = NULL;
> + workload->status = PTR_ERR(rq);
>   return workload->status;
>   }
>  
> - gvt_dbg_sched("ring id %d get i915 gem request %p\n",
> - ring_id, workload->req);
> + gvt_dbg_sched("ring id %d get i915 gem request %p\n", ring_id, rq);
> +
> + workload->req = i915_gem_request_get(rq);
>  
>   mutex_lock(>lock);
>  
> @@ -208,16 +208,16 @@ static int dispatch_workload(struct intel_vgpu_workload 
> *workload)
>   gvt_dbg_sched("ring id %d submit workload to i915 %p\n",
>   ring_id, workload->req);
>  
> - i915_add_request_no_flush(workload->req);
> -
> + i915_add_request_no_flush(rq);
>   workload->dispatched = true;
>   return 0;
>  err:
>   workload->status = ret;
> - if (workload->req)
> - workload->req = NULL;
> + i915_gem_request_put(fetch_and_zero(>req));
>

Looks we don't need put here as in error path from dispatch_workload()
we will go with below put path too in main thread.

>   mutex_unlock(>lock);
> +
> + i915_add_request_no_flush(rq);
>   return ret;
>  }
>  
> @@ -458,6 +458,8 @@ static int workload_thread(void *priv)
>  
>   complete_current_workload(gvt, ring_id);
>  
> + i915_gem_request_put(fetch_and_zero(>req));
> +
>   if (need_force_wake)
>   intel_uncore_forcewake_put(gvt->dev_priv,
>   FORCEWAKE_ALL);


-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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 -next] drm/i915/gvt: fix return value check

2016-10-19 Thread Zhenyu Wang
On 2016.10.19 16:18:03 +, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> In case of error, the function i915_gem_object_create() returns
> ERR_PTR() not NULL. The NULL test in the return value check should
> be replaced with IS_ERR().
> 
> Signed-off-by: Wei Yongjun 

Hi, Yongjun, we've already had this fixed in our queue for next pull request,
will send very soon.

Thanks.

> ---
>  drivers/gpu/drm/i915/gvt/cmd_parser.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
> b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> index 5808ee7..6abb2a6 100644
> --- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> +++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> @@ -1640,8 +1640,8 @@ static int perform_bb_shadow(struct parser_exec_state 
> *s)
>  
>   entry_obj->obj = i915_gem_object_create(&(s->vgpu->gvt->dev_priv->drm),
>   round_up(bb_size, PAGE_SIZE));
> - if (entry_obj->obj == NULL)
> - return -ENOMEM;
> + if (IS_ERR(entry_obj->obj))
> + return PTR_ERR(entry_obj->obj);
>   entry_obj->len = bb_size;
>   INIT_LIST_HEAD(_obj->list);
>  
> @@ -2712,8 +2712,8 @@ static int shadow_indirect_ctx(struct 
> intel_shadow_wa_ctx *wa_ctx)
>  
>   wa_ctx->indirect_ctx.obj = i915_gem_object_create(dev,
>   round_up(ctx_size + CACHELINE_BYTES, PAGE_SIZE));
> - if (wa_ctx->indirect_ctx.obj == NULL)
> - return -ENOMEM;
> + if (IS_ERR(wa_ctx->indirect_ctx.obj))
> + return PTR_ERR(wa_ctx->indirect_ctx.obj);
>  
>   ret = i915_gem_object_get_pages(wa_ctx->indirect_ctx.obj);
>   if (ret)
> 

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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 RFC 2/8] drm: Define a work struct for scheduling a uevent for modeset retry

2016-10-19 Thread Pandiyan, Dhinakaran
On Wed, 2016-10-19 at 14:46 -0700, Manasi Navare wrote:
> This work struct will be used to schedule a uevent on a separate
> thread. This will be scheduled after a link train failure during modeset
> to indicate a modeset retry request. It will get executed after the
> current modeset is complete and all locks are released. This was
> required to avoid deadlock.
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> 
> Signed-off-by: Manasi Navare 
> ---
>  include/drm/drm_connector.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index d499466..9218a24 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -687,6 +687,11 @@ struct drm_connector {
>* in case of link train failure during current modeset
>*/
>   bool link_train_retry;
> +
> + /* Work struct to schedule a uevent on link train failure for
> +  * DisplayPort.
> +  */
> + struct work_struct i915_modeset_retry_work;

Should this be in struct intel_connector instead ?

>  };
>  
>  #define obj_to_connector(x) container_of(x, struct drm_connector, base)

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


Re: [Intel-gfx] [PATCH 5/8] drm/i915: Add a atomic evasion step to watermark programming.

2016-10-19 Thread Matt Roper
On Wed, Oct 19, 2016 at 04:15:02PM -0700, Matt Roper wrote:
> On Wed, Oct 12, 2016 at 03:28:18PM +0200, Maarten Lankhorst wrote:
> > Allow the driver to write watermarks during atomic evasion.
> > This will make it possible to write the watermarks in a cleaner
> > way on gen9+.
> > 
> > Signed-off-by: Maarten Lankhorst 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  6 --
> >  drivers/gpu/drm/i915/intel_display.c | 18 --
> >  drivers/gpu/drm/i915/intel_pm.c  | 19 +--
> >  3 files changed, 29 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index f65ccf9b0bea..09588c58148f 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -484,6 +484,7 @@ struct sdvo_device_mapping {
> >  
> >  struct intel_connector;
> >  struct intel_encoder;
> > +struct intel_atomic_state;
> >  struct intel_crtc_state;
> >  struct intel_initial_plane_config;
> >  struct intel_crtc;
> > @@ -497,8 +498,9 @@ struct drm_i915_display_funcs {
> > int (*compute_intermediate_wm)(struct drm_device *dev,
> >struct intel_crtc *intel_crtc,
> >struct intel_crtc_state *newstate);
> > -   void (*initial_watermarks)(struct intel_crtc_state *cstate);
> > -   void (*optimize_watermarks)(struct intel_crtc_state *cstate);
> > +   void (*initial_watermarks)(struct intel_atomic_state *state, struct 
> > intel_crtc_state *cstate);
> > +   void (*atomic_evade_watermarks)(struct intel_atomic_state *state, 
> > struct intel_crtc_state *cstate);
> > +   void (*optimize_watermarks)(struct intel_atomic_state *state, struct 
> > intel_crtc_state *cstate);
> 
> initial_watermarks() and optimize_watermarks() are currently only used
> on ILK (and possibly by in-development VLV/CHV patches that Ville is
> working on?).  As far as I can see, the top-level state that we add as a
> parameter here doesn't actually get used in the implementations.  Are
> you adding it to just make them more similar to the signature of the new
> atomic_evade_watermarks vfunc or did you have something else in mind?

For that matter, it doesn't look like it's really used in
atomic_evade_watermarks either except to grab dev_priv (which we can
obtain in other ways).


Matt

> 
> I'd also suggest adding a brief comment to your new skl_evade_crtc_wm()
> function that indicates that nearly all of the gen9 watermark values are
> per-plane values that get written as part of the general plane update in
> skylake_update_primary_plane and/or skl_update_plane.  Given that those
> two functions are located in other files that may help clarify to future
> developers why this function appears so trivial.
> 
> 
> Matt
> 
> > int (*compute_global_watermarks)(struct drm_atomic_state *state);
> > void (*update_wm)(struct drm_crtc *crtc);
> > int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 55f8ec8c76ae..23d8c72dade3 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5160,7 +5160,7 @@ static void intel_pre_plane_update(struct 
> > intel_crtc_state *old_crtc_state)
> >  * us to.
> >  */
> > if (dev_priv->display.initial_watermarks != NULL)
> > -   dev_priv->display.initial_watermarks(pipe_config);
> > +   
> > dev_priv->display.initial_watermarks(to_intel_atomic_state(old_state), 
> > pipe_config);
> > else if (pipe_config->update_wm_pre)
> > intel_update_watermarks(>base);
> >  }
> > @@ -5374,7 +5374,7 @@ static void ironlake_crtc_enable(struct 
> > intel_crtc_state *pipe_config,
> > intel_color_load_luts(_config->base);
> >  
> > if (dev_priv->display.initial_watermarks != NULL)
> > -   dev_priv->display.initial_watermarks(intel_crtc->config);
> > +   
> > dev_priv->display.initial_watermarks(to_intel_atomic_state(old_state), 
> > intel_crtc->config);
> > intel_enable_pipe(intel_crtc);
> >  
> > if (intel_crtc->config->has_pch_encoder)
> > @@ -5480,7 +5480,7 @@ static void haswell_crtc_enable(struct 
> > intel_crtc_state *pipe_config,
> > intel_ddi_enable_transcoder_func(crtc);
> >  
> > if (dev_priv->display.initial_watermarks != NULL)
> > -   dev_priv->display.initial_watermarks(pipe_config);
> > +   
> > dev_priv->display.initial_watermarks(to_intel_atomic_state(old_state), 
> > pipe_config);
> > else
> > intel_update_watermarks(crtc);
> >  
> > @@ -14503,7 +14503,7 @@ static void intel_atomic_commit_tail(struct 
> > drm_atomic_state *state)
> > intel_cstate = to_intel_crtc_state(crtc->state);
> >  
> > if (dev_priv->display.optimize_watermarks)
> > -   

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Add a atomic evasion step to watermark programming.

2016-10-19 Thread Matt Roper
On Wed, Oct 12, 2016 at 03:28:18PM +0200, Maarten Lankhorst wrote:
> Allow the driver to write watermarks during atomic evasion.
> This will make it possible to write the watermarks in a cleaner
> way on gen9+.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  6 --
>  drivers/gpu/drm/i915/intel_display.c | 18 --
>  drivers/gpu/drm/i915/intel_pm.c  | 19 +--
>  3 files changed, 29 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index f65ccf9b0bea..09588c58148f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -484,6 +484,7 @@ struct sdvo_device_mapping {
>  
>  struct intel_connector;
>  struct intel_encoder;
> +struct intel_atomic_state;
>  struct intel_crtc_state;
>  struct intel_initial_plane_config;
>  struct intel_crtc;
> @@ -497,8 +498,9 @@ struct drm_i915_display_funcs {
>   int (*compute_intermediate_wm)(struct drm_device *dev,
>  struct intel_crtc *intel_crtc,
>  struct intel_crtc_state *newstate);
> - void (*initial_watermarks)(struct intel_crtc_state *cstate);
> - void (*optimize_watermarks)(struct intel_crtc_state *cstate);
> + void (*initial_watermarks)(struct intel_atomic_state *state, struct 
> intel_crtc_state *cstate);
> + void (*atomic_evade_watermarks)(struct intel_atomic_state *state, 
> struct intel_crtc_state *cstate);
> + void (*optimize_watermarks)(struct intel_atomic_state *state, struct 
> intel_crtc_state *cstate);

initial_watermarks() and optimize_watermarks() are currently only used
on ILK (and possibly by in-development VLV/CHV patches that Ville is
working on?).  As far as I can see, the top-level state that we add as a
parameter here doesn't actually get used in the implementations.  Are
you adding it to just make them more similar to the signature of the new
atomic_evade_watermarks vfunc or did you have something else in mind?

I'd also suggest adding a brief comment to your new skl_evade_crtc_wm()
function that indicates that nearly all of the gen9 watermark values are
per-plane values that get written as part of the general plane update in
skylake_update_primary_plane and/or skl_update_plane.  Given that those
two functions are located in other files that may help clarify to future
developers why this function appears so trivial.


Matt

>   int (*compute_global_watermarks)(struct drm_atomic_state *state);
>   void (*update_wm)(struct drm_crtc *crtc);
>   int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 55f8ec8c76ae..23d8c72dade3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5160,7 +5160,7 @@ static void intel_pre_plane_update(struct 
> intel_crtc_state *old_crtc_state)
>* us to.
>*/
>   if (dev_priv->display.initial_watermarks != NULL)
> - dev_priv->display.initial_watermarks(pipe_config);
> + 
> dev_priv->display.initial_watermarks(to_intel_atomic_state(old_state), 
> pipe_config);
>   else if (pipe_config->update_wm_pre)
>   intel_update_watermarks(>base);
>  }
> @@ -5374,7 +5374,7 @@ static void ironlake_crtc_enable(struct 
> intel_crtc_state *pipe_config,
>   intel_color_load_luts(_config->base);
>  
>   if (dev_priv->display.initial_watermarks != NULL)
> - dev_priv->display.initial_watermarks(intel_crtc->config);
> + 
> dev_priv->display.initial_watermarks(to_intel_atomic_state(old_state), 
> intel_crtc->config);
>   intel_enable_pipe(intel_crtc);
>  
>   if (intel_crtc->config->has_pch_encoder)
> @@ -5480,7 +5480,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
> *pipe_config,
>   intel_ddi_enable_transcoder_func(crtc);
>  
>   if (dev_priv->display.initial_watermarks != NULL)
> - dev_priv->display.initial_watermarks(pipe_config);
> + 
> dev_priv->display.initial_watermarks(to_intel_atomic_state(old_state), 
> pipe_config);
>   else
>   intel_update_watermarks(crtc);
>  
> @@ -14503,7 +14503,7 @@ static void intel_atomic_commit_tail(struct 
> drm_atomic_state *state)
>   intel_cstate = to_intel_crtc_state(crtc->state);
>  
>   if (dev_priv->display.optimize_watermarks)
> - dev_priv->display.optimize_watermarks(intel_cstate);
> + dev_priv->display.optimize_watermarks(intel_state, 
> intel_cstate);
>   }
>  
>   for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
> @@ -14908,7 +14908,6 @@ static void intel_begin_crtc_commit(struct drm_crtc 
> *crtc,
>   struct intel_crtc_state *old_intel_state =
>   

Re: [Intel-gfx] [PATCH 4/8] drm/i915/skl+: Clean up minimum allocations.

2016-10-19 Thread Matt Roper
On Wed, Oct 12, 2016 at 03:28:17PM +0200, Maarten Lankhorst wrote:
> Move calculating minimum allocations to a helper, which cleans up the
> code some more. The cursor is still allocated in advance because it
> doesn't count towards data rate and should always be reserved.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 66 
> -
>  1 file changed, 39 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 83c1b0acef38..45fb8275abea 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3342,6 +3342,32 @@ skl_ddb_min_alloc(const struct drm_plane_state *pstate,
>   return DIV_ROUND_UP((4 * src_w * plane_bpp), 512) * min_scanlines/4 + 3;
>  }
>  
> +static void
> +skl_ddb_calc_min(const struct intel_crtc_state *cstate, int num_active,
> +  uint16_t *minimum, uint16_t *y_minimum)
> +{
> + const struct drm_plane_state *pstate;
> + struct drm_plane *plane;
> + enum pipe pipe = to_intel_crtc(cstate->base.crtc)->pipe;
> +
> + drm_atomic_crtc_state_for_each_plane_state(plane, pstate, 
> >base) {
> + struct intel_plane *intel_plane = to_intel_plane(plane);
> + int id = skl_wm_plane_id(intel_plane);
> +
> + if (intel_plane->pipe != pipe ||
> + id == PLANE_CURSOR)
> + continue;
> +
> + if (!pstate->visible)
> + continue;
> +
> + minimum[id] = skl_ddb_min_alloc(pstate, 0);
> + y_minimum[id] = skl_ddb_min_alloc(pstate, 1);
> + }
> +
> + minimum[PLANE_CURSOR] = skl_cursor_allocation(num_active);
> +}
> +
>  static int
>  skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
> struct skl_ddb_allocation *ddb /* out */)
> @@ -3350,12 +3376,9 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>   struct drm_crtc *crtc = cstate->base.crtc;
>   struct drm_device *dev = crtc->dev;
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - struct intel_plane *intel_plane;
> - struct drm_plane *plane;
> - const struct drm_plane_state *pstate;
>   enum pipe pipe = intel_crtc->pipe;
>   struct skl_ddb_entry *alloc = >wm.skl.ddb;
> - uint16_t alloc_size, start, cursor_blocks;
> + uint16_t alloc_size, start;
>   uint16_t minimum[I915_MAX_PLANES] = {};
>   uint16_t y_minimum[I915_MAX_PLANES] = {};
>   unsigned int total_data_rate;
> @@ -3384,35 +3407,21 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>   return 0;
>   }
>  
> - cursor_blocks = skl_cursor_allocation(num_active);
> - ddb->plane[pipe][PLANE_CURSOR].start = alloc->end - cursor_blocks;
> - ddb->plane[pipe][PLANE_CURSOR].end = alloc->end;
> -
> - alloc_size -= cursor_blocks;
> -
> - /* 1. Allocate the mininum required blocks for each active plane */
> - drm_atomic_crtc_state_for_each_plane_state(plane, pstate, 
> >base) {
> - intel_plane = to_intel_plane(plane);
> - id = skl_wm_plane_id(intel_plane);
> -
> - if (intel_plane->pipe != pipe)
> - continue;
> -
> - if (!pstate->visible)
> - continue;
> + skl_ddb_calc_min(cstate, num_active, minimum, y_minimum);
>  
> - if (plane->type == DRM_PLANE_TYPE_CURSOR)
> - continue;
> -
> - minimum[id] = skl_ddb_min_alloc(pstate, 0);
> - y_minimum[id] = skl_ddb_min_alloc(pstate, 1);
> - }
> + /* 1. Allocate the mininum required blocks for each active plane

Minor style nitpick; different multi-line comment format than we
typically use (and that we use for #2 below).

Otherwise,

Reviewed-by: Matt Roper 


> +  * and allocate the cursor, it doesn't require extra allocation
> +  * proportional to the data rate.
> +  */
>  
> - for (i = 0; i < PLANE_CURSOR; i++) {
> + for (i = 0; i < I915_MAX_PLANES; i++) {
>   alloc_size -= minimum[i];
>   alloc_size -= y_minimum[i];
>   }
>  
> + ddb->plane[pipe][PLANE_CURSOR].start = alloc->end - 
> minimum[PLANE_CURSOR];
> + ddb->plane[pipe][PLANE_CURSOR].end = alloc->end;
> +
>   /*
>* 2. Distribute the remaining space in proportion to the amount of
>* data each plane needs to fetch from memory.
> @@ -3428,6 +3437,9 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>   unsigned rate;
>   uint16_t plane_blocks, y_plane_blocks = 0;
>  
> + if (id == PLANE_CURSOR)
> + continue;
> +
>   rate = data_rate[id];
>  
>   /*
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> 

[Intel-gfx] ✗ Fi.CI.BAT: failure for Hotplug Uevent on Link training failure on DP

2016-10-19 Thread Patchwork
== Series Details ==

Series: Hotplug Uevent on Link training failure on DP
URL   : https://patchwork.freedesktop.org/series/14057/
State : failure

== Summary ==

Series 14057v1 Hotplug Uevent on Link training failure on DP
https://patchwork.freedesktop.org/api/1.0/series/14057/revisions/1/mbox/

Test kms_busy:
Subgroup basic-flip-default-a:
pass   -> INCOMPLETE (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:214  dwarn:0   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:219  dwarn:4   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:168  pass:162  dwarn:0   dfail:0   fail:0   skip:5  
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2769/

456ed322a41b7ca9699ad10fe49775803a55656a drm-intel-nightly: 
2016y-10m-19d-20h-30m-34s UTC integration manifest
7104bdbb drm/i915: Add support for DP link training compliance
1c5d01d drm/i915: Link Rate fallback on Link training failure
8a3e80c drm/i915: Define the modeset retry work function
dda5447 drm/i915; Add a function to return index of link rate
0f79ecf6 drm/i915: Change the placement of some static functions in intel_dp.c
8a6e4e3 drm: Trigger a complete modeset if link_train_retry is set
8f8fa7f drm: Define a work struct for scheduling a uevent for modeset retry
02cc208 drm: Add a link_train_retry field to drm_connector

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


Re: [Intel-gfx] [PATCH 3/8] drm/i915/skl+: Remove minimum block allocation from crtc state.

2016-10-19 Thread Matt Roper
On Wed, Oct 12, 2016 at 03:28:16PM +0200, Maarten Lankhorst wrote:
> This is not required any more now that we get fresh state from
> drm_atomic_crtc_state_for_each_plane_state. Zero all state
> in advance.
> 
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/intel_drv.h |  4 
>  drivers/gpu/drm/i915/intel_pm.c  | 15 +--
>  2 files changed, 5 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 888054518f3c..a176e6cebab3 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -501,10 +501,6 @@ struct intel_crtc_wm_state {
>   /* gen9+ only needs 1-step wm programming */
>   struct skl_pipe_wm optimal;
>   struct skl_ddb_entry ddb;
> -
> - /* minimum block allocation */
> - uint16_t minimum_blocks[I915_MAX_PLANES];
> - uint16_t minimum_y_blocks[I915_MAX_PLANES];
>   } skl;
>   };
>  
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 97b6202c4097..83c1b0acef38 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3356,8 +3356,8 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>   enum pipe pipe = intel_crtc->pipe;
>   struct skl_ddb_entry *alloc = >wm.skl.ddb;
>   uint16_t alloc_size, start, cursor_blocks;
> - uint16_t *minimum = cstate->wm.skl.minimum_blocks;
> - uint16_t *y_minimum = cstate->wm.skl.minimum_y_blocks;
> + uint16_t minimum[I915_MAX_PLANES] = {};
> + uint16_t y_minimum[I915_MAX_PLANES] = {};
>   unsigned int total_data_rate;
>   int num_active;
>   int id, i;
> @@ -3398,16 +3398,11 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>   if (intel_plane->pipe != pipe)
>   continue;
>  
> - if (!pstate->visible) {
> - minimum[id] = 0;
> - y_minimum[id] = 0;
> + if (!pstate->visible)
>   continue;
> - }
> - if (plane->type == DRM_PLANE_TYPE_CURSOR) {
> - minimum[id] = 0;
> - y_minimum[id] = 0;
> +
> + if (plane->type == DRM_PLANE_TYPE_CURSOR)
>   continue;
> - }
>  
>   minimum[id] = skl_ddb_min_alloc(pstate, 0);
>   y_minimum[id] = skl_ddb_min_alloc(pstate, 1);
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 1/8] drm/i915/skl+: Prepare for removing data rate from skl watermark state

2016-10-19 Thread Matt Roper
On Wed, Oct 12, 2016 at 03:28:14PM +0200, Maarten Lankhorst wrote:
> Caching is not required, drm_atomic_crtc_state_for_each_plane_state
> can be used to inspect all plane_states that are assigned to the
> current crtc_state, so we can just recalculate every time.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 27 ---
>  1 file changed, 12 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 6af1587e9d84..b96a899c899d 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -31,6 +31,7 @@
>  #include "intel_drv.h"
>  #include "../../../platform/x86/intel_ips.h"
>  #include 
> +#include 
>  
>  /**
>   * DOC: RC6
> @@ -3242,18 +3243,17 @@ skl_get_total_relative_data_rate(struct 
> intel_crtc_state *intel_cstate)
>   struct drm_crtc *crtc = cstate->crtc;
>   struct drm_device *dev = crtc->dev;
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - const struct drm_plane *plane;
> + struct drm_plane *plane;
>   const struct intel_plane *intel_plane;
> - struct drm_plane_state *pstate;
> + const struct drm_plane_state *pstate;
>   unsigned int rate, total_data_rate = 0;
>   int id;
> - int i;
>  
>   if (WARN_ON(!state))
>   return 0;
>  
>   /* Calculate and cache data rate for each plane */
> - for_each_plane_in_state(state, plane, pstate, i) {
> + drm_atomic_crtc_state_for_each_plane_state(plane, pstate, cstate) {
>   id = skl_wm_plane_id(to_intel_plane(plane));
>   intel_plane = to_intel_plane(plane);
>  
> @@ -3356,7 +3356,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>   struct intel_plane *intel_plane;
>   struct drm_plane *plane;
> - struct drm_plane_state *pstate;
> + const struct drm_plane_state *pstate;
>   enum pipe pipe = intel_crtc->pipe;
>   struct skl_ddb_entry *alloc = >wm.skl.ddb;
>   uint16_t alloc_size, start, cursor_blocks;
> @@ -3392,14 +3392,14 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>   alloc_size -= cursor_blocks;
>  
>   /* 1. Allocate the mininum required blocks for each active plane */
> - for_each_plane_in_state(state, plane, pstate, i) {
> + drm_atomic_crtc_state_for_each_plane_state(plane, pstate, 
> >base) {
>   intel_plane = to_intel_plane(plane);
>   id = skl_wm_plane_id(intel_plane);
>  
>   if (intel_plane->pipe != pipe)
>   continue;
>  
> - if (!to_intel_plane_state(pstate)->base.visible) {
> + if (!pstate->visible) {
>   minimum[id] = 0;
>   y_minimum[id] = 0;
>   continue;
> @@ -3948,7 +3948,7 @@ skl_ddb_add_affected_planes(struct intel_crtc_state 
> *cstate)
>  
>   WARN_ON(!drm_atomic_get_existing_crtc_state(state, crtc));
>  
> - drm_for_each_plane_mask(plane, dev, crtc->state->plane_mask) {
> + drm_for_each_plane_mask(plane, dev, cstate->base.plane_mask) {

Is this change necessary?  Any plane that differs between the two masks
should already be part of our state, so I don't think this changes the
behavior at all.  The original 'crtc->state->plane_mask' form is closer
to the drm_atomic_add_affected_planes() that this function is modeled
after so my slight preference would be to leave it alone for
consistency.

Aside from that, this patch is

Reviewed-by: Matt Roper 

I remember when I first wrote an early version of this code it was just
doing a drm_atomic_get_plane_state() on each plane unconditionally,
which was non-optimal.  When I reworked it, I wasn't aware of
drm_atomic_crtc_state_for_each_plane_state (or maybe it didn't exist
yet), so I used caching as an alternative.  But the new approach is much
better so I'm glad we can get rid of the caching.


Matt

>   id = skl_wm_plane_id(to_intel_plane(plane));
>  
>   if (skl_ddb_entry_equal(_ddb->plane[pipe][id],
> @@ -4063,14 +4063,12 @@ skl_print_wm_changes(const struct drm_atomic_state 
> *state)
>   to_intel_atomic_state(state);
>   const struct drm_crtc *crtc;
>   const struct drm_crtc_state *cstate;
> - const struct drm_plane *plane;
>   const struct intel_plane *intel_plane;
> - const struct drm_plane_state *pstate;
>   const struct skl_ddb_allocation *old_ddb = _priv->wm.skl_hw.ddb;
>   const struct skl_ddb_allocation *new_ddb = _state->wm_results.ddb;
>   enum pipe pipe;
>   int id;
> - int i, j;
> + int i;
>  
>   for_each_crtc_in_state(state, crtc, cstate, i) {
>   if (!crtc->state)
> @@ -4078,10 +4076,9 @@ skl_print_wm_changes(const struct drm_atomic_state 
> *state)
>  
>   pipe = 

Re: [Intel-gfx] [PATCH 2/8] drm/i915/skl+: Remove data_rate from watermark struct.

2016-10-19 Thread Matt Roper
On Wed, Oct 12, 2016 at 03:28:15PM +0200, Maarten Lankhorst wrote:
> It's only used in one function, and can be calculated without caching it
> in the global struct by using drm_atomic_crtc_state_for_each_plane_state.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_drv.h |  4 
>  drivers/gpu/drm/i915/intel_pm.c  | 44 
> +++-
>  2 files changed, 21 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index bb468c974e14..888054518f3c 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -502,10 +502,6 @@ struct intel_crtc_wm_state {
>   struct skl_pipe_wm optimal;
>   struct skl_ddb_entry ddb;
>  
> - /* cached plane data rate */
> - unsigned plane_data_rate[I915_MAX_PLANES];
> - unsigned plane_y_data_rate[I915_MAX_PLANES];
> -
>   /* minimum block allocation */
>   uint16_t minimum_blocks[I915_MAX_PLANES];
>   uint16_t minimum_y_blocks[I915_MAX_PLANES];
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index b96a899c899d..97b6202c4097 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3236,12 +3236,13 @@ skl_plane_relative_data_rate(const struct 
> intel_crtc_state *cstate,
>   *   3 * 4096 * 8192  * 4 < 2^32
>   */
>  static unsigned int
> -skl_get_total_relative_data_rate(struct intel_crtc_state *intel_cstate)
> +skl_get_total_relative_data_rate(struct intel_crtc_state *intel_cstate,
> +  unsigned *plane_data_rate,
> +  unsigned *plane_y_data_rate)
>  {
>   struct drm_crtc_state *cstate = _cstate->base;
>   struct drm_atomic_state *state = cstate->state;
>   struct drm_crtc *crtc = cstate->crtc;
> - struct drm_device *dev = crtc->dev;
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>   struct drm_plane *plane;
>   const struct intel_plane *intel_plane;
> @@ -3263,21 +3264,16 @@ skl_get_total_relative_data_rate(struct 
> intel_crtc_state *intel_cstate)
>   /* packed/uv */
>   rate = skl_plane_relative_data_rate(intel_cstate,
>   pstate, 0);
> - intel_cstate->wm.skl.plane_data_rate[id] = rate;
> + plane_data_rate[id] = rate;
> +
> + total_data_rate += rate;
>  
>   /* y-plane */
>   rate = skl_plane_relative_data_rate(intel_cstate,
>   pstate, 1);
> - intel_cstate->wm.skl.plane_y_data_rate[id] = rate;
> - }
> -
> - /* Calculate CRTC's total data rate from cached values */
> - for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
> - int id = skl_wm_plane_id(intel_plane);
> + plane_y_data_rate[id] = rate;
>  
> - /* packed/uv */
> - total_data_rate += intel_cstate->wm.skl.plane_data_rate[id];
> - total_data_rate += intel_cstate->wm.skl.plane_y_data_rate[id];
> + total_data_rate += rate;
>   }
>  
>   return total_data_rate;
> @@ -3366,6 +3362,9 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>   int num_active;
>   int id, i;
>  
> + unsigned data_rate[I915_MAX_PLANES] = {};
> + unsigned y_data_rate[I915_MAX_PLANES] = {};
> +

Minor nitpick; if you picked a different names here (e.g.,
plane_data_rate[]) then you could leave the local variables farther down
named 'data_rate' and 'y_data_rate' which would reduce the diff changes
and result in a slightly smaller patch.

Whether or not you feel like making that change, killing the caching is
good so,

Reviewed-by: Matt Roper 


>   /* Clear the partitioning for disabled planes. */
>   memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
>   memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
> @@ -3425,29 +3424,28 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>*
>* FIXME: we may not allocate every single block here.
>*/
> - total_data_rate = skl_get_total_relative_data_rate(cstate);
> + total_data_rate = skl_get_total_relative_data_rate(cstate, data_rate, 
> y_data_rate);
>   if (total_data_rate == 0)
>   return 0;
>  
>   start = alloc->start;
> - for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
> - unsigned int data_rate, y_data_rate;
> + for (id = 0; id < I915_MAX_PLANES; id++) {
> + unsigned rate;
>   uint16_t plane_blocks, y_plane_blocks = 0;
> - int id = skl_wm_plane_id(intel_plane);
>  
> - data_rate = 

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2)

2016-10-19 Thread Patchwork
== Series Details ==

Series: drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2)
URL   : https://patchwork.freedesktop.org/series/11667/
State : warning

== Summary ==

Series 11667v2 drm/i915/dp: add lane_count check in intel_dp_check_link_status
https://patchwork.freedesktop.org/api/1.0/series/11667/revisions/2/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-skl-6700hq)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup nonblocking-crc-pipe-b:
pass   -> DMESG-WARN (fi-ivb-3770)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700hq)
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (fi-skl-6700hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:214  dwarn:0   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:220  dwarn:1   dfail:0   fail:0   skip:25 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2768/

456ed322a41b7ca9699ad10fe49775803a55656a drm-intel-nightly: 
2016y-10m-19d-20h-30m-34s UTC integration manifest
95638cb drm/i915/dp: add lane_count check in intel_dp_check_link_status

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


[Intel-gfx] [PATCH RFC 4/8] drm/i915: Change the placement of some static functions in intel_dp.c

2016-10-19 Thread Manasi Navare
From: "Navare, Manasi D" 

These static helper functions are required to be used during
fallback link rate implemnetation so they need to be placed at the top
of the file.

v3:
* Add cleanup to other patch (Mika Kahola)
v2:
* Dont move around functions declared in intel_drv.h (Rodrigo Vivi)

Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
Reviewed-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dp.c | 150 
 1 file changed, 75 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 88f3b74..6b54b0e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -213,6 +213,81 @@ static u8 intel_dp_max_lane_count(struct intel_dp 
*intel_dp)
return max_dotclk;
 }
 
+static int
+intel_dp_sink_rates(struct intel_dp *intel_dp, const int **sink_rates)
+{
+   if (intel_dp->num_sink_rates) {
+   *sink_rates = intel_dp->sink_rates;
+   return intel_dp->num_sink_rates;
+   }
+
+   *sink_rates = default_rates;
+
+   return (intel_dp_max_link_bw(intel_dp) >> 3) + 1;
+}
+
+static int
+intel_dp_source_rates(struct intel_dp *intel_dp, const int **source_rates)
+{
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
+   int size;
+
+   if (IS_BROXTON(dev_priv)) {
+   *source_rates = bxt_rates;
+   size = ARRAY_SIZE(bxt_rates);
+   } else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
+   *source_rates = skl_rates;
+   size = ARRAY_SIZE(skl_rates);
+   } else {
+   *source_rates = default_rates;
+   size = ARRAY_SIZE(default_rates);
+   }
+
+   /* This depends on the fact that 5.4 is last value in the array */
+   if (!intel_dp_source_supports_hbr2(intel_dp))
+   size--;
+
+   return size;
+}
+
+static int intersect_rates(const int *source_rates, int source_len,
+  const int *sink_rates, int sink_len,
+  int *common_rates)
+{
+   int i = 0, j = 0, k = 0;
+
+   while (i < source_len && j < sink_len) {
+   if (source_rates[i] == sink_rates[j]) {
+   if (WARN_ON(k >= DP_MAX_SUPPORTED_RATES))
+   return k;
+   common_rates[k] = source_rates[i];
+   ++k;
+   ++i;
+   ++j;
+   } else if (source_rates[i] < sink_rates[j]) {
+   ++i;
+   } else {
+   ++j;
+   }
+   }
+   return k;
+}
+
+static int intel_dp_common_rates(struct intel_dp *intel_dp,
+int *common_rates)
+{
+   const int *source_rates, *sink_rates;
+   int source_len, sink_len;
+
+   sink_len = intel_dp_sink_rates(intel_dp, _rates);
+   source_len = intel_dp_source_rates(intel_dp, _rates);
+
+   return intersect_rates(source_rates, source_len,
+  sink_rates, sink_len,
+  common_rates);
+}
+
 static enum drm_mode_status
 intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
@@ -1282,19 +1357,6 @@ static void intel_aux_reg_init(struct intel_dp *intel_dp)
intel_dp->aux.transfer = intel_dp_aux_transfer;
 }
 
-static int
-intel_dp_sink_rates(struct intel_dp *intel_dp, const int **sink_rates)
-{
-   if (intel_dp->num_sink_rates) {
-   *sink_rates = intel_dp->sink_rates;
-   return intel_dp->num_sink_rates;
-   }
-
-   *sink_rates = default_rates;
-
-   return (intel_dp_max_link_bw(intel_dp) >> 3) + 1;
-}
-
 bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp)
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
@@ -1307,31 +1369,6 @@ bool intel_dp_source_supports_hbr2(struct intel_dp 
*intel_dp)
return false;
 }
 
-static int
-intel_dp_source_rates(struct intel_dp *intel_dp, const int **source_rates)
-{
-   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
-   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
-   int size;
-
-   if (IS_BROXTON(dev_priv)) {
-   *source_rates = bxt_rates;
-   size = ARRAY_SIZE(bxt_rates);
-   } else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
-   *source_rates = skl_rates;
-   size = ARRAY_SIZE(skl_rates);
-   } else {
-   *source_rates = default_rates;
-   size = ARRAY_SIZE(default_rates);
-   }
-
- 

[Intel-gfx] [PATCH RFC 5/8] drm/i915; Add a function to return index of link rate

2016-10-19 Thread Manasi Navare
This is required to return the index of link rate into
common_rates array. This gets used to retry the link
training at lower link rate.

Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6b54b0e..a60bef8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -288,6 +288,21 @@ static int intel_dp_common_rates(struct intel_dp *intel_dp,
   common_rates);
 }
 
+static int intel_dp_link_rate_index(struct intel_dp *intel_dp, int 
*common_rates,
+   int link_rate)
+{
+   int common_len;
+   int index;
+
+   common_len = intel_dp_common_rates(intel_dp, common_rates);
+   for (index = 0; index < common_len; index++) {
+   if (link_rate == common_rates[common_len - index - 1])
+   return common_len - index - 1;
+   }
+
+   return -1;
+}
+
 static enum drm_mode_status
 intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
-- 
1.9.1

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


[Intel-gfx] [PATCH RFC 0/8] Hotplug Uevent on Link training failure on DP

2016-10-19 Thread Manasi Navare
These patches handle the DP link training failure during atomic modeset.
A new connector property is defined to indicate if link training retry
is requested on failure. If link training fails, we set this connector
property and send a hotplug uevent that gets exceuted after the current modeset
is completed an dlocks are released. The userspace is expected to monitor this
connector property to detect a change in connector and trigger a full modeset.
Here changes are made in fb_dev to monitor this property as well as the
atomic check modeset to use this new property to detect a change.
In the modeset retry, the modes are validated based on link rate lower than
the failed link rate and link is retrained at lower link rate.

Manasi Navare (7):
  drm: Add a link_train_retry field to drm_connector
  drm: Define a work struct for scheduling a uevent for modeset retry
  drm: Trigger a complete modeset if link_train_retry is set
  drm/i915; Add a function to return index of link rate
  drm/i915: Define the modeset retry work function
  drm/i915: Link Rate fallback on Link training failure
  drm/i915: Add support for DP link training compliance

Navare, Manasi D (1):
  drm/i915: Change the placement of some static functions in intel_dp.c

 drivers/gpu/drm/drm_atomic_helper.c   |   9 +
 drivers/gpu/drm/drm_fb_helper.c   |   3 +-
 drivers/gpu/drm/i915/intel_ddi.c  |  14 +-
 drivers/gpu/drm/i915/intel_dp.c   | 286 ++
 drivers/gpu/drm/i915/intel_dp_link_training.c |  12 +-
 drivers/gpu/drm/i915/intel_drv.h  |   8 +-
 include/drm/drm_connector.h   |  10 +
 7 files changed, 249 insertions(+), 93 deletions(-)

-- 
1.9.1

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


[Intel-gfx] [PATCH RFC 3/8] drm: Trigger a complete modeset if link_train_retry is set

2016-10-19 Thread Manasi Navare
The link_train_retry property of the connector needs to be checked
to see if a full modeset is required. If this is set, then link train
retry is requested possibly due to linktrain failure in the previous
modeset. Hence we need to indicate connector status changed in order to
trigger a full modeset.

Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/drm_atomic_helper.c | 9 +
 drivers/gpu/drm/drm_fb_helper.c | 3 ++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 07b432f..aeb2215 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -517,6 +517,15 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
 */
ret = update_connector_routing(state, connector,
   connector_state);
+   /* Set crtc->mode_changed and crtc->connectors_changed if
+* link_train_retry flag is set in the connector.
+*/
+   if (connector->link_train_retry) {
+   crtc_state = drm_atomic_get_existing_crtc_state(state,
+   
connector->state->crtc);
+   crtc_state->connectors_changed = true;
+   crtc_state->mode_changed = true;
+   }
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 8fffac8..b408e62 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2152,7 +2152,8 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper)
fb_crtc->desired_mode = mode;
fb_crtc->x = offset->x;
fb_crtc->y = offset->y;
-   if (modeset->mode)
+   if (modeset->mode &&
+   
!(fb_helper->connector_info[i]->connector->link_train_retry))
drm_mode_destroy(dev, modeset->mode);
modeset->mode = drm_mode_duplicate(dev,
   
fb_crtc->desired_mode);
-- 
1.9.1

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


[Intel-gfx] [PATCH RFC 7/8] drm/i915: Link Rate fallback on Link training failure

2016-10-19 Thread Manasi Navare
If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed and use a lower link rate
to prune the modes during the next modeset, configure the pipe at
lower link rate and retrian at lower link rate.

This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
4.3.1.6.

Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_ddi.c  | 14 ++-
 drivers/gpu/drm/i915/intel_dp.c   | 35 +--
 drivers/gpu/drm/i915/intel_dp_link_training.c | 12 ++---
 drivers/gpu/drm/i915/intel_drv.h  |  6 -
 4 files changed, 60 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 7f7741c..cccb301 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1642,6 +1642,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum port port = intel_ddi_get_encoder_port(encoder);
+   struct intel_connector *intel_connector = intel_dp->attached_connector;
+   struct drm_connector *connector = _connector->base;
 
intel_dp_set_link_params(intel_dp, link_rate, lane_count,
 link_mst);
@@ -1652,7 +1654,17 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
intel_prepare_dp_ddi_buffers(encoder);
intel_ddi_init_dp_buf_reg(encoder);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
-   intel_dp_start_link_train(intel_dp);
+   if (!intel_dp_start_link_train(intel_dp)) {
+   DRM_ERROR("Link Training failed at link rate = %d, lane count = 
%d",
+ link_rate, lane_count);
+   intel_dp->link_train_failed = true;
+   intel_dp->link_train_failed_link_rate = link_rate;
+   intel_dp->link_train_failed_lane_count = lane_count;
+   /* Schedule a Hotplug Uevent to userspace to start modeset */
+   schedule_work(>i915_modeset_retry_work);
+   } else
+   connector->link_train_retry = false;
+
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
 }
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index aae7f82..78246ba 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -313,6 +313,7 @@ static int intel_dp_link_rate_index(struct intel_dp 
*intel_dp, int *common_rates
int target_clock = mode->clock;
int max_rate, mode_rate, max_lanes, max_link_clock;
int max_dotclk;
+   int common_rates[DP_MAX_SUPPORTED_RATES] = {};
 
max_dotclk = intel_dp_downstream_max_dotclock(intel_dp);
 
@@ -326,8 +327,26 @@ static int intel_dp_link_rate_index(struct intel_dp 
*intel_dp, int *common_rates
target_clock = fixed_mode->clock;
}
 
-   max_link_clock = intel_dp_max_link_rate(intel_dp);
-   max_lanes = intel_dp_max_lane_count(intel_dp);
+   /* Prune the modes based on the link rate that failed */
+   if (intel_dp->link_train_failed_link_rate) {
+   intel_dp->link_rate_index = intel_dp_link_rate_index(intel_dp,
+
common_rates,
+
intel_dp->link_train_failed_link_rate);
+   if (intel_dp->link_rate_index > 0) {
+   max_link_clock = common_rates[intel_dp->link_rate_index 
- 1];
+   max_lanes = intel_dp_max_lane_count(intel_dp);
+   } else {
+   /* Here we can lower the lane count, but that is DP 1.3 
not 1.2 */
+   DRM_ERROR(" No Valid Mode Supported for this Link");
+   connector->link_train_retry = false;
+   intel_dp->link_train_failed_link_rate = 0;
+   intel_dp->link_rate_index = -1;
+   }
+   }
+   else {
+   max_link_clock = intel_dp_max_link_rate(intel_dp);
+   max_lanes = intel_dp_max_lane_count(intel_dp);
+   }
 
max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
mode_rate = intel_dp_link_required(target_clock, 18);
@@ -1610,6 +1629,14 @@ static int intel_dp_compute_bpp(struct intel_dp 
*intel_dp,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
return false;
 
+   /* Fall back to lower link rate in case of failure in previous 

[Intel-gfx] [PATCH RFC 6/8] drm/i915: Define the modeset retry work function

2016-10-19 Thread Manasi Navare
This work function gets scheduled on link training failure
during the atomic commit of modeset. It should get executed
after the current modeset is completed and send a hotplug uevent
to notify the usersapce about change in the connector link property
requesting link_train_retry

Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a60bef8..aae7f82 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5675,6 +5675,22 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
return false;
 }
 
+static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
+{
+   struct drm_connector *connector;
+
+   connector = container_of(work, typeof(*connector),
+i915_modeset_retry_work);
+
+   /* Grab the locks before changing connector property*/
+   mutex_lock(>dev->mode_config.mutex);
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
+ connector->name);
+   connector->link_train_retry = true;
+   mutex_unlock(>dev->mode_config.mutex);
+   drm_kms_helper_hotplug_event(connector->dev);
+}
+
 bool
 intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
struct intel_connector *intel_connector)
@@ -5687,6 +5703,10 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
enum port port = intel_dig_port->port;
int type;
 
+   /* Initialize the work for modeset in case of link train failure */
+   INIT_WORK(>i915_modeset_retry_work,
+ intel_dp_modeset_retry_work_fn);
+
if (WARN(intel_dig_port->max_lanes < 1,
 "Not enough lanes (%d) for DP on port %c\n",
 intel_dig_port->max_lanes, port_name(port)))
-- 
1.9.1

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


[Intel-gfx] [PATCH RFC 2/8] drm: Define a work struct for scheduling a uevent for modeset retry

2016-10-19 Thread Manasi Navare
This work struct will be used to schedule a uevent on a separate
thread. This will be scheduled after a link train failure during modeset
to indicate a modeset retry request. It will get executed after the
current modeset is complete and all locks are released. This was
required to avoid deadlock.

Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 

Signed-off-by: Manasi Navare 
---
 include/drm/drm_connector.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index d499466..9218a24 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -687,6 +687,11 @@ struct drm_connector {
 * in case of link train failure during current modeset
 */
bool link_train_retry;
+
+   /* Work struct to schedule a uevent on link train failure for
+* DisplayPort.
+*/
+   struct work_struct i915_modeset_retry_work;
 };
 
 #define obj_to_connector(x) container_of(x, struct drm_connector, base)
-- 
1.9.1

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


[Intel-gfx] [PATCH RFC 8/8] drm/i915: Add support for DP link training compliance

2016-10-19 Thread Manasi Navare
This patch adds support to handle automated DP compliance
link training test requests. This patch has been tested with
Unigraf DPR-120 DP Compliance device for testing Link
Training Compliance.
After we get a short pulse Compliance test request, test
request values are read and hotplug uevent is sent in order
to trigger another modeset during which the pipe is configured
and link is enabled for link parameters requested by the test.

Signed-off-by: Manasi Navare 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
---
 drivers/gpu/drm/i915/intel_dp.c  | 72 ++--
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 2 files changed, 63 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 78246ba..cd7a59e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1588,6 +1588,7 @@ static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
/* Conveniently, the link BW constants become indices with a shift...*/
int min_clock = 0;
int max_clock;
+   int link_rate_index;
int bpp, mode_rate;
int link_avail, link_clock;
int common_rates[DP_MAX_SUPPORTED_RATES] = {};
@@ -1636,6 +1637,19 @@ static int intel_dp_compute_bpp(struct intel_dp 
*intel_dp,
intel_dp->link_train_failed_link_rate = 0;
intel_dp->link_rate_index = -1;
}
+   /* Use values requested by Compliance Test Request */
+   if (intel_dp->compliance_test_link_rate &&
+   intel_dp->compliance_test_lane_count) {
+   link_rate_index = intel_dp_link_rate_index(intel_dp,
+  common_rates,
+  
drm_dp_bw_code_to_link_rate(intel_dp->compliance_test_link_rate));
+   if (link_rate_index >= 0)
+   min_clock = max_clock = link_rate_index;
+   min_lane_count = max_lane_count = 
intel_dp->compliance_test_lane_count;
+
+   intel_dp->compliance_test_link_rate = 0;
+   intel_dp->compliance_test_lane_count = 0;
+   }
 
DRM_DEBUG_KMS("DP link computation with max lane count %i "
  "max bw %d pixel clock %iKHz\n",
@@ -1684,6 +1698,7 @@ static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
}
}
}
+
}
 
return false;
@@ -3865,6 +3880,29 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
 static uint8_t intel_dp_autotest_link_training(struct intel_dp *intel_dp)
 {
uint8_t test_result = DP_TEST_ACK;
+   int status = 0;
+   /* (DP CTS 1.2)
+* 4.3.1.11
+*/
+   /* Read the TEST_LANE_COUNT and TEST_LINK_RTAE fields (DP CTS 3.1.4) */
+   status = drm_dp_dpcd_readb(_dp->aux, DP_TEST_LANE_COUNT,
+ _dp->compliance_test_lane_count);
+
+   if (status <= 0) {
+   DRM_DEBUG_KMS("Could not read test lane count from "
+ "reference sink\n");
+   return 0;
+   }
+   intel_dp->compliance_test_lane_count &= DP_MAX_LANE_COUNT_MASK;
+
+   status = drm_dp_dpcd_readb(_dp->aux, DP_TEST_LINK_RATE,
+  _dp->compliance_test_link_rate);
+   if (status <= 0) {
+   DRM_DEBUG_KMS("Could not read test link rate from "
+ "refernce sink\n");
+   return 0;
+   }
+
return test_result;
 }
 
@@ -3965,11 +4003,14 @@ static void intel_dp_handle_test_request(struct 
intel_dp *intel_dp)
}
 
 update_status:
-   status = drm_dp_dpcd_write(_dp->aux,
-  DP_TEST_RESPONSE,
-  , 1);
-   if (status <= 0)
-   DRM_DEBUG_KMS("Could not write test response to sink\n");
+   if (intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) {
+   status = drm_dp_dpcd_write(_dp->aux,
+  DP_TEST_RESPONSE,
+  , 1);
+   if (status <= 0)
+   DRM_DEBUG_KMS("Could not write test response "
+ "to sink\n");
+   }
 }
 
 static int
@@ -4074,9 +4115,7 @@ static void intel_dp_handle_test_request(struct intel_dp 
*intel_dp)
if (!to_intel_crtc(intel_encoder->base.crtc)->active)
return;
 
-   /* if link training is requested we should perform it always */
-   if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) ||
-   (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
+   if 

[Intel-gfx] [PATCH RFC 1/8] drm: Add a link_train_retry field to drm_connector

2016-10-19 Thread Manasi Navare
This is a boolean that is set to true if link training fails
during modeset in the atomic commit.
This will be used to detect a change in the connector properties
and to retrigger a full modeset so that the link can be retrained
at lower link rate value.

Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 

Signed-off-by: Manasi Navare 
---
 include/drm/drm_connector.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ac9d7d8..d499466 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -682,6 +682,11 @@ struct drm_connector {
uint8_t num_h_tile, num_v_tile;
uint8_t tile_h_loc, tile_v_loc;
uint16_t tile_h_size, tile_v_size;
+
+   /* Flag to indicate if link train retry is required for DisplayPort
+* in case of link train failure during current modeset
+*/
+   bool link_train_retry;
 };
 
 #define obj_to_connector(x) container_of(x, struct drm_connector, base)
-- 
1.9.1

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


[Intel-gfx] [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status

2016-10-19 Thread Matthew Auld
Currently it's entirely possible to go through the link training step
without first determining the lane_count, which is silly since we end up
doing a bunch of aux transfers of size = 0, as highlighted by
WARN_ON(!msg->buffer != !msg->size), and can only ever result in a
'failed to update link training' message. This can be observed during
intel_dp_long_pulse where we can do the link training step, but before
we have had a chance to set the link params. To avoid this we add an
extra check for the lane_count in intel_dp_check_link_status, which
should prevent us from doing the link training step prematurely.

v2: add WARN_ON_ONCE and FIXME comment (Ville)

References: https://bugs.freedesktop.org/show_bug.cgi?id=97344
Cc: Ville Syrjälä 
Cc: Mika Kahola 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/intel_dp.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 88f3b74..fb760ad 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4032,6 +4032,11 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
if (!to_intel_crtc(intel_encoder->base.crtc)->active)
return;
 
+   /* FIXME: we need to synchronize this sort of stuff with hardware
+* readout */
+   if (WARN_ON_ONCE(!intel_dp->lane_count))
+   return;
+
/* if link training is requested we should perform it always */
if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) ||
(!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
-- 
2.7.4

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


[Intel-gfx] [PATCH igt] igt: drop gem_storedw_loop from BAT

2016-10-19 Thread Chris Wilson
The inter-engine synchronisation (with and without semaphores) is
equally exercised by gem_sync, so leave gem_storedw_loop out of the
"quick" set.

Signed-off-by: Chris Wilson 
---
 tests/gem_storedw_loop.c  | 6 +++---
 tests/intel-ci/fast-feedback.testlist | 7 ---
 2 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/tests/gem_storedw_loop.c b/tests/gem_storedw_loop.c
index 317b8c6..4f05b21 100644
--- a/tests/gem_storedw_loop.c
+++ b/tests/gem_storedw_loop.c
@@ -185,14 +185,14 @@ igt_main
}
 
for (e = intel_execution_engines; e->name; e++) {
-   igt_subtest_f("basic-%s", e->name) {
+   igt_subtest_f("short-%s", e->name) {
check_test_requirements(fd, e->exec_id);
-   store_test(fd, e->exec_id | e->flags, 16*1024);
+   store_test(fd, e->exec_id | e->flags, 4*1024);
}
 
igt_subtest_f("long-%s", e->name) {
check_test_requirements(fd, e->exec_id);
-   store_test(fd, e->exec_id | e->flags, 1024*1024);
+   store_test(fd, e->exec_id | e->flags, 4*1024*1024);
}
}
 
diff --git a/tests/intel-ci/fast-feedback.testlist 
b/tests/intel-ci/fast-feedback.testlist
index 853b911..b8fce59 100644
--- a/tests/intel-ci/fast-feedback.testlist
+++ b/tests/intel-ci/fast-feedback.testlist
@@ -111,13 +111,6 @@ igt@gem_ringfill@basic-default
 igt@gem_ringfill@basic-default-forked
 igt@gem_ringfill@basic-default-hang
 igt@gem_ringfill@basic-default-interruptible
-igt@gem_storedw_loop@basic-blt
-igt@gem_storedw_loop@basic-bsd
-igt@gem_storedw_loop@basic-bsd1
-igt@gem_storedw_loop@basic-bsd2
-igt@gem_storedw_loop@basic-default
-igt@gem_storedw_loop@basic-render
-igt@gem_storedw_loop@basic-vebox
 igt@gem_sync@basic-all
 igt@gem_sync@basic-each
 igt@gem_sync@basic-many-each
-- 
2.9.3

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


Re: [Intel-gfx] [PATCH] drm/i915: STOP_MACHINE is no more, stop selecting it

2016-10-19 Thread Chris Wilson
On Wed, Oct 19, 2016 at 09:48:02PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 19, 2016 at 07:06:35PM +0100, Chris Wilson wrote:
> > With the merge of 4.9-rc1, we can say goodbye to having to forcibly
> > select STOP_MACHINE in order to have a working stop_machine(). The code
> > just works now and the CONFIG_STOP_MACHINE symbol removed.
> 
> Note the relevant commit too?
> 86fffe4a61dd ("kernel: remove stop_machine() Kconfig dependency")

It's more mysterious than that:

commit 21fabbebff0e17c7698ed399cae23958c214cc82
Author: Andreas Ziegler 
Date:   Mon Jan 25 12:41:19 2016 +0100

drm/i915: Remove select to deleted STOP_MACHINE from Kconfig

Commit 5bab6f60cb4d ("drm/i915: Serialise updates to GGTT with access
through GGTT on Braswell") depended upon a working stop_machine() and
so forced the selection of STOP_MACHINE. However, commit 86fffe4a61dd
("kernel: remove stop_machine() Kconfig dependency") removed the option
STOP_MACHINE from init/Kconfig and ensured that stop_machine()
universally works. Due to the order in which the patches were applied,
removing the select from DRM_I915 got lost during merging.

Remove the now obsolete select statement.

Signed-off-by: Andreas Ziegler 
Reviewed-by: Chris Wilson 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1453722079-2604-1-git-send-email-andreas.zieg...@fau.de
Cc: drm-intel-fi...@lists.freedesktop.org
Signed-off-by: Daniel Vetter 

is where we are meant to be. Oh, it's actually

commit 9f267eb8d2ea0a87f694da3f236067335e8cb7b9
Author: Chris Wilson 
Date:   Wed Oct 12 10:05:19 2016 +0100

drm/i915: Stop the machine whilst capturing the GPU crash dump

that reintroduced it because I had completely forgotten about it when
rebasing. Ok, the commitlog needs rewritting to reflect the actual mistake.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: STOP_MACHINE is no more, stop selecting it

2016-10-19 Thread Ville Syrjälä
On Wed, Oct 19, 2016 at 07:06:35PM +0100, Chris Wilson wrote:
> With the merge of 4.9-rc1, we can say goodbye to having to forcibly
> select STOP_MACHINE in order to have a working stop_machine(). The code
> just works now and the CONFIG_STOP_MACHINE symbol removed.

Note the relevant commit too?
86fffe4a61dd ("kernel: remove stop_machine() Kconfig dependency")

Reviewed-by: Ville Syrjälä 

> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index e1b32da8954e..c383684b538f 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -4,7 +4,6 @@ config DRM_I915
>   depends on X86 && PCI
>   select INTEL_GTT
>   select INTERVAL_TREE
> - select STOP_MACHINE
>   # we need shmfs for the swappable backing store, and in particular
>   # the shmem_readpage() which depends upon tmpfs
>   select SHMEM
> -- 
> 2.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH] rtc: cmos: Don't enable interrupts in the middle of the interrupt handler

2016-10-19 Thread Ville Syrjälä
On Wed, Oct 19, 2016 at 07:16:39PM +0100, Chris Wilson wrote:
> On Wed, Oct 19, 2016 at 09:02:04PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Using spin_lock_irq()/spin_unlock_irq() from within the interrupt
> > handler is a no-no. Let's save/restore the flags to avoid turning on
> > interrupts prematurely.
> > 
> > We hit this in a bunch of our CI systems, but for whatever reason I
> > wasn't able to reproduce on my own machine, so this fix is just
> > based on the backtrace.
> > 
> > [  202.634918] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2729 
> > trace_hardirqs_on_caller+0x113/0x1b0
> > [  202.634919] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
> > [  202.634929] Modules linked in: snd_hda_intel i915 x86_pkg_temp_thermal 
> > intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
> > lpc_ich snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi 
> > snd_hda_codec snd_hwdep i2c_designware_platform i2c_designware_core 
> > snd_hda_core mei_me mei snd_pcm r8169 mii sdhci_acpi sdhci mmc_core i2c_hid 
> > [last unloaded: i915]
> > [  202.634930] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G U  
> > 4.9.0-rc1-CI-CI_DRM_1734+ #1
> > [  202.634931] Hardware name: GIGABYTE M4HM87P-00/M4HM87P-00, BIOS F6 
> > 12/10/2014
> > [  202.634933]  88011ea03d68 8142dce5 88011ea03db8 
> > 
> > [  202.634934]  88011ea03da8 8107e496 0aa90002 
> > 81e249a0
> > [  202.634935]  81815637 82e7c280  
> > 0004
> > [  202.634936] Call Trace:
> > [  202.634939]  
> > [  202.634939]  [] dump_stack+0x67/0x92
> > [  202.634941]  [] __warn+0xc6/0xe0
> > [  202.634944]  [] ? _raw_spin_unlock_irq+0x27/0x50
> > [  202.634945]  [] warn_slowpath_fmt+0x4a/0x50
> > [  202.634946]  [] trace_hardirqs_on_caller+0x113/0x1b0
> > [  202.634948]  [] trace_hardirqs_on+0xd/0x10
> > [  202.634949]  [] _raw_spin_unlock_irq+0x27/0x50
> > [  202.634951]  [] rtc_handler+0x32/0xa0
> > [  202.634954]  [] acpi_ev_fixed_event_detect+0xd4/0xfb
> > [  202.634956]  [] acpi_ev_sci_xrupt_handler+0xf/0x2d
> > [  202.634957]  [] acpi_irq+0x11/0x2c
> > [  202.634960]  [] __handle_irq_event_percpu+0x58/0x370
> > [  202.634961]  [] handle_irq_event_percpu+0x1e/0x50
> > [  202.634962]  [] handle_irq_event+0x34/0x60
> > [  202.634963]  [] handle_fasteoi_irq+0xa6/0x170
> > [  202.634966]  [] handle_irq+0x15/0x20
> > [  202.634967]  [] do_IRQ+0x68/0x130
> > [  202.634968]  [] common_interrupt+0x89/0x89
> > [  202.634970]  
> > [  202.634970]  [] ? mwait_idle+0x93/0x210
> > [  202.634971]  [] ? mwait_idle+0x8a/0x210
> > [  202.634972]  [] arch_cpu_idle+0xa/0x10
> > [  202.634973]  [] default_idle_call+0x1e/0x30
> > [  202.634974]  [] cpu_startup_entry+0x17c/0x1f0
> > [  202.634976]  [] rest_init+0x127/0x130
> > [  202.634978]  [] start_kernel+0x3f6/0x403
> > [  202.634980]  [] x86_64_start_reservations+0x2a/0x2c
> > [  202.634981]  [] x86_64_start_kernel+0x173/0x186
> > [  202.634982] ---[ end trace 293c99618fa08d34 ]---
> > 
> > Cc: Gabriele Mazzotta 
> > Cc: Alexandre Belloni 
> > Fixes: 983bf1256edb ("rtc: cmos: Clear ACPI-driven alarms upon resume")
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/rtc/rtc-cmos.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> > index dd3d59806ffa..19cd49ad92dc 100644
> > --- a/drivers/rtc/rtc-cmos.c
> > +++ b/drivers/rtc/rtc-cmos.c
> > @@ -996,8 +996,9 @@ static u32 rtc_handler(void *context)
> > struct cmos_rtc *cmos = dev_get_drvdata(dev);
> > unsigned char rtc_control = 0;
> > unsigned char rtc_intr;
> > +   unsigned long flags;
> >  
> > -   spin_lock_irq(_lock);
> > +   spin_lock_irqsave(_lock, flags);
> 
> My reading of the acpi fixed event handlers suggests that this can only
> be called from interrupt context.

Ah, could be. I didn't bother digging quite that deep.

> 
> Anyway using irqsave is correct (just may be optimised away to a plain
> spin_lock() if the condition that this is only called in irq context is
> satisfied).
> 
> Reviewed-by: Chris Wilson 
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gvt: fix return value check

2016-10-19 Thread Patchwork
== Series Details ==

Series: drm/i915/gvt: fix return value check
URL   : https://patchwork.freedesktop.org/series/14033/
State : warning

== Summary ==

Series 14033v1 drm/i915/gvt: fix return value check
https://patchwork.freedesktop.org/api/1.0/series/14033/revisions/1/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-1:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup bad-nb-words-3:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup bad-pipe:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup bad-source:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2600)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:186  pass:160  dwarn:1   dfail:0   fail:1   skip:23 
fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:155  dwarn:29  dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:219  dwarn:4   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2765/

21787266bd182df4c0d2067cf1b5c2379f61c24d drm-intel-nightly: 
2016y-10m-19d-15h-39m-22s UTC integration manifest
933a4c2 drm/i915/gvt: fix return value check

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


Re: [Intel-gfx] [PATCH] rtc: cmos: Don't enable interrupts in the middle of the interrupt handler

2016-10-19 Thread Chris Wilson
On Wed, Oct 19, 2016 at 09:02:04PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Using spin_lock_irq()/spin_unlock_irq() from within the interrupt
> handler is a no-no. Let's save/restore the flags to avoid turning on
> interrupts prematurely.
> 
> We hit this in a bunch of our CI systems, but for whatever reason I
> wasn't able to reproduce on my own machine, so this fix is just
> based on the backtrace.
> 
> [  202.634918] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2729 
> trace_hardirqs_on_caller+0x113/0x1b0
> [  202.634919] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
> [  202.634929] Modules linked in: snd_hda_intel i915 x86_pkg_temp_thermal 
> intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
> lpc_ich snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi 
> snd_hda_codec snd_hwdep i2c_designware_platform i2c_designware_core 
> snd_hda_core mei_me mei snd_pcm r8169 mii sdhci_acpi sdhci mmc_core i2c_hid 
> [last unloaded: i915]
> [  202.634930] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G U  
> 4.9.0-rc1-CI-CI_DRM_1734+ #1
> [  202.634931] Hardware name: GIGABYTE M4HM87P-00/M4HM87P-00, BIOS F6 
> 12/10/2014
> [  202.634933]  88011ea03d68 8142dce5 88011ea03db8 
> 
> [  202.634934]  88011ea03da8 8107e496 0aa90002 
> 81e249a0
> [  202.634935]  81815637 82e7c280  
> 0004
> [  202.634936] Call Trace:
> [  202.634939]  
> [  202.634939]  [] dump_stack+0x67/0x92
> [  202.634941]  [] __warn+0xc6/0xe0
> [  202.634944]  [] ? _raw_spin_unlock_irq+0x27/0x50
> [  202.634945]  [] warn_slowpath_fmt+0x4a/0x50
> [  202.634946]  [] trace_hardirqs_on_caller+0x113/0x1b0
> [  202.634948]  [] trace_hardirqs_on+0xd/0x10
> [  202.634949]  [] _raw_spin_unlock_irq+0x27/0x50
> [  202.634951]  [] rtc_handler+0x32/0xa0
> [  202.634954]  [] acpi_ev_fixed_event_detect+0xd4/0xfb
> [  202.634956]  [] acpi_ev_sci_xrupt_handler+0xf/0x2d
> [  202.634957]  [] acpi_irq+0x11/0x2c
> [  202.634960]  [] __handle_irq_event_percpu+0x58/0x370
> [  202.634961]  [] handle_irq_event_percpu+0x1e/0x50
> [  202.634962]  [] handle_irq_event+0x34/0x60
> [  202.634963]  [] handle_fasteoi_irq+0xa6/0x170
> [  202.634966]  [] handle_irq+0x15/0x20
> [  202.634967]  [] do_IRQ+0x68/0x130
> [  202.634968]  [] common_interrupt+0x89/0x89
> [  202.634970]  
> [  202.634970]  [] ? mwait_idle+0x93/0x210
> [  202.634971]  [] ? mwait_idle+0x8a/0x210
> [  202.634972]  [] arch_cpu_idle+0xa/0x10
> [  202.634973]  [] default_idle_call+0x1e/0x30
> [  202.634974]  [] cpu_startup_entry+0x17c/0x1f0
> [  202.634976]  [] rest_init+0x127/0x130
> [  202.634978]  [] start_kernel+0x3f6/0x403
> [  202.634980]  [] x86_64_start_reservations+0x2a/0x2c
> [  202.634981]  [] x86_64_start_kernel+0x173/0x186
> [  202.634982] ---[ end trace 293c99618fa08d34 ]---
> 
> Cc: Gabriele Mazzotta 
> Cc: Alexandre Belloni 
> Fixes: 983bf1256edb ("rtc: cmos: Clear ACPI-driven alarms upon resume")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/rtc/rtc-cmos.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> index dd3d59806ffa..19cd49ad92dc 100644
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -996,8 +996,9 @@ static u32 rtc_handler(void *context)
>   struct cmos_rtc *cmos = dev_get_drvdata(dev);
>   unsigned char rtc_control = 0;
>   unsigned char rtc_intr;
> + unsigned long flags;
>  
> - spin_lock_irq(_lock);
> + spin_lock_irqsave(_lock, flags);

My reading of the acpi fixed event handlers suggests that this can only
be called from interrupt context.

Anyway using irqsave is correct (just may be optimised away to a plain
spin_lock() if the condition that this is only called in irq context is
satisfied).

Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: STOP_MACHINE is no more, stop selecting it

2016-10-19 Thread Chris Wilson
With the merge of 4.9-rc1, we can say goodbye to having to forcibly
select STOP_MACHINE in order to have a working stop_machine(). The code
just works now and the CONFIG_STOP_MACHINE symbol removed.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index e1b32da8954e..c383684b538f 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -4,7 +4,6 @@ config DRM_I915
depends on X86 && PCI
select INTEL_GTT
select INTERVAL_TREE
-   select STOP_MACHINE
# we need shmfs for the swappable backing store, and in particular
# the shmem_readpage() which depends upon tmpfs
select SHMEM
-- 
2.9.3

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


[Intel-gfx] [PATCH] rtc: cmos: Don't enable interrupts in the middle of the interrupt handler

2016-10-19 Thread ville . syrjala
From: Ville Syrjälä 

Using spin_lock_irq()/spin_unlock_irq() from within the interrupt
handler is a no-no. Let's save/restore the flags to avoid turning on
interrupts prematurely.

We hit this in a bunch of our CI systems, but for whatever reason I
wasn't able to reproduce on my own machine, so this fix is just
based on the backtrace.

[  202.634918] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2729 
trace_hardirqs_on_caller+0x113/0x1b0
[  202.634919] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
[  202.634929] Modules linked in: snd_hda_intel i915 x86_pkg_temp_thermal 
intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
lpc_ich snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi 
snd_hda_codec snd_hwdep i2c_designware_platform i2c_designware_core 
snd_hda_core mei_me mei snd_pcm r8169 mii sdhci_acpi sdhci mmc_core i2c_hid 
[last unloaded: i915]
[  202.634930] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G U  
4.9.0-rc1-CI-CI_DRM_1734+ #1
[  202.634931] Hardware name: GIGABYTE M4HM87P-00/M4HM87P-00, BIOS F6 12/10/2014
[  202.634933]  88011ea03d68 8142dce5 88011ea03db8 

[  202.634934]  88011ea03da8 8107e496 0aa90002 
81e249a0
[  202.634935]  81815637 82e7c280  
0004
[  202.634936] Call Trace:
[  202.634939]  
[  202.634939]  [] dump_stack+0x67/0x92
[  202.634941]  [] __warn+0xc6/0xe0
[  202.634944]  [] ? _raw_spin_unlock_irq+0x27/0x50
[  202.634945]  [] warn_slowpath_fmt+0x4a/0x50
[  202.634946]  [] trace_hardirqs_on_caller+0x113/0x1b0
[  202.634948]  [] trace_hardirqs_on+0xd/0x10
[  202.634949]  [] _raw_spin_unlock_irq+0x27/0x50
[  202.634951]  [] rtc_handler+0x32/0xa0
[  202.634954]  [] acpi_ev_fixed_event_detect+0xd4/0xfb
[  202.634956]  [] acpi_ev_sci_xrupt_handler+0xf/0x2d
[  202.634957]  [] acpi_irq+0x11/0x2c
[  202.634960]  [] __handle_irq_event_percpu+0x58/0x370
[  202.634961]  [] handle_irq_event_percpu+0x1e/0x50
[  202.634962]  [] handle_irq_event+0x34/0x60
[  202.634963]  [] handle_fasteoi_irq+0xa6/0x170
[  202.634966]  [] handle_irq+0x15/0x20
[  202.634967]  [] do_IRQ+0x68/0x130
[  202.634968]  [] common_interrupt+0x89/0x89
[  202.634970]  
[  202.634970]  [] ? mwait_idle+0x93/0x210
[  202.634971]  [] ? mwait_idle+0x8a/0x210
[  202.634972]  [] arch_cpu_idle+0xa/0x10
[  202.634973]  [] default_idle_call+0x1e/0x30
[  202.634974]  [] cpu_startup_entry+0x17c/0x1f0
[  202.634976]  [] rest_init+0x127/0x130
[  202.634978]  [] start_kernel+0x3f6/0x403
[  202.634980]  [] x86_64_start_reservations+0x2a/0x2c
[  202.634981]  [] x86_64_start_kernel+0x173/0x186
[  202.634982] ---[ end trace 293c99618fa08d34 ]---

Cc: Gabriele Mazzotta 
Cc: Alexandre Belloni 
Fixes: 983bf1256edb ("rtc: cmos: Clear ACPI-driven alarms upon resume")
Signed-off-by: Ville Syrjälä 
---
 drivers/rtc/rtc-cmos.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index dd3d59806ffa..19cd49ad92dc 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -996,8 +996,9 @@ static u32 rtc_handler(void *context)
struct cmos_rtc *cmos = dev_get_drvdata(dev);
unsigned char rtc_control = 0;
unsigned char rtc_intr;
+   unsigned long flags;
 
-   spin_lock_irq(_lock);
+   spin_lock_irqsave(_lock, flags);
if (cmos_rtc.suspend_ctrl)
rtc_control = CMOS_READ(RTC_CONTROL);
if (rtc_control & RTC_AIE) {
@@ -1006,7 +1007,7 @@ static u32 rtc_handler(void *context)
rtc_intr = CMOS_READ(RTC_INTR_FLAGS);
rtc_update_irq(cmos->rtc, 1, rtc_intr);
}
-   spin_unlock_irq(_lock);
+   spin_unlock_irqrestore(_lock, flags);
 
pm_wakeup_event(dev, 0);
acpi_clear_event(ACPI_EVENT_RTC);
-- 
2.7.4

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


Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Handle early failure during intel_get_load_detect_pipe

2016-10-19 Thread Chris Wilson
On Wed, Oct 19, 2016 at 05:47:39PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Handle early failure during intel_get_load_detect_pipe
> URL   : https://patchwork.freedesktop.org/series/14016/
> State : warning
> 
> == Summary ==
> 
> Series 14016v1 drm/i915: Handle early failure during 
> intel_get_load_detect_pipe
> https://patchwork.freedesktop.org/api/1.0/series/14016/revisions/1/mbox/
> 
> Test drv_module_reload_basic:
> pass   -> DMESG-WARN (fi-skl-6700hq)
> Test gem_exec_suspend:
> Subgroup basic-s3:
> dmesg-warn -> PASS   (fi-skl-6700hq)
> Test kms_cursor_legacy:
> Subgroup basic-busy-flip-before-cursor-legacy:
> pass   -> DMESG-WARN (fi-ilk-650)
> Test kms_force_connector_basic:
> Subgroup force-load-detect:
> incomplete -> PASS   (fi-byt-j1900)
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-a:
> dmesg-warn -> PASS   (fi-skl-6700hq)
> Subgroup suspend-read-crc-pipe-b:
> dmesg-warn -> PASS   (fi-skl-6700hq)
> incomplete -> PASS   (fi-snb-2600)
> Subgroup suspend-read-crc-pipe-c:
> dmesg-warn -> PASS   (fi-skl-6700hq)
> 
> fi-ilk-650   total:246  pass:159  dwarn:25  dfail:0   fail:2   skip:60 

All the warns are in -nightly, give or take piglit sporadicly assigning the
unrelated warns to individual tests. Too bad it didn't list all the
notrun -> pass, or still doesn't mention the actual oops on
fi-ivb-3720m.

Looks like we don't have a backmerge yet, so this needs to be applied to
drm-misc.

Reviewed-by: Daniel Vetter  (irc)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Handle early failure during intel_get_load_detect_pipe

2016-10-19 Thread Patchwork
== Series Details ==

Series: drm/i915: Handle early failure during intel_get_load_detect_pipe
URL   : https://patchwork.freedesktop.org/series/14016/
State : warning

== Summary ==

Series 14016v1 drm/i915: Handle early failure during intel_get_load_detect_pipe
https://patchwork.freedesktop.org/api/1.0/series/14016/revisions/1/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-skl-6700hq)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_force_connector_basic:
Subgroup force-load-detect:
incomplete -> PASS   (fi-byt-j1900)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-skl-6700hq)
incomplete -> PASS   (fi-snb-2600)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (fi-skl-6700hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:159  dwarn:25  dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2764/

21787266bd182df4c0d2067cf1b5c2379f61c24d drm-intel-nightly: 
2016y-10m-19d-15h-39m-22s UTC integration manifest
9646282 drm/i915: Handle early failure during intel_get_load_detect_pipe

___
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: Enable support for nonblocking modeset.

2016-10-19 Thread Patchwork
== Series Details ==

Series: drm/i915: Enable support for nonblocking modeset.
URL   : https://patchwork.freedesktop.org/series/14026/
State : failure

== Summary ==

Series 14026v1 drm/i915: Enable support for nonblocking modeset.
https://patchwork.freedesktop.org/api/1.0/series/14026/revisions/1/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_force_connector_basic:
Subgroup force-load-detect:
incomplete -> PASS   (fi-byt-j1900)
pass   -> INCOMPLETE (fi-snb-2600)
Test kms_pipe_crc_basic:
Subgroup bad-source:
pass   -> DMESG-WARN (fi-ivb-3770)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:159  dwarn:25  dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:220  dwarn:1   dfail:0   fail:0   skip:25 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:219  dwarn:4   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:186  pass:158  dwarn:0   dfail:0   fail:0   skip:27 
fi-kbl-7200u failed to collect. IGT log at Patchwork_2763/fi-kbl-7200u/igt.log

Results at /archive/results/CI_IGT_test/Patchwork_2763/

21787266bd182df4c0d2067cf1b5c2379f61c24d drm-intel-nightly: 
2016y-10m-19d-15h-39m-22s UTC integration manifest
c7a17a0 drm/i915: Enable support for nonblocking modeset
e2737d1 drm/i915: Pass atomic state to verify_connector_state
7755c7a drm/i915: Update atomic modeset state synchronously
0244ff6 drm/edid: Remove drm_select_eld
58fffa7 drm/i915: Pass atomic state to intel_audio_codec_enable
cdd07ea drm/i915: Convert intel_hdmi to use atomic state

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


Re: [Intel-gfx] [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

2016-10-19 Thread Dave Hansen
On 10/19/2016 10:01 AM, Michal Hocko wrote:
> The question I had earlier was whether this has to be an explicit FOLL
> flag used by g-u-p users or we can just use it internally when mm !=
> current->mm

The reason I chose not to do that was that deferred work gets run under
a basically random 'current'.  If we just use 'mm != current->mm', then
the deferred work will sometimes have pkeys enforced and sometimes not,
basically randomly.

We want to be consistent with whether they are enforced or not, so we
explicitly indicate that by calling the remote variant vs. plain.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status

2016-10-19 Thread Ville Syrjälä
On Tue, Sep 06, 2016 at 05:43:44PM +0300, Ville Syrjälä wrote:
> On Sat, Aug 27, 2016 at 02:33:25PM +0100, Matthew Auld wrote:
> > Currently it's entirely possible to go through the link training step
> > without first determining the lane_count, which is silly since we end up
> > doing a bunch of aux transfers of size = 0, as highlighted by
> > WARN_ON(!msg->buffer != !msg->size), and can only ever result in a
> > 'failed to update link training' message. This can be observed during
> > intel_dp_long_pulse where we can do the link training step, but before
> > we have had a chance to set the link params. To avoid this we add an
> > extra check for the lane_count in intel_dp_check_link_status, which
> > should prevent us from doing the link training step prematurely.
> > 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=97344
> > Cc: Jani Nikula 
> > Signed-off-by: Matthew Auld 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index a3c7dd8..0dbb672 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3927,6 +3927,9 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
> > if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> > return;
> >  
> > +   if (!intel_dp->lane_count)
> > +   return;
> 
> This pretty much amounts to the same thing that I did with 'active_streams' 
> in 
> my series [1]. The problem is that we need to sync up the state on readout to
> make it really work. Daniel wasn't too happy with my .sync_state() hook, so
> maybe we need something fancier.
> 
> [1] https://patchwork.freedesktop.org/series/10354/

So, looking at some recent logs I see we may hit this WARN spew a *lot*.
So we probably want this patch as a temporary measure. Maybe with
WARN_ONCE() + a comment, eg.

 /*
  * FIXME need to synchronize this sort of
  * stuff properly with hardware readout.
  */

?

> 
> > +
> > /* if link training is requested we should perform it always */
> > if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) ||
> > (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
> > -- 
> > 2.7.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

2016-10-19 Thread Michal Hocko
On Wed 19-10-16 09:49:43, Dave Hansen wrote:
> On 10/19/2016 02:07 AM, Michal Hocko wrote:
> > On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote:
> >> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
> >>> I am wondering whether we can go further. E.g. it is not really clear to
> >>> me whether we need an explicit FOLL_REMOTE when we can in fact check
> >>> mm != current->mm and imply that. Maybe there are some contexts which
> >>> wouldn't work, I haven't checked.
> >>
> >> This flag is set even when /proc/self/mem is used. I've not looked deeply 
> >> into
> >> this flag but perhaps accessing your own memory this way can be considered
> >> 'remote' since you're not accessing it directly. On the other hand, 
> >> perhaps this
> >> is just mistaken in this case?
> > 
> > My understanding of the flag is quite limited as well. All I know it is
> > related to protection keys and it is needed to bypass protection check.
> > See arch_vma_access_permitted. See also 1b2ee1266ea6 ("mm/core: Do not
> > enforce PKEY permissions on remote mm access").
> 
> Yeah, we need the flag to tell us when PKEYs should be applied or not.
> The current task's PKRU (pkey rights register) should really only be
> used to impact access to the task's memory, but has no bearing on how a
> given task should access remote memory.

The question I had earlier was whether this has to be an explicit FOLL
flag used by g-u-p users or we can just use it internally when mm !=
current->mm

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for Broxton ddi phy refactoring (rev5)

2016-10-19 Thread Patchwork
== Series Details ==

Series: Broxton ddi phy refactoring (rev5)
URL   : https://patchwork.freedesktop.org/series/13320/
State : failure

== Summary ==

Series 13320v5 Broxton ddi phy refactoring
https://patchwork.freedesktop.org/api/1.0/series/13320/revisions/5/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-skl-6700hq)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_force_connector_basic:
Subgroup force-load-detect:
incomplete -> PASS   (fi-byt-j1900)
pass   -> INCOMPLETE (fi-ivb-3770)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (fi-skl-6700hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:159  dwarn:25  dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:186  pass:164  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:209  pass:176  dwarn:0   dfail:0   fail:0   skip:32 

Results at /archive/results/CI_IGT_test/Patchwork_2762/

21787266bd182df4c0d2067cf1b5c2379f61c24d drm-intel-nightly: 
2016y-10m-19d-15h-39m-22s UTC integration manifest
b7c7077 drm/i915: Address broxton phy registers based on phy and channel number
88ab5e1 drm/i915: Add location of the Rcomp resistor to bxt_ddi_phy_info
12c0f43 drm/i915: Create a struct to hold information about the broxton phys
6e830b9 drm/i915: Move broxton vswing sequence to intel_dpio_phy.c
df0c1d2 drm/i915: Move DPIO phy documentation section to intel_dpio_phy.c
421e554 drm/i915: Move broxton phy code to intel_dpio_phy.c
125da91 drm/i915: Pass lane count to bxt_ddi_phy_calc_lane_optmin_mask()
cf9f51f drm/i915: Explicitly map broxton DPIO power wells to phys
8f7b31c drm/i915: Rename struct i915_power_well field data to id

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


Re: [Intel-gfx] [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

2016-10-19 Thread Dave Hansen
On 10/19/2016 02:07 AM, Michal Hocko wrote:
> On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote:
>> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
>>> I am wondering whether we can go further. E.g. it is not really clear to
>>> me whether we need an explicit FOLL_REMOTE when we can in fact check
>>> mm != current->mm and imply that. Maybe there are some contexts which
>>> wouldn't work, I haven't checked.
>>
>> This flag is set even when /proc/self/mem is used. I've not looked deeply 
>> into
>> this flag but perhaps accessing your own memory this way can be considered
>> 'remote' since you're not accessing it directly. On the other hand, perhaps 
>> this
>> is just mistaken in this case?
> 
> My understanding of the flag is quite limited as well. All I know it is
> related to protection keys and it is needed to bypass protection check.
> See arch_vma_access_permitted. See also 1b2ee1266ea6 ("mm/core: Do not
> enforce PKEY permissions on remote mm access").

Yeah, we need the flag to tell us when PKEYs should be applied or not.
The current task's PKRU (pkey rights register) should really only be
used to impact access to the task's memory, but has no bearing on how a
given task should access remote memory.

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


Re: [Intel-gfx] [PATCH] drm/i915: Add i915 perf infrastructure

2016-10-19 Thread Robert Bragg
On Wed, Oct 12, 2016 at 12:41 PM, Joonas Lahtinen <
joonas.lahti...@linux.intel.com> wrote:

> On ti, 2016-10-11 at 12:03 -0700, Robert Bragg wrote:
> > > > +   case DRM_I915_PERF_PROP_MAX:
> > > > +   BUG();
> > >
> > > We already handle this case above, but I guess we still need this in
> > > order to silence gcc...
> >
> > right, and preferable to having a default: case, for the future compiler
> warning to handle any new properties here.
>
> Please, do use MISSING_CASE instead. Daniel is known to get upset for
> far less ;)
>
> Generally consensus is that BUG() is used only when there're no other
> options to back out.
>

thanks for this pointer.

I'll add a default: with MISSING_CASE as that looks like an i915-specific
convention; though it seems like a real shame to defer missing case issues
to runtime errors instead of taking advantage of the compiler complaining
at build time that a case has been forgotten.

Thanks,
- Robert



>
> 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] [PATCH -next] drm/i915/gvt: fix return value check

2016-10-19 Thread Wei Yongjun
From: Wei Yongjun 

In case of error, the function i915_gem_object_create() returns
ERR_PTR() not NULL. The NULL test in the return value check should
be replaced with IS_ERR().

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/i915/gvt/cmd_parser.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index 5808ee7..6abb2a6 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -1640,8 +1640,8 @@ static int perform_bb_shadow(struct parser_exec_state *s)
 
entry_obj->obj = i915_gem_object_create(&(s->vgpu->gvt->dev_priv->drm),
round_up(bb_size, PAGE_SIZE));
-   if (entry_obj->obj == NULL)
-   return -ENOMEM;
+   if (IS_ERR(entry_obj->obj))
+   return PTR_ERR(entry_obj->obj);
entry_obj->len = bb_size;
INIT_LIST_HEAD(_obj->list);
 
@@ -2712,8 +2712,8 @@ static int shadow_indirect_ctx(struct intel_shadow_wa_ctx 
*wa_ctx)
 
wa_ctx->indirect_ctx.obj = i915_gem_object_create(dev,
round_up(ctx_size + CACHELINE_BYTES, PAGE_SIZE));
-   if (wa_ctx->indirect_ctx.obj == NULL)
-   return -ENOMEM;
+   if (IS_ERR(wa_ctx->indirect_ctx.obj))
+   return PTR_ERR(wa_ctx->indirect_ctx.obj);
 
ret = i915_gem_object_get_pages(wa_ctx->indirect_ctx.obj);
if (ret)

___
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: Stop reporting error details in dmesg as well as the error-state

2016-10-19 Thread Patchwork
== Series Details ==

Series: drm/i915: Stop reporting error details in dmesg as well as the 
error-state
URL   : https://patchwork.freedesktop.org/series/14021/
State : failure

== Summary ==

Series 14021v1 drm/i915: Stop reporting error details in dmesg as well as the 
error-state
https://patchwork.freedesktop.org/api/1.0/series/14021/revisions/1/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-skl-6770hq)
dmesg-warn -> PASS   (fi-skl-6700hq)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-6700hq)
fail   -> DMESG-WARN (fi-ilk-650)
incomplete -> PASS   (fi-snb-2520m)
Test kms_busy:
Subgroup basic-flip-default-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-default-b:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-busy-flip-before-cursor-varying-size:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-after-cursor-legacy:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-after-cursor-varying-size:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-before-cursor-varying-size:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_force_connector_basic:
Subgroup force-load-detect:
incomplete -> PASS   (fi-ivb-3770)
incomplete -> PASS   (fi-byt-j1900)
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> FAIL   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup hang-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-skl-6700hq)
fail   -> DMESG-WARN (fi-ilk-650)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-skl-6700hq)
fail   -> DMESG-WARN (fi-ilk-650)
pass   -> INCOMPLETE (fi-snb-2600)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-skl-6700hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:209  pass:178  dwarn:1   dfail:0   fail:1   skip:28 
fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:159  dwarn:25  dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:219  dwarn:4   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:229  dwarn:2   dfail:0   fail:1   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Update kerneldoc for intel_dpll_mgr.c

2016-10-19 Thread Jani Nikula
On Wed, 19 Oct 2016, Ander Conselvan De Oliveira  wrote:
> On Thu, 2016-10-13 at 15:46 +0200, Daniel Vetter wrote:
>> > +  /**
>> > +   * @hw_state: hardware configuration for the DPLL.
>> "... stored in struct _dpll_hw_state." - I love my hyperlinks ;-)
>
> I'll add that, but I think it's silly. The type of the field is struct
> intel_dpll_hw_state, so I think it would be more natural if the documentation
> tool would add that link automatically.

Agreed.

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: Fix LSPCON kernel-doc

2016-10-19 Thread Jani Nikula
On Wed, 19 Oct 2016, Ville Syrjälä  wrote:
> On Wed, Oct 19, 2016 at 03:08:04PM +0300, Jani Nikula wrote:
>> Fix warnings on building htmldocs.
>> 
>> v2: whitespace around '/' (Ville)
>> 
>> Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
>> Cc: Rodrigo Vivi 
>> Cc: Shashank Sharma 
>> Cc: 
>> Signed-off-by: Jani Nikula 
>
> lgtm
> Reviewed-by: Ville Syrjälä 

Pushed to drm-intel-next-queued, thanks for the review.

BR,
Jani.

>
>> 
>> ---
>> 
>> n.b. 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") has
>> been merged via drm-intel tree
>> ---
>>  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 14 +++---
>>  include/drm/drm_dp_dual_mode_helper.h | 15 ---
>>  2 files changed, 15 insertions(+), 14 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
>> b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
>> index 2624e266abbd..488355bdafb9 100644
>> --- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
>> @@ -377,9 +377,9 @@ EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);
>>  
>>  /**
>>   * drm_lspcon_get_mode: Get LSPCON's current mode of operation by
>> - * by reading offset (0x80, 0x41)
>> - * @i2c_adapter: I2C-over-aux adapter
>> - * @current_mode: out vaiable, current lspcon mode of operation
>> + * reading offset (0x80, 0x41)
>> + * @adapter: I2C-over-aux adapter
>> + * @mode: current lspcon mode of operation output variable
>>   *
>>   * Returns:
>>   * 0 on success, sets the current_mode value to appropriate mode
>> @@ -413,10 +413,10 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
>>  EXPORT_SYMBOL(drm_lspcon_get_mode);
>>  
>>  /**
>> - * drm_lspcon_change_mode: Change LSPCON's mode of operation by
>> - * by writing offset (0x80, 0x40)
>> - * @i2c_adapter: I2C-over-aux adapter
>> - * @reqd_mode: required mode of operation
>> + * drm_lspcon_set_mode: Change LSPCON's mode of operation by
>> + * writing offset (0x80, 0x40)
>> + * @adapter: I2C-over-aux adapter
>> + * @mode: required mode of operation
>>   *
>>   * Returns:
>>   * 0 on success, -error on failure/timeout
>> diff --git a/include/drm/drm_dp_dual_mode_helper.h 
>> b/include/drm/drm_dp_dual_mode_helper.h
>> index 55677704add8..4c42db81fcb4 100644
>> --- a/include/drm/drm_dp_dual_mode_helper.h
>> +++ b/include/drm/drm_dp_dual_mode_helper.h
>> @@ -70,12 +70,13 @@ ssize_t drm_dp_dual_mode_write(struct i2c_adapter 
>> *adapter,
>> u8 offset, const void *buffer, size_t size);
>>  
>>  /**
>> -* enum drm_lspcon_mode
>> -* @lspcon_mode_ls: Level shifter mode of LSPCON
>> -*   which drives DP++ to HDMI 1.4 conversion.
>> -* @lspcon_mode_pcon: Protocol converter mode of LSPCON
>> -*   which drives DP++ to HDMI 2.0 active conversion.
>> -*/
>> + * enum drm_lspcon_mode
>> + * @DRM_LSPCON_MODE_INVALID: No LSPCON.
>> + * @DRM_LSPCON_MODE_LS: Level shifter mode of LSPCON
>> + *  which drives DP++ to HDMI 1.4 conversion.
>> + * @DRM_LSPCON_MODE_PCON: Protocol converter mode of LSPCON
>> + *  which drives DP++ to HDMI 2.0 active conversion.
>> + */
>>  enum drm_lspcon_mode {
>>  DRM_LSPCON_MODE_INVALID,
>>  DRM_LSPCON_MODE_LS,
>> @@ -90,7 +91,7 @@ enum drm_lspcon_mode {
>>   * @DRM_DP_DUAL_MODE_TYPE1_HDMI: Type 1 HDMI adaptor
>>   * @DRM_DP_DUAL_MODE_TYPE2_DVI: Type 2 DVI adaptor
>>   * @DRM_DP_DUAL_MODE_TYPE2_HDMI: Type 2 HDMI adaptor
>> - * @DRM_DP_DUAL_MODE_TYPE2_LSPCON: Level shifter /protocol converter
>> + * @DRM_DP_DUAL_MODE_LSPCON: Level shifter / protocol converter
>>   */
>>  enum drm_dp_dual_mode_type {
>>  DRM_DP_DUAL_MODE_NONE,
>> -- 
>> 2.1.4

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


Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Fix LSPCON kernel-doc (rev2)

2016-10-19 Thread Jani Nikula
On Wed, 19 Oct 2016, Patchwork  wrote:
> == Series Details ==
>
> Series: drm: Fix LSPCON kernel-doc (rev2)
> URL   : https://patchwork.freedesktop.org/series/14017/
> State : failure
>
> == Summary ==
>
> Series 14017v2 drm: Fix LSPCON kernel-doc
> https://patchwork.freedesktop.org/api/1.0/series/14017/revisions/2/mbox/
>
> Test gem_exec_suspend:
> Subgroup basic-s3:
> incomplete -> PASS   (fi-snb-2520m)
> fail   -> DMESG-WARN (fi-ilk-650)
> Test kms_busy:
> Subgroup basic-flip-default-a:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup basic-flip-default-b:
> pass   -> DMESG-WARN (fi-ilk-650)
> Test kms_cursor_legacy:
> Subgroup basic-busy-flip-before-cursor-legacy:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup basic-busy-flip-before-cursor-varying-size:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup basic-flip-after-cursor-legacy:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup basic-flip-after-cursor-varying-size:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup basic-flip-before-cursor-legacy:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup basic-flip-before-cursor-varying-size:
> pass   -> DMESG-WARN (fi-ilk-650)
> Test kms_flip:
> Subgroup basic-flip-vs-dpms:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup basic-flip-vs-modeset:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup basic-flip-vs-wf_vblank:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup basic-plain-flip:
> pass   -> DMESG-WARN (fi-ilk-650)
> Test kms_force_connector_basic:
> Subgroup force-load-detect:
> incomplete -> PASS   (fi-ivb-3770)
> incomplete -> PASS   (fi-byt-j1900)
> Test kms_pipe_crc_basic:
> Subgroup hang-read-crc-pipe-a:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup hang-read-crc-pipe-b:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup nonblocking-crc-pipe-a:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup nonblocking-crc-pipe-a-frame-sequence:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup nonblocking-crc-pipe-b:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup nonblocking-crc-pipe-b-frame-sequence:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup read-crc-pipe-a:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup read-crc-pipe-a-frame-sequence:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup read-crc-pipe-b:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup read-crc-pipe-b-frame-sequence:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup suspend-read-crc-pipe-a:
> fail   -> DMESG-WARN (fi-ilk-650)
> Subgroup suspend-read-crc-pipe-b:
> pass   -> INCOMPLETE (fi-snb-2600)
> fail   -> PASS   (fi-ilk-650)

ilk on an underrun spree. Funny how a comments only change causes
that. :/

J.


>
> fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
> fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42 
> fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
> fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31 
> fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
> fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
> fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
> fi-ilk-650   total:246  pass:160  dwarn:24  dfail:0   fail:2   skip:60 
> fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
> fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
> fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
> fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
> fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
> fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
> fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
> fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
> fi-snb-2600  total:209  pass:176  dwarn:0   dfail:0   fail:0   skip:32 
>
> Results at /archive/results/CI_IGT_test/Patchwork_2760/
>
> d5cbeba648bec880aa0e1f7a531e684499a079a7 drm-intel-nightly: 
> 2016y-10m-19d-11h-13m-08s UTC integration manifest
> 827d5ad drm: Fix LSPCON kernel-doc
>

-- 
Jani Nikula, Intel Open Source 

Re: [Intel-gfx] [PATCH 1/2] shmem: Support for registration of Driver/file owner specific ops

2016-10-19 Thread akash goel
On Thu, Mar 24, 2016 at 5:41 PM, Joonas Lahtinen
 wrote:
> On ke, 2016-03-23 at 11:39 +0530, akash.g...@intel.com wrote:
>> From: Chris Wilson 
>>
>> This provides support for the Drivers or shmem file owners to register
>> a set of callbacks, which can be invoked from the address space operations
>> methods implemented by shmem.
>> This allow the file owners to hook into the shmem address space operations
>> to do some extra/custom operations in addition to the default ones.
>>
>> The private_data field of address_space struct is used to store the pointer
>> to driver specific ops.
>> Currently only one ops field is defined, which is migratepage, but can be
>> extended on need basis.
>>
>> The need for driver specific operations arises since some of the operations
>> (like migratepage) may not be handled completely within shmem, so as to be
>> effective, and would need some driver specific handling also.
>>
>> Specifically, i915.ko would like to participate in migratepage().
>> i915.ko uses shmemfs to provide swappable backing storage for its user
>> objects, but when those objects are in use by the GPU it must pin the entire
>> object until the GPU is idle. As a result, large chunks of memory can be
>> arbitrarily withdrawn from page migration, resulting in premature
>> out-of-memory due to fragmentation. However, if i915.ko can receive the
>> migratepage() request, it can then flush the object from the GPU, remove
>> its pin and thus enable the migration.
>>
>> Since Gfx allocations are one of the major consumer of system memory, its
>> imperative to have such a mechanism to effectively deal with fragmentation.
>> And therefore the need for such a provision for initiating driver specific
>> actions during address space operations.
>>
>> Cc: Hugh Dickins 
>> Cc: linux...@kvack.org
>> Signed-off-by: Sourab Gupta 
>> Signed-off-by: Akash Goel 
>> ---
>>  include/linux/shmem_fs.h | 17 +
>>  mm/shmem.c   | 17 -
>>  2 files changed, 33 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
>> index 4d4780c..6cfa76a 100644
>> --- a/include/linux/shmem_fs.h
>> +++ b/include/linux/shmem_fs.h
>> @@ -34,11 +34,28 @@ struct shmem_sb_info {
>>   struct mempolicy *mpol; /* default memory policy for mappings */
>>  };
>>
>> +struct shmem_dev_info {
>> + void *dev_private_data;
>> + int (*dev_migratepage)(struct address_space *mapping,
>> +struct page *newpage, struct page *page,
>> +enum migrate_mode mode, void *dev_priv_data);
>
> One might want to have a separate shmem_dev_operations struct or
> similar.
>
Sorry for the very late turnaround.

Sorry couldn't get your point here. Are you suggesting to rename the
structure to shmem_dev_operations ?

>> +};
>> +
>>  static inline struct shmem_inode_info *SHMEM_I(struct inode *inode)
>>  {
>>   return container_of(inode, struct shmem_inode_info, vfs_inode);
>>  }
>>
>> +static inline int shmem_set_device_ops(struct address_space *mapping,
>> + struct shmem_dev_info *info)
>> +{
>> + if (mapping->private_data != NULL)
>> + return -EEXIST;
>> +
>
> I did a quick random peek and most set functions are just void and
> override existing data. I'd suggest the same.
>
>> + mapping->private_data = info;
>
Fine will change the return type to void and remove the check.

> Also, doesn't this kinda steal the mapping->private_data, might that be
> unexpected for the user? I notice currently it's not being touched at
> all.
>
Sorry by User do you mean the shmem client who called shmem_file_setup() ?
It seems clients are not expected to touch mapping->private_data and
so shmemfs can safely use it.

Best regards
Akash

>> + return 0;
>> +}
>> +
>>  /*
>>   * Functions in mm/shmem.c called directly from elsewhere:
>>   */
>> diff --git a/mm/shmem.c b/mm/shmem.c
>> index 440e2a7..f8625c4 100644
>> --- a/mm/shmem.c
>> +++ b/mm/shmem.c
>> @@ -952,6 +952,21 @@ redirty:
>>   return 0;
>>  }
>>
>> +#ifdef CONFIG_MIGRATION
>> +static int shmem_migratepage(struct address_space *mapping,
>> +  struct page *newpage, struct page *page,
>> +  enum migrate_mode mode)
>> +{
>> + struct shmem_dev_info *dev_info = mapping->private_data;
>> +
>> + if (dev_info && dev_info->dev_migratepage)
>> + return dev_info->dev_migratepage(mapping, newpage, page,
>> + mode, dev_info->dev_private_data);
>> +
>> + return migrate_page(mapping, newpage, page, mode);
>> +}
>> +#endif
>> +
>>  #ifdef CONFIG_NUMA
>>  #ifdef CONFIG_TMPFS
>>  static void shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
>> @@ -3168,7 +3183,7 @@ static const struct address_space_operations 
>> 

Re: [Intel-gfx] [PATCH RESEND 9/9] drm/i915: set proper N/M in modeset

2016-10-19 Thread Jani Nikula

Sorry it's taken me forever to get back to this. Some comments inline.

BR,
Jani.

On Wed, 12 Oct 2016, "Yang, Libin"  wrote:
>> -Original Message-
>> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>> Lin, Mengdong
>> Sent: Wednesday, October 12, 2016 10:46 AM
>> To: Nikula, Jani ; intel-gfx@lists.freedesktop.org
>> Cc: Nikula, Jani ; libin.y...@linux.intel.com;
>> Pandiyan, Dhinakaran 
>> Subject: Re: [Intel-gfx] [PATCH RESEND 9/9] drm/i915: set proper N/M in
>> modeset
>> 
>> 
>> 
>> > -Original Message-
>> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
>> > Behalf Of Jani Nikula
>> > Sent: Monday, October 10, 2016 11:04 PM
>> > To: intel-gfx@lists.freedesktop.org
>> > Cc: Nikula, Jani ; libin.y...@linux.intel.com;
>> > Pandiyan, Dhinakaran 
>> > Subject: [Intel-gfx] [PATCH RESEND 9/9] drm/i915: set proper N/M in
>> > modeset
>> >
>> > When modeset occurs and the LS_CLK is set to some special values in DP
>> > mode, the N/M need to be set manually if audio is playing. Otherwise
>> > the first several seconds may be silent in audio playback.
>> >
>> > The relationship of Maud and Naud is expressed in the following equation:
>> > Maud/Naud = 512 * fs / f_LS_Clk
>> >
>> > Please refer VESA DisplayPort Standard spec for details.
>> >
>> > Signed-off-by: Libin Yang 
>> > Signed-off-by: Jani Nikula 
>> > ---
>> >  drivers/gpu/drm/i915/i915_reg.h|   7 +++
>> >  drivers/gpu/drm/i915/intel_audio.c | 100
>> > -
>> >  2 files changed, 105 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> > b/drivers/gpu/drm/i915/i915_reg.h index 595d196f753f..8d9dbc7d5b32
>> > 100644
>> > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > @@ -7359,6 +7359,13 @@ enum {
>> >  #define _HSW_AUD_MISC_CTRL_B  0x65110
>> >  #define HSW_AUD_MISC_CTRL(pipe)   _MMIO_PIPE(pipe,
>> > _HSW_AUD_MISC_CTRL_A, _HSW_AUD_MISC_CTRL_B)
>> >
>> > +#define _HSW_AUD_M_CTS_ENABLE_A   0x65028
>> > +#define _HSW_AUD_M_CTS_ENABLE_B   0x65128
>> > +#define HSW_AUD_M_CTS_ENABLE(pipe)_MMIO_PIPE(pipe,
>> > _HSW_AUD_M_CTS_ENABLE_A, _HSW_AUD_M_CTS_ENABLE_B)
>> > +#define   AUD_M_CTS_M_VALUE_INDEX (1 << 21)
>> > +#define   AUD_M_CTS_M_PROG_ENABLE (1 << 20)
>> > +#define   AUD_CONFIG_M_MASK   0xf
>> 
>> The last line cause misalignment after applying the patch.
>> 
>> > +
>> >  #define _HSW_AUD_DIP_ELD_CTRL_ST_A0x650b4
>> >  #define _HSW_AUD_DIP_ELD_CTRL_ST_B0x651b4
>> >  #define HSW_AUD_DIP_ELD_CTRL(pipe)_MMIO_PIPE(pipe,
>> > _HSW_AUD_DIP_ELD_CTRL_ST_A, _HSW_AUD_DIP_ELD_CTRL_ST_B) diff --
>> git
>> > a/drivers/gpu/drm/i915/intel_audio.c
>> > b/drivers/gpu/drm/i915/intel_audio.c
>> > index 81df29ca4947..0bc2701b6c9c 100644
>> > --- a/drivers/gpu/drm/i915/intel_audio.c
>> > +++ b/drivers/gpu/drm/i915/intel_audio.c
>> > @@ -57,6 +57,70 @@
>> >   * struct _audio_component_audio_ops @audio_ops is called from
>> > i915 driver.
>> >   */
>> >
>> > +/* DP N/M table */
>> > +#define LC_540M 54
>> > +#define LC_270M 27
>> > +#define LC_162M 162000
>> > +
>> > +struct dp_aud_n_m {
>> > +  int sample_rate;
>> > +  int clock;
>> > +  u16 n;
>> > +  u16 m;
>> > +};
>> > +
>> > +static const struct dp_aud_n_m dp_aud_n_m[] = {
>> > +  { 192000, LC_540M, 5625, 1024 },
>> > +  { 176400, LC_540M, 9375, 1568 },
>> > +  { 96000, LC_540M, 5625, 512 },
>> > +  { 88200, LC_540M, 9375, 784 },
>> > +  { 48000, LC_540M, 5625, 256 },
>> > +  { 44100, LC_540M, 9375, 392 },
>> > +  { 32000, LC_540M, 16875, 512 },

Any particular reason these M/N values are half of what they're in table
2-104 of DP 1.4 spec? (Admittedly the table is an informative example.)

>> > +  { 192000, LC_270M, 5625, 2048 },
>> > +  { 176400, LC_270M, 9375, 3136 },
>> > +  { 96000, LC_270M, 5625, 1024 },
>> > +  { 88200, LC_270M, 9375, 1568 },
>> > +  { 48000, LC_270M, 5625, 512 },
>> > +  { 44100, LC_270M, 9375, 784 },
>> > +  { 32000, LC_270M, 16875, 1024 },
>> > +  { 192000, LC_162M, 3375, 2048 },
>> > +  { 176400, LC_162M, 5625, 3136 },
>> > +  { 96000, LC_162M, 3375, 1024 },
>> > +  { 88200, LC_162M, 5625, 1568 },
>> > +  { 48000, LC_162M, 3375, 512 },
>> > +  { 44100, LC_162M, 5625, 784 },
>> > +  { 32000, LC_162M, 10125, 1024 },

Do we not support 128 or 64 kHz audio?

>> > +};
>> > +
>> > +static const struct dp_aud_n_m *
>> > +audio_config_dp_get_n_m(struct intel_crtc *intel_crtc, int rate) {
>> > +  int i;
>> > +
>> > +  for (i = 0; i < ARRAY_SIZE(dp_aud_n_m); i++) {
>> > +  if (rate == dp_aud_n_m[i].sample_rate &&
>> > +  intel_crtc->config->port_clock == dp_aud_n_m[i].clock)
>> > +  return _aud_n_m[i];

Re: [Intel-gfx] [PATCH] drm: Fix LSPCON kernel-doc

2016-10-19 Thread Ville Syrjälä
On Wed, Oct 19, 2016 at 03:08:04PM +0300, Jani Nikula wrote:
> Fix warnings on building htmldocs.
> 
> v2: whitespace around '/' (Ville)
> 
> Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
> Cc: Rodrigo Vivi 
> Cc: Shashank Sharma 
> Cc: 
> Signed-off-by: Jani Nikula 

lgtm
Reviewed-by: Ville Syrjälä 

> 
> ---
> 
> n.b. 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") has
> been merged via drm-intel tree
> ---
>  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 14 +++---
>  include/drm/drm_dp_dual_mode_helper.h | 15 ---
>  2 files changed, 15 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
> b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> index 2624e266abbd..488355bdafb9 100644
> --- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> @@ -377,9 +377,9 @@ EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);
>  
>  /**
>   * drm_lspcon_get_mode: Get LSPCON's current mode of operation by
> - * by reading offset (0x80, 0x41)
> - * @i2c_adapter: I2C-over-aux adapter
> - * @current_mode: out vaiable, current lspcon mode of operation
> + * reading offset (0x80, 0x41)
> + * @adapter: I2C-over-aux adapter
> + * @mode: current lspcon mode of operation output variable
>   *
>   * Returns:
>   * 0 on success, sets the current_mode value to appropriate mode
> @@ -413,10 +413,10 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
>  EXPORT_SYMBOL(drm_lspcon_get_mode);
>  
>  /**
> - * drm_lspcon_change_mode: Change LSPCON's mode of operation by
> - * by writing offset (0x80, 0x40)
> - * @i2c_adapter: I2C-over-aux adapter
> - * @reqd_mode: required mode of operation
> + * drm_lspcon_set_mode: Change LSPCON's mode of operation by
> + * writing offset (0x80, 0x40)
> + * @adapter: I2C-over-aux adapter
> + * @mode: required mode of operation
>   *
>   * Returns:
>   * 0 on success, -error on failure/timeout
> diff --git a/include/drm/drm_dp_dual_mode_helper.h 
> b/include/drm/drm_dp_dual_mode_helper.h
> index 55677704add8..4c42db81fcb4 100644
> --- a/include/drm/drm_dp_dual_mode_helper.h
> +++ b/include/drm/drm_dp_dual_mode_helper.h
> @@ -70,12 +70,13 @@ ssize_t drm_dp_dual_mode_write(struct i2c_adapter 
> *adapter,
>  u8 offset, const void *buffer, size_t size);
>  
>  /**
> -* enum drm_lspcon_mode
> -* @lspcon_mode_ls: Level shifter mode of LSPCON
> -*which drives DP++ to HDMI 1.4 conversion.
> -* @lspcon_mode_pcon: Protocol converter mode of LSPCON
> -*which drives DP++ to HDMI 2.0 active conversion.
> -*/
> + * enum drm_lspcon_mode
> + * @DRM_LSPCON_MODE_INVALID: No LSPCON.
> + * @DRM_LSPCON_MODE_LS: Level shifter mode of LSPCON
> + *   which drives DP++ to HDMI 1.4 conversion.
> + * @DRM_LSPCON_MODE_PCON: Protocol converter mode of LSPCON
> + *   which drives DP++ to HDMI 2.0 active conversion.
> + */
>  enum drm_lspcon_mode {
>   DRM_LSPCON_MODE_INVALID,
>   DRM_LSPCON_MODE_LS,
> @@ -90,7 +91,7 @@ enum drm_lspcon_mode {
>   * @DRM_DP_DUAL_MODE_TYPE1_HDMI: Type 1 HDMI adaptor
>   * @DRM_DP_DUAL_MODE_TYPE2_DVI: Type 2 DVI adaptor
>   * @DRM_DP_DUAL_MODE_TYPE2_HDMI: Type 2 HDMI adaptor
> - * @DRM_DP_DUAL_MODE_TYPE2_LSPCON: Level shifter /protocol converter
> + * @DRM_DP_DUAL_MODE_LSPCON: Level shifter / protocol converter
>   */
>  enum drm_dp_dual_mode_type {
>   DRM_DP_DUAL_MODE_NONE,
> -- 
> 2.1.4

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Fix LSPCON kernel-doc (rev2)

2016-10-19 Thread Patchwork
== Series Details ==

Series: drm: Fix LSPCON kernel-doc (rev2)
URL   : https://patchwork.freedesktop.org/series/14017/
State : failure

== Summary ==

Series 14017v2 drm: Fix LSPCON kernel-doc
https://patchwork.freedesktop.org/api/1.0/series/14017/revisions/2/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-snb-2520m)
fail   -> DMESG-WARN (fi-ilk-650)
Test kms_busy:
Subgroup basic-flip-default-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-default-b:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-busy-flip-before-cursor-varying-size:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-after-cursor-legacy:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-after-cursor-varying-size:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-before-cursor-varying-size:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_force_connector_basic:
Subgroup force-load-detect:
incomplete -> PASS   (fi-ivb-3770)
incomplete -> PASS   (fi-byt-j1900)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup hang-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup suspend-read-crc-pipe-a:
fail   -> DMESG-WARN (fi-ilk-650)
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2600)
fail   -> PASS   (fi-ilk-650)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:160  dwarn:24  dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:209  pass:176  dwarn:0   dfail:0   fail:0   skip:32 

Results at /archive/results/CI_IGT_test/Patchwork_2760/

d5cbeba648bec880aa0e1f7a531e684499a079a7 drm-intel-nightly: 
2016y-10m-19d-11h-13m-08s UTC integration manifest
827d5ad drm: Fix LSPCON kernel-doc

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


[Intel-gfx] [PATCH igt] igt/gem_tiled_pread_basic: Only print the erroneous location

2016-10-19 Thread Chris Wilson
Emitting a debug message for every pixel tested takes us from 0.4s to 20s
on an old Core2.

Signed-off-by: Chris Wilson 
---
 tests/gem_tiled_pread_basic.c | 32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/tests/gem_tiled_pread_basic.c b/tests/gem_tiled_pread_basic.c
index bad3650..425bb07 100644
--- a/tests/gem_tiled_pread_basic.c
+++ b/tests/gem_tiled_pread_basic.c
@@ -87,11 +87,16 @@ swizzle_bit(int bit, int offset)
return (offset & (1 << bit)) >> (bit - 6);
 }
 
+struct offset {
+   int base_x, base_y;
+   int tile_x, tile_y;
+};
+
 /* Translate from a swizzled offset in the tiled buffer to the corresponding
  * value from the original linear buffer.
  */
 static uint32_t
-calculate_expected(int offset)
+calculate_expected(int offset, struct offset *dbg)
 {
int tile_off = offset & (tile_size - 1);
int tile_base = offset & -tile_size;
@@ -99,15 +104,14 @@ calculate_expected(int offset)
int tiles_per_row = 4*WIDTH / tile_width;
 
/* base x,y values from the tile (page) index. */
-   int base_y = tile_index / tiles_per_row * tile_height;
-   int base_x = tile_index % tiles_per_row * (tile_width/4);
+   dbg->base_y = tile_index / tiles_per_row * tile_height;
+   dbg->base_x = tile_index % tiles_per_row * (tile_width/4);
 
/* x, y offsets within the tile */
-   int tile_y = tile_off / tile_width;
-   int tile_x = (tile_off % tile_width) / 4;
+   dbg->tile_y = tile_off / tile_width;
+   dbg->tile_x = (tile_off % tile_width) / 4;
 
-   igt_debug("%3d, %3d, %3d,%3d\n", base_x, base_y, tile_x, tile_y);
-   return (base_y + tile_y) * WIDTH + base_x + tile_x;
+   return (dbg->base_y + dbg->tile_y) * WIDTH + dbg->base_x + dbg->tile_x;
 }
 
 igt_simple_main
@@ -163,7 +167,8 @@ igt_simple_main
 * offset it's looking for).
 */
for (j = offset; j < offset + len; j += 4) {
-   uint32_t expected_val, found_val;
+   struct offset dbg;
+   uint32_t expected, found;
int swizzled_offset;
const char *swizzle_str;
 
@@ -200,12 +205,15 @@ igt_simple_main
igt_assert_f(0, "Bad swizzle bits; %d\n",
 swizzle);
}
-   expected_val = calculate_expected(swizzled_offset);
-   found_val = linear[(j - offset) / 4];
-   igt_assert_f(expected_val == found_val,
+   expected = calculate_expected(swizzled_offset, );
+   found = linear[(j - offset) / 4];
+   igt_assert_f(expected == found,
 "Bad read [%d]: %d instead of %d at 0x%08x 
"
+"[tile (%d, %d) subtile (%d, %d)] "
 "for read from 0x%08x to 0x%08x, 
swizzle=%s\n",
-i, found_val, expected_val, j,
+i, found, expected, j,
+dbg.base_x, dbg.base_y,
+dbg.tile_x, dbg.tile_y,
 offset, offset + len,
 swizzle_str);
}
-- 
2.9.3

___
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: Handle early failure during intel_get_load_detect_pipe

2016-10-19 Thread Patchwork
== Series Details ==

Series: drm/i915: Handle early failure during intel_get_load_detect_pipe
URL   : https://patchwork.freedesktop.org/series/14016/
State : failure

== Summary ==

Series 14016v1 drm/i915: Handle early failure during intel_get_load_detect_pipe
https://patchwork.freedesktop.org/api/1.0/series/14016/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6770hq)
Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-snb-2520m)
fail   -> DMESG-WARN (fi-ilk-650)
pass   -> DMESG-WARN (fi-skl-6700hq)
dmesg-warn -> INCOMPLETE (fi-byt-j1900)
Test kms_busy:
Subgroup basic-flip-default-a:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-busy-flip-before-cursor-varying-size:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-after-cursor-legacy:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-after-cursor-varying-size:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-before-cursor-varying-size:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_force_connector_basic:
Subgroup force-load-detect:
incomplete -> PASS   (fi-ivb-3770)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup hang-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup suspend-read-crc-pipe-a:
fail   -> DMESG-WARN (fi-ilk-650)
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-b:
fail   -> DMESG-WARN (fi-ilk-650)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> INCOMPLETE (fi-skl-6700k)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-skl-6700hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:76   pass:62   dwarn:0   dfail:0   fail:1   skip:12 
fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:160  dwarn:24  dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:208  pass:186  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:219  dwarn:4   dfail:0   fail:0   skip:23 
fi-skl-6700k total:209  pass:185  dwarn:1   dfail:0   fail:0   skip:22 
fi-skl-6770hqtotal:246  pass:231  dwarn:1   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2759/

d5cbeba648bec880aa0e1f7a531e684499a079a7 drm-intel-nightly: 
2016y-10m-19d-11h-13m-08s UTC integration manifest
b3ed176 drm/i915: Handle 

[Intel-gfx] [RESEND PATCH 1/6] drm/i915: Convert intel_hdmi to use atomic state

2016-10-19 Thread Maarten Lankhorst
This is the last connector still looking at crtc->config. Fix this.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 48 +--
 1 file changed, 21 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 501334242d38..ef43244a884f 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -975,7 +975,9 @@ static void intel_hdmi_get_config(struct intel_encoder 
*encoder,
pipe_config->lane_count = 4;
 }
 
-static void intel_enable_hdmi_audio(struct intel_encoder *encoder)
+static void intel_enable_hdmi_audio(struct intel_encoder *encoder,
+   struct intel_crtc_state *pipe_config,
+   struct drm_connector_state *conn_state)
 {
struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
 
@@ -991,21 +993,20 @@ static void g4x_enable_hdmi(struct intel_encoder *encoder,
 {
struct drm_device *dev = encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(>base);
u32 temp;
 
temp = I915_READ(intel_hdmi->hdmi_reg);
 
temp |= SDVO_ENABLE;
-   if (crtc->config->has_audio)
+   if (pipe_config->has_audio)
temp |= SDVO_AUDIO_ENABLE;
 
I915_WRITE(intel_hdmi->hdmi_reg, temp);
POSTING_READ(intel_hdmi->hdmi_reg);
 
-   if (crtc->config->has_audio)
-   intel_enable_hdmi_audio(encoder);
+   if (pipe_config->has_audio)
+   intel_enable_hdmi_audio(encoder, pipe_config, conn_state);
 }
 
 static void ibx_enable_hdmi(struct intel_encoder *encoder,
@@ -1040,8 +1041,8 @@ static void ibx_enable_hdmi(struct intel_encoder *encoder,
 * FIXME: BSpec says this should be done at the end of
 * of the modeset sequence, so not sure if this isn't too soon.
 */
-   if (crtc->config->pipe_bpp > 24 &&
-   crtc->config->pixel_multiplier > 1) {
+   if (pipe_config->pipe_bpp > 24 &&
+   pipe_config->pixel_multiplier > 1) {
I915_WRITE(intel_hdmi->hdmi_reg, temp & ~SDVO_ENABLE);
POSTING_READ(intel_hdmi->hdmi_reg);
 
@@ -1055,8 +1056,8 @@ static void ibx_enable_hdmi(struct intel_encoder *encoder,
POSTING_READ(intel_hdmi->hdmi_reg);
}
 
-   if (crtc->config->has_audio)
-   intel_enable_hdmi_audio(encoder);
+   if (pipe_config->has_audio)
+   intel_enable_hdmi_audio(encoder, pipe_config, conn_state);
 }
 
 static void cpt_enable_hdmi(struct intel_encoder *encoder,
@@ -1073,7 +1074,7 @@ static void cpt_enable_hdmi(struct intel_encoder *encoder,
temp = I915_READ(intel_hdmi->hdmi_reg);
 
temp |= SDVO_ENABLE;
-   if (crtc->config->has_audio)
+   if (pipe_config->has_audio)
temp |= SDVO_AUDIO_ENABLE;
 
/*
@@ -1086,7 +1087,7 @@ static void cpt_enable_hdmi(struct intel_encoder *encoder,
 * 4. enable HDMI clock gating
 */
 
-   if (crtc->config->pipe_bpp > 24) {
+   if (pipe_config->pipe_bpp > 24) {
I915_WRITE(TRANS_CHICKEN1(pipe),
   I915_READ(TRANS_CHICKEN1(pipe)) |
   TRANS_CHICKEN1_HDMIUNIT_GC_DISABLE);
@@ -1098,7 +1099,7 @@ static void cpt_enable_hdmi(struct intel_encoder *encoder,
I915_WRITE(intel_hdmi->hdmi_reg, temp);
POSTING_READ(intel_hdmi->hdmi_reg);
 
-   if (crtc->config->pipe_bpp > 24) {
+   if (pipe_config->pipe_bpp > 24) {
temp &= ~SDVO_COLOR_FORMAT_MASK;
temp |= HDMI_COLOR_FORMAT_12bpc;
 
@@ -1110,8 +,8 @@ static void cpt_enable_hdmi(struct intel_encoder *encoder,
   ~TRANS_CHICKEN1_HDMIUNIT_GC_DISABLE);
}
 
-   if (crtc->config->has_audio)
-   intel_enable_hdmi_audio(encoder);
+   if (pipe_config->has_audio)
+   intel_enable_hdmi_audio(encoder, pipe_config, conn_state);
 }
 
 static void vlv_enable_hdmi(struct intel_encoder *encoder,
@@ -1178,9 +1179,7 @@ static void g4x_disable_hdmi(struct intel_encoder 
*encoder,
 struct intel_crtc_state *old_crtc_state,
 struct drm_connector_state *old_conn_state)
 {
-   struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
-
-   if (crtc->config->has_audio)
+   if (old_crtc_state->has_audio)
intel_audio_codec_disable(encoder);
 
intel_disable_hdmi(encoder, old_crtc_state, old_conn_state);
@@ -1190,9 +1189,7 @@ static void pch_disable_hdmi(struct intel_encoder 
*encoder,
 struct intel_crtc_state *old_crtc_state,
 struct drm_connector_state 

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [01/12] drm/i915/gvt: s/drm_gem_object_unreference/i915_gem_object_put/

2016-10-19 Thread Patchwork
== Series Details ==

Series: series starting with [01/12] drm/i915/gvt: 
s/drm_gem_object_unreference/i915_gem_object_put/
URL   : https://patchwork.freedesktop.org/series/14013/
State : warning

== Summary ==

Series 14013v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/14013/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-snb-2520m)
fail   -> DMESG-WARN (fi-ilk-650)
Test kms_busy:
Subgroup basic-flip-default-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-default-b:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-busy-flip-before-cursor-varying-size:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-after-cursor-legacy:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-after-cursor-varying-size:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-before-cursor-varying-size:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_force_connector_basic:
Subgroup force-load-detect:
incomplete -> PASS   (fi-byt-j1900)
incomplete -> PASS   (fi-ivb-3770)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup hang-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup suspend-read-crc-pipe-a:
fail   -> DMESG-WARN (fi-ilk-650)
Subgroup suspend-read-crc-pipe-b:
fail   -> DMESG-WARN (fi-ilk-650)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:159  dwarn:25  dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:209  pass:187  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2758/

d5cbeba648bec880aa0e1f7a531e684499a079a7 drm-intel-nightly: 
2016y-10m-19d-11h-13m-08s UTC integration manifest
d560dee drm/i915/gvt: Remove defunct vmap_batch()
9bf8686 drm/i915/gvt: Use common mapping routines for shadow_bb object
dc92fe6 drm/i915/gvt: Use common mapping routines for indirect_ctx object
02977e8 drm/i915/gvt: Stop waiting whilst holding struct_mutex
e22ba7c drm/i915/gvt: Stop checking for impossible interrupts from a kthread
8a57b82 drm/i915/gvt: Hold a reference on the request
599585e drm/i915/gvt: 

[Intel-gfx] [RESEND PATCH 3/6] drm/edid: Remove drm_select_eld

2016-10-19 Thread Maarten Lankhorst
The only user was i915, which is now gone.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_edid.c | 26 --
 include/drm/drm_edid.h |  1 -
 2 files changed, 27 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 95de47ba1e77..fc81e0eb6abf 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3578,32 +3578,6 @@ int drm_av_sync_delay(struct drm_connector *connector,
 EXPORT_SYMBOL(drm_av_sync_delay);
 
 /**
- * drm_select_eld - select one ELD from multiple HDMI/DP sinks
- * @encoder: the encoder just changed display mode
- *
- * It's possible for one encoder to be associated with multiple HDMI/DP sinks.
- * The policy is now hard coded to simply use the first HDMI/DP sink's ELD.
- *
- * Return: The connector associated with the first HDMI/DP sink that has ELD
- * attached to it.
- */
-struct drm_connector *drm_select_eld(struct drm_encoder *encoder)
-{
-   struct drm_connector *connector;
-   struct drm_device *dev = encoder->dev;
-
-   WARN_ON(!mutex_is_locked(>mode_config.mutex));
-   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
-
-   drm_for_each_connector(connector, dev)
-   if (connector->encoder == encoder && connector->eld[0])
-   return connector;
-
-   return NULL;
-}
-EXPORT_SYMBOL(drm_select_eld);
-
-/**
  * drm_detect_hdmi_monitor - detect whether monitor is HDMI
  * @edid: monitor EDID information
  *
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index c3a7d440bc11..38eabf65f19d 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -330,7 +330,6 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad 
**sads);
 int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb);
 int drm_av_sync_delay(struct drm_connector *connector,
  const struct drm_display_mode *mode);
-struct drm_connector *drm_select_eld(struct drm_encoder *encoder);
 
 #ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
 int drm_load_edid_firmware(struct drm_connector *connector);
-- 
2.7.4

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


[Intel-gfx] [RESEND PATCH 5/6] drm/i915: Pass atomic state to verify_connector_state

2016-10-19 Thread Maarten Lankhorst
This gets rid of a warning that the connectors are used without locking
when doing a nonblocking modeset.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ba7f7be3aa4f..54a4b2704179 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13501,11 +13501,15 @@ static void verify_wm_state(struct drm_crtc *crtc,
 }
 
 static void
-verify_connector_state(struct drm_device *dev, struct drm_crtc *crtc)
+verify_connector_state(struct drm_device *dev,
+  struct drm_atomic_state *state,
+  struct drm_crtc *crtc)
 {
struct drm_connector *connector;
+   struct drm_connector_state *old_conn_state;
+   int i;
 
-   drm_for_each_connector(connector, dev) {
+   for_each_connector_in_state(state, connector, old_conn_state, i) {
struct drm_encoder *encoder = connector->encoder;
struct drm_connector_state *state = connector->state;
 
@@ -13713,15 +13717,16 @@ verify_shared_dpll_state(struct drm_device *dev, 
struct drm_crtc *crtc,
 
 static void
 intel_modeset_verify_crtc(struct drm_crtc *crtc,
-struct drm_crtc_state *old_state,
-struct drm_crtc_state *new_state)
+ struct drm_atomic_state *state,
+ struct drm_crtc_state *old_state,
+ struct drm_crtc_state *new_state)
 {
if (!needs_modeset(new_state) &&
!to_intel_crtc_state(new_state)->update_pipe)
return;
 
verify_wm_state(crtc, new_state);
-   verify_connector_state(crtc->dev, crtc);
+   verify_connector_state(crtc->dev, state, crtc);
verify_crtc_state(crtc, old_state, new_state);
verify_shared_dpll_state(crtc->dev, crtc, old_state, new_state);
 }
@@ -13737,10 +13742,11 @@ verify_disabled_dpll_state(struct drm_device *dev)
 }
 
 static void
-intel_modeset_verify_disabled(struct drm_device *dev)
+intel_modeset_verify_disabled(struct drm_device *dev,
+ struct drm_atomic_state *state)
 {
verify_encoder_state(dev);
-   verify_connector_state(dev, NULL);
+   verify_connector_state(dev, state, NULL);
verify_disabled_dpll_state(dev);
 }
 
@@ -14399,7 +14405,7 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
if (!intel_can_enable_sagv(state))
intel_disable_sagv(dev_priv);
 
-   intel_modeset_verify_disabled(dev);
+   intel_modeset_verify_disabled(dev, state);
}
 
/* Complete the events for pipes that have now been disabled */
@@ -14451,7 +14457,7 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
if (put_domains[i])
modeset_put_power_domains(dev_priv, put_domains[i]);
 
-   intel_modeset_verify_crtc(crtc, old_crtc_state, crtc->state);
+   intel_modeset_verify_crtc(crtc, state, old_crtc_state, 
crtc->state);
}
 
if (intel_state->modeset && intel_can_enable_sagv(state))
-- 
2.7.4

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


[Intel-gfx] [RESEND PATCH 4/6] drm/i915: Update atomic modeset state synchronously

2016-10-19 Thread Maarten Lankhorst
All of this state should be updated as soon as possible. It shouldn't be
done later because then future updates may not depend on it.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 69b9e91f071e..ba7f7be3aa4f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14341,14 +14341,8 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
 
drm_atomic_helper_wait_for_dependencies(state);
 
-   if (intel_state->modeset) {
-   memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
-  sizeof(intel_state->min_pixclk));
-   dev_priv->active_crtcs = intel_state->active_crtcs;
-   dev_priv->atomic_cdclk_freq = intel_state->cdclk;
-
+   if (intel_state->modeset)
intel_display_power_get(dev_priv, POWER_DOMAIN_MODESET);
-   }
 
for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
@@ -14558,6 +14552,13 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_atomic_track_fbs(state);
 
drm_atomic_state_get(state);
+   if (intel_state->modeset) {
+   memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
+  sizeof(intel_state->min_pixclk));
+   dev_priv->active_crtcs = intel_state->active_crtcs;
+   dev_priv->atomic_cdclk_freq = intel_state->cdclk;
+   }
+
if (nonblock)
queue_work(system_unbound_wq, >commit_work);
else
-- 
2.7.4

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


[Intel-gfx] [RESEND PATCH 2/6] drm/i915: Pass atomic state to intel_audio_codec_enable

2016-10-19 Thread Maarten Lankhorst
drm_select_eld requires mode_config.mutex and connection_mutex
because it looks at the connector list and at the legacy encoders.

This is not required, because when we call audio_codec_enable we know
which connector it was called for, so pass the state.

This also removes having to look at crtc->config.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_audio.c | 17 ++---
 drivers/gpu/drm/i915/intel_ddi.c   |  2 +-
 drivers/gpu/drm/i915/intel_dp.c| 11 ++-
 drivers/gpu/drm/i915/intel_drv.h   |  4 +++-
 drivers/gpu/drm/i915/intel_hdmi.c  |  2 +-
 5 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index 7093cfbb62b1..63ef25893c7e 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -485,23 +485,26 @@ static void ilk_audio_codec_enable(struct drm_connector 
*connector,
 /**
  * intel_audio_codec_enable - Enable the audio codec for HD audio
  * @intel_encoder: encoder on which to enable audio
+ * @crtc_state: pointer to the current crtc state.
+ * @conn_state: pointer to the current connector state.
  *
  * The enable sequences may only be performed after enabling the transcoder and
  * port, and after completed link training.
  */
-void intel_audio_codec_enable(struct intel_encoder *intel_encoder)
+void intel_audio_codec_enable(struct intel_encoder *intel_encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state)
 {
struct drm_encoder *encoder = _encoder->base;
-   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
-   const struct drm_display_mode *adjusted_mode = 
>config->base.adjusted_mode;
+   const struct drm_display_mode *adjusted_mode = 
_state->base.adjusted_mode;
struct drm_connector *connector;
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
struct i915_audio_component *acomp = dev_priv->audio_component;
enum port port = intel_encoder->port;
-   enum pipe pipe = crtc->pipe;
+   enum pipe pipe = drm_crtc_index(crtc_state->base.crtc);
 
-   connector = drm_select_eld(encoder);
-   if (!connector)
+   connector = conn_state->connector;
+   if (!connector || !connector->eld[0])
return;
 
DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
@@ -512,7 +515,7 @@ void intel_audio_codec_enable(struct intel_encoder 
*intel_encoder)
 
/* ELD Conn_Type */
connector->eld[5] &= ~(3 << 2);
-   if (intel_crtc_has_dp_encoder(crtc->config))
+   if (intel_crtc_has_dp_encoder(crtc_state))
connector->eld[5] |= (1 << 2);
 
connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 7f7741c1406d..6748279310a4 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1824,7 +1824,7 @@ static void intel_enable_ddi(struct intel_encoder 
*intel_encoder,
 
if (intel_crtc->config->has_audio) {
intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
-   intel_audio_codec_enable(intel_encoder);
+   intel_audio_codec_enable(intel_encoder, pipe_config, 
conn_state);
}
 }
 
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 88f3b745a326..6046f0f54cb3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2734,7 +2734,8 @@ static void intel_dp_enable_port(struct intel_dp 
*intel_dp,
 }
 
 static void intel_enable_dp(struct intel_encoder *encoder,
-   struct intel_crtc_state *pipe_config)
+   struct intel_crtc_state *pipe_config,
+   struct drm_connector_state *conn_state)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
struct drm_device *dev = encoder->base.dev;
@@ -2776,7 +2777,7 @@ static void intel_enable_dp(struct intel_encoder *encoder,
if (pipe_config->has_audio) {
DRM_DEBUG_DRIVER("Enabling DP audio on pipe %c\n",
 pipe_name(pipe));
-   intel_audio_codec_enable(encoder);
+   intel_audio_codec_enable(encoder, pipe_config, conn_state);
}
 }
 
@@ -2786,7 +2787,7 @@ static void g4x_enable_dp(struct intel_encoder *encoder,
 {
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
 
-   intel_enable_dp(encoder, pipe_config);
+   intel_enable_dp(encoder, pipe_config, conn_state);
intel_edp_backlight_on(intel_dp);
 }
 
@@ -2923,7 +2924,7 @@ static void vlv_pre_enable_dp(struct intel_encoder 
*encoder,
 {
vlv_phy_pre_encoder_enable(encoder);
 
-   intel_enable_dp(encoder, pipe_config);
+   

[Intel-gfx] [RESEND PATCH 0/6] drm/i915: Enable support for nonblocking modeset.

2016-10-19 Thread Maarten Lankhorst
This is a rebased version of the series. Patch 4 fails to apply because
of drm_atomic_state refcounting, but otherwise unchanged.

This series is tested on my BDW and SKL. Skylake requires
Lyude's fixes + "[PATCH 0/8] drm/i915/gen9+: Atomic wm fixes."

Maarten Lankhorst (6):
  drm/i915: Convert intel_hdmi to use atomic state
  drm/i915: Pass atomic state to intel_audio_codec_enable
  drm/edid: Remove drm_select_eld
  drm/i915: Update atomic modeset state synchronously
  drm/i915: Pass atomic state to verify_connector_state
  drm/i915: Enable support for nonblocking modeset

 drivers/gpu/drm/drm_edid.c   | 26 ---
 drivers/gpu/drm/i915/intel_audio.c   | 17 +++-
 drivers/gpu/drm/i915/intel_ddi.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c | 48 +-
 drivers/gpu/drm/i915/intel_dp.c  | 11 
 drivers/gpu/drm/i915/intel_drv.h |  4 ++-
 drivers/gpu/drm/i915/intel_hdmi.c| 50 
 include/drm/drm_edid.h   |  1 -
 8 files changed, 65 insertions(+), 94 deletions(-)

-- 
2.7.4

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


[Intel-gfx] [RESEND PATCH 6/6] drm/i915: Enable support for nonblocking modeset

2016-10-19 Thread Maarten Lankhorst
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 54a4b2704179..523bb97c3bca 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14519,10 +14519,6 @@ static void intel_atomic_track_fbs(struct 
drm_atomic_state *state)
  * This function commits a top-level state object that has been validated
  * with drm_atomic_helper_check().
  *
- * FIXME:  Atomic modeset support for i915 is not yet complete.  At the moment
- * nonblocking commits are only safe for pure plane updates. Everything else
- * should work though.
- *
  * RETURNS
  * Zero for success or -errno.
  */
@@ -14534,11 +14530,6 @@ static int intel_atomic_commit(struct drm_device *dev,
struct drm_i915_private *dev_priv = to_i915(dev);
int ret = 0;
 
-   if (intel_state->modeset && nonblock) {
-   DRM_DEBUG_KMS("nonblocking commit for modeset not yet 
implemented.\n");
-   return -EINVAL;
-   }
-
ret = drm_atomic_helper_setup_commit(state, nonblock);
if (ret)
return ret;
-- 
2.7.4

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gvt: Add runtime pm around fences

2016-10-19 Thread Patchwork
== Series Details ==

Series: drm/i915/gvt: Add runtime pm around fences
URL   : https://patchwork.freedesktop.org/series/14011/
State : warning

== Summary ==

Series 14011v1 drm/i915/gvt: Add runtime pm around fences
https://patchwork.freedesktop.org/api/1.0/series/14011/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test gem_exec_suspend:
Subgroup basic-s3:
fail   -> DMESG-WARN (fi-ilk-650)
incomplete -> PASS   (fi-snb-2520m)
pass   -> DMESG-WARN (fi-skl-6700hq)
Test kms_busy:
Subgroup basic-flip-default-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-default-b:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-busy-flip-before-cursor-varying-size:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-after-cursor-legacy:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-after-cursor-varying-size:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-before-cursor-varying-size:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_force_connector_basic:
Subgroup force-load-detect:
incomplete -> PASS   (fi-ivb-3770)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup hang-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup suspend-read-crc-pipe-a:
fail   -> DMESG-WARN (fi-ilk-650)
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-b:
fail   -> DMESG-WARN (fi-ilk-650)
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-skl-6700hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:186  pass:160  dwarn:1   dfail:0   fail:1   skip:23 
fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:159  dwarn:25  dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:219  dwarn:4   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:208  pass:175  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2757/

d5cbeba648bec880aa0e1f7a531e684499a079a7 drm-intel-nightly: 
2016y-10m-19d-11h-13m-08s UTC integration manifest
9cd54f0 drm/i915/gvt: Add runtime pm around fences

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


Re: [Intel-gfx] IGT contributions and reviews

2016-10-19 Thread Daniel Vetter
On Wed, Oct 19, 2016 at 1:26 PM, Jani Nikula
 wrote:
> On Wed, 19 Oct 2016, Daniel Vetter  wrote:
>> On Tue, Oct 18, 2016 at 07:33:10PM +0300, Jani Nikula wrote:
>>> On Tue, 18 Oct 2016, Petri Latvala  wrote:
>>> > The current contributing docs for IGT state:
>>> >
>>> > <<
>>> >   There is no formal review requirement and regular contributors with
>>> >   commit access can push patches right after submitting them to the
>>> >   mailing lists. But invasive changes, new helper libraries and
>>> >   contributions from newcomers should go through a proper review to
>>> >   ensure overall consistency in the codebase.
>>> >>>
>>> >
>>> >
>>> > While not requiring reviews or acks has definitely increased the
>>> > speed of development, I feel the time for slowing down a bit has
>>> > come.
>>>
>>> Agreed. (Though a more rigorous review requirement doesn't necessarily
>>> slow things down in the big picture.)
>>>
>>> > At the very least I would like to see all commits have a visit to the
>>> > mailing list before pushing, as the current docs already ask for. The
>>> > "right after" part would be changed to a $period of quarantine, maybe
>>> > 24 hours?
>>>
>>> Sounds good to me.
>>
>> We've already had this, and people stopped bothering. What will be
>> different this time around? I feel a bit like we do need to be a bit more
>> formal here, to really make this stick ...
>>
>> Also, who's going to be the annoying maintainer who reminds everyone every
>> time they break the rules? It'll take some serious effort here to get
>> folks off their well-trodded paths onto a new one I think.
>
> What's your concrete proposal?

1. Bring up the topic.
2. Discuss it to death until suitable rough consensus emerges.
3. Roll out new rules and have a semi-evil maintainer (I can help with
that) enforce them.

I think anything up to full review starndards like we have them for
the kernel (for all of igt, for simplicity) should be on the table,
and would in my opinion be an adequate choice. Personally I'm leaning
more towards the process-heavy side. Replied to Paulo with more of my
reasons for that.
-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] IGT contributions and reviews

2016-10-19 Thread Jani Nikula
On Wed, 19 Oct 2016, Paulo Zanoni  wrote:
> Why is Daniel asking me to submit patches to the mailing list if that
> guy doesn't seem to need to follow the same rule? Is this some sort of
> double- standard?".

Not to take anything away from a perfectly good rant, but from now on
it's really s/Daniel/Petri/ for IGT.

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] IGT contributions and reviews

2016-10-19 Thread Daniel Vetter
On Wed, Oct 19, 2016 at 3:06 PM, Paulo Zanoni  wrote:
>> > > At the very least I would like to see all commits have a visit to
>> > > the
>> > > mailing list before pushing, as the current docs already ask for.
>> > > The
>> > > "right after" part would be changed to a $period of quarantine,
>> > > maybe
>> > > 24 hours?
>> >
>> > Sounds good to me.
>>
>> We've already had this, and people stopped bothering. What will be
>> different this time around? I feel a bit like we do need to be a bit
>> more
>> formal here, to really make this stick ...
>
> I think the problem is that if only one single person doesn't follow
> the rules, a few others will notice and start thinking: "If this guy
> doesn't need to follow the rules, why do I need to? Why is Daniel
> asking me to submit patches to the mailing list if that guy doesn't
> seem to need to follow the same rule? Is this some sort of double-
> standard?". Then person #2 stops following the rule, which makes more
> people realize the same thing, which makes person #3 and #4 stop, etc.
> So please, whatever rule we decide, let's make sure *everybody has to
> follow it*, no exception for special cases, no allowing-people-to-get-
> away-with-it. No double standards. 
>
> As a consequence of what I said, we do need to think: what if someone
> doesn't follow the rule we decide? What will we *actually* do? Will it
> really work if all we do is to politely ask them on IRC? Maybe the lack
> of consequences is that degraded our previous rule?

Yeah I think that was kinda what happened. At first I did gently prod
people who bent the rules a bit into what I think would be the better
direction. But pretty much from the start I didn't want to be too much
of an annoyance, because when I put my maintainer dictator hammer down
and said I want to see testcases I think a few people were very
sceptical. Hence I was really happy with every engineer who discovered
that igts are useful and started hacking on them like mad, even if the
process went out of the window a bit.

But I do think that now igt and tests as a primary deliverable is
well-established, and we seem to have a few issues from the lack of
any kind of review or otherwise coordination:
- Duplicated tests, and sometimes duplicated test infrastructure that
probably should be better extracted into helper libraries.
- Much harder to ramp up new folks since they can't go watch the pros
do their work on the m-l like on the kernel side.
- Defacto double-standards pissing off contributors.
- Lack of sharing of useful testing tricks. E.g. I only learned by
accident of Chris' very clever delay-batch trick, and I think that's
something which should be used in a lot more places.
- And finally I think we have a bit a quality problem with tests
itself ("works on my machine, it must be perfect") which is causing
some serious hiccups and fun with CI.

Would love to here the thoughts of others here.
-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


[Intel-gfx] [PATCH igt] igt: Check the physical swizzle status

2016-10-19 Thread Chris Wilson
The kernel tries to hide L-shaped memory with asymmetric swizzling from
userspace by reporting lies through the get-tiling interface. Check for
these lies by comparing the reported swizzle with the actual swizzle,
and only run swizzling tests where we know the underlying physical
swizzling.

Signed-off-by: Chris Wilson 
---
 lib/igt_draw.c| 10 +-
 lib/igt_sysfs.c   |  3 ++-
 lib/ioctl_wrappers.c  | 23 +++
 lib/ioctl_wrappers.h  |  2 +-
 tests/gem_tiled_pread_basic.c |  2 +-
 5 files changed, 28 insertions(+), 12 deletions(-)

diff --git a/lib/igt_draw.c b/lib/igt_draw.c
index 45fa10f..3afb827 100644
--- a/lib/igt_draw.c
+++ b/lib/igt_draw.c
@@ -246,7 +246,7 @@ static void draw_rect_mmap_cpu(int fd, struct buf_data 
*buf, struct rect *rect,
 
gem_set_domain(fd, buf->handle, I915_GEM_DOMAIN_CPU,
   I915_GEM_DOMAIN_CPU);
-   gem_get_tiling(fd, buf->handle, , );
+   igt_require(gem_get_tiling(fd, buf->handle, , ));
 
/* We didn't implement suport for the older tiling methods yet. */
if (tiling != I915_TILING_NONE)
@@ -295,7 +295,7 @@ static void draw_rect_mmap_wc(int fd, struct buf_data *buf, 
struct rect *rect,
 
gem_set_domain(fd, buf->handle, I915_GEM_DOMAIN_GTT,
   I915_GEM_DOMAIN_GTT);
-   gem_get_tiling(fd, buf->handle, , );
+   igt_require(gem_get_tiling(fd, buf->handle, , ));
 
/* We didn't implement suport for the older tiling methods yet. */
if (tiling != I915_TILING_NONE)
@@ -392,7 +392,7 @@ static void draw_rect_pwrite(int fd, struct buf_data *buf,
 {
uint32_t tiling, swizzle;
 
-   gem_get_tiling(fd, buf->handle, , );
+   igt_require(gem_get_tiling(fd, buf->handle, , ));
 
switch (tiling) {
case I915_TILING_NONE:
@@ -419,7 +419,7 @@ static void draw_rect_blt(int fd, struct cmd_data *cmd_data,
uint32_t tiling, swizzle;
int pitch;
 
-   gem_get_tiling(fd, buf->handle, , );
+   igt_require(gem_get_tiling(fd, buf->handle, , ));
 
dst = gem_handle_to_libdrm_bo(cmd_data->bufmgr, fd, "", buf->handle);
igt_assert(dst);
@@ -483,7 +483,7 @@ static void draw_rect_render(int fd, struct cmd_data 
*cmd_data,
rect->w % (32 / buf->bpp) != 0 ||
rect->h % (32 / buf->bpp) != 0);
 
-   gem_get_tiling(fd, buf->handle, , );
+   igt_require(gem_get_tiling(fd, buf->handle, , ));
 
/* We create a temporary buffer and copy from it using rendercopy. */
tmp.size = rect->w * rect->h * pixel_size;
diff --git a/lib/igt_sysfs.c b/lib/igt_sysfs.c
index 612de75..c19821d 100644
--- a/lib/igt_sysfs.c
+++ b/lib/igt_sysfs.c
@@ -148,7 +148,8 @@ int igt_sysfs_open_parameters(int device)
if (dir < 0)
return -1;
 
-   params = openat(dir, "device/driver/module/parameters", O_RDONLY);
+   params = -1;
+   //params = openat(dir, "device/driver/module/parameters", O_RDONLY);
close(dir);
 
if (params < 0) { /* builtin? */
diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 8632878..95bc5e2 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -111,6 +111,19 @@ gem_handle_to_libdrm_bo(drm_intel_bufmgr *bufmgr, int fd, 
const char *name, uint
return bo;
 }
 
+static int
+__gem_get_tiling(int fd, struct drm_i915_gem_get_tiling *arg)
+{
+   int err;
+
+   err = 0;
+   if (igt_ioctl(fd, DRM_IOCTL_I915_GEM_GET_TILING, arg))
+   err = -errno;
+   errno = 0;
+
+   return err;
+}
+
 /**
  * gem_get_tiling:
  * @fd: open i915 drm file descriptor
@@ -119,21 +132,23 @@ gem_handle_to_libdrm_bo(drm_intel_bufmgr *bufmgr, int fd, 
const char *name, uint
  * @swizzle: (out) bit 6 swizzle mode
  *
  * This wraps the GET_TILING ioctl.
+ *
+ * Returns whether the actual physical tiling matches the reported tiling.
  */
-void
+bool
 gem_get_tiling(int fd, uint32_t handle, uint32_t *tiling, uint32_t *swizzle)
 {
struct drm_i915_gem_get_tiling get_tiling;
-   int ret;
 
memset(_tiling, 0, sizeof(get_tiling));
get_tiling.handle = handle;
 
-   ret = igt_ioctl(fd, DRM_IOCTL_I915_GEM_GET_TILING, _tiling);
-   igt_assert(ret == 0);
+   igt_assert_eq(__gem_get_tiling(fd, _tiling), 0);
 
*tiling = get_tiling.tiling_mode;
*swizzle = get_tiling.swizzle_mode;
+
+   return get_tiling.phys_swizzle_mode == get_tiling.swizzle_mode;
 }
 
 int __gem_set_tiling(int fd, uint32_t handle, uint32_t tiling, uint32_t stride)
diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
index 42dc3cb..465f760 100644
--- a/lib/ioctl_wrappers.h
+++ b/lib/ioctl_wrappers.h
@@ -53,7 +53,7 @@ drm_intel_bo * gem_handle_to_libdrm_bo(drm_intel_bufmgr 
*bufmgr, int fd,
 /* ioctl_wrappers.c:
  *
  * ioctl wrappers and similar stuff for bare metal testing */
-void gem_get_tiling(int fd, uint32_t 

Re: [Intel-gfx] IGT contributions and reviews

2016-10-19 Thread Paulo Zanoni
Em Qua, 2016-10-19 às 09:50 +0200, Daniel Vetter escreveu:
> On Tue, Oct 18, 2016 at 07:33:10PM +0300, Jani Nikula wrote:
> > 
> > On Tue, 18 Oct 2016, Petri Latvala  wrote:
> > > 
> > > The current contributing docs for IGT state:
> > > 
> > > <<
> > >   There is no formal review requirement and regular contributors
> > > with
> > >   commit access can push patches right after submitting them to
> > > the
> > >   mailing lists. But invasive changes, new helper libraries and
> > >   contributions from newcomers should go through a proper review
> > > to
> > >   ensure overall consistency in the codebase.
> > > > 
> > > > > 
> > > > > 
> > > 
> > > 
> > > While not requiring reviews or acks has definitely increased the
> > > speed of development, I feel the time for slowing down a bit has
> > > come.
> > 
> > Agreed. (Though a more rigorous review requirement doesn't
> > necessarily
> > slow things down in the big picture.)
> > 
> > > 
> > > At the very least I would like to see all commits have a visit to
> > > the
> > > mailing list before pushing, as the current docs already ask for.
> > > The
> > > "right after" part would be changed to a $period of quarantine,
> > > maybe
> > > 24 hours?
> > 
> > Sounds good to me.
> 
> We've already had this, and people stopped bothering. What will be
> different this time around? I feel a bit like we do need to be a bit
> more
> formal here, to really make this stick ...

I think the problem is that if only one single person doesn't follow
the rules, a few others will notice and start thinking: "If this guy
doesn't need to follow the rules, why do I need to? Why is Daniel
asking me to submit patches to the mailing list if that guy doesn't
seem to need to follow the same rule? Is this some sort of double-
standard?". Then person #2 stops following the rule, which makes more
people realize the same thing, which makes person #3 and #4 stop, etc.
So please, whatever rule we decide, let's make sure *everybody has to
follow it*, no exception for special cases, no allowing-people-to-get-
away-with-it. No double standards. 

As a consequence of what I said, we do need to think: what if someone
doesn't follow the rule we decide? What will we *actually* do? Will it
really work if all we do is to politely ask them on IRC? Maybe the lack
of consequences is that degraded our previous rule?


> 
> Also, who's going to be the annoying maintainer who reminds everyone
> every
> time they break the rules? It'll take some serious effort here to get
> folks off their well-trodded paths onto a new one I think.
> -Daniel
> 
> > 
> > > 
> > > As for requiring reviews or acks before pushing, how do the
> > > developers
> > > at large feel about that? Different rules for different parts of
> > > IGT?
> > > (Benchmarks, tools, tests, CI test sets, lib)
> > 
> > I think there are two big buckets here:
> > 
> > * Tests in BAT and the BAT set list. I think we need r-b/ack on the
> >   mailing list on these changes before pushing. (In the long run,
> > I'd
> >   like to have these go through a CI run with everything else
> > unchanged
> >   too.)
> > 
> > * Everything else. Other tests and tools. I'd be happy with
> > requiring
> >   the patches are sent to the list, and either receiving r-b/ack or
> > 24
> >   hrs during weekdays without negative feedback.
> > 
> > > 
> > > The goal with this discussion is to reach a suitable tradeoff
> > > between
> > > stability from CI point of view and fruitful use of programmer
> > > time.
> > 
> > Thanks for starting the discussion.
> > 
> > BR,
> > Jani.
> > 
> > 
> > -- 
> > Jani Nikula, Intel Open Source Technology Center
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: Hold a reference on the request

2016-10-19 Thread Patchwork
== Series Details ==

Series: drm/i915/gvt: Hold a reference on the request
URL   : https://patchwork.freedesktop.org/series/14009/
State : failure

== Summary ==

Series 14009v1 drm/i915/gvt: Hold a reference on the request
https://patchwork.freedesktop.org/api/1.0/series/14009/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-snb-2520m)
pass   -> DMESG-WARN (fi-skl-6700hq)
dmesg-warn -> INCOMPLETE (fi-byt-j1900)
pass   -> INCOMPLETE (fi-skl-6770hq)
Test kms_force_connector_basic:
Subgroup force-load-detect:
incomplete -> PASS   (fi-ivb-3770)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-ivb-3520m)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:76   pass:62   dwarn:0   dfail:0   fail:1   skip:12 
fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:181  dwarn:0   dfail:0   fail:5   skip:60 
fi-ivb-3520m total:210  pass:188  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:208  pass:184  dwarn:1   dfail:0   fail:0   skip:22 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:76   pass:72   dwarn:0   dfail:0   fail:0   skip:3  
fi-snb-2520m total:209  pass:176  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2755/

d5cbeba648bec880aa0e1f7a531e684499a079a7 drm-intel-nightly: 
2016y-10m-19d-11h-13m-08s UTC integration manifest
8e8a654 drm/i915/gvt: Hold a reference on the request

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


[Intel-gfx] [PATCH] drm/i915: Stop reporting error details in dmesg as well as the error-state

2016-10-19 Thread Chris Wilson
As we already capture all the information from the registers into the
error-state, also dumping that to dmesg just generates noise that upsets
CI and users alike (and doesn't provide us with any more information).

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_irq.c | 86 ++---
 1 file changed, 11 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4c40a13d26e4..1d4bc67d27d4 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2578,90 +2578,26 @@ i915_err_print_instdone(struct drm_i915_private 
*dev_priv,
   slice, subslice, instdone->row[slice][subslice]);
 }
 
-static void i915_report_and_clear_eir(struct drm_i915_private *dev_priv)
+static void i915_clear_error_registers(struct drm_i915_private *dev_priv)
 {
-   struct intel_instdone instdone;
-   u32 eir = I915_READ(EIR);
-   int pipe;
-
-   if (!eir)
-   return;
-
-   pr_err("render error detected, EIR: 0x%08x\n", eir);
-
-   intel_engine_get_instdone(dev_priv->engine[RCS], );
-
-   if (IS_G4X(dev_priv)) {
-   if (eir & (GM45_ERROR_MEM_PRIV | GM45_ERROR_CP_PRIV)) {
-   u32 ipeir = I915_READ(IPEIR_I965);
-
-   pr_err("  IPEIR: 0x%08x\n", I915_READ(IPEIR_I965));
-   pr_err("  IPEHR: 0x%08x\n", I915_READ(IPEHR_I965));
-   i915_err_print_instdone(dev_priv, );
-   pr_err("  INSTPS: 0x%08x\n", I915_READ(INSTPS));
-   pr_err("  ACTHD: 0x%08x\n", I915_READ(ACTHD_I965));
-   I915_WRITE(IPEIR_I965, ipeir);
-   POSTING_READ(IPEIR_I965);
-   }
-   if (eir & GM45_ERROR_PAGE_TABLE) {
-   u32 pgtbl_err = I915_READ(PGTBL_ER);
-   pr_err("page table error\n");
-   pr_err("  PGTBL_ER: 0x%08x\n", pgtbl_err);
-   I915_WRITE(PGTBL_ER, pgtbl_err);
-   POSTING_READ(PGTBL_ER);
-   }
-   }
+   u32 eir;
 
-   if (!IS_GEN2(dev_priv)) {
-   if (eir & I915_ERROR_PAGE_TABLE) {
-   u32 pgtbl_err = I915_READ(PGTBL_ER);
-   pr_err("page table error\n");
-   pr_err("  PGTBL_ER: 0x%08x\n", pgtbl_err);
-   I915_WRITE(PGTBL_ER, pgtbl_err);
-   POSTING_READ(PGTBL_ER);
-   }
-   }
+   if (!IS_GEN2(dev_priv))
+   I915_WRITE(PGTBL_ER, I915_READ(PGTBL_ER));
 
-   if (eir & I915_ERROR_MEMORY_REFRESH) {
-   pr_err("memory refresh error:\n");
-   for_each_pipe(dev_priv, pipe)
-   pr_err("pipe %c stat: 0x%08x\n",
-  pipe_name(pipe), I915_READ(PIPESTAT(pipe)));
-   /* pipestat has already been acked */
-   }
-   if (eir & I915_ERROR_INSTRUCTION) {
-   pr_err("instruction error\n");
-   pr_err("  INSTPM: 0x%08x\n", I915_READ(INSTPM));
-   i915_err_print_instdone(dev_priv, );
-   if (INTEL_GEN(dev_priv) < 4) {
-   u32 ipeir = I915_READ(IPEIR);
-
-   pr_err("  IPEIR: 0x%08x\n", I915_READ(IPEIR));
-   pr_err("  IPEHR: 0x%08x\n", I915_READ(IPEHR));
-   pr_err("  ACTHD: 0x%08x\n", I915_READ(ACTHD));
-   I915_WRITE(IPEIR, ipeir);
-   POSTING_READ(IPEIR);
-   } else {
-   u32 ipeir = I915_READ(IPEIR_I965);
-
-   pr_err("  IPEIR: 0x%08x\n", I915_READ(IPEIR_I965));
-   pr_err("  IPEHR: 0x%08x\n", I915_READ(IPEHR_I965));
-   pr_err("  INSTPS: 0x%08x\n", I915_READ(INSTPS));
-   pr_err("  ACTHD: 0x%08x\n", I915_READ(ACTHD_I965));
-   I915_WRITE(IPEIR_I965, ipeir);
-   POSTING_READ(IPEIR_I965);
-   }
-   }
+   if (INTEL_GEN(dev_priv) < 4)
+   I915_WRITE(IPEIR, I915_READ(IPEIR));
+   else
+   I915_WRITE(IPEIR_I965, I915_READ(IPEIR_I965));
 
-   I915_WRITE(EIR, eir);
-   POSTING_READ(EIR);
+   I915_WRITE(EIR, I915_READ(EIR));
eir = I915_READ(EIR);
if (eir) {
/*
 * some errors might have become stuck,
 * mask them.
 */
-   DRM_ERROR("EIR stuck: 0x%08x, masking\n", eir);
+   DRM_DEBUG_DRIVER("EIR stuck: 0x%08x, masking\n", eir);
I915_WRITE(EMR, I915_READ(EMR) | eir);
I915_WRITE(IIR, I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT);
}
@@ -2690,7 +2626,7 @@ void i915_handle_error(struct drm_i915_private *dev_priv,

[Intel-gfx] [PATCH] drm: Fix LSPCON kernel-doc

2016-10-19 Thread Jani Nikula
Fix warnings on building htmldocs.

v2: whitespace around '/' (Ville)

Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
Cc: Rodrigo Vivi 
Cc: Shashank Sharma 
Cc: 
Signed-off-by: Jani Nikula 

---

n.b. 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") has
been merged via drm-intel tree
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 14 +++---
 include/drm/drm_dp_dual_mode_helper.h | 15 ---
 2 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 2624e266abbd..488355bdafb9 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -377,9 +377,9 @@ EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);
 
 /**
  * drm_lspcon_get_mode: Get LSPCON's current mode of operation by
- * by reading offset (0x80, 0x41)
- * @i2c_adapter: I2C-over-aux adapter
- * @current_mode: out vaiable, current lspcon mode of operation
+ * reading offset (0x80, 0x41)
+ * @adapter: I2C-over-aux adapter
+ * @mode: current lspcon mode of operation output variable
  *
  * Returns:
  * 0 on success, sets the current_mode value to appropriate mode
@@ -413,10 +413,10 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
 EXPORT_SYMBOL(drm_lspcon_get_mode);
 
 /**
- * drm_lspcon_change_mode: Change LSPCON's mode of operation by
- * by writing offset (0x80, 0x40)
- * @i2c_adapter: I2C-over-aux adapter
- * @reqd_mode: required mode of operation
+ * drm_lspcon_set_mode: Change LSPCON's mode of operation by
+ * writing offset (0x80, 0x40)
+ * @adapter: I2C-over-aux adapter
+ * @mode: required mode of operation
  *
  * Returns:
  * 0 on success, -error on failure/timeout
diff --git a/include/drm/drm_dp_dual_mode_helper.h 
b/include/drm/drm_dp_dual_mode_helper.h
index 55677704add8..4c42db81fcb4 100644
--- a/include/drm/drm_dp_dual_mode_helper.h
+++ b/include/drm/drm_dp_dual_mode_helper.h
@@ -70,12 +70,13 @@ ssize_t drm_dp_dual_mode_write(struct i2c_adapter *adapter,
   u8 offset, const void *buffer, size_t size);
 
 /**
-* enum drm_lspcon_mode
-* @lspcon_mode_ls: Level shifter mode of LSPCON
-*  which drives DP++ to HDMI 1.4 conversion.
-* @lspcon_mode_pcon: Protocol converter mode of LSPCON
-*  which drives DP++ to HDMI 2.0 active conversion.
-*/
+ * enum drm_lspcon_mode
+ * @DRM_LSPCON_MODE_INVALID: No LSPCON.
+ * @DRM_LSPCON_MODE_LS: Level shifter mode of LSPCON
+ * which drives DP++ to HDMI 1.4 conversion.
+ * @DRM_LSPCON_MODE_PCON: Protocol converter mode of LSPCON
+ * which drives DP++ to HDMI 2.0 active conversion.
+ */
 enum drm_lspcon_mode {
DRM_LSPCON_MODE_INVALID,
DRM_LSPCON_MODE_LS,
@@ -90,7 +91,7 @@ enum drm_lspcon_mode {
  * @DRM_DP_DUAL_MODE_TYPE1_HDMI: Type 1 HDMI adaptor
  * @DRM_DP_DUAL_MODE_TYPE2_DVI: Type 2 DVI adaptor
  * @DRM_DP_DUAL_MODE_TYPE2_HDMI: Type 2 HDMI adaptor
- * @DRM_DP_DUAL_MODE_TYPE2_LSPCON: Level shifter /protocol converter
+ * @DRM_DP_DUAL_MODE_LSPCON: Level shifter / protocol converter
  */
 enum drm_dp_dual_mode_type {
DRM_DP_DUAL_MODE_NONE,
-- 
2.1.4

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


Re: [Intel-gfx] [PATCH 5/7] drm/i915: Update kerneldoc for intel_dpll_mgr.c

2016-10-19 Thread Ander Conselvan De Oliveira
On Thu, 2016-10-13 at 15:46 +0200, Daniel Vetter wrote:
> On Tue, Oct 04, 2016 at 03:32:15PM +0300, Ander Conselvan de Oliveira wrote:
> > 
> > The documentation for most of the non-static members and structs were
> > missing. Fix that.
> > 
> > v2: Fix typos (Durga)
> > 
> > v3: Rebase.
> > Fix make docs warnings.
> > Document more.
> > 
> > Signed-off-by: Ander Conselvan de Oliveira  > l.com>
> As mentioned in an earlier patch, I think we should also move
> intel_atomic_get_shared_dpll_state from intel_atomic.c into
> intel_dpll_mgr.c. Grouping functions by the data structures they touch
> makes imo much more sense, than grouping them by topic. That way all the
> dpll stuff is in one place.
> 
> > 
> > ---
> >  Documentation/gpu/i915.rst|  12 +++
> >  drivers/gpu/drm/i915/intel_dpll_mgr.c |  90 ++--
> >  drivers/gpu/drm/i915/intel_dpll_mgr.h | 155 ++-
> > ---
> >  3 files changed, 237 insertions(+), 20 deletions(-)
> > 
> > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> > index 87aaffc..c19e437 100644
> > --- a/Documentation/gpu/i915.rst
> > +++ b/Documentation/gpu/i915.rst
> > @@ -204,6 +204,18 @@ Video BIOS Table (VBT)
> >  .. kernel-doc:: drivers/gpu/drm/i915/intel_vbt_defs.h
> > :internal:
> >  
> > +Display PLLs
> > +
> > +
> > +.. kernel-doc:: drivers/gpu/drm/i915/intel_dpll_mgr.c
> > +   :doc: Display PLLs
> > +
> > +.. kernel-doc:: drivers/gpu/drm/i915/intel_dpll_mgr.c
> > +   :internal:
> > +
> > +.. kernel-doc:: drivers/gpu/drm/i915/intel_dpll_mgr.h
> > +   :internal:
> > +
> >  Memory Management and Command Submission
> >  
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > index 9446446..8c4efa9 100644
> > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > @@ -23,6 +23,25 @@
> >  
> >  #include "intel_drv.h"
> >  
> > +/**
> > + * DOC: Display PLLs
> > + *
> > + * Display PLLs used for driving outputs vary by platform. While some have
> > + * per-pipe or per-encoder dedicated PLLs, others allow the use of any PLL
> > + * from a pool. In the latter scenario, it is possible that multiple pipes
> > + * share a PLL if their configurations match.
> > + *
> > + * This file provides an abstraction over display PLLs. The function
> > + * intel_shared_dpll_init() initializes the PLLs for the given
> > platform.  The
> > + * users of a PLL are tracked and that tracking is integrated with the
> > atomic
> > + * modest interface. During an atomic operation, a PLL can be requested for
> > a
> > + * given crtc and encoder configuration by calling intel_get_shared_dpll()
> > and
> s/crtc/CRTC/ for consistency (abbreviations are all upercase), pls do that
> on the entire doc.
> 
> > 
> > + * a previously used PLL can be released with intel_release_shared_dpll().
> > + * Changes to the users are first staged in the atomic state, and then made
> > + * effective by calling intel_shared_dpll_swap_state() during the atomic
> > + * commit phase.
> > + */
> > +
> >  struct intel_shared_dpll *
> >  skl_find_link_pll(struct drm_i915_private *dev_priv, int clock)
> >  {
> > @@ -61,6 +80,14 @@ skl_find_link_pll(struct drm_i915_private *dev_priv, int
> > clock)
> >     return pll;
> >  }
> >  
> > +/**
> > + * intel_get_shared_dpll_by_id - get a DPLL given its id
> > + * @dev_priv: i915 device instance
> > + * @id: pll id
> > + *
> > + * Returns:
> > + * A pointer to the DPLL with @id
> > + */
> >  struct intel_shared_dpll *
> >  intel_get_shared_dpll_by_id(struct drm_i915_private *dev_priv,
> >     enum intel_dpll_id id)
> > @@ -68,6 +95,14 @@ intel_get_shared_dpll_by_id(struct drm_i915_private
> > *dev_priv,
> >     return _priv->shared_dplls[id];
> >  }
> >  
> > +/**
> > + * intel_get_shared_dpll_id - get the id of a DPLL
> > + * @dev_priv: i915 device instance
> > + * @pll: the DPLL
> > + *
> > + * Returns:
> > + * The id of @pll
> > + */
> >  enum intel_dpll_id
> >  intel_get_shared_dpll_id(struct drm_i915_private *dev_priv,
> >      struct intel_shared_dpll *pll)
> > @@ -96,6 +131,13 @@ void assert_shared_dpll(struct drm_i915_private
> > *dev_priv,
> >     pll->name, onoff(state), onoff(cur_state));
> >  }
> >  
> > +/**
> > + * intel_prepare_shared_dpll - call a dpll's prepare hook
> > + * @crtc: crtc which has a shared dpll
> > + *
> > + * This calls the PLL's prepare hook if it has one and if the PLL is not
> > + * already enabled. The prepare hook is platform specific.
> > + */
> >  void intel_prepare_shared_dpll(struct intel_crtc *crtc)
> >  {
> >     struct drm_device *dev = crtc->base.dev;
> > @@ -118,12 +160,10 @@ void intel_prepare_shared_dpll(struct intel_crtc
> > *crtc)
> >  }
> >  
> >  /**
> > - * intel_enable_shared_dpll - enable PCH PLL
> > - * @dev_priv: i915 private 

Re: [Intel-gfx] [PATCH] drm: Fix LSPCON kernel-doc

2016-10-19 Thread Ville Syrjälä
On Wed, Oct 19, 2016 at 02:43:24PM +0300, Jani Nikula wrote:
> Fix warnings on building htmldocs.
> 
> Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
> Cc: Rodrigo Vivi 
> Cc: Shashank Sharma 
> Cc: 
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> n.b. 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") has
> been merged via drm-intel tree
> ---
>  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 14 +++---
>  include/drm/drm_dp_dual_mode_helper.h | 15 ---
>  2 files changed, 15 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
> b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> index 2624e266abbd..488355bdafb9 100644
> --- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> @@ -377,9 +377,9 @@ EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);
>  
>  /**
>   * drm_lspcon_get_mode: Get LSPCON's current mode of operation by
> - * by reading offset (0x80, 0x41)
> - * @i2c_adapter: I2C-over-aux adapter
> - * @current_mode: out vaiable, current lspcon mode of operation
> + * reading offset (0x80, 0x41)
> + * @adapter: I2C-over-aux adapter
> + * @mode: current lspcon mode of operation output variable
>   *
>   * Returns:
>   * 0 on success, sets the current_mode value to appropriate mode
> @@ -413,10 +413,10 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
>  EXPORT_SYMBOL(drm_lspcon_get_mode);
>  
>  /**
> - * drm_lspcon_change_mode: Change LSPCON's mode of operation by
> - * by writing offset (0x80, 0x40)
> - * @i2c_adapter: I2C-over-aux adapter
> - * @reqd_mode: required mode of operation
> + * drm_lspcon_set_mode: Change LSPCON's mode of operation by
> + * writing offset (0x80, 0x40)
> + * @adapter: I2C-over-aux adapter
> + * @mode: required mode of operation
>   *
>   * Returns:
>   * 0 on success, -error on failure/timeout
> diff --git a/include/drm/drm_dp_dual_mode_helper.h 
> b/include/drm/drm_dp_dual_mode_helper.h
> index 55677704add8..1f04c5cfd402 100644
> --- a/include/drm/drm_dp_dual_mode_helper.h
> +++ b/include/drm/drm_dp_dual_mode_helper.h
> @@ -70,12 +70,13 @@ ssize_t drm_dp_dual_mode_write(struct i2c_adapter 
> *adapter,
>  u8 offset, const void *buffer, size_t size);
>  
>  /**
> -* enum drm_lspcon_mode
> -* @lspcon_mode_ls: Level shifter mode of LSPCON
> -*which drives DP++ to HDMI 1.4 conversion.
> -* @lspcon_mode_pcon: Protocol converter mode of LSPCON
> -*which drives DP++ to HDMI 2.0 active conversion.
> -*/
> + * enum drm_lspcon_mode
> + * @DRM_LSPCON_MODE_INVALID: No LSPCON.
> + * @DRM_LSPCON_MODE_LS: Level shifter mode of LSPCON
> + *   which drives DP++ to HDMI 1.4 conversion.
> + * @DRM_LSPCON_MODE_PCON: Protocol converter mode of LSPCON
> + *   which drives DP++ to HDMI 2.0 active conversion.
> + */
>  enum drm_lspcon_mode {
>   DRM_LSPCON_MODE_INVALID,
>   DRM_LSPCON_MODE_LS,
> @@ -90,7 +91,7 @@ enum drm_lspcon_mode {
>   * @DRM_DP_DUAL_MODE_TYPE1_HDMI: Type 1 HDMI adaptor
>   * @DRM_DP_DUAL_MODE_TYPE2_DVI: Type 2 DVI adaptor
>   * @DRM_DP_DUAL_MODE_TYPE2_HDMI: Type 2 HDMI adaptor
> - * @DRM_DP_DUAL_MODE_TYPE2_LSPCON: Level shifter /protocol converter
> + * @DRM_DP_DUAL_MODE_LSPCON: Level shifter /protocol converter

May want to fix up the whitespace around '/' a bit too. Looks weird now.

>   */
>  enum drm_dp_dual_mode_type {
>   DRM_DP_DUAL_MODE_NONE,
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


[Intel-gfx] [PATCH] drm: Fix LSPCON kernel-doc

2016-10-19 Thread Jani Nikula
Fix warnings on building htmldocs.

Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
Cc: Rodrigo Vivi 
Cc: Shashank Sharma 
Cc: 
Signed-off-by: Jani Nikula 

---

n.b. 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") has
been merged via drm-intel tree
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 14 +++---
 include/drm/drm_dp_dual_mode_helper.h | 15 ---
 2 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 2624e266abbd..488355bdafb9 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -377,9 +377,9 @@ EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);
 
 /**
  * drm_lspcon_get_mode: Get LSPCON's current mode of operation by
- * by reading offset (0x80, 0x41)
- * @i2c_adapter: I2C-over-aux adapter
- * @current_mode: out vaiable, current lspcon mode of operation
+ * reading offset (0x80, 0x41)
+ * @adapter: I2C-over-aux adapter
+ * @mode: current lspcon mode of operation output variable
  *
  * Returns:
  * 0 on success, sets the current_mode value to appropriate mode
@@ -413,10 +413,10 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
 EXPORT_SYMBOL(drm_lspcon_get_mode);
 
 /**
- * drm_lspcon_change_mode: Change LSPCON's mode of operation by
- * by writing offset (0x80, 0x40)
- * @i2c_adapter: I2C-over-aux adapter
- * @reqd_mode: required mode of operation
+ * drm_lspcon_set_mode: Change LSPCON's mode of operation by
+ * writing offset (0x80, 0x40)
+ * @adapter: I2C-over-aux adapter
+ * @mode: required mode of operation
  *
  * Returns:
  * 0 on success, -error on failure/timeout
diff --git a/include/drm/drm_dp_dual_mode_helper.h 
b/include/drm/drm_dp_dual_mode_helper.h
index 55677704add8..1f04c5cfd402 100644
--- a/include/drm/drm_dp_dual_mode_helper.h
+++ b/include/drm/drm_dp_dual_mode_helper.h
@@ -70,12 +70,13 @@ ssize_t drm_dp_dual_mode_write(struct i2c_adapter *adapter,
   u8 offset, const void *buffer, size_t size);
 
 /**
-* enum drm_lspcon_mode
-* @lspcon_mode_ls: Level shifter mode of LSPCON
-*  which drives DP++ to HDMI 1.4 conversion.
-* @lspcon_mode_pcon: Protocol converter mode of LSPCON
-*  which drives DP++ to HDMI 2.0 active conversion.
-*/
+ * enum drm_lspcon_mode
+ * @DRM_LSPCON_MODE_INVALID: No LSPCON.
+ * @DRM_LSPCON_MODE_LS: Level shifter mode of LSPCON
+ * which drives DP++ to HDMI 1.4 conversion.
+ * @DRM_LSPCON_MODE_PCON: Protocol converter mode of LSPCON
+ * which drives DP++ to HDMI 2.0 active conversion.
+ */
 enum drm_lspcon_mode {
DRM_LSPCON_MODE_INVALID,
DRM_LSPCON_MODE_LS,
@@ -90,7 +91,7 @@ enum drm_lspcon_mode {
  * @DRM_DP_DUAL_MODE_TYPE1_HDMI: Type 1 HDMI adaptor
  * @DRM_DP_DUAL_MODE_TYPE2_DVI: Type 2 DVI adaptor
  * @DRM_DP_DUAL_MODE_TYPE2_HDMI: Type 2 HDMI adaptor
- * @DRM_DP_DUAL_MODE_TYPE2_LSPCON: Level shifter /protocol converter
+ * @DRM_DP_DUAL_MODE_LSPCON: Level shifter /protocol converter
  */
 enum drm_dp_dual_mode_type {
DRM_DP_DUAL_MODE_NONE,
-- 
2.1.4

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


[Intel-gfx] [PATCH] drm/i915: Handle early failure during intel_get_load_detect_pipe

2016-10-19 Thread Chris Wilson
In the error path, we have to be ready to handle an error before either
the state or restore_state have been allocated.

[  397.001342] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[  397.001419] IP: [] intel_get_load_detect_pipe+0xe4/0x610 
[i915]
[  397.001502] PGD 136a2a067
[  397.001523] PUD 134b5f067
[  397.001546] PMD 0

[  397.001569] Oops: 0002 [#1] PREEMPT SMP
[  397.001599] Modules linked in: snd_hda_intel i915 cdc_ncm usbnet mii 
x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul 
ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_realtek 
snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm lpc_ich 
mei_me mei sdhci_pci sdhci mmc_core e1000e ptp pps_core [last unloaded: i915]
[  397.001902] CPU: 1 PID: 9287 Comm: kms_force_conne Tainted: G U  
4.9.0-rc1-CI-CI_DRM_1730+ #1
[  397.001965] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 ) 
07/02/2012
[  397.002017] task: 880138c38040 task.stack: c900083e4000
[  397.002057] RIP: 0010:[]  [] 
intel_get_load_detect_pipe+0xe4/0x610 [i915]
[  397.002153] RSP: 0018:c900083e7ae8  EFLAGS: 00010286
[  397.002191] RAX: ffdd RBX: c900083e7bc8 RCX: 0006
[  397.002239] RDX: 0006 RSI: 880138c388b8 RDI: c900083e79e0
[  397.002287] RBP: c900083e7b78 R08:  R09: 
[  397.002335] R10:  R11:  R12: 
[  397.002386] R13: 8801305e1158 R14: ffdd R15: 
[  397.002434] FS:  7fea1b03c740() GS:88013e24() 
knlGS:
[  397.002488] CS:  0010 DS:  ES:  CR0: 80050033
[  397.002528] CR2:  CR3: 0001361da000 CR4: 001406e0
[  397.002576] Stack:
[  397.002592]  88013046f180  c900083e7bc0 

[  397.002655]   8801306bd038 88012e98 
c901
[  397.002718]  c900 880136b8ca88 88012e980890 
88012e980540
[  397.002780] Call Trace:
[  397.002828]  [] intel_crt_detect+0x3c4/0x8f0 [i915]
[  397.002876]  [] ? vprintk_default+0x1a/0x20
[  397.002918]  [] ? printk+0x43/0x4b
[  397.002956]  [] 
drm_helper_probe_single_connector_modes+0x406/0x4f0
[  397.003014]  [] ? mutex_unlock+0x9/0x10
[  397.003054]  [] drm_mode_getconnector+0x33c/0x3c0
[  397.003099]  [] ? debug_lockdep_rcu_enabled+0x1d/0x20
[  397.003147]  [] ? __might_fault+0x3e/0x90
[  397.003191]  [] drm_ioctl+0x1f6/0x480
[  397.003231]  [] ? 
drm_mode_connector_property_set_ioctl+0x30/0x30
[  397.003285]  [] do_vfs_ioctl+0x8e/0x690
[  397.003324]  [] ? task_work_run+0x8c/0xb0
[  397.003366]  [] ? trace_hardirqs_on_caller+0x122/0x1b0
[  397.003412]  [] SyS_ioctl+0x3c/0x70
[  397.003451]  [] entry_SYSCALL_64_fastpath+0x1c/0xb1
[  397.003496] Code: 85 c0 41 89 c6 75 57 49 8b 85 f0 00 00 00 48 89 de 45 31 
ff 48 8d 78 20 e8 1a 89 13 e1 45 31 c9 85 c0 41 89 c6 0f 84 2f 01 00 00  41 
83 29 01 74 53 f0 41 83 2f 01 74 2d 41 83 fe dd 75 35 48
[  397.003837] RIP  [] intel_get_load_detect_pipe+0xe4/0x610 
[i915]
[  397.003921]  RSP 
[  397.003947] CR2: 

Testcase: igt/kms_force_connector_basic/force-load-detect # ivb-3720m
Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state"
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_display.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 69b9e91f071e..e64a7edd5e60 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11283,9 +11283,14 @@ bool intel_get_load_detect_pipe(struct drm_connector 
*connector,
return true;
 
 fail:
-   drm_atomic_state_put(state);
-   drm_atomic_state_put(restore_state);
-   restore_state = state = NULL;
+   if (state) {
+   drm_atomic_state_put(state);
+   state = NULL;
+   }
+   if (restore_state) {
+   drm_atomic_state_put(restore_state);
+   restore_state = NULL;
+   }
 
if (ret == -EDEADLK) {
drm_modeset_backoff(ctx);
-- 
2.9.3

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


Re: [Intel-gfx] IGT contributions and reviews

2016-10-19 Thread Jani Nikula
On Wed, 19 Oct 2016, Daniel Vetter  wrote:
> On Tue, Oct 18, 2016 at 07:33:10PM +0300, Jani Nikula wrote:
>> On Tue, 18 Oct 2016, Petri Latvala  wrote:
>> > The current contributing docs for IGT state:
>> >
>> > <<
>> >   There is no formal review requirement and regular contributors with
>> >   commit access can push patches right after submitting them to the
>> >   mailing lists. But invasive changes, new helper libraries and
>> >   contributions from newcomers should go through a proper review to
>> >   ensure overall consistency in the codebase.
>> >>>
>> >
>> >
>> > While not requiring reviews or acks has definitely increased the
>> > speed of development, I feel the time for slowing down a bit has
>> > come.
>> 
>> Agreed. (Though a more rigorous review requirement doesn't necessarily
>> slow things down in the big picture.)
>> 
>> > At the very least I would like to see all commits have a visit to the
>> > mailing list before pushing, as the current docs already ask for. The
>> > "right after" part would be changed to a $period of quarantine, maybe
>> > 24 hours?
>> 
>> Sounds good to me.
>
> We've already had this, and people stopped bothering. What will be
> different this time around? I feel a bit like we do need to be a bit more
> formal here, to really make this stick ...
>
> Also, who's going to be the annoying maintainer who reminds everyone every
> time they break the rules? It'll take some serious effort here to get
> folks off their well-trodded paths onto a new one I think.

What's your concrete proposal?

BR,
Jani.


> -Daniel
>
>> > As for requiring reviews or acks before pushing, how do the developers
>> > at large feel about that? Different rules for different parts of IGT?
>> > (Benchmarks, tools, tests, CI test sets, lib)
>> 
>> I think there are two big buckets here:
>> 
>> * Tests in BAT and the BAT set list. I think we need r-b/ack on the
>>   mailing list on these changes before pushing. (In the long run, I'd
>>   like to have these go through a CI run with everything else unchanged
>>   too.)
>> 
>> * Everything else. Other tests and tools. I'd be happy with requiring
>>   the patches are sent to the list, and either receiving r-b/ack or 24
>>   hrs during weekdays without negative feedback.
>> 
>> > The goal with this discussion is to reach a suitable tradeoff between
>> > stability from CI point of view and fruitful use of programmer time.
>> 
>> Thanks for starting the discussion.
>> 
>> 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

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


Re: [Intel-gfx] [PATCH 1/2] drm: make is_lspcon_adaptor static

2016-10-19 Thread Jani Nikula
On Tue, 18 Oct 2016, "Sharma, Shashank"  wrote:
> Reviewed-by: Shashank Sharma

Both pushed to drm-intel-next-queued, thanks for the review.

RB,
Jani.

>
> Regards
> Shashank
> -Original Message-
> From: Nikula, Jani 
> Sent: Tuesday, October 18, 2016 4:52 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; Vivi, Rodrigo 
> ; Sharma, Shashank ; 
> dri-de...@lists.freedesktop.org
> Subject: [PATCH 1/2] drm: make is_lspcon_adaptor static
>
> Fixes sparse warning:
>
> drivers/gpu/drm/drm_dp_dual_mode_helper.c:151:6: warning: symbol 
> 'is_lspcon_adaptor' was not declared. Should it be static?
>
> Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
> Cc: Rodrigo Vivi 
> Cc: Shashank Sharma 
> Cc: 
> Signed-off-by: Jani Nikula 
>
> ---
>
> n.b. 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") has been 
> merged via drm-intel tree
> ---
>  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
> b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> index a7aeb1ec852c..2624e266abbd 100644
> --- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> @@ -148,8 +148,8 @@ static bool is_type2_adaptor(uint8_t adaptor_id)
> DP_DUAL_MODE_REV_TYPE2);
>  }
>  
> -bool is_lspcon_adaptor(const char hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN],
> - const uint8_t adaptor_id)
> +static bool is_lspcon_adaptor(const char hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN],
> +   const uint8_t adaptor_id)
>  {
>   return is_hdmi_adaptor(hdmi_id) &&
>   (adaptor_id == (DP_DUAL_MODE_TYPE_TYPE2 |
> --
> 2.1.4
>

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


Re: [Intel-gfx] [PATCH] drm: fix sparse warnings on undeclared symbols in crc debugfs

2016-10-19 Thread Jani Nikula
On Tue, 18 Oct 2016, Chris Wilson  wrote:
> On Tue, Oct 18, 2016 at 02:28:35PM +0300, Jani Nikula wrote:
>> Fixes sparse warnings:
>> 
>> drivers/gpu/drm/drm_debugfs_crc.c:118:30: warning: symbol
>> 'drm_crtc_crc_control_fops' was not declared. Should it be static?
>> 
>> drivers/gpu/drm/drm_debugfs_crc.c:264:30: warning: symbol
>> 'drm_crtc_crc_data_fops' was not declared. Should it be static?
>> 
>> drivers/gpu/drm/drm_debugfs_crc.c:281:5: warning: symbol
>> 'drm_debugfs_crtc_crc_add' was not declared. Should it be static?
>> 
>> Fixes: 9edbf1fa600a ("drm: Add API for capturing frame CRCs")
>> Cc: Benjamin Gaignard 
>> Cc: Daniel Vetter 
>> Cc: Emil Velikov 
>> Cc: Tomeu Vizoso 
>> Signed-off-by: Jani Nikula 
> Reviewed-by: Chris Wilson 

Pushed to drm-misc, thanks for the review.

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] gvt gem fixes

2016-10-19 Thread Chris Wilson
On Wed, Oct 19, 2016 at 06:45:51PM +0800, Zhenyu Wang wrote:
> On 2016.10.19 11:11:35 +0100, Chris Wilson wrote:
> > I think this is the set required to bring gvt into line, at least to
> > unblock myself.
> 
> Thanks a lot, Chris. I'd like to merge this in next pull request,
> or let me know you want to be picked up by drm-intel directly.
> If 4/12 would be picked up alone, I'll skip that one in gvt tree.

If you are confident in having the pull ready in the next day or so,
I'll just preface my series with these and they will evaporate after the
merge.

I'll apply 4/12 right now to get that out of the way.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/gvt: Stop checking for impossible interrupts from a kthread (rev2)

2016-10-19 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/gvt: Stop checking for impossible 
interrupts from a kthread (rev2)
URL   : https://patchwork.freedesktop.org/series/14004/
State : failure

== Summary ==

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

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m)
incomplete -> PASS   (fi-snb-2600)
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:181  dwarn:0   dfail:0   fail:5   skip:60 
fi-ivb-3520m total:186  pass:164  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:209  pass:176  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2754/

8bbf308ef2835c2b631f339d9d9d26e817934c84 drm-intel-nightly: 
2016y-10m-19d-07h-44m-01s UTC integration manifest
74f5ac5 drm/i915/gvt: Stop waiting whilst holding struct_mutex
0346400 drm/i915/gvt: Stop checking for impossible interrupts from a kthread

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


Re: [Intel-gfx] [PATCH 07/12] drm/i915/gvt: Hold a reference on the request

2016-10-19 Thread Chris Wilson
On Wed, Oct 19, 2016 at 06:32:54PM +0800, Zhenyu Wang wrote:
> On 2016.10.19 11:11:42 +0100, Chris Wilson wrote:
> > The workload took a pointer to the request, and even waited upon,
> > without holding a reference on the request. Take that reference
> > explicitly and fix up the error path following request allocation that
> > missed flushing the request.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/gvt/scheduler.c | 24 +---
> >  1 file changed, 13 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> > b/drivers/gpu/drm/i915/gvt/scheduler.c
> > index b15cdf5978a9..224f19ae61ab 100644
> > --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> > +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> > @@ -163,6 +163,7 @@ static int dispatch_workload(struct intel_vgpu_workload 
> > *workload)
> > int ring_id = workload->ring_id;
> > struct i915_gem_context *shadow_ctx = workload->vgpu->shadow_ctx;
> > struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
> > +   struct drm_i915_gem_request *rq;
> > int ret;
> >  
> > gvt_dbg_sched("ring id %d prepare to dispatch workload %p\n",
> > @@ -171,17 +172,16 @@ static int dispatch_workload(struct 
> > intel_vgpu_workload *workload)
> > shadow_ctx->desc_template = workload->ctx_desc.addressing_mode <<
> > GEN8_CTX_ADDRESSING_MODE_SHIFT;
> >  
> > -   workload->req = i915_gem_request_alloc(dev_priv->engine[ring_id],
> > -  shadow_ctx);
> > -   if (IS_ERR_OR_NULL(workload->req)) {
> > +   rq = i915_gem_request_alloc(dev_priv->engine[ring_id], shadow_ctx);
> > +   if (IS_ERR(rq)) {
> > gvt_err("fail to allocate gem request\n");
> > -   workload->status = PTR_ERR(workload->req);
> > -   workload->req = NULL;
> > +   workload->status = PTR_ERR(rq);
> > return workload->status;
> > }
> >  
> > -   gvt_dbg_sched("ring id %d get i915 gem request %p\n",
> > -   ring_id, workload->req);
> > +   gvt_dbg_sched("ring id %d get i915 gem request %p\n", ring_id, rq);
> > +
> > +   workload->req = i915_gem_request_get(rq);
> >  
> > mutex_lock(>lock);
> >  
> > @@ -208,16 +208,16 @@ static int dispatch_workload(struct 
> > intel_vgpu_workload *workload)
> > gvt_dbg_sched("ring id %d submit workload to i915 %p\n",
> > ring_id, workload->req);
> >  
> > -   i915_add_request_no_flush(workload->req);
> > -
> > +   i915_add_request_no_flush(rq);
> > workload->dispatched = true;
> > return 0;
> >  err:
> > workload->status = ret;
> > -   if (workload->req)
> > -   workload->req = NULL;
> > +   i915_gem_request_put(fetch_and_zero(>req));
> >  
> > mutex_unlock(>lock);
> 
> Might not need to hold gvt->lock when put request?

I was just updating the current worklod->req = NULL which was under the
lock, using the same code as later. You can drop i915_gem_request_put(rq)
afterwards which is what I did at first, before deciding using the same
style for both was nicer.

> > +
> > +   i915_add_request_no_flush(rq);
> 
> Why still add request in error path?

The request may have changed global state which is now associated with
the request. You have to pass it back upon completion, whether or not
you have added your own workload to the request.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] gvt gem fixes

2016-10-19 Thread Zhenyu Wang
On 2016.10.19 11:11:35 +0100, Chris Wilson wrote:
> I think this is the set required to bring gvt into line, at least to
> unblock myself.

Thanks a lot, Chris. I'd like to merge this in next pull request,
or let me know you want to be picked up by drm-intel directly.
If 4/12 would be picked up alone, I'll skip that one in gvt tree.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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 v4 2/2] drm/i915: Make GPU pages movable

2016-10-19 Thread Joonas Lahtinen
On ti, 2016-10-18 at 14:39 +0100, Chris Wilson wrote:
> It's in my tree (on top of nightly) already with Joonas' r-b.

Patch 1/2 seems to have my comments already, could be addressed and
respined too.

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 08/41] drm/i915: Rearrange i915_wait_request() accounting with callers

2016-10-19 Thread Joonas Lahtinen
On ti, 2016-10-18 at 19:51 +0100, Matthew Auld wrote:
> > 
> >   * Returns 0 if the request was found within the alloted time.
> > Else returns the
> >   * errno with remaining time filled in timeout argument.
> >   */
> > -int i915_wait_request(struct drm_i915_gem_request *req,
> > - unsigned int flags,
> > - s64 *timeout,
> > - struct intel_rps_client *rps)
> > +long i915_wait_request(struct drm_i915_gem_request *req,
> > +  unsigned int flags,
> > +  long timeout)
> >  {
> A good time to update the kernel doc here?

Good catch, should definitely be done.

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] ✗ Fi.CI.BAT: failure for series starting with [CI,1/4] drm/i915: Bump object bookkeeping to u64 from size_t

2016-10-19 Thread Chris Wilson
On Tue, Oct 18, 2016 at 05:46:48PM +, Saarinen, Jani wrote:
> > On Tue, Oct 18, 2016 at 01:05:24PM -, Patchwork wrote:
> > > == Series Details ==
> > >
> > > Series: series starting with [CI,1/4] drm/i915: Bump object bookkeeping to
> > u64 from size_t
> > > URL   : https://patchwork.freedesktop.org/series/13950/
> > > State : failure
> > >
> > > == Summary ==
> > >
> > > Series 13950v1 Series without cover letter
> > > https://patchwork.freedesktop.org/api/1.0/series/13950/revisions/1/mbo
> > > x/
> > >
> > > Test gem_exec_suspend:
> > > Subgroup basic-s3:
> > > pass   -> INCOMPLETE (fi-snb-2600)
> > > dmesg-warn -> INCOMPLETE (fi-skl-6700hq)
> > 
> > New sporadic failures not observed on the prior trybot pass.
> > Challenge for CI to gather some logs.
> Or is this actually just still not covered from all rc1 breakages?

Looks to be a separate issue, but definitely new in rc1 afaict.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 07/12] drm/i915/gvt: Hold a reference on the request

2016-10-19 Thread Zhenyu Wang
On 2016.10.19 11:11:42 +0100, Chris Wilson wrote:
> The workload took a pointer to the request, and even waited upon,
> without holding a reference on the request. Take that reference
> explicitly and fix up the error path following request allocation that
> missed flushing the request.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/gvt/scheduler.c | 24 +---
>  1 file changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> b/drivers/gpu/drm/i915/gvt/scheduler.c
> index b15cdf5978a9..224f19ae61ab 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -163,6 +163,7 @@ static int dispatch_workload(struct intel_vgpu_workload 
> *workload)
>   int ring_id = workload->ring_id;
>   struct i915_gem_context *shadow_ctx = workload->vgpu->shadow_ctx;
>   struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
> + struct drm_i915_gem_request *rq;
>   int ret;
>  
>   gvt_dbg_sched("ring id %d prepare to dispatch workload %p\n",
> @@ -171,17 +172,16 @@ static int dispatch_workload(struct intel_vgpu_workload 
> *workload)
>   shadow_ctx->desc_template = workload->ctx_desc.addressing_mode <<
>   GEN8_CTX_ADDRESSING_MODE_SHIFT;
>  
> - workload->req = i915_gem_request_alloc(dev_priv->engine[ring_id],
> -shadow_ctx);
> - if (IS_ERR_OR_NULL(workload->req)) {
> + rq = i915_gem_request_alloc(dev_priv->engine[ring_id], shadow_ctx);
> + if (IS_ERR(rq)) {
>   gvt_err("fail to allocate gem request\n");
> - workload->status = PTR_ERR(workload->req);
> - workload->req = NULL;
> + workload->status = PTR_ERR(rq);
>   return workload->status;
>   }
>  
> - gvt_dbg_sched("ring id %d get i915 gem request %p\n",
> - ring_id, workload->req);
> + gvt_dbg_sched("ring id %d get i915 gem request %p\n", ring_id, rq);
> +
> + workload->req = i915_gem_request_get(rq);
>  
>   mutex_lock(>lock);
>  
> @@ -208,16 +208,16 @@ static int dispatch_workload(struct intel_vgpu_workload 
> *workload)
>   gvt_dbg_sched("ring id %d submit workload to i915 %p\n",
>   ring_id, workload->req);
>  
> - i915_add_request_no_flush(workload->req);
> -
> + i915_add_request_no_flush(rq);
>   workload->dispatched = true;
>   return 0;
>  err:
>   workload->status = ret;
> - if (workload->req)
> - workload->req = NULL;
> + i915_gem_request_put(fetch_and_zero(>req));
>  
>   mutex_unlock(>lock);

Might not need to hold gvt->lock when put request?

> +
> + i915_add_request_no_flush(rq);

Why still add request in error path?

>   return ret;
>  }
>  
> @@ -458,6 +458,8 @@ static int workload_thread(void *priv)
>  
>   complete_current_workload(gvt, ring_id);
>  
> + i915_gem_request_put(fetch_and_zero(>req));
> +
>   if (need_force_wake)
>   intel_uncore_forcewake_put(gvt->dev_priv,
>   FORCEWAKE_ALL);
> -- 
> 2.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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 10/12] drm/i915/gvt: Use common mapping routines for indirect_ctx object

2016-10-19 Thread Zhenyu Wang
On 2016.10.19 11:11:45 +0100, Chris Wilson wrote:
> We have the ability to map an object, so use it rather than opencode it
> badly.
> 
> Signed-off-by: Chris Wilson 

Planned to fix these mapping too, obviously not fast than you..

Reviewed-by: Zhenyu Wang 

> ---
>  drivers/gpu/drm/i915/gvt/cmd_parser.c | 28 +---
>  drivers/gpu/drm/i915/gvt/execlist.c   |  2 +-
>  2 files changed, 10 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
> b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> index 464fc3c9935b..2b16609b 100644
> --- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> +++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> @@ -2715,7 +2715,7 @@ static int shadow_indirect_ctx(struct 
> intel_shadow_wa_ctx *wa_ctx)
>   unsigned long guest_gma = wa_ctx->indirect_ctx.guest_gma;
>   struct drm_i915_gem_object *obj;
>   int ret = 0;
> - void *dest = NULL;
> + void *map;
>  
>   obj = i915_gem_object_create(dev,
>roundup(ctx_size + CACHELINE_BYTES,
> @@ -2723,18 +2723,12 @@ static int shadow_indirect_ctx(struct 
> intel_shadow_wa_ctx *wa_ctx)
>   if (IS_ERR(obj))
>   return PTR_ERR(obj);
>  
> - ret = i915_gem_object_get_pages(obj);
> - if (ret)
> - goto put_obj;
> -
> - i915_gem_object_pin_pages(obj);
> -
>   /* get the va of the shadow batch buffer */
> - dest = (void *)vmap_batch(obj, 0, ctx_size + CACHELINE_BYTES);
> - if (!dest) {
> + map = i915_gem_object_pin_map(obj, I915_MAP_WB);
> + if (IS_ERR(map)) {
>   gvt_err("failed to vmap shadow indirect ctx\n");
> - ret = -ENOMEM;
> - goto unpin_src;
> + ret = PTR_ERR(map);
> + goto put_obj;
>   }
>  
>   ret = i915_gem_object_set_to_cpu_domain(obj, false);
> @@ -2743,25 +2737,21 @@ static int shadow_indirect_ctx(struct 
> intel_shadow_wa_ctx *wa_ctx)
>   goto unmap_src;
>   }
>  
> - wa_ctx->indirect_ctx.shadow_va = dest;
> -
> - memset(dest, 0, round_up(ctx_size + CACHELINE_BYTES, PAGE_SIZE));
> -
>   ret = copy_gma_to_hva(wa_ctx->workload->vgpu,
>   wa_ctx->workload->vgpu->gtt.ggtt_mm,
> - guest_gma, guest_gma + ctx_size, dest);
> + guest_gma, guest_gma + ctx_size,
> + map);
>   if (ret) {
>   gvt_err("fail to copy guest indirect ctx\n");
>   goto unmap_src;
>   }
>  
>   wa_ctx->indirect_ctx.obj = obj;
> + wa_ctx->indirect_ctx.shadow_va = map;
>   return 0;
>  
>  unmap_src:
> - vunmap(dest);
> -unpin_src:
> - i915_gem_object_unpin_pages(wa_ctx->indirect_ctx.obj);
> + i915_gem_object_unpin_map(obj);
>  put_obj:
>   i915_gem_object_put(wa_ctx->indirect_ctx.obj);
>   return ret;
> diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
> b/drivers/gpu/drm/i915/gvt/execlist.c
> index b79d148a4e32..d8a6d6366899 100644
> --- a/drivers/gpu/drm/i915/gvt/execlist.c
> +++ b/drivers/gpu/drm/i915/gvt/execlist.c
> @@ -517,8 +517,8 @@ static void release_shadow_wa_ctx(struct 
> intel_shadow_wa_ctx *wa_ctx)
>   if (wa_ctx->indirect_ctx.size == 0)
>   return;
>  
> + i915_gem_object_unpin_map(wa_ctx->indirect_ctx.obj);
>   i915_gem_object_put(wa_ctx->indirect_ctx.obj);
> - kvfree(wa_ctx->indirect_ctx.shadow_va);
>  }
>  
>  static int complete_execlist_workload(struct intel_vgpu_workload *workload)
> -- 
> 2.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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 04/12] drm/i915: Catch premature unpinning of pages

2016-10-19 Thread Joonas Lahtinen
On ke, 2016-10-19 at 11:11 +0100, Chris Wilson wrote:
> Try to catch the violation of unpinning the backing storage whilst still
> bound to the GPU.
> 
> 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


[Intel-gfx] [PATCH 12/12] drm/i915/gvt: Remove defunct vmap_batch()

2016-10-19 Thread Chris Wilson
This code was removed from i915_cmd_parser.c but still an obsolete
version wound up being duplicated into gvt/cmd_parser.c. Good riddance.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gvt/cmd_parser.c | 38 ---
 1 file changed, 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index a91405df394d..84759ef8bb17 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -1581,44 +1581,6 @@ static uint32_t find_bb_size(struct parser_exec_state *s)
return bb_size;
 }
 
-static u32 *vmap_batch(struct drm_i915_gem_object *obj,
-  unsigned int start, unsigned int len)
-{
-   int i;
-   void *addr = NULL;
-   struct sg_page_iter sg_iter;
-   int first_page = start >> PAGE_SHIFT;
-   int last_page = (len + start + 4095) >> PAGE_SHIFT;
-   int npages = last_page - first_page;
-   struct page **pages;
-
-   pages = drm_malloc_ab(npages, sizeof(*pages));
-   if (pages == NULL) {
-   DRM_DEBUG_DRIVER("Failed to get space for pages\n");
-   goto finish;
-   }
-
-   i = 0;
-   for_each_sg_page(obj->pages->sgl, _iter, obj->pages->nents,
-first_page) {
-   pages[i++] = sg_page_iter_page(_iter);
-   if (i == npages)
-   break;
-   }
-
-   addr = vmap(pages, i, 0, PAGE_KERNEL);
-   if (addr == NULL) {
-   DRM_DEBUG_DRIVER("Failed to vmap pages\n");
-   goto finish;
-   }
-
-finish:
-   if (pages)
-   drm_free_large(pages);
-   return (u32 *)addr;
-}
-
-
 static int perform_bb_shadow(struct parser_exec_state *s)
 {
struct intel_shadow_bb_entry *entry_obj;
-- 
2.9.3

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


[Intel-gfx] [PATCH 10/12] drm/i915/gvt: Use common mapping routines for indirect_ctx object

2016-10-19 Thread Chris Wilson
We have the ability to map an object, so use it rather than opencode it
badly.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gvt/cmd_parser.c | 28 +---
 drivers/gpu/drm/i915/gvt/execlist.c   |  2 +-
 2 files changed, 10 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index 464fc3c9935b..2b16609b 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -2715,7 +2715,7 @@ static int shadow_indirect_ctx(struct intel_shadow_wa_ctx 
*wa_ctx)
unsigned long guest_gma = wa_ctx->indirect_ctx.guest_gma;
struct drm_i915_gem_object *obj;
int ret = 0;
-   void *dest = NULL;
+   void *map;
 
obj = i915_gem_object_create(dev,
 roundup(ctx_size + CACHELINE_BYTES,
@@ -2723,18 +2723,12 @@ static int shadow_indirect_ctx(struct 
intel_shadow_wa_ctx *wa_ctx)
if (IS_ERR(obj))
return PTR_ERR(obj);
 
-   ret = i915_gem_object_get_pages(obj);
-   if (ret)
-   goto put_obj;
-
-   i915_gem_object_pin_pages(obj);
-
/* get the va of the shadow batch buffer */
-   dest = (void *)vmap_batch(obj, 0, ctx_size + CACHELINE_BYTES);
-   if (!dest) {
+   map = i915_gem_object_pin_map(obj, I915_MAP_WB);
+   if (IS_ERR(map)) {
gvt_err("failed to vmap shadow indirect ctx\n");
-   ret = -ENOMEM;
-   goto unpin_src;
+   ret = PTR_ERR(map);
+   goto put_obj;
}
 
ret = i915_gem_object_set_to_cpu_domain(obj, false);
@@ -2743,25 +2737,21 @@ static int shadow_indirect_ctx(struct 
intel_shadow_wa_ctx *wa_ctx)
goto unmap_src;
}
 
-   wa_ctx->indirect_ctx.shadow_va = dest;
-
-   memset(dest, 0, round_up(ctx_size + CACHELINE_BYTES, PAGE_SIZE));
-
ret = copy_gma_to_hva(wa_ctx->workload->vgpu,
wa_ctx->workload->vgpu->gtt.ggtt_mm,
-   guest_gma, guest_gma + ctx_size, dest);
+   guest_gma, guest_gma + ctx_size,
+   map);
if (ret) {
gvt_err("fail to copy guest indirect ctx\n");
goto unmap_src;
}
 
wa_ctx->indirect_ctx.obj = obj;
+   wa_ctx->indirect_ctx.shadow_va = map;
return 0;
 
 unmap_src:
-   vunmap(dest);
-unpin_src:
-   i915_gem_object_unpin_pages(wa_ctx->indirect_ctx.obj);
+   i915_gem_object_unpin_map(obj);
 put_obj:
i915_gem_object_put(wa_ctx->indirect_ctx.obj);
return ret;
diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
b/drivers/gpu/drm/i915/gvt/execlist.c
index b79d148a4e32..d8a6d6366899 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.c
+++ b/drivers/gpu/drm/i915/gvt/execlist.c
@@ -517,8 +517,8 @@ static void release_shadow_wa_ctx(struct 
intel_shadow_wa_ctx *wa_ctx)
if (wa_ctx->indirect_ctx.size == 0)
return;
 
+   i915_gem_object_unpin_map(wa_ctx->indirect_ctx.obj);
i915_gem_object_put(wa_ctx->indirect_ctx.obj);
-   kvfree(wa_ctx->indirect_ctx.shadow_va);
 }
 
 static int complete_execlist_workload(struct intel_vgpu_workload *workload)
-- 
2.9.3

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


[Intel-gfx] [PATCH 07/12] drm/i915/gvt: Hold a reference on the request

2016-10-19 Thread Chris Wilson
The workload took a pointer to the request, and even waited upon,
without holding a reference on the request. Take that reference
explicitly and fix up the error path following request allocation that
missed flushing the request.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gvt/scheduler.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index b15cdf5978a9..224f19ae61ab 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -163,6 +163,7 @@ static int dispatch_workload(struct intel_vgpu_workload 
*workload)
int ring_id = workload->ring_id;
struct i915_gem_context *shadow_ctx = workload->vgpu->shadow_ctx;
struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
+   struct drm_i915_gem_request *rq;
int ret;
 
gvt_dbg_sched("ring id %d prepare to dispatch workload %p\n",
@@ -171,17 +172,16 @@ static int dispatch_workload(struct intel_vgpu_workload 
*workload)
shadow_ctx->desc_template = workload->ctx_desc.addressing_mode <<
GEN8_CTX_ADDRESSING_MODE_SHIFT;
 
-   workload->req = i915_gem_request_alloc(dev_priv->engine[ring_id],
-  shadow_ctx);
-   if (IS_ERR_OR_NULL(workload->req)) {
+   rq = i915_gem_request_alloc(dev_priv->engine[ring_id], shadow_ctx);
+   if (IS_ERR(rq)) {
gvt_err("fail to allocate gem request\n");
-   workload->status = PTR_ERR(workload->req);
-   workload->req = NULL;
+   workload->status = PTR_ERR(rq);
return workload->status;
}
 
-   gvt_dbg_sched("ring id %d get i915 gem request %p\n",
-   ring_id, workload->req);
+   gvt_dbg_sched("ring id %d get i915 gem request %p\n", ring_id, rq);
+
+   workload->req = i915_gem_request_get(rq);
 
mutex_lock(>lock);
 
@@ -208,16 +208,16 @@ static int dispatch_workload(struct intel_vgpu_workload 
*workload)
gvt_dbg_sched("ring id %d submit workload to i915 %p\n",
ring_id, workload->req);
 
-   i915_add_request_no_flush(workload->req);
-
+   i915_add_request_no_flush(rq);
workload->dispatched = true;
return 0;
 err:
workload->status = ret;
-   if (workload->req)
-   workload->req = NULL;
+   i915_gem_request_put(fetch_and_zero(>req));
 
mutex_unlock(>lock);
+
+   i915_add_request_no_flush(rq);
return ret;
 }
 
@@ -458,6 +458,8 @@ static int workload_thread(void *priv)
 
complete_current_workload(gvt, ring_id);
 
+   i915_gem_request_put(fetch_and_zero(>req));
+
if (need_force_wake)
intel_uncore_forcewake_put(gvt->dev_priv,
FORCEWAKE_ALL);
-- 
2.9.3

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


[Intel-gfx] [PATCH 06/12] drm/i915/gvt: Remove dangerous unpin of backing storage of bound GPU object

2016-10-19 Thread Chris Wilson
Unpinning the pages prior to the object being release from the GPU may
allow the GPU to read and write into system pages (i.e. use after free
by the hw).

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gvt/execlist.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
b/drivers/gpu/drm/i915/gvt/execlist.c
index cfdd3ae13fb0..b79d148a4e32 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.c
+++ b/drivers/gpu/drm/i915/gvt/execlist.c
@@ -404,7 +404,11 @@ static void prepare_shadow_batch_buffer(struct 
intel_vgpu_workload *workload)
gvt_err("Cannot pin\n");
return;
}
-   i915_gem_object_unpin_pages(entry_obj->obj);
+
+   /* FIXME: we are not tracking our pinned VMA leaving it
+* up to the core to fix up the stray pin_count upon
+* free.
+*/
 
/* update the relocate gma with shadow batch buffer*/
set_gma_to_bb_cmd(entry_obj,
@@ -454,7 +458,11 @@ static void prepare_shadow_wa_ctx(struct 
intel_shadow_wa_ctx *wa_ctx)
gvt_err("Cannot pin indirect ctx obj\n");
return;
}
-   i915_gem_object_unpin_pages(wa_ctx->indirect_ctx.obj);
+
+   /* FIXME: we are not tracking our pinned VMA leaving it
+* up to the core to fix up the stray pin_count upon
+* free.
+*/
 
wa_ctx->indirect_ctx.shadow_gma = i915_ggtt_offset(vma);
 
-- 
2.9.3

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


[Intel-gfx] [PATCH 01/12] drm/i915/gvt: s/drm_gem_object_unreference/i915_gem_object_put/

2016-10-19 Thread Chris Wilson
Deprecated functions; it is also not clear whether these are called from
the right context.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gvt/execlist.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
b/drivers/gpu/drm/i915/gvt/execlist.c
index c50a3d1a5131..a9d04c378755 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.c
+++ b/drivers/gpu/drm/i915/gvt/execlist.c
@@ -498,7 +498,7 @@ static void release_shadow_batch_buffer(struct 
intel_vgpu_workload *workload)
 
list_for_each_entry_safe(entry_obj, temp, >shadow_bb,
 list) {
-   drm_gem_object_unreference(&(entry_obj->obj->base));
+   i915_gem_object_put(entry_obj->obj);
kvfree(entry_obj->va);
list_del(_obj->list);
kfree(entry_obj);
@@ -511,7 +511,7 @@ static void release_shadow_wa_ctx(struct 
intel_shadow_wa_ctx *wa_ctx)
if (wa_ctx->indirect_ctx.size == 0)
return;
 
-   drm_gem_object_unreference(&(wa_ctx->indirect_ctx.obj->base));
+   i915_gem_object_put(wa_ctx->indirect_ctx.obj);
kvfree(wa_ctx->indirect_ctx.shadow_va);
 }
 
-- 
2.9.3

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


[Intel-gfx] [PATCH 05/12] drm/i915/gvt: Use the returned VMA to provide the virtual address

2016-10-19 Thread Chris Wilson
The purpose of returning the just-pinned VMA is so that we can use the
information within, like its address. Also it should be tracked and used
as the cookie to unpin...

Signed-off-by: Chris Wilson 
Reviewed-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/execlist.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
b/drivers/gpu/drm/i915/gvt/execlist.c
index a9d04c378755..cfdd3ae13fb0 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.c
+++ b/drivers/gpu/drm/i915/gvt/execlist.c
@@ -385,8 +385,6 @@ static int set_gma_to_bb_cmd(struct intel_shadow_bb_entry 
*entry_obj,
 static void prepare_shadow_batch_buffer(struct intel_vgpu_workload *workload)
 {
int gmadr_bytes = workload->vgpu->gvt->device_info.gmadr_bytes_in_cmd;
-   struct i915_vma *vma;
-   unsigned long gma;
 
/* pin the gem object to ggtt */
if (!list_empty(>shadow_bb)) {
@@ -398,8 +396,10 @@ static void prepare_shadow_batch_buffer(struct 
intel_vgpu_workload *workload)
 
list_for_each_entry_safe(entry_obj, temp, >shadow_bb,
list) {
+   struct i915_vma *vma;
+
vma = i915_gem_object_ggtt_pin(entry_obj->obj, NULL, 0,
-   0, 0);
+  4, 0);
if (IS_ERR(vma)) {
gvt_err("Cannot pin\n");
return;
@@ -407,9 +407,9 @@ static void prepare_shadow_batch_buffer(struct 
intel_vgpu_workload *workload)
i915_gem_object_unpin_pages(entry_obj->obj);
 
/* update the relocate gma with shadow batch buffer*/
-   gma = i915_gem_object_ggtt_offset(entry_obj->obj, NULL);
-   WARN_ON(!IS_ALIGNED(gma, 4));
-   set_gma_to_bb_cmd(entry_obj, gma, gmadr_bytes);
+   set_gma_to_bb_cmd(entry_obj,
+ i915_ggtt_offset(vma),
+ gmadr_bytes);
}
}
 }
@@ -441,7 +441,6 @@ static int update_wa_ctx_2_shadow_ctx(struct 
intel_shadow_wa_ctx *wa_ctx)
 static void prepare_shadow_wa_ctx(struct intel_shadow_wa_ctx *wa_ctx)
 {
struct i915_vma *vma;
-   unsigned long gma;
unsigned char *per_ctx_va =
(unsigned char *)wa_ctx->indirect_ctx.shadow_va +
wa_ctx->indirect_ctx.size;
@@ -449,16 +448,15 @@ static void prepare_shadow_wa_ctx(struct 
intel_shadow_wa_ctx *wa_ctx)
if (wa_ctx->indirect_ctx.size == 0)
return;
 
-   vma = i915_gem_object_ggtt_pin(wa_ctx->indirect_ctx.obj, NULL, 0, 0, 0);
+   vma = i915_gem_object_ggtt_pin(wa_ctx->indirect_ctx.obj, NULL,
+  0, CACHELINE_BYTES, 0);
if (IS_ERR(vma)) {
gvt_err("Cannot pin indirect ctx obj\n");
return;
}
i915_gem_object_unpin_pages(wa_ctx->indirect_ctx.obj);
 
-   gma = i915_gem_object_ggtt_offset(wa_ctx->indirect_ctx.obj, NULL);
-   WARN_ON(!IS_ALIGNED(gma, CACHELINE_BYTES));
-   wa_ctx->indirect_ctx.shadow_gma = gma;
+   wa_ctx->indirect_ctx.shadow_gma = i915_ggtt_offset(vma);
 
wa_ctx->per_ctx.shadow_gma = *((unsigned int *)per_ctx_va + 1);
memset(per_ctx_va, 0, CACHELINE_BYTES);
-- 
2.9.3

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


[Intel-gfx] [PATCH 08/12] drm/i915/gvt: Stop checking for impossible interrupts from a kthread

2016-10-19 Thread Chris Wilson
The kthread will not be interrupted, don't even bother checking.

Signed-off-by: Chris Wilson 
Reviewed-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/scheduler.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 224f19ae61ab..310435498932 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -423,12 +423,7 @@ static int workload_thread(void *priv)
/*
 * Always take i915 big lock first
 */
-   ret = i915_mutex_lock_interruptible(>dev_priv->drm);
-   if (ret < 0) {
-   gvt_err("i915 submission is not available, retry\n");
-   schedule_timeout(1);
-   continue;
-   }
+   mutex_lock(>dev_priv->drm.struct_mutex);
 
gvt_dbg_sched("ring id %d will dispatch workload %p\n",
workload->ring_id, workload);
@@ -447,7 +442,7 @@ static int workload_thread(void *priv)
workload->ring_id, workload);
 
workload->status = i915_wait_request(workload->req,
-I915_WAIT_INTERRUPTIBLE | 
I915_WAIT_LOCKED,
+I915_WAIT_LOCKED,
 NULL, NULL);
if (workload->status != 0)
gvt_err("fail to wait workload, skip\n");
-- 
2.9.3

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


[Intel-gfx] [PATCH 09/12] drm/i915/gvt: Stop waiting whilst holding struct_mutex

2016-10-19 Thread Chris Wilson
For whatever reason, the gvt scheduler runs synchronously. At the very
least, lets run synchronously without holding the struct_mutex.

v2: cut'n'paste mutex_lock instead of unlock.
Replace long hold of struct_mutex with a mutex to serialise the worker
threads.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gvt/scheduler.c | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 310435498932..9957d8832c63 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -390,6 +390,8 @@ struct workload_thread_param {
int ring_id;
 };
 
+static DEFINE_MUTEX(scheduler_mutex);
+
 static int workload_thread(void *priv)
 {
struct workload_thread_param *p = (struct workload_thread_param *)priv;
@@ -414,17 +416,14 @@ static int workload_thread(void *priv)
if (kthread_should_stop())
break;
 
+   mutex_lock(_mutex);
+
gvt_dbg_sched("ring id %d next workload %p vgpu %d\n",
workload->ring_id, workload,
workload->vgpu->id);
 
intel_runtime_pm_get(gvt->dev_priv);
 
-   /*
-* Always take i915 big lock first
-*/
-   mutex_lock(>dev_priv->drm.struct_mutex);
-
gvt_dbg_sched("ring id %d will dispatch workload %p\n",
workload->ring_id, workload);
 
@@ -432,7 +431,10 @@ static int workload_thread(void *priv)
intel_uncore_forcewake_get(gvt->dev_priv,
FORCEWAKE_ALL);
 
+   mutex_lock(>dev_priv->drm.struct_mutex);
ret = dispatch_workload(workload);
+   mutex_unlock(>dev_priv->drm.struct_mutex);
+
if (ret) {
gvt_err("fail to dispatch workload, skip\n");
goto complete;
@@ -442,8 +444,7 @@ static int workload_thread(void *priv)
workload->ring_id, workload);
 
workload->status = i915_wait_request(workload->req,
-I915_WAIT_LOCKED,
-NULL, NULL);
+0, NULL, NULL);
if (workload->status != 0)
gvt_err("fail to wait workload, skip\n");
 
@@ -451,7 +452,9 @@ static int workload_thread(void *priv)
gvt_dbg_sched("will complete workload %p\n, status: %d\n",
workload, workload->status);
 
+   mutex_lock(>dev_priv->drm.struct_mutex);
complete_current_workload(gvt, ring_id);
+   mutex_unlock(>dev_priv->drm.struct_mutex);
 
i915_gem_request_put(fetch_and_zero(>req));
 
@@ -459,9 +462,10 @@ static int workload_thread(void *priv)
intel_uncore_forcewake_put(gvt->dev_priv,
FORCEWAKE_ALL);
 
-   mutex_unlock(>dev_priv->drm.struct_mutex);
-
intel_runtime_pm_put(gvt->dev_priv);
+
+   mutex_unlock(_mutex);
+
}
return 0;
 }
-- 
2.9.3

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


[Intel-gfx] [PATCH 02/12] drm/i915/gvt: Add runtime pm around fences

2016-10-19 Thread Chris Wilson
Manipulating the fence_list requires the runtime wakelock, as does
writing to the fence registers. Acquire a wakelock for the former, and
assert that the device is awake for the latter.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gvt/aperture_gm.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c 
b/drivers/gpu/drm/i915/gvt/aperture_gm.c
index e0211f83bd93..fc51f3e35835 100644
--- a/drivers/gpu/drm/i915/gvt/aperture_gm.c
+++ b/drivers/gpu/drm/i915/gvt/aperture_gm.c
@@ -144,6 +144,8 @@ void intel_vgpu_write_fence(struct intel_vgpu *vgpu,
struct drm_i915_fence_reg *reg;
i915_reg_t fence_reg_lo, fence_reg_hi;
 
+   assert_rpm_wakelock_held(dev_priv);
+
if (WARN_ON(fence > vgpu_fence_sz(vgpu)))
return;
 
@@ -172,6 +174,8 @@ static void free_vgpu_fence(struct intel_vgpu *vgpu)
if (WARN_ON(!vgpu_fence_sz(vgpu)))
return;
 
+   intel_runtime_pm_get(dev_priv);
+
mutex_lock(_priv->drm.struct_mutex);
for (i = 0; i < vgpu_fence_sz(vgpu); i++) {
reg = vgpu->fence.regs[i];
@@ -180,6 +184,8 @@ static void free_vgpu_fence(struct intel_vgpu *vgpu)
  _priv->mm.fence_list);
}
mutex_unlock(_priv->drm.struct_mutex);
+
+   intel_runtime_pm_put(dev_priv);
 }
 
 static int alloc_vgpu_fence(struct intel_vgpu *vgpu)
@@ -190,6 +196,8 @@ static int alloc_vgpu_fence(struct intel_vgpu *vgpu)
int i;
struct list_head *pos, *q;
 
+   intel_runtime_pm_get(dev_priv);
+
/* Request fences from host */
mutex_lock(_priv->drm.struct_mutex);
i = 0;
@@ -207,6 +215,7 @@ static int alloc_vgpu_fence(struct intel_vgpu *vgpu)
goto out_free_fence;
 
mutex_unlock(_priv->drm.struct_mutex);
+   intel_runtime_pm_put(dev_priv);
return 0;
 out_free_fence:
/* Return fences to host, if fail */
@@ -218,6 +227,7 @@ static int alloc_vgpu_fence(struct intel_vgpu *vgpu)
  _priv->mm.fence_list);
}
mutex_unlock(_priv->drm.struct_mutex);
+   intel_runtime_pm_put(dev_priv);
return -ENOSPC;
 }
 
-- 
2.9.3

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


[Intel-gfx] [PATCH 11/12] drm/i915/gvt: Use common mapping routines for shadow_bb object

2016-10-19 Thread Chris Wilson
We have the ability to map an object, so use it rather than opencode it
badly. Note that the object remains permanently pinned, this is poor
practise.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gvt/cmd_parser.c | 21 ++---
 drivers/gpu/drm/i915/gvt/execlist.c   |  2 +-
 2 files changed, 7 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index 2b16609b..a91405df394d 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -1648,18 +1648,10 @@ static int perform_bb_shadow(struct parser_exec_state 
*s)
entry_obj->len = bb_size;
INIT_LIST_HEAD(_obj->list);
 
-   ret = i915_gem_object_get_pages(entry_obj->obj);
-   if (ret)
+   dst = i915_gem_object_pin_map(entry_obj->obj, I915_MAP_WB);
+   if (IS_ERR(dst)) {
+   ret = PTR_ERR(dst);
goto put_obj;
-
-   i915_gem_object_pin_pages(entry_obj->obj);
-
-   /* get the va of the shadow batch buffer */
-   dst = (void *)vmap_batch(entry_obj->obj, 0, bb_size);
-   if (!dst) {
-   gvt_err("failed to vmap shadow batch\n");
-   ret = -ENOMEM;
-   goto unpin_src;
}
 
ret = i915_gem_object_set_to_cpu_domain(entry_obj->obj, false);
@@ -1673,7 +1665,8 @@ static int perform_bb_shadow(struct parser_exec_state *s)
 
/* copy batch buffer to shadow batch buffer*/
ret = copy_gma_to_hva(s->vgpu, s->vgpu->gtt.ggtt_mm,
-   gma, gma + bb_size, dst);
+ gma, gma + bb_size,
+ dst);
if (ret) {
gvt_err("fail to copy guest ring buffer\n");
goto unmap_src;
@@ -1694,9 +1687,7 @@ static int perform_bb_shadow(struct parser_exec_state *s)
return 0;
 
 unmap_src:
-   vunmap(dst);
-unpin_src:
-   i915_gem_object_unpin_pages(entry_obj->obj);
+   i915_gem_object_unpin_map(entry_obj->obj);
 put_obj:
i915_gem_object_put(entry_obj->obj);
 free_entry:
diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
b/drivers/gpu/drm/i915/gvt/execlist.c
index d8a6d6366899..3ed78f7e76f2 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.c
+++ b/drivers/gpu/drm/i915/gvt/execlist.c
@@ -504,8 +504,8 @@ static void release_shadow_batch_buffer(struct 
intel_vgpu_workload *workload)
 
list_for_each_entry_safe(entry_obj, temp, >shadow_bb,
 list) {
+   i915_gem_object_unpin_map(entry_obj->obj);
i915_gem_object_put(entry_obj->obj);
-   kvfree(entry_obj->va);
list_del(_obj->list);
kfree(entry_obj);
}
-- 
2.9.3

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


[Intel-gfx] [PATCH 04/12] drm/i915: Catch premature unpinning of pages

2016-10-19 Thread Chris Wilson
Try to catch the violation of unpinning the backing storage whilst still
bound to the GPU.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 33c44c631bab..6c8a104b42ed 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3181,14 +3181,15 @@ i915_gem_object_get_page(struct drm_i915_gem_object 
*obj, int n)
 
 static inline void i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
 {
-   BUG_ON(obj->pages == NULL);
+   GEM_BUG_ON(obj->pages == NULL);
obj->pages_pin_count++;
 }
 
 static inline void i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
 {
-   BUG_ON(obj->pages_pin_count == 0);
+   GEM_BUG_ON(obj->pages_pin_count == 0);
obj->pages_pin_count--;
+   GEM_BUG_ON(obj->pages_pin_count < obj->bind_count);
 }
 
 enum i915_map_type {
-- 
2.9.3

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


[Intel-gfx] [PATCH 03/12] drm/i915/gvt: i915_gem_object_create() returns an error pointer

2016-10-19 Thread Chris Wilson
On failure from i915_gem_object_create(), we need to check for an error
pointer not NULL.

Signed-off-by: Chris Wilson 
Reviewed-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/cmd_parser.c | 48 ---
 1 file changed, 28 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index 5808ee7c1935..464fc3c9935b 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -1638,16 +1638,19 @@ static int perform_bb_shadow(struct parser_exec_state 
*s)
if (entry_obj == NULL)
return -ENOMEM;
 
-   entry_obj->obj = i915_gem_object_create(&(s->vgpu->gvt->dev_priv->drm),
-   round_up(bb_size, PAGE_SIZE));
-   if (entry_obj->obj == NULL)
-   return -ENOMEM;
+   entry_obj->obj =
+   i915_gem_object_create(&(s->vgpu->gvt->dev_priv->drm),
+  roundup(bb_size, PAGE_SIZE));
+   if (IS_ERR(entry_obj->obj)) {
+   ret = PTR_ERR(entry_obj->obj);
+   goto free_entry;
+   }
entry_obj->len = bb_size;
INIT_LIST_HEAD(_obj->list);
 
ret = i915_gem_object_get_pages(entry_obj->obj);
if (ret)
-   return ret;
+   goto put_obj;
 
i915_gem_object_pin_pages(entry_obj->obj);
 
@@ -1673,7 +1676,7 @@ static int perform_bb_shadow(struct parser_exec_state *s)
gma, gma + bb_size, dst);
if (ret) {
gvt_err("fail to copy guest ring buffer\n");
-   return ret;
+   goto unmap_src;
}
 
list_add(_obj->list, >workload->shadow_bb);
@@ -1694,7 +1697,10 @@ static int perform_bb_shadow(struct parser_exec_state *s)
vunmap(dst);
 unpin_src:
i915_gem_object_unpin_pages(entry_obj->obj);
-
+put_obj:
+   i915_gem_object_put(entry_obj->obj);
+free_entry:
+   kfree(entry_obj);
return ret;
 }
 
@@ -2707,31 +2713,31 @@ static int shadow_indirect_ctx(struct 
intel_shadow_wa_ctx *wa_ctx)
struct drm_device *dev = _ctx->workload->vgpu->gvt->dev_priv->drm;
int ctx_size = wa_ctx->indirect_ctx.size;
unsigned long guest_gma = wa_ctx->indirect_ctx.guest_gma;
+   struct drm_i915_gem_object *obj;
int ret = 0;
void *dest = NULL;
 
-   wa_ctx->indirect_ctx.obj = i915_gem_object_create(dev,
-   round_up(ctx_size + CACHELINE_BYTES, PAGE_SIZE));
-   if (wa_ctx->indirect_ctx.obj == NULL)
-   return -ENOMEM;
+   obj = i915_gem_object_create(dev,
+roundup(ctx_size + CACHELINE_BYTES,
+PAGE_SIZE));
+   if (IS_ERR(obj))
+   return PTR_ERR(obj);
 
-   ret = i915_gem_object_get_pages(wa_ctx->indirect_ctx.obj);
+   ret = i915_gem_object_get_pages(obj);
if (ret)
-   return ret;
+   goto put_obj;
 
-   i915_gem_object_pin_pages(wa_ctx->indirect_ctx.obj);
+   i915_gem_object_pin_pages(obj);
 
/* get the va of the shadow batch buffer */
-   dest = (void *)vmap_batch(wa_ctx->indirect_ctx.obj, 0,
-   ctx_size + CACHELINE_BYTES);
+   dest = (void *)vmap_batch(obj, 0, ctx_size + CACHELINE_BYTES);
if (!dest) {
gvt_err("failed to vmap shadow indirect ctx\n");
ret = -ENOMEM;
goto unpin_src;
}
 
-   ret = i915_gem_object_set_to_cpu_domain(wa_ctx->indirect_ctx.obj,
-   false);
+   ret = i915_gem_object_set_to_cpu_domain(obj, false);
if (ret) {
gvt_err("failed to set shadow indirect ctx to CPU\n");
goto unmap_src;
@@ -2746,16 +2752,18 @@ static int shadow_indirect_ctx(struct 
intel_shadow_wa_ctx *wa_ctx)
guest_gma, guest_gma + ctx_size, dest);
if (ret) {
gvt_err("fail to copy guest indirect ctx\n");
-   return ret;
+   goto unmap_src;
}
 
+   wa_ctx->indirect_ctx.obj = obj;
return 0;
 
 unmap_src:
vunmap(dest);
 unpin_src:
i915_gem_object_unpin_pages(wa_ctx->indirect_ctx.obj);
-
+put_obj:
+   i915_gem_object_put(wa_ctx->indirect_ctx.obj);
return ret;
 }
 
-- 
2.9.3

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


[Intel-gfx] gvt gem fixes

2016-10-19 Thread Chris Wilson
I think this is the set required to bring gvt into line, at least to
unblock myself.
-Chris

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


[Intel-gfx] [PATCH] drm/i915/gvt: Add runtime pm around fences

2016-10-19 Thread Chris Wilson
Manipulating the fence_list requires the runtime wakelock, as does
writing to the fence registers. Acquire a wakelock for the former, and
assert that the device is awake for the latter.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gvt/aperture_gm.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c 
b/drivers/gpu/drm/i915/gvt/aperture_gm.c
index e0211f83bd93..fc51f3e35835 100644
--- a/drivers/gpu/drm/i915/gvt/aperture_gm.c
+++ b/drivers/gpu/drm/i915/gvt/aperture_gm.c
@@ -144,6 +144,8 @@ void intel_vgpu_write_fence(struct intel_vgpu *vgpu,
struct drm_i915_fence_reg *reg;
i915_reg_t fence_reg_lo, fence_reg_hi;
 
+   assert_rpm_wakelock_held(dev_priv);
+
if (WARN_ON(fence > vgpu_fence_sz(vgpu)))
return;
 
@@ -172,6 +174,8 @@ static void free_vgpu_fence(struct intel_vgpu *vgpu)
if (WARN_ON(!vgpu_fence_sz(vgpu)))
return;
 
+   intel_runtime_pm_get(dev_priv);
+
mutex_lock(_priv->drm.struct_mutex);
for (i = 0; i < vgpu_fence_sz(vgpu); i++) {
reg = vgpu->fence.regs[i];
@@ -180,6 +184,8 @@ static void free_vgpu_fence(struct intel_vgpu *vgpu)
  _priv->mm.fence_list);
}
mutex_unlock(_priv->drm.struct_mutex);
+
+   intel_runtime_pm_put(dev_priv);
 }
 
 static int alloc_vgpu_fence(struct intel_vgpu *vgpu)
@@ -190,6 +196,8 @@ static int alloc_vgpu_fence(struct intel_vgpu *vgpu)
int i;
struct list_head *pos, *q;
 
+   intel_runtime_pm_get(dev_priv);
+
/* Request fences from host */
mutex_lock(_priv->drm.struct_mutex);
i = 0;
@@ -207,6 +215,7 @@ static int alloc_vgpu_fence(struct intel_vgpu *vgpu)
goto out_free_fence;
 
mutex_unlock(_priv->drm.struct_mutex);
+   intel_runtime_pm_put(dev_priv);
return 0;
 out_free_fence:
/* Return fences to host, if fail */
@@ -218,6 +227,7 @@ static int alloc_vgpu_fence(struct intel_vgpu *vgpu)
  _priv->mm.fence_list);
}
mutex_unlock(_priv->drm.struct_mutex);
+   intel_runtime_pm_put(dev_priv);
return -ENOSPC;
 }
 
-- 
2.9.3

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


  1   2   >