Re: [Intel-gfx] [PATCH v5 1/5] drm: Add driver-private objects to atomic state

[kbuild test robot]

Hi Dhinakaran,

[auto build test WARNING on next-20170330]
[cannot apply to drm/drm-next drm-intel/for-linux-next v4.9-rc8 v4.9-rc7 
v4.9-rc6 v4.11-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Dhinakaran-Pandiyan/drm-Add-driver-private-objects-to-atomic-state/20170401-113603
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
   include/linux/init.h:1: warning: no structured comments found
   kernel/sched/core.c:2088: warning: No description found for parameter 'rf'
   kernel/sched/core.c:2088: warning: Excess function parameter 'cookie' 
description in 'try_to_wake_up_local'
   include/linux/kthread.h:26: warning: Excess function parameter '...' 
description in 'kthread_create'
   kernel/sys.c:1: warning: no structured comments found
   include/linux/device.h:969: warning: No description found for parameter 
'dma_ops'
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/linux/iio/iio.h:597: warning: No description found for parameter 
'trig_readonly'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'indio_dev'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'trig'
   include/linux/device.h:970: warning: No description found for parameter 
'dma_ops'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'set_busid'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_handler'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_preinstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_postinstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_uninstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'debugfs_init'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_open_object'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_close_object'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'prime_handle_to_fd'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'prime_fd_to_handle'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_export'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_import'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_vm_ops'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'major'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'minor'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'patchlevel'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'name'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'desc'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'date'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'driver_features'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'ioctls'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'num_ioctls'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'fops'
>> include/drm/drm_atomic.h:829: warning: No description found for parameter 
>> 'obj'
>> include/drm/drm_atomic.h:829: warning: No description found for parameter 
>> 'obj_state'
>> include/drm/drm_atomic.h:829: warning: No description found for parameter 
>> '__i'
>> include/drm/drm_atomic.h:829: warning: No description found for parameter 
>> '__funcs'
   include/drm/drm_atomic.h:848: warning: No description found for parameter 
'obj'
   include/drm/drm_atomic.h:848: warning: No description found for parameter 
'obj_state'
   include/drm/drm_atomic.h:848: warning: No description found for parameter 
'__i'
   include/drm/drm_atomic.h:848: warning: No description found for parameter 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/audio: not to set N/M value manually for KBL.

[Patchwork]

== Series Details ==

Series: drm/i915/audio: not to set N/M value manually for KBL.
URL   : https://patchwork.freedesktop.org/series/22303/
State : success

== Summary ==

Series 22303v1 drm/i915/audio: not to set N/M value manually for KBL.
https://patchwork.freedesktop.org/api/1.0/series/22303/revisions/1/mbox/

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

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 433s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 424s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 580s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 517s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 563s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 486s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 495s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 412s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 411s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 430s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 480s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 486s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 466s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 570s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 451s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 568s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 458s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 486s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 431s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 535s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time: 402s

19ceec7d516a7c4614833ba7a3724a4bea0c59d3 drm-tip: 2017y-03m-31d-20h-10m-03s UTC 
integration manifest
66240f8 drm/i915/audio: not to set N/M value manually for KBL.

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value manually for KBL.

[Quanxian Wang]

It doesn't work on KBL. Just using automatic N/M.

According to the bspec, when set N/M, should disable
and enable transcoder which attaching DP audio. but there is no
such code to do that.
without this implementation except KBL platforms, seems work well.

Signed-off-by: Quanxian Wang 
Tested-By: Wang Zhijun
Tested-By: Cui Yueping
---
 drivers/gpu/drm/i915/intel_audio.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index 52c207e..0542031 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -300,7 +300,7 @@ hsw_dp_audio_config_update(struct intel_crtc *intel_crtc, 
enum port port,
tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
tmp |= AUD_CONFIG_N_VALUE_INDEX;
 
-   if (nm) {
+   if (!IS_KABYLAKE(dev_priv) && nm) {
tmp &= ~AUD_CONFIG_N_MASK;
tmp |= AUD_CONFIG_N(nm->n);
tmp |= AUD_CONFIG_N_PROG_ENABLE;
@@ -308,6 +308,9 @@ hsw_dp_audio_config_update(struct intel_crtc *intel_crtc, 
enum port port,
 
I915_WRITE(HSW_AUD_CFG(pipe), tmp);
 
+   if (IS_KABYLAKE(dev_priv))
+   return;
+
tmp = I915_READ(HSW_AUD_M_CTS_ENABLE(pipe));
tmp &= ~AUD_CONFIG_M_MASK;
tmp &= ~AUD_M_CTS_M_VALUE_INDEX;
-- 
2.5.0

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

Re: [Intel-gfx] [PATCH v5 4/5] drm: Connector helper function to release resources

[Pandiyan, Dhinakaran]

On Thu, 2017-03-30 at 12:36 +0200, Maarten Lankhorst wrote:
> Op 30-03-17 om 10:42 schreef Dhinakaran Pandiyan:
> > From: "Pandiyan, Dhinakaran" 
> >
> > Having an ->atomic_release callback is useful to release shared resources
> > that get allocated in compute_config(). This function is expected to be
> > called in the atomic_check() phase before new resources are acquired.
> >
> > v4: Document that the function is conditionally called and before
> > other atomic_checks() (Daniel)
> > v3: Use the new 'for_each_oldnew_connector_in_state()' macro.
> > v2: Moved the caller hunk to this patch (Daniel)
> >
> > Cc: Daniel Vetter 
> > Cc: Maarten Lankhorst 
> > Cc: Archit Taneja 
> > Cc: Chris Wilson 
> > Cc: Harry Wentland 
> > Reviewed-by: Maarten Lankhorst 
> > Reviewed-by: Daniel Vetter 
> > Suggested-by: Daniel Vetter 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c  | 19 +++
> >  include/drm/drm_modeset_helper_vtables.h | 16 
> >  2 files changed, 35 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index d14094d..9d07669 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -586,6 +586,25 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > }
> > }
> >  
> > +   for_each_oldnew_connector_in_state(state, connector, 
> > old_connector_state, new_connector_state, i) {
> > +   const struct drm_connector_helper_funcs *conn_funcs;
> > +   struct drm_crtc_state *crtc_state;
> > +
> > +   conn_funcs = connector->helper_private;
> > +   if (!conn_funcs->atomic_release)
> > +   continue;
> > +
> > +   if (!old_connector_state->crtc)
> > +   continue;
> > +
> > +   crtc_state = drm_atomic_get_existing_crtc_state(state, 
> > old_connector_state->crtc);
> > +
> > +   if (crtc_state->connectors_changed ||
> > +   crtc_state->mode_changed ||
> > +   (crtc_state->active_changed && !crtc_state->active))
> > +   conn_funcs->atomic_release(connector, 
> > new_connector_state);
> > +   }
> > +
> > return mode_fixup(state);
> >  }
> Oops, I'm just looking at patch 5 again..
> 
> atomic_release should return an int to allow error propogation. There's no 
> good reason why it shouldn't.
> This would allow handling errors in patch 5 more gracefully.

Makes sense, will change that. This made me think about how
intel_dp_mst_atomic_release() handles an invalid mst_port reference
i.e., in case the port is gone. I'll fix both and send a new version.

-DK


> >  EXPORT_SYMBOL(drm_atomic_helper_check_modeset);
> > diff --git a/include/drm/drm_modeset_helper_vtables.h 
> > b/include/drm/drm_modeset_helper_vtables.h
> > index 091c422..84e80aa 100644
> > --- a/include/drm/drm_modeset_helper_vtables.h
> > +++ b/include/drm/drm_modeset_helper_vtables.h
> > @@ -836,6 +836,22 @@ struct drm_connector_helper_funcs {
> >  */
> > struct drm_encoder *(*atomic_best_encoder)(struct drm_connector 
> > *connector,
> >struct drm_connector_state 
> > *connector_state);
> > +
> > +   /**
> > +* @atomic_release:
> > +*
> > +* This function is conditionally called to release shared resources
> > +* when the attached CRTC's mode changes or it's connectors change or
> > +* becomes inactive. It is called before the corresponding
> > +* _crtc_helper_funcs.atomic_check or
> > +* _crtc_helper_funcs.mode_fixup hooks are called.
> > +*
> > +* NOTE:
> > +*
> > +* This function is called in the check phase of an atomic update.
> > +*/
> > +   void (*atomic_release)(struct drm_connector *connector,
> > +  struct drm_connector_state *connector_state);
> >  };
> >  
> >  /**
> 
> 
> ___
> 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 v2 1/2] drm/i915/scheduler: add gvt force-single-submission for guc

[Dong, Chuanxiao]

> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Chris Wilson
> Sent: Friday, March 31, 2017 10:24 PM
> To: Dong, Chuanxiao 
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> Subject: Re: [PATCH v2 1/2] drm/i915/scheduler: add gvt force-single-
> submission for guc
> 
> On Tue, Mar 28, 2017 at 05:38:40PM +0800, Chuanxiao Dong wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index dd0e9d587..951540f 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -377,24 +377,6 @@ static void execlists_submit_ports(struct
> intel_engine_cs *engine)
> > writel(lower_32_bits(desc[0]), elsp);  }
> >
> > -static bool ctx_single_port_submission(const struct i915_gem_context
> > *ctx) -{
> > -   return (IS_ENABLED(CONFIG_DRM_I915_GVT) &&
> > -   i915_gem_context_force_single_submission(ctx));
> > -}
> > -
> > -static bool can_merge_ctx(const struct i915_gem_context *prev,
> > - const struct i915_gem_context *next)
> > -{
> > -   if (prev != next)
> > -   return false;
> > -
> > -   if (ctx_single_port_submission(prev))
> > -   return false;
> > -
> > -   return true;
> > -}
> > -
> >  static void execlists_dequeue(struct intel_engine_cs *engine)  {
> > struct drm_i915_gem_request *last;
> > @@ -462,7 +444,8 @@ static void execlists_dequeue(struct
> intel_engine_cs *engine)
> >  * request, and so we never need to tell the hardware about
> >  * the first.
> >  */
> > -   if (last && !can_merge_ctx(cursor->ctx, last->ctx)) {
> > +   if (last && ((last->ctx != cursor->ctx) ||
> > +   intel_gvt_context_single_port_submit(last->ctx))) {
> 
> Which is easier to understand the original code or the replacement?
> Bonus points for sticking to coding style.

I was thinking to use the original code but didn't find a good place to define 
can_merge_ctx(). The function of can_merge_ctx() is normal to all i915 gem 
context, seems i915_gem_context.h is a good place. But as can_merge_ctx() will 
call intel_gvt_context_single_port_submit() which is defined in intel_gvt.h, 
and intel_gvt_context_single_port_submit() will call the function defined in 
i915_gem_context.h as well, that will build a dependency between 
i915_gem_context.h and intel_gvt.h which seems not sense. So just use the above 
replacement to make it simple. Can we use this replacement? Or keep the 
original function?

Thanks
Chuanxiao

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

Re: [Intel-gfx] [PATCH v3] drm/i915/dp: Read link status more times when EQ not done

[Rodrigo Vivi]

On Mon, Mar 13, 2017 at 1:12 AM, Lee, Shawn C  wrote:
> From: "Lee, Shawn C" 
>
> Display driver read DPCD register 0x202, 0x203 and 0x204 to identify
> eDP sink status.If PSR exit is ongoing at eDP sink, and eDP source
> read these registers at the same time. Panel will report EQ & symbol
> lock not done. It will cause panel display flicking.
>
> Try to read link status more times if eDP EQ not done. Panel side
> request at least 1000us for fast link train while doing PSR exit.
> So wait more than 1000us then retrieve sink's status again.

it is missing a v2 and v3 here with explanations on the changes.
It was hard to follow the changes.

>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99639
> TEST=Reboot DUT and no flicking on local display at login screen
>
> Cc: Cooper Chiou 
> Cc: Wei Shun Chen 
> Cc: Gary C Wang 
> Cc: Jani Nikula 
> Cc: Rodrigo Vivi 
>
> Signed-off-by: Lee, Shawn C 
> ---
>  drivers/gpu/drm/i915/intel_dp.c |   34 --
>  1 file changed, 24 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 024798a9c016..d50827a92aa2 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4225,15 +4225,11 @@ static void intel_dp_handle_test_request(struct 
> intel_dp *intel_dp)
>  {
> struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
> struct drm_device *dev = intel_dp_to_dev(intel_dp);
> -   u8 link_status[DP_LINK_STATUS_SIZE];
> +   struct drm_i915_private *dev_priv = dev->dev_private;
> +   u8 link_status[DP_LINK_STATUS_SIZE], retry = 1;
>
> WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
>
> -   if (!intel_dp_get_link_status(intel_dp, link_status)) {
> -   DRM_ERROR("Failed to get link status\n");
> -   return;
> -   }
> -
> if (!intel_encoder->base.crtc)
> return;
>
> @@ -4245,13 +4241,31 @@ static void intel_dp_handle_test_request(struct 
> intel_dp *intel_dp)
> if (!intel_dp->lane_count)
> return;
>
> +   if (is_edp(intel_dp) && dev_priv->psr.enabled)
> +   retry = 3;
> +
> /* Retrain if Channel EQ or CR not ok */
> -   if (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count)) {
> -   DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",
> - intel_encoder->base.name);
> +   while ( retry-- ) {
> +   if (!intel_dp_get_link_status(intel_dp, link_status)) {
> +   DRM_ERROR("Failed to get link status\n");
> +   return;

Well, if link status is not ok you return without retrying, so, why is
this here?

> +   }
>
> -   intel_dp_retrain_link(intel_dp);
> +   if (drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))
> +   return;
> +
> +   /*
> +* EQ not ok may caused by fast link train while exit PSR 
> active,
> +* wait at least 1000 us then read it again.
> +*/
> +   if (retry)
> +   usleep_range(1000, 1500);

maybe this retry is randomly just masking the real issue.
Jim recently found out that on psr enable we are clearing a bit that
we should never touch by spec.
I'd try Jim's patch(es) first to see if they solve the issue for you.

> }
> +
> +   DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",
> +   intel_encoder->base.name);
> +
> +   intel_dp_retrain_link(intel_dp);
>  }
>
>  /*
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



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

Re: [Intel-gfx] [PATCH 0/3] drm/i915: Fix SKL+ 90/270 degree rotated scanout

[Chris Wilson]

On Fri, Mar 31, 2017 at 09:00:53PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> I figured it's about time I fix what I broke with my fb offset stuff.
> I've posted the scaler thing before, but the watermark and fbc stuff
> is new.
> 
> Based on some quick tests the WM fixes seem effective. Or at least
> underruns seemed to disappear when I was running xonotic with 90/270
> degree rotation.

The key question for me is would we be able to detect any of the errors
in igt? How can we improve our testing?
-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] ✓ Fi.CI.BAT: success for drm/i915/uc: Drop use of MISSING_CASE on trivial enums

[Chris Wilson]

On Fri, Mar 31, 2017 at 12:41:41PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/uc: Drop use of MISSING_CASE on trivial enums
> URL   : https://patchwork.freedesktop.org/series/22274/
> State : success
> 
> == Summary ==
> 
> Series 22274v1 drm/i915/uc: Drop use of MISSING_CASE on trivial enums
> https://patchwork.freedesktop.org/api/1.0/series/22274/revisions/1/mbox/

And pushed. Thanks,
-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: Clear gt.active_requests before checking idle status

[Chris Wilson]

On Fri, Mar 31, 2017 at 08:40:36PM +0100, Matthew Auld wrote:
> On 03/31, Chris Wilson wrote:
> > commit 8490ae207f1d ("drm/i915: Suppress busy status for engines if
> > wedged") moved the check for inflight requests to the
> > intel_engines_are_idle() check to protect the idle worker. However, the
> > request selftests were also checking the engine idle status and erroring
> > out if they did not become idle within a short period of time after the
> > final wait. In order to accommodate the new check, call retire requests
> > prior to the engine check so that we flush all the waits.
> > 
> > Fixes: 8490ae207f1d ("drm/i915: Suppress busy status for engines if wedged")
> > Signed-off-by: Chris Wilson 
> > Cc: Matthew Auld 
> > Cc: Joonas Lahtinen 
> > Cc: Tvrtko Ursulin 
> Reviewed-by: Matthew Auld 

Pushed, simple fix to live_request -- my bad.
-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: Clear gt.active_requests before checking idle status

[Matthew Auld]

On 03/31, Chris Wilson wrote:
> commit 8490ae207f1d ("drm/i915: Suppress busy status for engines if
> wedged") moved the check for inflight requests to the
> intel_engines_are_idle() check to protect the idle worker. However, the
> request selftests were also checking the engine idle status and erroring
> out if they did not become idle within a short period of time after the
> final wait. In order to accommodate the new check, call retire requests
> prior to the engine check so that we flush all the waits.
> 
> Fixes: 8490ae207f1d ("drm/i915: Suppress busy status for engines if wedged")
> Signed-off-by: Chris Wilson 
> Cc: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Tvrtko Ursulin 
Reviewed-by: Matthew Auld 

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Clear gt.active_requests before checking idle status

[Patchwork]

== Series Details ==

Series: drm/i915: Clear gt.active_requests before checking idle status
URL   : https://patchwork.freedesktop.org/series/22296/
State : success

== Summary ==

Series 22296v1 drm/i915: Clear gt.active_requests before checking idle status
https://patchwork.freedesktop.org/api/1.0/series/22296/revisions/1/mbox/

Test gem_exec_fence:
Subgroup await-hang-default:
pass   -> INCOMPLETE (fi-ilk-650) fdo#100144
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-bxt-t5700) fdo#100125

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 428s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 425s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 574s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 513s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 536s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 493s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 481s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 405s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 403s
fi-ilk-650   total:48   pass:27   dwarn:0   dfail:0   fail:0   skip:20  
time: 0s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 493s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 489s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 461s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 570s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 464s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 568s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 463s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 494s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 433s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 525s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time: 408s

5a229613e4ef7d50ae0ae42ed50a57f4463d163f drm-tip: 2017y-03m-31d-16h-10m-12s UTC 
integration manifest
62cc9c2 drm/i915: Clear gt.active_requests before checking idle status

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Clear gt.active_requests before checking idle status

[Chris Wilson]

commit 8490ae207f1d ("drm/i915: Suppress busy status for engines if
wedged") moved the check for inflight requests to the
intel_engines_are_idle() check to protect the idle worker. However, the
request selftests were also checking the engine idle status and erroring
out if they did not become idle within a short period of time after the
final wait. In order to accommodate the new check, call retire requests
prior to the engine check so that we flush all the waits.

Fixes: 8490ae207f1d ("drm/i915: Suppress busy status for engines if wedged")
Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/selftests/i915_gem_request.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_request.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_request.c
index 6b788ffda822..98b7aac41eec 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_request.c
@@ -301,7 +301,9 @@ static int end_live_test(struct live_test *t)
 {
struct drm_i915_private *i915 = t->i915;
 
-   if (wait_for(intel_engines_are_idle(i915), 1)) {
+   i915_gem_retire_requests(i915);
+
+   if (wait_for(intel_engines_are_idle(i915), 10)) {
pr_err("%s(%s): GPU not idle\n", t->func, t->name);
return -EIO;
}
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH v4 04/11] drm/fb-helper: Push down modeset lock into FB helpers

[Daniel Vetter]

On Wed, Mar 29, 2017 at 04:43:54PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Move the modeset locking from drivers into FB helpers.
> 
> Tested-by: John Stultz 
> Reviewed-by: Daniel Vetter 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/drm_fb_helper.c| 40 
> +-
>  drivers/gpu/drm/i915/intel_dp_mst.c|  3 ---
>  drivers/gpu/drm/radeon/radeon_dp_mst.c |  7 --
>  3 files changed, 34 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 673a47445d61..18105cbe9810 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -109,8 +109,8 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
>   for (({ lockdep_assert_held(&(fbh)->dev->mode_config.mutex); }), \
>i__ = 0; i__ < (fbh)->connector_count; i__++)
>  
> -int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
> - struct drm_connector *connector)
> +static int __drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
> +  struct drm_connector *connector)
>  {
>   struct drm_fb_helper_connector *fb_conn;
>   struct drm_fb_helper_connector **temp;
> @@ -141,8 +141,23 @@ int drm_fb_helper_add_one_connector(struct drm_fb_helper 
> *fb_helper,
>   drm_connector_get(connector);
>   fb_conn->connector = connector;
>   fb_helper->connector_info[fb_helper->connector_count++] = fb_conn;
> +
>   return 0;
>  }
> +
> +int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
> + struct drm_connector *connector)
> +{
> + int err;
> +
> + mutex_lock(_helper->dev->mode_config.mutex);
> +
> + err = __drm_fb_helper_add_one_connector(fb_helper, connector);
> +
> + mutex_unlock(_helper->dev->mode_config.mutex);
> +
> + return err;
> +}
>  EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
>  
>  /**
> @@ -172,8 +187,7 @@ int drm_fb_helper_single_add_all_connectors(struct 
> drm_fb_helper *fb_helper)
>   mutex_lock(>mode_config.mutex);
>   drm_connector_list_iter_begin(dev, _iter);
>   drm_for_each_connector_iter(connector, _iter) {
> - ret = drm_fb_helper_add_one_connector(fb_helper, connector);
> -
> + ret = __drm_fb_helper_add_one_connector(fb_helper, connector);
>   if (ret)
>   goto fail;
>   }
> @@ -198,8 +212,8 @@ int drm_fb_helper_single_add_all_connectors(struct 
> drm_fb_helper *fb_helper)
>  }
>  EXPORT_SYMBOL(drm_fb_helper_single_add_all_connectors);
>  
> -int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
> -struct drm_connector *connector)
> +static int __drm_fb_helper_remove_one_connector(struct drm_fb_helper 
> *fb_helper,
> + struct drm_connector *connector)
>  {
>   struct drm_fb_helper_connector *fb_helper_connector;
>   int i, j;
> @@ -227,6 +241,20 @@ int drm_fb_helper_remove_one_connector(struct 
> drm_fb_helper *fb_helper,
>  
>   return 0;
>  }
> +
> +int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
> +struct drm_connector *connector)
> +{
> + int err;
> +
> + mutex_lock(_helper->dev->mode_config.mutex);
> +
> + err = __drm_fb_helper_remove_one_connector(fb_helper, connector);
> +
> + mutex_unlock(_helper->dev->mode_config.mutex);
> +
> + return err;
> +}
>  EXPORT_SYMBOL(drm_fb_helper_remove_one_connector);
>  
>  static void drm_fb_helper_save_lut_atomic(struct drm_crtc *crtc, struct 
> drm_fb_helper *helper)
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index c1f62eb07c07..1e3ee32a9acb 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -484,15 +484,12 @@ static void intel_dp_destroy_mst_connector(struct 
> drm_dp_mst_topology_mgr *mgr,
>  struct drm_connector *connector)
>  {
>   struct intel_connector *intel_connector = to_intel_connector(connector);
> - struct drm_device *dev = connector->dev;
>  
>   drm_connector_unregister(connector);
>  
>   /* need to nuke the connector */
> - drm_modeset_lock_all(dev);
>   intel_connector_remove_from_fbdev(intel_connector);
>   intel_connector->mst_port = NULL;
> - drm_modeset_unlock_all(dev);

I missed that you missed the add_to_fbdev case :( I merged the first 3
patches to drm-misc.

Thanks, Daniel

>  
>   drm_connector_unreference(_connector->base);
>   DRM_DEBUG_KMS("\n");
> diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c 
> b/drivers/gpu/drm/radeon/radeon_dp_mst.c
> index 6598306dca9b..ebdf1b859cb6 100644
> --- 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix SKL+ 90/270 degree rotated scanout

[Patchwork]

== Series Details ==

Series: drm/i915: Fix SKL+ 90/270 degree rotated scanout
URL   : https://patchwork.freedesktop.org/series/22295/
State : success

== Summary ==

Series 22295v1 drm/i915: Fix SKL+ 90/270 degree rotated scanout
https://patchwork.freedesktop.org/api/1.0/series/22295/revisions/1/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-byt-n2820) fdo#100415

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 436s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 425s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 572s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 507s
fi-bxt-t5700 total:278  pass:257  dwarn:1   dfail:0   fail:0   skip:20  
time: 552s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 487s
fi-byt-n2820 total:278  pass:246  dwarn:1   dfail:0   fail:0   skip:31  
time: 482s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 411s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 411s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 422s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 482s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 482s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 453s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 571s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 452s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 570s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 462s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 494s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 432s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 527s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 401s

5a229613e4ef7d50ae0ae42ed50a57f4463d163f drm-tip: 2017y-03m-31d-16h-10m-12s UTC 
integration manifest
96f25eb drm/i915: Fix 90/270 rotated coordinates for FBC
8098628 drm/i915: Fix SKL+ watermarks for 90/270 rotation
18d0b32 drm/i915: Fix scaling check for 90/270 degree plane rotation

== Logs ==

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

Re: [Intel-gfx] [PATCH v10] drm/i915: Implement Link Rate fallback on Link training failure

[Manasi Navare]

On Fri, Mar 31, 2017 at 01:33:04PM +0300, Jani Nikula wrote:
> On Fri, 31 Mar 2017, Manasi Navare  wrote:
> > Hi Jani,
> >
> > I have reviewed your recent DP link rate / lane count
> > refactoring patch series and I believe that it will soon get merged.
> 
> I haven't received reviews on all of the patches in my series yet, in
> particular the first patches are missing reviews so I can't even get
> started pushing them.
> 
> BR,
> Jani.
>

Ok, I will spend some time reviewing these patches today so you
can push those. 
Is that why you are waiting to merge this patch?

Regards
Manasi

 
> 
> >
> > Are you waiting on merging this patch so that your refactoring
> > series gets merged first? Or can we merge this patch since
> > it already has ACKs and R-bs.
> >
> > Please advise on next steps for this patch, since some
> > of the PSR related patches are pending merge because of this.
> >
> > Regards
> > Manasi
> >
> >
> > On Wed, Mar 22, 2017 at 08:44:36AM -0700, Manasi Navare wrote:
> >> Hi Jani/Ville,
> >> 
> >> I need to add another quick fix which would be required for the fallback
> >> to happen as expected. Should I respin this patch to add that fix or
> >> should I wait for this to get landed?
> >> 
> >> I have mentioned the fix suggested below, please let me know your thoughts 
> >> on that.
> >> 
> >> 
> >> On Tue, Mar 14, 2017 at 03:11:51PM -0700, Manasi Navare wrote:
> >> > 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, update the link status property
> >> > to "BAD" and use a lower link rate to prune the modes. It will redo
> >> > the modeset on the current mode at lower link rate or if the current
> >> > mode gets pruned due to lower link constraints then, it will send a
> >> > hotplug uevent for userspace to handle it.
> >> > 
> >> > This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
> >> > 4.3.1.6.
> >> > 
> >> > This patch is a resend of the original commit id (233ce881dd91fb
> >> > "drm/i915: Implement Link Rate fallback on Link training failure")
> >> > which got reverted in this commit id (afc1ebf4562a14 Revert
> >> > "drm/i915: Implement Link Rate fallback on Link training failure")
> >> > due to CI failures.
> >> > 
> >> > After investigating the CI failures it was found that these
> >> > were essentially the failures which were always there but hidden because
> >> > they used to be DRM_DEBUG_KMS messages for link failures so never got
> >> > caught by CI. But now this patch actually throws DRM_ERROR if the link
> >> > training fails at RBR and 1 lane. So it caught these link train failures.
> >> > 
> >> > There were two failures:
> >> > 1. On SKL 6700k this was because the machine in CI lab is a SKL desktop
> >> > without eDP on Port A. But our VBT initialization code in the driver 
> >> > writes
> >> > VBT defaults in a way that it always sets DP flag on Port A and this does
> >> > not get cleared after parsing the VBT outputs. This has been fixed in
> >> > commit id (bb1d132935c2f8 "drm/i915/vbt: split out defaults that are set
> >> > when there is no VBT) and (665788572c6410b "drm/i915/vbt: don't propagate
> >> > errors from intel_bios_init())
> >> > 
> >> > 2. On ILK-650 desktop - This was happening because of a bad monitor 
> >> > desktop
> >> > combination. I switched the monitor in the CI lab and that helped get rid
> >> > of the link failures on ILK system.
> >> > 
> >> > v10:
> >> > * Rebase on drm-tip and resend after revert
> >> > v9:
> >> > * Use the trimmed max values of link rate/lane count based on
> >> > link train fallback (Daniel Vetter)
> >> > v8:
> >> > * Set link_status to BAD first and then call mode_valid (Jani Nikula)
> >> > v7:
> >> > Remove the redundant variable in previous patch itself
> >> > v6:
> >> > * Obtain link rate index from fallback_link_rate using
> >> > the helper intel_dp_link_rate_index (Jani Nikula)
> >> > * Include fallback within intel_dp_start_link_train (Jani Nikula)
> >> > v5:
> >> > * Move set link status to drm core (Daniel Vetter, Jani Nikula)
> >> > v4:
> >> > * Add fallback support for non DDI platforms too
> >> > * Set connector->link status inside set_link_status function
> >> > (Jani Nikula)
> >> > v3:
> >> > * Set link status property to BAd unconditionally (Jani Nikula)
> >> > * Dont use two separate variables link_train_failed and link_status
> >> > to indicate same thing (Jani Nikula)
> >> > v2:
> >> > * Squashed a few patches (Jani Nikula)
> >> > 
> >> > Acked-by: Tony Cheng 
> >> > Acked-by: Harry Wentland 
> >> > Cc: Jani Nikula 
> >> > Cc: Daniel Vetter 
> >> > Cc: Ville Syrjala 
> >> > Signed-off-by: Manasi Navare 
> >> > Reviewed-by: Jani Nikula 

[Intel-gfx] [PATCH 2/3] drm/i915: Fix SKL+ watermarks for 90/270 rotation

[ville . syrjala]

From: Ville Syrjälä 

skl_check_plane_surface() already rotates the clipped plane source
coordinates to match the scanout direction because that's the way
the GTT mapping is set up. Thus we no longer need to rotate the
coordinates in the watermark code.

For cursors we use the non-clipped coordinates which are not rotated
appropriately, but that doesn't actually matter since cursors don't
even support 90/270 degree rotation.

Cc: sta...@vger.kernel.org
Cc: Tvrtko Ursulin 
Fixes: b63a16f6cd89 ("drm/i915: Compute display surface offset in the plane 
check hook for SKL+")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_pm.c | 36 
 1 file changed, 24 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 570bd603f401..6b1caf9ed3ca 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3373,20 +3373,26 @@ skl_plane_downscale_amount(const struct 
intel_crtc_state *cstate,
 
/* n.b., src is 16.16 fixed point, dst is whole integer */
if (plane->id == PLANE_CURSOR) {
+   /*
+* Cursors only support 0/180 degree rotation,
+* hence no need to account for rotation here.
+*/
src_w = pstate->base.src_w;
src_h = pstate->base.src_h;
dst_w = pstate->base.crtc_w;
dst_h = pstate->base.crtc_h;
} else {
+   /*
+* Src coordinates are already rotated by 270 degrees for
+* the 90/270 degree plane rotation cases (to match the
+* GTT mapping), hence no need to account for rotation here.
+*/
src_w = drm_rect_width(>base.src);
src_h = drm_rect_height(>base.src);
dst_w = drm_rect_width(>base.dst);
dst_h = drm_rect_height(>base.dst);
}
 
-   if (drm_rotation_90_or_270(pstate->base.rotation))
-   swap(dst_w, dst_h);
-
downscale_h = max(src_h / dst_h, (uint32_t)DRM_PLANE_HELPER_NO_SCALING);
downscale_w = max(src_w / dst_w, (uint32_t)DRM_PLANE_HELPER_NO_SCALING);
 
@@ -3417,12 +3423,14 @@ skl_plane_relative_data_rate(const struct 
intel_crtc_state *cstate,
if (y && format != DRM_FORMAT_NV12)
return 0;
 
+   /*
+* Src coordinates are already rotated by 270 degrees for
+* the 90/270 degree plane rotation cases (to match the
+* GTT mapping), hence no need to account for rotation here.
+*/
width = drm_rect_width(_pstate->base.src) >> 16;
height = drm_rect_height(_pstate->base.src) >> 16;
 
-   if (drm_rotation_90_or_270(pstate->rotation))
-   swap(width, height);
-
/* for planar format */
if (format == DRM_FORMAT_NV12) {
if (y)  /* y-plane data rate */
@@ -3505,12 +3513,14 @@ skl_ddb_min_alloc(const struct drm_plane_state *pstate,
fb->modifier != I915_FORMAT_MOD_Yf_TILED)
return 8;
 
+   /*
+* Src coordinates are already rotated by 270 degrees for
+* the 90/270 degree plane rotation cases (to match the
+* GTT mapping), hence no need to account for rotation here.
+*/
src_w = drm_rect_width(_pstate->base.src) >> 16;
src_h = drm_rect_height(_pstate->base.src) >> 16;
 
-   if (drm_rotation_90_or_270(pstate->rotation))
-   swap(src_w, src_h);
-
/* Halve UV plane width and height for NV12 */
if (fb->format->format == DRM_FORMAT_NV12 && !y) {
src_w /= 2;
@@ -3794,13 +3804,15 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
width = intel_pstate->base.crtc_w;
height = intel_pstate->base.crtc_h;
} else {
+   /*
+* Src coordinates are already rotated by 270 degrees for
+* the 90/270 degree plane rotation cases (to match the
+* GTT mapping), hence no need to account for rotation here.
+*/
width = drm_rect_width(_pstate->base.src) >> 16;
height = drm_rect_height(_pstate->base.src) >> 16;
}
 
-   if (drm_rotation_90_or_270(pstate->rotation))
-   swap(width, height);
-
cpp = fb->format->cpp[0];
plane_pixel_rate = skl_adjusted_plane_pixel_rate(cstate, intel_pstate);
 
-- 
2.10.2

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

[Intel-gfx] [PATCH 0/3] drm/i915: Fix SKL+ 90/270 degree rotated scanout

[ville . syrjala]

From: Ville Syrjälä 

I figured it's about time I fix what I broke with my fb offset stuff.
I've posted the scaler thing before, but the watermark and fbc stuff
is new.

Based on some quick tests the WM fixes seem effective. Or at least
underruns seemed to disappear when I was running xonotic with 90/270
degree rotation.

Entire series available here:
git://github.com/vsyrjala/linux.git skl_rotation_fixes

Ville Syrjälä (3):
  drm/i915: Fix scaling check for 90/270 degree plane rotation
  drm/i915: Fix SKL+ watermarks for 90/270 rotation
  drm/i915: Fix 90/270 rotated coordinates for FBC

 drivers/gpu/drm/i915/intel_display.c | 14 --
 drivers/gpu/drm/i915/intel_fbc.c | 19 +++
 drivers/gpu/drm/i915/intel_pm.c  | 36 
 3 files changed, 39 insertions(+), 30 deletions(-)

-- 
2.10.2

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

[Intel-gfx] [PATCH 3/3] drm/i915: Fix 90/270 rotated coordinates for FBC

[ville . syrjala]

From: Ville Syrjälä 

The clipped src coordinates have already been rotated by 270 degrees for
when the plane rotation is 90/270 degrees, hence the FBC code should no
longer swap the width and height.

Cc: sta...@vger.kernel.org
Cc: Tvrtko Ursulin 
Cc: Paulo Zanoni 
Fixes: b63a16f6cd89 ("drm/i915: Compute display surface offset in the plane 
check hook for SKL+")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_fbc.c | 19 +++
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index ded2add18b26..d93c58410bff 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -82,20 +82,10 @@ static unsigned int get_crtc_fence_y_offset(struct 
intel_crtc *crtc)
 static void intel_fbc_get_plane_source_size(struct intel_fbc_state_cache 
*cache,
int *width, int *height)
 {
-   int w, h;
-
-   if (drm_rotation_90_or_270(cache->plane.rotation)) {
-   w = cache->plane.src_h;
-   h = cache->plane.src_w;
-   } else {
-   w = cache->plane.src_w;
-   h = cache->plane.src_h;
-   }
-
if (width)
-   *width = w;
+   *width = cache->plane.src_w;
if (height)
-   *height = h;
+   *height = cache->plane.src_h;
 }
 
 static int intel_fbc_calculate_cfb_size(struct drm_i915_private *dev_priv,
@@ -746,6 +736,11 @@ static void intel_fbc_update_state_cache(struct intel_crtc 
*crtc,
cache->crtc.hsw_bdw_pixel_rate = crtc_state->pixel_rate;
 
cache->plane.rotation = plane_state->base.rotation;
+   /*
+* Src coordinates are already rotated by 270 degrees for
+* the 90/270 degree plane rotation cases (to match the
+* GTT mapping), hence no need to account for rotation here.
+*/
cache->plane.src_w = drm_rect_width(_state->base.src) >> 16;
cache->plane.src_h = drm_rect_height(_state->base.src) >> 16;
cache->plane.visible = plane_state->base.visible;
-- 
2.10.2

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

[Intel-gfx] [PATCH 1/3] drm/i915: Fix scaling check for 90/270 degree plane rotation

[ville . syrjala]

From: Ville Syrjälä 

Starting from commit b63a16f6cd89 ("drm/i915: Compute display surface
offset in the plane check hook for SKL+") we've already rotated the src
coordinates by 270 degrees by the time we check if a scaler is needed
or not, so we must not account for the rotation a second time.
Previously we did these steps in the opposite order and hence the
scaler check had to deal with rotation itself. The double rotation
handling causes us to enable a scaler pretty much every time 90/270
degree plane rotation is requested, leading to fuzzier fonts and whatnot.

v2: s/unsigned/unsigned int/ to appease checkpatch

Cc: sta...@vger.kernel.org
Cc: Tvrtko Ursulin 
Reported-by: Tvrtko Ursulin 
Tested-by: Tvrtko Ursulin 
Fixes: b63a16f6cd89 ("drm/i915: Compute display surface offset in the plane 
check hook for SKL+")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 81baa5a9780c..09c9995cafe6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4609,7 +4609,7 @@ static void cpt_verify_modeset(struct drm_device *dev, 
int pipe)
 
 static int
 skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
- unsigned scaler_user, int *scaler_id, unsigned int rotation,
+ unsigned int scaler_user, int *scaler_id,
  int src_w, int src_h, int dst_w, int dst_h)
 {
struct intel_crtc_scaler_state *scaler_state =
@@ -4618,9 +4618,12 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
to_intel_crtc(crtc_state->base.crtc);
int need_scaling;
 
-   need_scaling = drm_rotation_90_or_270(rotation) ?
-   (src_h != dst_w || src_w != dst_h):
-   (src_w != dst_w || src_h != dst_h);
+   /*
+* Src coordinates are already rotated by 270 degrees for
+* the 90/270 degree plane rotation cases (to match the
+* GTT mapping), hence no need to account for rotation here.
+*/
+   need_scaling = src_w != dst_w || src_h != dst_h;
 
/*
 * if plane is being disabled or scaler is no more required or force 
detach
@@ -4682,7 +4685,7 @@ int skl_update_scaler_crtc(struct intel_crtc_state *state)
const struct drm_display_mode *adjusted_mode = 
>base.adjusted_mode;
 
return skl_update_scaler(state, !state->base.active, SKL_CRTC_INDEX,
-   >scaler_state.scaler_id, DRM_ROTATE_0,
+   >scaler_state.scaler_id,
state->pipe_src_w, state->pipe_src_h,
adjusted_mode->crtc_hdisplay, adjusted_mode->crtc_vdisplay);
 }
@@ -4711,7 +4714,6 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
ret = skl_update_scaler(crtc_state, force_detach,
drm_plane_index(_plane->base),
_state->scaler_id,
-   plane_state->base.rotation,
drm_rect_width(_state->base.src) >> 16,
drm_rect_height(_state->base.src) >> 16,
drm_rect_width(_state->base.dst),
-- 
2.10.2

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

Re: [Intel-gfx] [PATCH] squash! drm/i915: Add format modifiers for Intel

[Ville Syrjälä]

On Fri, Mar 31, 2017 at 08:25:23AM -0700, Ben Widawsky wrote:
> 
> make sprite and cursor have separate functions
> ---
> 
> Ville, I think this addresses most of your comments. I'm guessing you're going
> to ask for separate gen sprite plane functions, but I think this looks pretty
> decent as is.

Yeah, separate might be nice, but I'm fine with this. I think I want to
see if I can rethink some of the format check stuff all over anyway.
That might want the separate the functions or it might not. I don't
think I'll know until I try and see how it would all turn out.
In the meantime we can proceed with this.

But plese drop the plane type BUG_ON()s. We've generally decided to not
do BUGs anymore, and we don't have such things in any other plane vfunc
either. Oh, and it looks like you have some tabs vs. spaces mess in that
sprite funciton.

> ---
> 
>  drivers/gpu/drm/i915/intel_display.c | 26 --
>  drivers/gpu/drm/i915/intel_sprite.c  | 51 
> 
>  2 files changed, 69 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index a5edcc910f4a..3f7ce8c39bc8 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13535,18 +13535,16 @@ static bool skl_mod_supported(uint32_t format, 
> uint64_t modifier)
>   }
>  }
>  
> -static bool intel_plane_format_mod_supported(struct drm_plane *plane,
> -  uint32_t format,
> -  uint64_t modifier)
> +static bool intel_primary_plane_format_mod_supported(struct drm_plane *plane,
> +  uint32_t format,
> +  uint64_t modifier)
>  {
>   struct drm_i915_private *dev_priv = to_i915(plane->dev);
>  
>   if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
>   return false;
>  
> - if (plane->base.type == DRM_PLANE_TYPE_PRIMARY)
> - return modifier == DRM_FORMAT_MOD_LINEAR &&
> - format == DRM_FORMAT_ARGB;
> + BUG_ON(plane->base.type != DRM_PLANE_TYPE_PRIMARY);
>  
>   if (INTEL_GEN(dev_priv) >= 9)
>   return skl_mod_supported(format, modifier);
> @@ -13558,6 +13556,18 @@ static bool intel_plane_format_mod_supported(struct 
> drm_plane *plane,
>   return false;
>  }
>  
> +static bool intel_cursor_plane_format_mod_supported(struct drm_plane *plane,
> + uint32_t format,
> + uint64_t modifier)
> +{
> + if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
> + return false;
> +
> + BUG_ON(plane->base.type != DRM_PLANE_TYPE_CURSOR);
> +
> + return modifier == DRM_FORMAT_MOD_LINEAR && format == 
> DRM_FORMAT_ARGB;
> +}
> +
>  const struct drm_plane_funcs intel_plane_funcs = {
>   .update_plane = drm_atomic_helper_update_plane,
>   .disable_plane = drm_atomic_helper_disable_plane,
> @@ -13567,7 +13577,7 @@ const struct drm_plane_funcs intel_plane_funcs = {
>   .atomic_set_property = intel_plane_atomic_set_property,
>   .atomic_duplicate_state = intel_plane_duplicate_state,
>   .atomic_destroy_state = intel_plane_destroy_state,
> - .format_mod_supported = intel_plane_format_mod_supported,
> + .format_mod_supported = intel_primary_plane_format_mod_supported,
>  };
>  
>  static int
> @@ -13704,7 +13714,7 @@ static const struct drm_plane_funcs 
> intel_cursor_plane_funcs = {
>   .atomic_set_property = intel_plane_atomic_set_property,
>   .atomic_duplicate_state = intel_plane_duplicate_state,
>   .atomic_destroy_state = intel_plane_destroy_state,
> - .format_mod_supported = intel_plane_format_mod_supported,
> + .format_mod_supported = intel_cursor_plane_format_mod_supported,
>  };
>  
>  static struct intel_plane *
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index bf18d9edc66f..dae8e8a943b9 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -30,6 +30,7 @@
>   * support.
>   */
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1102,6 +1103,56 @@ static const uint64_t skl_plane_format_modifiers[] = {
>   DRM_FORMAT_MOD_INVALID
>  };
>  
> +static bool intel_sprite_plane_format_mod_supported(struct drm_plane *plane,
> +uint32_t format,
> +uint64_t modifier)
> +{
> +struct drm_i915_private *dev_priv = to_i915(plane->dev);
> +
> +if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
> +return false;
> +
> +BUG_ON(plane->base.type != DRM_PLANE_TYPE_OVERLAY);
> +
> + switch (format) {
> + case DRM_FORMAT_XBGR2101010:
> + case 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Use LINEAR modifier instead of NONE (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915: Use LINEAR modifier instead of 
NONE (rev2)
URL   : https://patchwork.freedesktop.org/series/21854/
State : success

== Summary ==

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

Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 430s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 424s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 564s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 508s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 550s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 484s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 482s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 412s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 410s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 421s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 481s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 467s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 453s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 565s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 457s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 574s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 463s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 491s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 432s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 528s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 403s

a544b108466ecc1d3819b735f7c35f7f8c071b9a drm-tip: 2017y-03m-31d-14h-34m-10s UTC 
integration manifest
6ed3e31 drm: Add new DRM_IOCTL_MODE_GETPLANE2

== Logs ==

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

[Intel-gfx] [PATCH] dim: Use mktemp for pull-request mails

[Sean Paul]

Instead of hardcoding ~/tmp in dim (and failing when it doesn't
exist), use mktemp to create the pull-request mail file.

Signed-off-by: Sean Paul 
---
 dim | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/dim b/dim
index 8357d4f..8b61fd8 100755
--- a/dim
+++ b/dim
@@ -1278,9 +1278,11 @@ function prep_pull_mail_overview
 # $@: tags, if any, to extract into the pull request overview
 function prep_pull_mail
 {
-   prep_pull_mail_greetings > ~/tmp/dim-pull-request
-   prep_pull_mail_overview "$@" >> ~/tmp/dim-pull-request
-   prep_pull_mail_signature >> ~/tmp/dim-pull-request
+   file=$1
+   shift
+   prep_pull_mail_greetings > $file
+   prep_pull_mail_overview "$@" >> $file
+   prep_pull_mail_signature >> $file
 }
 
 function dim_create_workdir
@@ -1391,17 +1393,18 @@ function dim_update_next_continue
$DRY git tag $tag_testing $DIM_DRM_INTEL_REMOTE/drm-intel-testing
$DRY git push $DIM_DRM_INTEL_REMOTE $tag_testing
 
-   cat > ~/tmp/test-request <<-HERE
+   req_file=$(mktemp)
+   cat > $req_file <<-HERE
Hi all,
 
HERE
obj=$(git rev-parse $tag)
if [[ "$(git cat-file -t $obj)" == "tag" ]] ; then
-   git cat-file -p $obj | tail -n+6 >> ~/tmp/test-request
+   git cat-file -p $obj | tail -n+6 >> $req_file
else
-   echo "" >> 
~/tmp/test-request
+   echo "" >> 
$req_file
fi
-   cat >> ~/tmp/test-request <<-HERE
+   cat >> $req_file <<-HERE
 
Happy testing!
 
@@ -1409,7 +1412,7 @@ function dim_update_next_continue
HERE
 
$DRY $DIM_MUA -s "Updated drm-intel-testing" \
--i ~/tmp/test-request \
+-i $req_file \
 -c "$addr_intel_gfx" \
 -c "$addr_intel_gfx_maintainer1" \
 -c "$addr_intel_gfx_maintainer2" \
@@ -1448,6 +1451,7 @@ function dim_pull_request
branch=${1:?$usage}
upstream=${2:?$usage}
remote=$(branch_to_remote $branch)
+   req_file=$(mktemp)
 
if [ "$branch" != "drm-intel-next" ]; then
assert_branch $branch
@@ -1461,7 +1465,7 @@ function dim_pull_request
if [ "$branch" = "drm-intel-next" ]; then
# drm-intel-next pulls have been tagged using dim update-next
drm_intel_next_tags=$(git log "$branch@{upstream}" ^$upstream 
--decorate | grep "(.*tag: drm-intel-next-" | sed -e "s/^.*(.*tag: 
\(drm-intel-next-[^ ,]*\).*)$/\1/")
-   prep_pull_mail $drm_intel_next_tags
+   prep_pull_mail $req_file $drm_intel_next_tags
tag=$(git describe --all --exact "$branch@{upstream}")
 
repo="drm-intel"
@@ -1475,7 +1479,7 @@ function dim_pull_request
gitk "$branch@{upstream}" ^$upstream &
$DRY git tag -a $tag "$branch@{upstream}"
$DRY git push $remote $tag
-   prep_pull_mail $tag
+   prep_pull_mail $req_file $tag
 
repo=$(branch_to_repo $branch)
fi
@@ -1483,9 +1487,9 @@ function dim_pull_request
url=${drm_tip_repos[$repo]}
git_url=$(echo $url | sed -e 's/git\./anongit./' -e 's/ssh:/git:/')
 
-   git request-pull $upstream $git_url $tag >> ~/tmp/dim-pull-request
+   git request-pull $upstream $git_url $tag >> $req_file
$DRY $DIM_MUA -s "[PULL] $branch" \
-   -i ~/tmp/dim-pull-request \
+   -i $req_file \
-c "$addr_intel_gfx" \
-c "$addr_dri_devel" \
-c "$addr_intel_gfx_maintainer1" \
-- 
2.12.2.564.g063fe858b8-goog

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

[Intel-gfx] [PATCH] squash! drm/i915: Add format modifiers for Intel

[Ben Widawsky]

make sprite and cursor have separate functions
---

Ville, I think this addresses most of your comments. I'm guessing you're going
to ask for separate gen sprite plane functions, but I think this looks pretty
decent as is.
---

 drivers/gpu/drm/i915/intel_display.c | 26 --
 drivers/gpu/drm/i915/intel_sprite.c  | 51 
 2 files changed, 69 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a5edcc910f4a..3f7ce8c39bc8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13535,18 +13535,16 @@ static bool skl_mod_supported(uint32_t format, 
uint64_t modifier)
}
 }
 
-static bool intel_plane_format_mod_supported(struct drm_plane *plane,
-uint32_t format,
-uint64_t modifier)
+static bool intel_primary_plane_format_mod_supported(struct drm_plane *plane,
+uint32_t format,
+uint64_t modifier)
 {
struct drm_i915_private *dev_priv = to_i915(plane->dev);
 
if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
return false;
 
-   if (plane->base.type == DRM_PLANE_TYPE_PRIMARY)
-   return modifier == DRM_FORMAT_MOD_LINEAR &&
-   format == DRM_FORMAT_ARGB;
+   BUG_ON(plane->base.type != DRM_PLANE_TYPE_PRIMARY);
 
if (INTEL_GEN(dev_priv) >= 9)
return skl_mod_supported(format, modifier);
@@ -13558,6 +13556,18 @@ static bool intel_plane_format_mod_supported(struct 
drm_plane *plane,
return false;
 }
 
+static bool intel_cursor_plane_format_mod_supported(struct drm_plane *plane,
+   uint32_t format,
+   uint64_t modifier)
+{
+   if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
+   return false;
+
+   BUG_ON(plane->base.type != DRM_PLANE_TYPE_CURSOR);
+
+   return modifier == DRM_FORMAT_MOD_LINEAR && format == 
DRM_FORMAT_ARGB;
+}
+
 const struct drm_plane_funcs intel_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
@@ -13567,7 +13577,7 @@ const struct drm_plane_funcs intel_plane_funcs = {
.atomic_set_property = intel_plane_atomic_set_property,
.atomic_duplicate_state = intel_plane_duplicate_state,
.atomic_destroy_state = intel_plane_destroy_state,
-   .format_mod_supported = intel_plane_format_mod_supported,
+   .format_mod_supported = intel_primary_plane_format_mod_supported,
 };
 
 static int
@@ -13704,7 +13714,7 @@ static const struct drm_plane_funcs 
intel_cursor_plane_funcs = {
.atomic_set_property = intel_plane_atomic_set_property,
.atomic_duplicate_state = intel_plane_duplicate_state,
.atomic_destroy_state = intel_plane_destroy_state,
-   .format_mod_supported = intel_plane_format_mod_supported,
+   .format_mod_supported = intel_cursor_plane_format_mod_supported,
 };
 
 static struct intel_plane *
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index bf18d9edc66f..dae8e8a943b9 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -30,6 +30,7 @@
  * support.
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1102,6 +1103,56 @@ static const uint64_t skl_plane_format_modifiers[] = {
DRM_FORMAT_MOD_INVALID
 };
 
+static bool intel_sprite_plane_format_mod_supported(struct drm_plane *plane,
+uint32_t format,
+uint64_t modifier)
+{
+struct drm_i915_private *dev_priv = to_i915(plane->dev);
+
+if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
+return false;
+
+BUG_ON(plane->base.type != DRM_PLANE_TYPE_OVERLAY);
+
+   switch (format) {
+   case DRM_FORMAT_XBGR2101010:
+   case DRM_FORMAT_ABGR2101010:
+   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+   return true;
+   break;
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_ABGR:
+   case DRM_FORMAT_ARGB:
+   if (INTEL_GEN(dev_priv) >= 9 || IS_VALLEYVIEW(dev_priv) 
|| IS_CHERRYVIEW(dev_priv))
+   return true;
+   break;
+   case DRM_FORMAT_XBGR:
+   if (INTEL_GEN(dev_priv) >= 6)
+   return true;
+   break;
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_YUYV:
+   case 

[Intel-gfx] [PULL] drm-misc-next

[Sean Paul]

Hi Dave,
Here's the 2nd last pull for 4.12, everything landed after next week will punt
to 4.13.

drm-misc-next-2017-03-31:
drm-misc for 4.12:

Core:
- Removed some fb subsampling dimension checks from core (Ville)
- Some MST slot cleanup (Dhinakaran)
- Extracted drm_debugfs.h & drm_ioctl.h from drmP.h (Daniel)
- Added drm_atomic_helper_shutdown() to compliment suspend/resume counterparts
  (Daniel)
- Pipe context through legacy modeset to remove legacy_backoff nasties (Daniel)
- Cleanups around vblank as well as allowing lockless counter reads (Chris W.)
- VGA Switcheroo added to MAINTAINERS with Lukas Wunner as reviewer (Lukas)

Drivers:
- Enhancements to rockchip driver probe (Jeffy) and dsi (Chris Z.)
- Thunderbolt external GPU awareness added (Lukas)

Cheers, D̶a̶n̶i̶e̶l̶(silly dim) Sean


The following changes since commit 65d1086c44791112188f6aebbdc3a27cab3736d3:

  BackMerge tag 'v4.11-rc3' into drm-next (2017-03-23 12:05:13 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2017-03-31

for you to fetch changes up to b121b051d14cc6e4e799e96e9c06c55989f9e073:

  apple-gmux: Don't switch external DP port on 2011+ MacBook Pros (2017-03-30 
22:42:30 +0200)


drm-misc for 4.12:

Core:
- Removed some fb subsampling dimension checks from core (Ville)
- Some MST slot cleanup (Dhinakaran)
- Extracted drm_debugfs.h & drm_ioctl.h from drmP.h (Daniel)
- Added drm_atomic_helper_shutdown() to compliment suspend/resume counterparts
  (Daniel)
- Pipe context through legacy modeset to remove legacy_backoff nasties (Daniel)
- Cleanups around vblank as well as allowing lockless counter reads (Chris W.)
- VGA Switcheroo added to MAINTAINERS with Lukas Wunner as reviewer (Lukas)

Drivers:
- Enhancements to rockchip driver probe (Jeffy) and dsi (Chris Z.)
- Thunderbolt external GPU awareness added (Lukas)


Chris Wilson (6):
  drm: Make the decision to keep vblank irq enabled earlier
  drm: Mark up accesses of vblank->enabled outside of its spinlock
  drm: vblank cannot be enabled if dev->irq_enabled is false
  drm: Refactor vblank sequence number comparison
  drm: Peek at the current counter/timestamp for vblank queries
  drm: Convert cmpxchg(bool) back to a two step operation

Chris Zhong (4):
  drm/rockchip/dsi: check phy_cfg_clk only for RK3399
  dt-bindings: add the grf clock for dw-mipi-dsi
  drm/rockchip/dsi: enable the grf clk before writing grf registers
  drm/rockchip/dsi: correct the grf_switch_reg name

Christopher Spinrath (1):
  drm/bridge: ti-tfp410: support hpd via gpio

Daniel Vetter (31):
  drm/doc: Document feature merge deadlines
  Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux 
into drm-misc-next
  drm: drop extern from function decls
  drm: Extract drm_debugfs.h
  drm: document driver interface for CRC capturing
  drm/debugfs: Add kerneldoc
  drm/tilcdc: Drop calls to modeset_lock_crtc
  drm: Extract drm_ioctl.h
  drm/todo: Add tinydrm refactoring ideas
  drm/vblank: Remove DRM_VBLANKTIME_IN_VBLANK
  drm/atomic: Introduce drm_atomic_helper_shutdown
  drm/tegra: Don't use modeset_lock_crtc
  drm/doc: remove standard connector props from the csv file
  drm: Document kms locking a bit better
  drm: document the all the atomic iterators
  drm: Wire up proper acquire ctx for plane functions
  drm: Add acquire ctx parameter to ->update_plane
  drm: drm_plane_force_disable is not for atomic drivers
  drm: Add acquire ctx parameter to ->plane_disable
  drm/atomic-helper: remove backoff hack from disable/update_plane
  drm: Roll out acquire context for the page_flip ioctl
  drm: Add acquire ctx parameter to ->page_flip(_target)
  drm/atomic-helper: remove backoff hack from page_flip
  drm: simplify the locking in the GETCRTC ioctl
  drm: Restrict drm_mode_set_config_internal to non-atomic drivers
  drm: Add explicit acquire ctx handling around ->set_config
  drm: Add acquire ctx parameter to ->set_config
  drm/atomic-helper: Remove the backoff hack from set_config
  drm: Fixup failure paths in drm_atomic_helper_set_config
  drm: Clear e after kfree in drm_mode_page_flip_ioctl
  drm: Fix locking gotcha in page_flip ioctl

Eric Anholt (1):
  drm: Clarify the role of plane_state argument to drm_simple update().

Gabriel Krisman Bertazi (1):
  drm: bochs: Prevent double-free of fb helper

Jani Nikula (1):
  drm/scdc: declare drm_scdc_get_scrambling_status

Javi Merino (1):
  drm: use .hword to represent 16-bit numbers

Jeffy Chen (1):
  drm/rockchip: Refactor the component match logic.

Lukas Wunner (6):
  MAINTAINERS: Add Lukas Wunner as reviewer for vga_switcheroo
  PCI: Recognize Thunderbolt devices
  

Re: [Intel-gfx] [PATCH i-g-t 1/2] benchmarks/gem_wsim: Command submission workload simulator

[Chris Wilson]

On Fri, Mar 31, 2017 at 03:58:25PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Tool which emits batch buffers to engines with configurable
> sequences, durations, contexts, dependencies and userspace waits.
> 
> Unfinished but shows promise so sending out for early feedback.
> 
> v2:
>  * Load workload descriptors from files. (also -w)
>  * Help text.
>  * Calibration control if needed. (-t)
>  * NORELOC | LUT to eb flags.
>  * Added sample workload to wsim/workload1.
> 
> TODO list:
> 
>  * Better error handling.
>  * Multi-context support for individual clients.

I think that will also wants multiple dependencies. 

>  * Random/variable batch length.
>  * Load balancing plug-in.
>  * ... ?

Waits and delayed execution cycles.

Multiple clients (as threads).

-- 
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 i-g-t 2/2] igt/scripts: trace.pl to parse the i915 tracepoints

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Given a log file created via perf with some interesting trace
events enabled, this tool can generate the timeline graph of
requests getting queued, their dependencies resolved, sent to
the GPU for executing and finally completed.

This can be useful when analyzing certain classes of performance
issues. More help is available in the tool itself.

The tool will also calculate some overall per engine statistics,
like total time engine was idle and similar.

v2:
 * Address missing git add.
 * Make html output optional (--html switch) and by default
   just output aggregated per engine stats to stdout.

v3:
 * Added --trace option which invokes perf with the correct
   options automatically.
 * Added --avg-delay-stats which prints averages for things
   like waiting on ready, waiting on GPU and context save
   duration.
 * Fix warnings when no waits on an engine.
 * Correct help text.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Harri Syrja 
Cc: Krzysztof E Olinski 
---
 scripts/Makefile.am |   2 +-
 scripts/trace.pl| 946 
 2 files changed, 947 insertions(+), 1 deletion(-)
 create mode 100755 scripts/trace.pl

diff --git a/scripts/Makefile.am b/scripts/Makefile.am
index 85d4a5cf4e5c..641715294936 100644
--- a/scripts/Makefile.am
+++ b/scripts/Makefile.am
@@ -1,2 +1,2 @@
-dist_noinst_SCRIPTS = intel-gfx-trybot who.sh run-tests.sh
+dist_noinst_SCRIPTS = intel-gfx-trybot who.sh run-tests.sh trace.pl
 noinst_PYTHON = throttle.py
diff --git a/scripts/trace.pl b/scripts/trace.pl
new file mode 100755
index ..6bf97ef63560
--- /dev/null
+++ b/scripts/trace.pl
@@ -0,0 +1,946 @@
+#! /usr/bin/perl
+#
+# Copyright © 2017 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+# IN THE SOFTWARE.
+#
+
+use strict;
+use warnings;
+use 5.010;
+
+my $gid = 0;
+my (%db, %queue, %submit, %notify, %rings, %ctxdb, %ringmap, %reqwait);
+my @freqs;
+
+my $max_items = 3000;
+my $width_us = 32000;
+my $correct_durations = 0;
+my %ignore_ring;
+my %skip_box;
+my $html = 0;
+my $trace = 0;
+my $avg_delay_stats = 0;
+
+my @args;
+
+sub arg_help
+{
+   return unless scalar(@_);
+
+   if ($_[0] eq '--help' or $_[0] eq '-h') {
+   shift @_;
+print <trace.log
+
+   This file in turn should be piped into this tool which will generate some
+   statistics out of it, or if --html was given HTML output.
+
+   HTML can be viewed from a directory containing the 'vis' JavaScript module.
+   On Ubuntu this can be installed like this:
+
+   apt-get install npm
+   npm install vis
+
+Usage:
+   trace.pl  output-file
+
+  --help / -h  This help text
+  --max-items=num / -m num Maximum number of boxes to put on the
+   timeline. More boxes means more work for
+ 

[Intel-gfx] [PATCH i-g-t 1/2] benchmarks/gem_wsim: Command submission workload simulator

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Tool which emits batch buffers to engines with configurable
sequences, durations, contexts, dependencies and userspace waits.

Unfinished but shows promise so sending out for early feedback.

v2:
 * Load workload descriptors from files. (also -w)
 * Help text.
 * Calibration control if needed. (-t)
 * NORELOC | LUT to eb flags.
 * Added sample workload to wsim/workload1.

TODO list:

 * Better error handling.
 * Multi-context support for individual clients.
 * Random/variable batch length.
 * Load balancing plug-in.
 * ... ?

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: "Rogozhkin, Dmitry V" 

gem_wsim updates

Signed-off-by: Tvrtko Ursulin 
---
 benchmarks/Makefile.sources |   1 +
 benchmarks/gem_wsim.c   | 593 
 benchmarks/wsim/workload1   |   7 +
 3 files changed, 601 insertions(+)
 create mode 100644 benchmarks/gem_wsim.c
 create mode 100644 benchmarks/wsim/workload1

diff --git a/benchmarks/Makefile.sources b/benchmarks/Makefile.sources
index 3af54ebe36f2..3a941150abb3 100644
--- a/benchmarks/Makefile.sources
+++ b/benchmarks/Makefile.sources
@@ -14,6 +14,7 @@ benchmarks_prog_list =\
gem_prw \
gem_set_domain  \
gem_syslatency  \
+   gem_wsim\
kms_vblank  \
prime_lookup\
vgem_mmap   \
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
new file mode 100644
index ..029967281251
--- /dev/null
+++ b/benchmarks/gem_wsim.c
@@ -0,0 +1,593 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "drm.h"
+#include "ioctl_wrappers.h"
+#include "drmtest.h"
+#include "intel_io.h"
+
+struct w_step
+{
+   /* Workload step metadata */
+   unsigned int context;
+   unsigned int engine;
+   unsigned int duration;
+   int dependency;
+   int wait;
+
+   /* Implementation details */
+   struct drm_i915_gem_execbuffer2 eb;
+   struct drm_i915_gem_exec_object2 obj[3];
+};
+
+struct workload
+{
+   unsigned int nr_steps;
+   struct w_step *steps;
+
+   uint32_t ctx_id;
+};
+
+enum intel_engine_id {
+   RCS,
+   BCS,
+   balance_VCS,
+   VCS,
+   VCS1,
+   VCS2,
+   VECS,
+   NUM_ENGINES
+};
+
+static const unsigned int eb_engine_map[NUM_ENGINES] = {
+   [RCS] = I915_EXEC_RENDER,
+   [BCS] = I915_EXEC_BLT,
+   [balance_VCS] = I915_EXEC_BSD,
+   [VCS] = I915_EXEC_BSD,
+   [VCS1] = I915_EXEC_BSD | I915_EXEC_BSD_RING1,
+   [VCS2] = I915_EXEC_BSD | I915_EXEC_BSD_RING2,
+   [VECS] = I915_EXEC_VEBOX };
+
+static const uint32_t bbe = 0xa << 23;
+static const unsigned int nop_calibration_us = 1000;
+static unsigned long nop_calibration;
+
+static bool quiet;
+static int fd;
+
+/*
+ * Workload descriptor:
+ *
+ * ctx.engine.duration.dependency.wait,...
+ * <0|1>,...
+ *
+ * Engine ids: RCS, BCS, VCS, VCS1, VCS2, VECS
+ *
+ * 
"1.VCS1.3000.0.1,1.RCS.1000.-1.0,1.RCS.3700.0.0,1.RCS.1000.-2.0,1.VCS2.2300.-2.0,1.RCS.4700.-1.0,1.VCS2.600.-1.1"
+ */
+
+static struct workload *parse_workload(char *desc)
+{
+   struct workload *wrk;
+   unsigned int nr_steps = 0;
+   char *token, *tctx, *tstart = desc;
+   char *field, *fctx, *fstart;
+   struct w_step step, *steps = NULL;
+   unsigned int valid;
+   int tmp;
+
+   while ((token = strtok_r(tstart, ",", )) != NULL) {
+   tstart = 

[Intel-gfx] [PATCH i-g-t 0/2] Workload simulation and tracing

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Another WIP posting with some interopability improvements this time.

Example usage:

root@scnuc:~/intel-gpu-tools# benchmarks/gem_wsim
Calibrating nop delay with 1% tolerance...
Nop calibration for 1000us delay is 438660.
root@scnuc:~/intel-gpu-tools# scripts/trace.pl --trace benchmarks/gem_wsim -n 
438660 -r 600 -w benchmarks/wsim/workload1 -c 2 -x
Using 438660 nop calibration for 1000us delay.
2 clients.
Swapping VCS rings between clients.
0: 10.222053s elapsed (58.696622 workloads/s)
1: 10.225807s elapsed (58.675078 workloads/s)
10.226307s elapsed (117.344411 workloads/s)
[ perf record: Woken up 16 times to write data ]
[ perf record: Captured and wrote 3.929 MB perf.data (44688 samples) ]
root@scnuc:~/intel-gpu-tools# perf script | scripts/trace.pl -i 1 -i 4
Ring0: 4832 batches, 4329.07 (4348.11) avg batch us, 0.15% idle, 138.73% busy, 
23.88% runnable, 79.66% queued, 0.01% wait)
Ring2: 1808 batches, 1715.68 (1719.99) avg batch us, 69.68% idle, 30.38% busy, 
0.12% runnable, 112.04% queued, 99.32% wait)
Ring3: 1810 batches, 1727.59 (1739.31) avg batch us, 69.28% idle, 30.75% busy, 
0.11% runnable, 105.37% queued, 99.46% wait)

Most interesting metric here is the engine idle time which will come into play
as I start adding the load balancing options to gem_wsim.

Secondary mode here would be:

root@scnuc:~/intel-gpu-tools# perf script | scripts/trace.pl -i 1 -i 4 --html 
>graph.html

This would enable a timeline of GPU request execution to be viewed with a little
bit of local setup as described in the trace.pl help text.

Tvrtko Ursulin (2):
  benchmarks/gem_wsim: Command submission workload simulator
  igt/scripts: trace.pl to parse the i915 tracepoints

 benchmarks/Makefile.sources |   1 +
 benchmarks/gem_wsim.c   | 593 +++
 benchmarks/wsim/workload1   |   7 +
 scripts/Makefile.am |   2 +-
 scripts/trace.pl| 946 
 5 files changed, 1548 insertions(+), 1 deletion(-)
 create mode 100644 benchmarks/gem_wsim.c
 create mode 100644 benchmarks/wsim/workload1
 create mode 100755 scripts/trace.pl

-- 
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: warning for series starting with [1/2] drm/i915: Redefine ptr_pack_bits() and friends

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Redefine ptr_pack_bits() and 
friends
URL   : https://patchwork.freedesktop.org/series/22284/
State : warning

== Summary ==

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

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-bsw-n3050) fdo#100113
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (fi-bsw-n3050)

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 429s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 430s
fi-bsw-n3050 total:278  pass:237  dwarn:2   dfail:0   fail:0   skip:39  
time: 562s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 508s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 554s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 486s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 487s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 405s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 405s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 420s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 494s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 475s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 451s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 571s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 453s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 572s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 456s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 494s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 437s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 529s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 404s

d083fa23d514574a26bfcf91aa5e1de4e6262cd9 drm-tip: 2017y-03m-31d-11h-25m-25s UTC 
integration manifest
1a4382e drm/i915/execlists: Pack the count into the low bits of the port.request
a6dac331 drm/i915: Redefine ptr_pack_bits() and friends

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/scheduler: add gvt force-single-submission for guc

[Chris Wilson]

On Tue, Mar 28, 2017 at 05:38:40PM +0800, Chuanxiao Dong wrote:
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index dd0e9d587..951540f 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -377,24 +377,6 @@ static void execlists_submit_ports(struct 
> intel_engine_cs *engine)
>   writel(lower_32_bits(desc[0]), elsp);
>  }
>  
> -static bool ctx_single_port_submission(const struct i915_gem_context *ctx)
> -{
> - return (IS_ENABLED(CONFIG_DRM_I915_GVT) &&
> - i915_gem_context_force_single_submission(ctx));
> -}
> -
> -static bool can_merge_ctx(const struct i915_gem_context *prev,
> -   const struct i915_gem_context *next)
> -{
> - if (prev != next)
> - return false;
> -
> - if (ctx_single_port_submission(prev))
> - return false;
> -
> - return true;
> -}
> -
>  static void execlists_dequeue(struct intel_engine_cs *engine)
>  {
>   struct drm_i915_gem_request *last;
> @@ -462,7 +444,8 @@ static void execlists_dequeue(struct intel_engine_cs 
> *engine)
>* request, and so we never need to tell the hardware about
>* the first.
>*/
> - if (last && !can_merge_ctx(cursor->ctx, last->ctx)) {
> + if (last && ((last->ctx != cursor->ctx) ||
> + intel_gvt_context_single_port_submit(last->ctx))) {

Which is easier to understand the original code or the replacement?
Bonus points for sticking to coding style.
-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 2/2] drm/i915/execlists: Pack the count into the low bits of the port.request

[Chris Wilson]

add/remove: 1/1 grow/shrink: 5/4 up/down: 391/-578 (-187)
function old new   delta
execlists_submit_ports   262 471+209
port_assign.isra   - 136+136
capture 63446359 +15
reset_common_ring438 452 +14
execlists_submit_request 228 238 +10
gen8_init_common_ring334 341  +7
intel_engine_is_idle 106 105  -1
i915_engine_info23142290 -24
__i915_gem_set_wedged_BKL485 411 -74
intel_lrc_irq_handler   17891604-185
execlists_update_context 294   --294

The most important change there is the improve to the
intel_lrc_irq_handler and excclist_submit_ports (net improvement since
execlists_update_context is now inlined).

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  32 ---
 drivers/gpu/drm/i915/i915_gem.c|   6 +-
 drivers/gpu/drm/i915/i915_gpu_error.c  |  13 ++-
 drivers/gpu/drm/i915/i915_guc_submission.c |  18 ++--
 drivers/gpu/drm/i915/intel_engine_cs.c |   2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 133 -
 drivers/gpu/drm/i915/intel_ringbuffer.h|   8 +-
 7 files changed, 120 insertions(+), 92 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d689e511744e..0273591c43ad 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3317,6 +3317,7 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
if (i915.enable_execlists) {
u32 ptr, read, write;
struct rb_node *rb;
+   unsigned int idx;
 
seq_printf(m, "\tExeclist status: 0x%08x %08x\n",
   I915_READ(RING_EXECLIST_STATUS_LO(engine)),
@@ -3334,8 +3335,7 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
if (read > write)
write += GEN8_CSB_ENTRIES;
while (read < write) {
-   unsigned int idx = ++read % GEN8_CSB_ENTRIES;
-
+   idx = ++read % GEN8_CSB_ENTRIES;
seq_printf(m, "\tExeclist CSB[%d]: 0x%08x, 
context: %d\n",
   idx,
   
I915_READ(RING_CONTEXT_STATUS_BUF_LO(engine, idx)),
@@ -3343,21 +3343,19 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
}
 
rcu_read_lock();
-   rq = READ_ONCE(engine->execlist_port[0].request);
-   if (rq) {
-   seq_printf(m, "\t\tELSP[0] count=%d, ",
-  engine->execlist_port[0].count);
-   print_request(m, rq, "rq: ");
-   } else {
-   seq_printf(m, "\t\tELSP[0] idle\n");
-   }
-   rq = READ_ONCE(engine->execlist_port[1].request);
-   if (rq) {
-   seq_printf(m, "\t\tELSP[1] count=%d, ",
-  engine->execlist_port[1].count);
-   print_request(m, rq, "rq: ");
-   } else {
-   seq_printf(m, "\t\tELSP[1] idle\n");
+   for (idx = 0; idx < ARRAY_SIZE(engine->execlist_port); 
idx++) {
+   unsigned int count;
+
+   rq = port_unpack(>execlist_port[idx],
+count);
+   if (rq) {
+   seq_printf(m, "\t\tELSP[%d] count=%d, ",
+  idx, count);
+   print_request(m, rq, "rq: ");
+   } else {
+   seq_printf(m, "\t\tELSP[%d] idle\n",
+  idx);
+   }
}
rcu_read_unlock();
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 82638895ad20..946050bf4282 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2967,12 +2967,14 @@ static void engine_set_wedged(struct intel_engine_cs 
*engine)
 */
 
if (i915.enable_execlists) {
+   struct execlist_port *port = engine->execlist_port;

[Intel-gfx] [PATCH 1/2] drm/i915: Redefine ptr_pack_bits() and friends

[Chris Wilson]

Rebrand the current (pointer | bits) pack/unpack utility macros as
explicit bit twiddling for PAGE_SIZE so that we can use the more
flexible underlying macros for different bits.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c |  2 +-
 drivers/gpu/drm/i915/i915_gem.c|  6 +++---
 drivers/gpu/drm/i915/i915_utils.h  | 19 +--
 3 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 7af100f84410..1b69a1f9a1ea 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1284,7 +1284,7 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
 
if (*cmd == MI_BATCH_BUFFER_END) {
if (needs_clflush_after) {
-   void *ptr = 
ptr_mask_bits(shadow_batch_obj->mm.mapping);
+   void *ptr = 
page_mask_bits(shadow_batch_obj->mm.mapping);
drm_clflush_virt_range(ptr,
   (void *)(cmd + 1) - ptr);
}
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bbc6f1c9f175..82638895ad20 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2228,7 +2228,7 @@ void __i915_gem_object_put_pages(struct 
drm_i915_gem_object *obj,
if (obj->mm.mapping) {
void *ptr;
 
-   ptr = ptr_mask_bits(obj->mm.mapping);
+   ptr = page_mask_bits(obj->mm.mapping);
if (is_vmalloc_addr(ptr))
vunmap(ptr);
else
@@ -2560,7 +2560,7 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object 
*obj,
}
GEM_BUG_ON(!obj->mm.pages);
 
-   ptr = ptr_unpack_bits(obj->mm.mapping, has_type);
+   ptr = page_unpack_bits(obj->mm.mapping, has_type);
if (ptr && has_type != type) {
if (pinned) {
ret = -EBUSY;
@@ -2582,7 +2582,7 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object 
*obj,
goto err_unpin;
}
 
-   obj->mm.mapping = ptr_pack_bits(ptr, type);
+   obj->mm.mapping = page_pack_bits(ptr, type);
}
 
 out_unlock:
diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index c5455d36b617..67b1a1897310 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -70,20 +70,27 @@
 #define overflows_type(x, T) \
(sizeof(x) > sizeof(T) && (x) >> (sizeof(T) * BITS_PER_BYTE))
 
-#define ptr_mask_bits(ptr) ({  \
+#define ptr_mask_bits(ptr, n) ({   \
unsigned long __v = (unsigned long)(ptr);   \
-   (typeof(ptr))(__v & PAGE_MASK); \
+   (typeof(ptr))(__v & -BIT(n));   \
 })
 
-#define ptr_unpack_bits(ptr, bits) ({  \
+#define ptr_unmask_bits(ptr, n) ((unsigned long)(ptr) & (BIT(n) - 1))
+
+#define ptr_unpack_bits(ptr, bits, n) ({   \
unsigned long __v = (unsigned long)(ptr);   \
-   (bits) = __v & ~PAGE_MASK;  \
-   (typeof(ptr))(__v & PAGE_MASK); \
+   (bits) = __v & (BIT(n) - 1);\
+   (typeof(ptr))(__v & -BIT(n));   \
 })
 
-#define ptr_pack_bits(ptr, bits)   \
+#define ptr_pack_bits(ptr, bits, n)\
((typeof(ptr))((unsigned long)(ptr) | (bits)))
 
+#define page_mask_bits(ptr) ptr_mask_bits(ptr, PAGE_SHIFT)
+#define page_unmask_bits(ptr) ptr_unmask_bits(ptr, PAGE_SHIFT)
+#define page_pack_bits(ptr, bits) ptr_pack_bits(ptr, bits, PAGE_SHIFT)
+#define page_unpack_bits(ptr, bits) ptr_unpack_bits(ptr, bits, PAGE_SHIFT)
+
 #define ptr_offset(ptr, member) offsetof(typeof(*(ptr)), member)
 
 #define fetch_and_zero(ptr) ({ \
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH] drm/i915/uc: Drop use of MISSING_CASE on trivial enums

[Chris Wilson]

On Fri, Mar 31, 2017 at 10:26:52AM +, Michal Wajdeczko wrote:
> We can rely on compiler to notify us if we miss any case.
> This approach may also reduce driver size (reported ~4K).
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Chris Wilson 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 

With the default compile flags,

drivers/gpu/drm/i915/intel_uc.h: In function ‘intel_uc_fw_type_repr’:
drivers/gpu/drm/i915/intel_uc.h:130:2: warning: enumeration value 
‘THIS_DOES_NOT_EXIST’ not handled in switch [-Wswitch]
  switch (type) {

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

Re: [Intel-gfx] [PATCH] drm/i915: use static const array for PICK macro

[Arnd Bergmann]

On Tue, Mar 21, 2017 at 12:23 PM, Jani Nikula
 wrote:
> On Tue, 21 Mar 2017, Daniel Vetter  wrote:
>> On Tue, Mar 21, 2017 at 09:44:07AM +0100, Arnd Bergmann wrote:
> Arnd, can you check that with kasan please? (I don't have gcc 7.) For me
> the size diff against current git is
>
> text   data bss dec hex filename
> -1137236  312112948 1171395  11dfc3 drivers/gpu/drm/i915/i915.ko
> +1139702  312112948 1173861  11e965 drivers/gpu/drm/i915/i915.ko

Sorry for the late reply.

I was rather sure that I had done the numbers and replied to you earlier, but
I see no evidence of that, so here it comes again, using gcc-7 and kasan:

   text   databssdechex filename
2623339 511153  12064 3146556 30033c
obj-x86/drivers/gpu/drm/i915/i915-original.o
2634886 511153  12064 3158103 303057
obj-x86/drivers/gpu/drm/i915/i915-linux-next.o
2617989 520561  12064 3150614 301316
obj-x86/drivers/gpu/drm/i915/i915-arndpatch.o

The first one is linux-next with ce64645d86ac ("drm/i915: use variadic macros
and arrays to choose port/pipe based registers") reverted, the second one is
the current version, and the third is with my patch applied on top.

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/huc: Simplify intel_huc_init_hw()

[Patchwork]

== Series Details ==

Series: drm/i915/huc: Simplify intel_huc_init_hw()
URL   : https://patchwork.freedesktop.org/series/22280/
State : success

== Summary ==

Series 22280v1 drm/i915/huc: Simplify intel_huc_init_hw()
https://patchwork.freedesktop.org/api/1.0/series/22280/revisions/1/mbox/

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

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 427s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 425s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 574s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 514s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 597s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 479s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 488s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 412s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 412s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 424s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 495s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 471s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 453s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 570s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 449s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 576s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 461s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 491s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 430s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 537s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time: 408s

d083fa23d514574a26bfcf91aa5e1de4e6262cd9 drm-tip: 2017y-03m-31d-11h-25m-25s UTC 
integration manifest
9673e6f7 drm/i915/huc: Simplify intel_huc_init_hw()

== Logs ==

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

[Intel-gfx] [PATCH] drivers: gpu: drm: i915L intel_lpe_audio: Fix kerneldoc comments

[Tamara Diaconita]

Add description for existing parameter 'pipe' to fix the build
warning: ./drivers/gpu/drm/i915/intel_lpe_audio.c:342: warning: No
description found for parameter 'pipe'.

Signed-off-by: Tamara Diaconita 
---
 drivers/gpu/drm/i915/intel_lpe_audio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c 
b/drivers/gpu/drm/i915/intel_lpe_audio.c
index 7a5b41b..d8ca187 100644
--- a/drivers/gpu/drm/i915/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
@@ -331,6 +331,7 @@ void intel_lpe_audio_teardown(struct drm_i915_private 
*dev_priv)
  * audio driver and i915
  * @dev_priv: the i915 drm device private data
  * @eld : ELD data
+ * @pipe: pipe id
  * @port: port id
  * @tmds_clk_speed: tmds clock frequency in Hz
  *
-- 
2.9.3

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

Re: [Intel-gfx] i915 Invert backlight brightness

[Jani Nikula]

On Fri, 31 Mar 2017, Georgios Dakidis  wrote:
> lspci -n
> 00:02.0 0300: 8086:0f31 (rev 0e)
> lspci -nn
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor 
> Z36xxx/Z37xxx Series Graphics & Display [8086:0f31] (rev 0e)

I'm almost certain you have some other issue than one that requires
i915.invert_brightness. It was only ever really needed for some gen4
hardware, AFAICT. Please file a bug at [1], describe your problem,
attach dmesg with drm.debug=14 module parameter set.

BR,
Jani.

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel


-- 
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] ✓ Fi.CI.BAT: success for drm/i915/uc: Drop use of MISSING_CASE on trivial enums

[Patchwork]

== Series Details ==

Series: drm/i915/uc: Drop use of MISSING_CASE on trivial enums
URL   : https://patchwork.freedesktop.org/series/22274/
State : success

== Summary ==

Series 22274v1 drm/i915/uc: Drop use of MISSING_CASE on trivial enums
https://patchwork.freedesktop.org/api/1.0/series/22274/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 431s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 429s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 570s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 508s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 555s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 486s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 485s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 405s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 411s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 423s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 485s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 459s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 455s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 569s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 442s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 572s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 454s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 486s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 431s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 532s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 403s

d083fa23d514574a26bfcf91aa5e1de4e6262cd9 drm-tip: 2017y-03m-31d-11h-25m-25s UTC 
integration manifest
7f850a7 drm/i915/uc: Drop use of MISSING_CASE on trivial enums

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t 2/4] gem_create: Test huge object creation as a basic test

[Chris Wilson]

On Fri, Mar 31, 2017 at 12:56:40PM +0100, Tvrtko Ursulin wrote:
> Userspace WARN was the trigger, but real motive is making sure page
> count overflow protection remains in place. Ensuring obj->base.size
> matches the backing store and there is no possibility of having an
> VMA larger than the object and so either corruption or reading
> foreign data. Or maybe some other fails along the way as well.

Just to say: we do have VMA both larger and smaller than the object,
even ones the same size! I regard the kselftests as better means to
really probe internal corner cases, but will never disregard any test
for what it tells us about the system and what it may find that no other
test might.
-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/huc: Simplify intel_huc_init_hw()

[Michal Wajdeczko]

On last guc/huc cleanup series we've simplified guc init hw
function but missed the one for the huc. While here, change
its signature as we don't care about huc loading status.

Signed-off-by: Michal Wajdeczko 
Cc: Anusha Srivatsa 
Cc: Arkadiusz Hiler 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_huc.c | 48 +++-
 drivers/gpu/drm/i915/intel_uc.h  |  2 +-
 2 files changed, 9 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index 9ee8196..385cacb 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -186,68 +186,36 @@ void intel_huc_select_fw(struct intel_huc *huc)
  * earlier call to intel_huc_init(), so here we need only check that
  * is succeeded, and then transfer the image to the h/w.
  *
- * Return: non-zero code on error
  */
-int intel_huc_init_hw(struct intel_huc *huc)
+void intel_huc_init_hw(struct intel_huc *huc)
 {
struct drm_i915_private *dev_priv = huc_to_i915(huc);
int err;
 
-   if (huc->fw.fetch_status == INTEL_UC_FIRMWARE_NONE)
-   return 0;
-
DRM_DEBUG_DRIVER("%s fw status: fetch %s, load %s\n",
huc->fw.path,
intel_uc_fw_status_repr(huc->fw.fetch_status),
intel_uc_fw_status_repr(huc->fw.load_status));
 
-   if (huc->fw.fetch_status == INTEL_UC_FIRMWARE_SUCCESS &&
-   huc->fw.load_status == INTEL_UC_FIRMWARE_FAIL)
-   return -ENOEXEC;
+   if (huc->fw.fetch_status != INTEL_UC_FIRMWARE_SUCCESS)
+   return;
 
huc->fw.load_status = INTEL_UC_FIRMWARE_PENDING;
 
-   switch (huc->fw.fetch_status) {
-   case INTEL_UC_FIRMWARE_FAIL:
-   /* something went wrong :( */
-   err = -EIO;
-   goto fail;
-
-   case INTEL_UC_FIRMWARE_NONE:
-   case INTEL_UC_FIRMWARE_PENDING:
-   default:
-   /* "can't happen" */
-   WARN_ONCE(1, "HuC fw %s invalid fetch_status %s [%d]\n",
-   huc->fw.path,
-   intel_uc_fw_status_repr(huc->fw.fetch_status),
-   huc->fw.fetch_status);
-   err = -ENXIO;
-   goto fail;
-
-   case INTEL_UC_FIRMWARE_SUCCESS:
-   break;
-   }
-
err = huc_ucode_xfer(dev_priv);
-   if (err)
-   goto fail;
 
-   huc->fw.load_status = INTEL_UC_FIRMWARE_SUCCESS;
+   huc->fw.load_status = err ?
+   INTEL_UC_FIRMWARE_FAIL : INTEL_UC_FIRMWARE_SUCCESS;
 
DRM_DEBUG_DRIVER("%s fw status: fetch %s, load %s\n",
huc->fw.path,
intel_uc_fw_status_repr(huc->fw.fetch_status),
intel_uc_fw_status_repr(huc->fw.load_status));
 
-   return 0;
-
-fail:
-   if (huc->fw.load_status == INTEL_UC_FIRMWARE_PENDING)
-   huc->fw.load_status = INTEL_UC_FIRMWARE_FAIL;
-
-   DRM_ERROR("Failed to complete HuC uCode load with ret %d\n", err);
+   if (huc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
+   DRM_ERROR("Failed to complete HuC uCode load with ret %d\n", 
err);
 
-   return err;
+   return;
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 4b7f73a..2f0229d 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -266,7 +266,7 @@ static inline u32 guc_ggtt_offset(struct i915_vma *vma)
 
 /* intel_huc.c */
 void intel_huc_select_fw(struct intel_huc *huc);
-int intel_huc_init_hw(struct intel_huc *huc);
+void intel_huc_init_hw(struct intel_huc *huc);
 void intel_guc_auth_huc(struct drm_i915_private *dev_priv);
 
 #endif
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH i-g-t 2/4] gem_create: Test huge object creation as a basic test

[Tvrtko Ursulin]

On 31/03/2017 12:46, Chris Wilson wrote:

On Fri, Mar 31, 2017 at 12:38:51PM +0100, Tvrtko Ursulin wrote:


On 31/03/2017 12:16, Chris Wilson wrote:

On Fri, Mar 31, 2017 at 12:07:29PM +0100, Tvrtko Ursulin wrote:


On 31/03/2017 11:48, Chris Wilson wrote:

On Fri, Mar 31, 2017 at 08:08:28AM +0100, Tvrtko Ursulin wrote:


On 30/03/2017 18:22, Chris Wilson wrote:

On Thu, Mar 30, 2017 at 05:58:07PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

It is hard to imagine a more basic test than this one.

Also removed the skip on simulation since I don't know why
would that be needed here.

Signed-off-by: Tvrtko Ursulin 
---
tests/gem_create.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/tests/gem_create.c b/tests/gem_create.c
index de7b82094545..f687b7b40be4 100644
--- a/tests/gem_create.c
+++ b/tests/gem_create.c
@@ -44,6 +44,7 @@
#include 
#include 
#include 
+#include 

#include 

@@ -95,10 +96,13 @@ static void invalid_flag_test(int fd)

static void invalid_size_test(int fd)
{
-   int handle;
+   uint32_t handle;

handle = __gem_create(fd, 0);
igt_assert(!handle);
+
+   handle = __gem_create(fd, INT_MAX * 4096UL + 1);


Why is that an invalid size? Invalid huge in terms of API might arguably
be 1<0 and page aligned.


Because of the comment above the WARN I am removing in "drm/i915:
Remove user triggerable WARN from i915_gem_object_create". We cannot
support larger ones with the combination of sg_table data types and
how we use them (unsigned int nents).


That's an implementation limitation, not an abi one. It is really
important that we do not enshrine kernel internals as expectations,
especially not as a basic test - the expectation is that we will support
massive objects. Having a reality check test to see how far we can get
is useful.


We added code to the driver to prevent userspace from attempting
something. It makes sense to have a test for that, so that one day
if it gets removed in error the test fails, rather than memory
corruption in the kernel happens.


We added code to detect if we would overflow the internal types. We
don't want that to be an artificial ABI restriction.


We can talk about basic or not basic, but I don't see how the
existence of such test can be argued against in principle.


My argument is that userspace should be expecting it to succeed and the
test should fail on current kernels because we are not able to live up
to those expectations. It's enshrining the failure as part of the ABI
that I am wary of.


IGT tests many things apart from the ABI so I wouldn't be worried
about that so much. Basic keyword is not the same as ABI to me.

Failing test has a problem that it is not very useful since it
doesn't get run anywhere. Or we could start tagging tests with a
test driven development tag. Those would then represent tests for
features which we won't but don't have, or are simply broken.

Still the two are not mutually exclusive. We could have a test with
knowledge of implementation details to ensure no memory
corruptions/exploits. And we could have a tdd test like I described
above. Former would pass today and the latter would fail.

Compromise as having the succeeding test as not basic?


Can we just probe what the maximum size create will take. Report it and
fail if less than 4GiB. If your ulterior motive is to ensure that we
don't WARN from userspace paths, that suits you, and it suits my
ulterior motive that we do move to support full 64bit allocations.
(And when we do, start planning for 128bit allocations :)


Userspace WARN was the trigger, but real motive is making sure page 
count overflow protection remains in place. Ensuring obj->base.size 
matches the backing store and there is no possibility of having an VMA 
larger than the object and so either corruption or reading foreign data. 
Or maybe some other fails along the way as well.


Regards,

Tvrtko




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

Re: [Intel-gfx] [PATCH i-g-t 2/4] gem_create: Test huge object creation as a basic test

[Chris Wilson]

On Fri, Mar 31, 2017 at 12:38:51PM +0100, Tvrtko Ursulin wrote:
> 
> On 31/03/2017 12:16, Chris Wilson wrote:
> >On Fri, Mar 31, 2017 at 12:07:29PM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 31/03/2017 11:48, Chris Wilson wrote:
> >>>On Fri, Mar 31, 2017 at 08:08:28AM +0100, Tvrtko Ursulin wrote:
> 
> On 30/03/2017 18:22, Chris Wilson wrote:
> >On Thu, Mar 30, 2017 at 05:58:07PM +0100, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin 
> >>
> >>It is hard to imagine a more basic test than this one.
> >>
> >>Also removed the skip on simulation since I don't know why
> >>would that be needed here.
> >>
> >>Signed-off-by: Tvrtko Ursulin 
> >>---
> >>tests/gem_create.c | 10 ++
> >>1 file changed, 6 insertions(+), 4 deletions(-)
> >>
> >>diff --git a/tests/gem_create.c b/tests/gem_create.c
> >>index de7b82094545..f687b7b40be4 100644
> >>--- a/tests/gem_create.c
> >>+++ b/tests/gem_create.c
> >>@@ -44,6 +44,7 @@
> >>#include 
> >>#include 
> >>#include 
> >>+#include 
> >>
> >>#include 
> >>
> >>@@ -95,10 +96,13 @@ static void invalid_flag_test(int fd)
> >>
> >>static void invalid_size_test(int fd)
> >>{
> >>-   int handle;
> >>+   uint32_t handle;
> >>
> >>handle = __gem_create(fd, 0);
> >>igt_assert(!handle);
> >>+
> >>+   handle = __gem_create(fd, INT_MAX * 4096UL + 1);
> >
> >Why is that an invalid size? Invalid huge in terms of API might arguably
> >be 1< >has to be >0 and page aligned.
> 
> Because of the comment above the WARN I am removing in "drm/i915:
> Remove user triggerable WARN from i915_gem_object_create". We cannot
> support larger ones with the combination of sg_table data types and
> how we use them (unsigned int nents).
> >>>
> >>>That's an implementation limitation, not an abi one. It is really
> >>>important that we do not enshrine kernel internals as expectations,
> >>>especially not as a basic test - the expectation is that we will support
> >>>massive objects. Having a reality check test to see how far we can get
> >>>is useful.
> >>
> >>We added code to the driver to prevent userspace from attempting
> >>something. It makes sense to have a test for that, so that one day
> >>if it gets removed in error the test fails, rather than memory
> >>corruption in the kernel happens.
> >
> >We added code to detect if we would overflow the internal types. We
> >don't want that to be an artificial ABI restriction.
> >
> >>We can talk about basic or not basic, but I don't see how the
> >>existence of such test can be argued against in principle.
> >
> >My argument is that userspace should be expecting it to succeed and the
> >test should fail on current kernels because we are not able to live up
> >to those expectations. It's enshrining the failure as part of the ABI
> >that I am wary of.
> 
> IGT tests many things apart from the ABI so I wouldn't be worried
> about that so much. Basic keyword is not the same as ABI to me.
> 
> Failing test has a problem that it is not very useful since it
> doesn't get run anywhere. Or we could start tagging tests with a
> test driven development tag. Those would then represent tests for
> features which we won't but don't have, or are simply broken.
> 
> Still the two are not mutually exclusive. We could have a test with
> knowledge of implementation details to ensure no memory
> corruptions/exploits. And we could have a tdd test like I described
> above. Former would pass today and the latter would fail.
> 
> Compromise as having the succeeding test as not basic?

Can we just probe what the maximum size create will take. Report it and
fail if less than 4GiB. If your ulterior motive is to ensure that we
don't WARN from userspace paths, that suits you, and it suits my
ulterior motive that we do move to support full 64bit allocations.
(And when we do, start planning for 128bit allocations :)
-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 i-g-t 2/4] gem_create: Test huge object creation as a basic test

[Tvrtko Ursulin]

On 31/03/2017 12:16, Chris Wilson wrote:

On Fri, Mar 31, 2017 at 12:07:29PM +0100, Tvrtko Ursulin wrote:


On 31/03/2017 11:48, Chris Wilson wrote:

On Fri, Mar 31, 2017 at 08:08:28AM +0100, Tvrtko Ursulin wrote:


On 30/03/2017 18:22, Chris Wilson wrote:

On Thu, Mar 30, 2017 at 05:58:07PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

It is hard to imagine a more basic test than this one.

Also removed the skip on simulation since I don't know why
would that be needed here.

Signed-off-by: Tvrtko Ursulin 
---
tests/gem_create.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/tests/gem_create.c b/tests/gem_create.c
index de7b82094545..f687b7b40be4 100644
--- a/tests/gem_create.c
+++ b/tests/gem_create.c
@@ -44,6 +44,7 @@
#include 
#include 
#include 
+#include 

#include 

@@ -95,10 +96,13 @@ static void invalid_flag_test(int fd)

static void invalid_size_test(int fd)
{
-   int handle;
+   uint32_t handle;

handle = __gem_create(fd, 0);
igt_assert(!handle);
+
+   handle = __gem_create(fd, INT_MAX * 4096UL + 1);


Why is that an invalid size? Invalid huge in terms of API might arguably
be 1<0 and page aligned.


Because of the comment above the WARN I am removing in "drm/i915:
Remove user triggerable WARN from i915_gem_object_create". We cannot
support larger ones with the combination of sg_table data types and
how we use them (unsigned int nents).


That's an implementation limitation, not an abi one. It is really
important that we do not enshrine kernel internals as expectations,
especially not as a basic test - the expectation is that we will support
massive objects. Having a reality check test to see how far we can get
is useful.


We added code to the driver to prevent userspace from attempting
something. It makes sense to have a test for that, so that one day
if it gets removed in error the test fails, rather than memory
corruption in the kernel happens.


We added code to detect if we would overflow the internal types. We
don't want that to be an artificial ABI restriction.


We can talk about basic or not basic, but I don't see how the
existence of such test can be argued against in principle.


My argument is that userspace should be expecting it to succeed and the
test should fail on current kernels because we are not able to live up
to those expectations. It's enshrining the failure as part of the ABI
that I am wary of.


IGT tests many things apart from the ABI so I wouldn't be worried about 
that so much. Basic keyword is not the same as ABI to me.


Failing test has a problem that it is not very useful since it doesn't 
get run anywhere. Or we could start tagging tests with a test driven 
development tag. Those would then represent tests for features which we 
won't but don't have, or are simply broken.


Still the two are not mutually exclusive. We could have a test with 
knowledge of implementation details to ensure no memory 
corruptions/exploits. And we could have a tdd test like I described 
above. Former would pass today and the latter would fail.


Compromise as having the succeeding test as not basic?

Regards,

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

Re: [Intel-gfx] [PATCH] drm/i915: disable KASAN for handlers

[Arnd Bergmann]

On Fri, Mar 31, 2017 at 12:29 PM, Jani Nikula
 wrote:
> On Fri, 31 Mar 2017, Zhenyu Wang  wrote:
>> On 2017.03.30 11:46:27 +0200, Jiri Slaby wrote:
>>> Handlers are currently the only blocker to compile the kernel with gcc 7
>>> and KASAN+use-after-scope enabled:
>>> drivers/gpu/drm/i915/gvt/handlers.c:2200:1: error: the frame size of 43760 
>>> bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
>>> drivers/gpu/drm/i915/gvt/handlers.c:2402:1: error: the frame size of 9400 
>>> bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
>>> drivers/gpu/drm/i915/gvt/handlers.c:2628:1: error: the frame size of 11256 
>>> bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
>>>
>>> It is due to many expansions of MMIO_* macros in init_generic_mmio_info.
>>> INTEL_GVT_MMIO_OFFSET generates for each such line a __reg and an
>>> offset. There are too many for KASAN to keep up.
>>>
>>> So disable KASAN for this file.
>>>
>>> Signed-off-by: Jiri Slaby 
>>> Cc: Martin Liska 
>>> Cc: Zhenyu Wang 
>>> Cc: Zhi Wang 
>>> Cc: Daniel Vetter 
>>> Cc: Jani Nikula 
>>> Cc: David Airlie 
>>> Cc: intel-gvt-...@lists.freedesktop.org
>>> Cc: intel-gfx@lists.freedesktop.org
>>> Cc: dri-de...@lists.freedesktop.org
>>> ---
>>>  drivers/gpu/drm/i915/gvt/Makefile | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
>>> b/drivers/gpu/drm/i915/gvt/Makefile
>>> index b123c20e2097..942f1849d194 100644
>>> --- a/drivers/gpu/drm/i915/gvt/Makefile
>>> +++ b/drivers/gpu/drm/i915/gvt/Makefile
>>> @@ -6,3 +6,5 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o 
>>> trace_points.o firmware.o \
>>>  ccflags-y   += -I$(src) -I$(src)/$(GVT_DIR) -Wall
>>>  i915-y  += $(addprefix $(GVT_DIR)/, 
>>> $(GVT_SOURCE))
>>>  obj-$(CONFIG_DRM_I915_GVT_KVMGT)+= $(GVT_DIR)/kvmgt.o
>>> +
>>> +KASAN_SANITIZE_handlers.o := n
>>> --
>>> 2.12.2
>>>
>>
>> Applied this, we'd better cleanup legacy usage to current i915 mmio
>> reg define. Thanks!
>
> Hmmh, that was a bit fast, there was a related discussion going in [1].
>
> BR,
> Jani.
>
>
> [1] 20170320215713.3086140-1-arnd@arndb.de">http://mid.mail-archive.com/20170320215713.3086140-1-arnd@arndb.de

Sorry about that, it looked like I never replied to your last mail.

There is also a related problem that I had sent another fix for:
https://patchwork.kernel.org/patch/9601349/

I still think that my two patches are correct and they should both be applied.

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

Re: [Intel-gfx] [PATCH] drm/i915: make a few DDI functions static

[Paulo Zanoni]

Em Sex, 2017-03-31 às 13:21 +0300, Ville Syrjälä escreveu:
> On Thu, Mar 30, 2017 at 05:57:52PM -0300, Paulo Zanoni wrote:
> > 
> > We don't need to export them since they're not being used outside
> > the
> > file. The next time I try to find the callers for these things I
> > will
> > know I won't need to look outside intel_ddi.c.
> 
> You don't do cscope/ctags/whatever?

When a function is static I just put the vim cursor on top of its name
and press * and go with n/N. I think that's always faster than any
other method. But yeah, for non-static stuff I end up having to use
better tools.

> 
> But anyway static is good since it hands the compiler a bit more
> rope.
> 
> Reviewed-by: Ville Syrjälä 

Thanks!

> 
> > 
> > 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c | 8 
> >  drivers/gpu/drm/i915/intel_drv.h | 4 
> >  2 files changed, 4 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 83abab9..0914ad9 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -539,7 +539,7 @@ intel_ddi_get_buf_trans_fdi(struct
> > drm_i915_private *dev_priv,
> >   * values in advance. This function programs the correct values
> > for
> >   * DP/eDP/FDI use cases.
> >   */
> > -void intel_prepare_dp_ddi_buffers(struct intel_encoder *encoder)
> > +static void intel_prepare_dp_ddi_buffers(struct intel_encoder
> > *encoder)
> >  {
> >     struct drm_i915_private *dev_priv = to_i915(encoder-
> > >base.dev);
> >     u32 iboost_bit = 0;
> > @@ -806,7 +806,7 @@ void hsw_fdi_link_train(struct intel_crtc
> > *crtc,
> >        DP_TP_CTL_ENABLE);
> >  }
> >  
> > -void intel_ddi_init_dp_buf_reg(struct intel_encoder *encoder)
> > +static void intel_ddi_init_dp_buf_reg(struct intel_encoder
> > *encoder)
> >  {
> >     struct intel_dp *intel_dp = enc_to_intel_dp(
> > >base);
> >     struct intel_digital_port *intel_dig_port =
> > @@ -1616,8 +1616,8 @@ uint32_t ddi_signal_levels(struct intel_dp
> > *intel_dp)
> >     return DDI_BUF_TRANS_SELECT(level);
> >  }
> >  
> > -void intel_ddi_clk_select(struct intel_encoder *encoder,
> > -     struct intel_shared_dpll *pll)
> > +static void intel_ddi_clk_select(struct intel_encoder *encoder,
> > +    struct intel_shared_dpll *pll)
> >  {
> >     struct drm_i915_private *dev_priv = to_i915(encoder-
> > >base.dev);
> >     enum port port = intel_ddi_get_encoder_port(encoder);
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index e24641b..313fad0 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1229,12 +1229,9 @@ void intel_crt_init(struct drm_i915_private
> > *dev_priv);
> >  void intel_crt_reset(struct drm_encoder *encoder);
> >  
> >  /* intel_ddi.c */
> > -void intel_ddi_clk_select(struct intel_encoder *encoder,
> > -     struct intel_shared_dpll *pll);
> >  void intel_ddi_fdi_post_disable(struct intel_encoder
> > *intel_encoder,
> >     struct intel_crtc_state
> > *old_crtc_state,
> >     struct drm_connector_state
> > *old_conn_state);
> > -void intel_prepare_dp_ddi_buffers(struct intel_encoder *encoder);
> >  void hsw_fdi_link_train(struct intel_crtc *crtc,
> >     const struct intel_crtc_state
> > *crtc_state);
> >  void intel_ddi_init(struct drm_i915_private *dev_priv, enum port
> > port);
> > @@ -1255,7 +1252,6 @@ bool intel_ddi_is_audio_enabled(struct
> > drm_i915_private *dev_priv,
> >  void intel_ddi_get_config(struct intel_encoder *encoder,
> >       struct intel_crtc_state *pipe_config);
> >  
> > -void intel_ddi_init_dp_buf_reg(struct intel_encoder *encoder);
> >  void intel_ddi_clock_get(struct intel_encoder *encoder,
> >      struct intel_crtc_state *pipe_config);
> >  void intel_ddi_set_vc_payload_alloc(const struct intel_crtc_state
> > *crtc_state,
> > -- 
> > 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 i-g-t 2/4] gem_create: Test huge object creation as a basic test

[Chris Wilson]

On Fri, Mar 31, 2017 at 12:07:29PM +0100, Tvrtko Ursulin wrote:
> 
> On 31/03/2017 11:48, Chris Wilson wrote:
> >On Fri, Mar 31, 2017 at 08:08:28AM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 30/03/2017 18:22, Chris Wilson wrote:
> >>>On Thu, Mar 30, 2017 at 05:58:07PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> It is hard to imagine a more basic test than this one.
> 
> Also removed the skip on simulation since I don't know why
> would that be needed here.
> 
> Signed-off-by: Tvrtko Ursulin 
> ---
> tests/gem_create.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/tests/gem_create.c b/tests/gem_create.c
> index de7b82094545..f687b7b40be4 100644
> --- a/tests/gem_create.c
> +++ b/tests/gem_create.c
> @@ -44,6 +44,7 @@
> #include 
> #include 
> #include 
> +#include 
> 
> #include 
> 
> @@ -95,10 +96,13 @@ static void invalid_flag_test(int fd)
> 
> static void invalid_size_test(int fd)
> {
> - int handle;
> + uint32_t handle;
> 
>   handle = __gem_create(fd, 0);
>   igt_assert(!handle);
> +
> + handle = __gem_create(fd, INT_MAX * 4096UL + 1);
> >>>
> >>>Why is that an invalid size? Invalid huge in terms of API might arguably
> >>>be 1< >>>has to be >0 and page aligned.
> >>
> >>Because of the comment above the WARN I am removing in "drm/i915:
> >>Remove user triggerable WARN from i915_gem_object_create". We cannot
> >>support larger ones with the combination of sg_table data types and
> >>how we use them (unsigned int nents).
> >
> >That's an implementation limitation, not an abi one. It is really
> >important that we do not enshrine kernel internals as expectations,
> >especially not as a basic test - the expectation is that we will support
> >massive objects. Having a reality check test to see how far we can get
> >is useful.
> 
> We added code to the driver to prevent userspace from attempting
> something. It makes sense to have a test for that, so that one day
> if it gets removed in error the test fails, rather than memory
> corruption in the kernel happens.

We added code to detect if we would overflow the internal types. We
don't want that to be an artificial ABI restriction.
 
> We can talk about basic or not basic, but I don't see how the
> existence of such test can be argued against in principle.

My argument is that userspace should be expecting it to succeed and the
test should fail on current kernels because we are not able to live up
to those expectations. It's enshrining the failure as part of the ABI
that I am wary of.
-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 i-g-t 4/4] gem_create: Convert stolen test to uABI checking

[Tvrtko Ursulin]

On 31/03/2017 11:50, Chris Wilson wrote:

On Fri, Mar 31, 2017 at 08:11:10AM +0100, Tvrtko Ursulin wrote:


On 30/03/2017 18:25, Chris Wilson wrote:

On Thu, Mar 30, 2017 at 05:58:09PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Stolen never materialized so convert this test into checking
that the garbage in padding remains legal.

Signed-off-by: Tvrtko Ursulin 
---
tests/gem_create.c | 39 ---
1 file changed, 12 insertions(+), 27 deletions(-)

diff --git a/tests/gem_create.c b/tests/gem_create.c
index 21df13f7b655..0dad06c784c5 100644
--- a/tests/gem_create.c
+++ b/tests/gem_create.c
@@ -27,8 +27,7 @@

/** @file gem_create.c
 *
- * This is a test for the extended and old gem_create ioctl, that
- * includes allocation of object from stolen memory and shmem.
+ * This is a test for the gem_create ioctl.
 *
 * The goal is to simply ensure that basics work and invalid input
 * combinations are rejected.
@@ -62,36 +61,22 @@ IGT_TEST_DESCRIPTION("This is a test for the extended & old 
gem_create ioctl,"
 " that includes allocation of object from stolen memory"
 " and shmem.");

-#define CLEAR(s) memset(, 0, sizeof(s))
#define PAGE_SIZE 4096

-struct local_i915_gem_create_v2 {
-   uint64_t size;
-   uint32_t handle;
-   uint32_t pad;
-#define I915_CREATE_PLACEMENT_STOLEN (1<<0)
-   uint32_t flags;
-} create;
-
-#define LOCAL_IOCTL_I915_GEM_CREATE   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_CREATE, struct local_i915_gem_create_v2)
-
-static void invalid_flag_test(int fd)
+/*
+ * Verify that historical omission of checking for garbage in the padding
+ * field still holds.
+ */
+static void test_pad_garbage(int fd)
{
+   struct drm_i915_gem_create create = { };
int ret;

-   gem_require_stolen_support(fd);
-
create.handle = 0;
create.size = PAGE_SIZE;
-   create.flags = ~I915_CREATE_PLACEMENT_STOLEN;
-   ret = drmIoctl(fd, LOCAL_IOCTL_I915_GEM_CREATE, );
-
-   igt_assert(ret <= 0);
-
-   create.flags = ~0;
-   ret = drmIoctl(fd, LOCAL_IOCTL_I915_GEM_CREATE, );
-
-   igt_assert(ret <= 0);
+   create.pad = 1;
+   ret = drmIoctl(fd, DRM_IOCTL_I915_GEM_CREATE, );
+   igt_assert_eq(ret, 0);
}

static void invalid_size_test(int fd)
@@ -134,8 +119,8 @@ igt_main
fd = drm_open_driver(DRIVER_INTEL);
}

-   igt_subtest("stolen-invalid-flag")
-   invalid_flag_test(fd);
+   igt_subtest("basic-pad-garbage")
+   test_pad_garbage(fd);


Not basic though. I just dislike having negative tests that we intend to
break be part of basic. (I dislike negative tests in general as they are
restrictive and limit creativity, a false limitation in terms of ABI.)


My understanding is that we can never break this now. I mean that we
have to allow userspace putting garbage in the padding field forever
now.

I don't fully understand right now then how createv2 implementation
was suggesting to re-purpose half of the padding for flags at the
moment as well.


It's simple, the code here doesn't reflect the kernel interface :)


Okay I was mistaken that createv2 split the u64 pad into u32 pad and u32 
flags. In fact pad is u32 today and createv2 was extending the structure.


Kernel interface for gem_create today accepts garbage in the pad field. 
Hence we can never use it for something else.


So please explain in more detail why testing that garbage in pad is not 
rejected is wrong. Maybe it's a slow day for me, but I don't get it.


Regards,

Tvrtko


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

Re: [Intel-gfx] [PATCH i-g-t 2/4] gem_create: Test huge object creation as a basic test

[Tvrtko Ursulin]

On 31/03/2017 11:48, Chris Wilson wrote:

On Fri, Mar 31, 2017 at 08:08:28AM +0100, Tvrtko Ursulin wrote:


On 30/03/2017 18:22, Chris Wilson wrote:

On Thu, Mar 30, 2017 at 05:58:07PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

It is hard to imagine a more basic test than this one.

Also removed the skip on simulation since I don't know why
would that be needed here.

Signed-off-by: Tvrtko Ursulin 
---
tests/gem_create.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/tests/gem_create.c b/tests/gem_create.c
index de7b82094545..f687b7b40be4 100644
--- a/tests/gem_create.c
+++ b/tests/gem_create.c
@@ -44,6 +44,7 @@
#include 
#include 
#include 
+#include 

#include 

@@ -95,10 +96,13 @@ static void invalid_flag_test(int fd)

static void invalid_size_test(int fd)
{
-   int handle;
+   uint32_t handle;

handle = __gem_create(fd, 0);
igt_assert(!handle);
+
+   handle = __gem_create(fd, INT_MAX * 4096UL + 1);


Why is that an invalid size? Invalid huge in terms of API might arguably
be 1<0 and page aligned.


Because of the comment above the WARN I am removing in "drm/i915:
Remove user triggerable WARN from i915_gem_object_create". We cannot
support larger ones with the combination of sg_table data types and
how we use them (unsigned int nents).


That's an implementation limitation, not an abi one. It is really
important that we do not enshrine kernel internals as expectations,
especially not as a basic test - the expectation is that we will support
massive objects. Having a reality check test to see how far we can get
is useful.


We added code to the driver to prevent userspace from attempting 
something. It makes sense to have a test for that, so that one day if it 
gets removed in error the test fails, rather than memory corruption in 
the kernel happens.


We can talk about basic or not basic, but I don't see how the existence 
of such test can be argued against in principle.


Regards,

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

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Move retire-requests into i915_gem_wait_for_idle()

[Chris Wilson]

On Fri, Mar 31, 2017 at 11:21:22AM +0300, Joonas Lahtinen wrote:
> On to, 2017-03-30 at 15:50 +0100, Chris Wilson wrote:
> > As we now distinguish everywhere that can call
> > i915_gem_retire_requests() following a successful wait_for_idle, we can
> > remove the duplication by moving that call into i915_gem_wait_for_idle()
> > itself.
> > 
> > Signed-off-by: Chris Wilson 
> 
> 
> 
> > @@ -4180,8 +4180,6 @@ fault_irq_set(struct drm_i915_private *i915,
> >     goto err_unlock;
> >  
> >     /* Retire to kick idle work */
> 
> Stale comment, best before date was yesterday.
> 
> i915_gem_idle_gpu or something might be more descriptive now.

In the past it was actually called i915_gpu_idle().

It evolved from that as that isn't very clear what it actually does, and
predated GEM (i.e. it also dealt with DRI1). I like having the "wait" in
the name, as that should make the might_sleep() very clear and ties in
nicely with passing around the wait-flags.

i915_gem_wait_for_idle() is still my favourite, yet.
-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 i-g-t 4/4] gem_create: Convert stolen test to uABI checking

[Chris Wilson]

On Fri, Mar 31, 2017 at 08:11:10AM +0100, Tvrtko Ursulin wrote:
> 
> On 30/03/2017 18:25, Chris Wilson wrote:
> >On Thu, Mar 30, 2017 at 05:58:09PM +0100, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin 
> >>
> >>Stolen never materialized so convert this test into checking
> >>that the garbage in padding remains legal.
> >>
> >>Signed-off-by: Tvrtko Ursulin 
> >>---
> >> tests/gem_create.c | 39 ---
> >> 1 file changed, 12 insertions(+), 27 deletions(-)
> >>
> >>diff --git a/tests/gem_create.c b/tests/gem_create.c
> >>index 21df13f7b655..0dad06c784c5 100644
> >>--- a/tests/gem_create.c
> >>+++ b/tests/gem_create.c
> >>@@ -27,8 +27,7 @@
> >>
> >> /** @file gem_create.c
> >>  *
> >>- * This is a test for the extended and old gem_create ioctl, that
> >>- * includes allocation of object from stolen memory and shmem.
> >>+ * This is a test for the gem_create ioctl.
> >>  *
> >>  * The goal is to simply ensure that basics work and invalid input
> >>  * combinations are rejected.
> >>@@ -62,36 +61,22 @@ IGT_TEST_DESCRIPTION("This is a test for the extended & 
> >>old gem_create ioctl,"
> >> " that includes allocation of object from stolen memory"
> >> " and shmem.");
> >>
> >>-#define CLEAR(s) memset(, 0, sizeof(s))
> >> #define PAGE_SIZE 4096
> >>
> >>-struct local_i915_gem_create_v2 {
> >>-   uint64_t size;
> >>-   uint32_t handle;
> >>-   uint32_t pad;
> >>-#define I915_CREATE_PLACEMENT_STOLEN (1<<0)
> >>-   uint32_t flags;
> >>-} create;
> >>-
> >>-#define LOCAL_IOCTL_I915_GEM_CREATE   DRM_IOWR(DRM_COMMAND_BASE + 
> >>DRM_I915_GEM_CREATE, struct local_i915_gem_create_v2)
> >>-
> >>-static void invalid_flag_test(int fd)
> >>+/*
> >>+ * Verify that historical omission of checking for garbage in the padding
> >>+ * field still holds.
> >>+ */
> >>+static void test_pad_garbage(int fd)
> >> {
> >>+   struct drm_i915_gem_create create = { };
> >>int ret;
> >>
> >>-   gem_require_stolen_support(fd);
> >>-
> >>create.handle = 0;
> >>create.size = PAGE_SIZE;
> >>-   create.flags = ~I915_CREATE_PLACEMENT_STOLEN;
> >>-   ret = drmIoctl(fd, LOCAL_IOCTL_I915_GEM_CREATE, );
> >>-
> >>-   igt_assert(ret <= 0);
> >>-
> >>-   create.flags = ~0;
> >>-   ret = drmIoctl(fd, LOCAL_IOCTL_I915_GEM_CREATE, );
> >>-
> >>-   igt_assert(ret <= 0);
> >>+   create.pad = 1;
> >>+   ret = drmIoctl(fd, DRM_IOCTL_I915_GEM_CREATE, );
> >>+   igt_assert_eq(ret, 0);
> >> }
> >>
> >> static void invalid_size_test(int fd)
> >>@@ -134,8 +119,8 @@ igt_main
> >>fd = drm_open_driver(DRIVER_INTEL);
> >>}
> >>
> >>-   igt_subtest("stolen-invalid-flag")
> >>-   invalid_flag_test(fd);
> >>+   igt_subtest("basic-pad-garbage")
> >>+   test_pad_garbage(fd);
> >
> >Not basic though. I just dislike having negative tests that we intend to
> >break be part of basic. (I dislike negative tests in general as they are
> >restrictive and limit creativity, a false limitation in terms of ABI.)
> 
> My understanding is that we can never break this now. I mean that we
> have to allow userspace putting garbage in the padding field forever
> now.
> 
> I don't fully understand right now then how createv2 implementation
> was suggesting to re-purpose half of the padding for flags at the
> moment as well.

It's simple, the code here doesn't reflect the kernel interface :)
-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 i-g-t 2/4] gem_create: Test huge object creation as a basic test

[Chris Wilson]

On Fri, Mar 31, 2017 at 08:08:28AM +0100, Tvrtko Ursulin wrote:
> 
> On 30/03/2017 18:22, Chris Wilson wrote:
> >On Thu, Mar 30, 2017 at 05:58:07PM +0100, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin 
> >>
> >>It is hard to imagine a more basic test than this one.
> >>
> >>Also removed the skip on simulation since I don't know why
> >>would that be needed here.
> >>
> >>Signed-off-by: Tvrtko Ursulin 
> >>---
> >> tests/gem_create.c | 10 ++
> >> 1 file changed, 6 insertions(+), 4 deletions(-)
> >>
> >>diff --git a/tests/gem_create.c b/tests/gem_create.c
> >>index de7b82094545..f687b7b40be4 100644
> >>--- a/tests/gem_create.c
> >>+++ b/tests/gem_create.c
> >>@@ -44,6 +44,7 @@
> >> #include 
> >> #include 
> >> #include 
> >>+#include 
> >>
> >> #include 
> >>
> >>@@ -95,10 +96,13 @@ static void invalid_flag_test(int fd)
> >>
> >> static void invalid_size_test(int fd)
> >> {
> >>-   int handle;
> >>+   uint32_t handle;
> >>
> >>handle = __gem_create(fd, 0);
> >>igt_assert(!handle);
> >>+
> >>+   handle = __gem_create(fd, INT_MAX * 4096UL + 1);
> >
> >Why is that an invalid size? Invalid huge in terms of API might arguably
> >be 1< >has to be >0 and page aligned.
> 
> Because of the comment above the WARN I am removing in "drm/i915:
> Remove user triggerable WARN from i915_gem_object_create". We cannot
> support larger ones with the combination of sg_table data types and
> how we use them (unsigned int nents).

That's an implementation limitation, not an abi one. It is really
important that we do not enshrine kernel internals as expectations,
especially not as a basic test - the expectation is that we will support
massive objects. Having a reality check test to see how far we can get
is useful.

For example, lazy population of pages is an abi feature (I think so, at
least all userspace takes that into account, but I don't know if anyone
is really depending on it -- certainly due to the limitations we have in
place lazy is good, and userspace does try to take advantage of that,
and compensates for it at others, but whether anyone would break because
of a change to population semantics, not sure), so we could reasonably
allocate all pot of sizes and check the kernel doesn't reject them, until
the overflow check at -4095.
 
> >/* Only multiples of page size (4096) are allowed. Check all likely
> > * misalignments from pot boundaries to check validity and possibility
> > * of incorrect overflow.
> > */
> > for (int order = 0; order < 64; order++) {
> > uint64_t size = (uint64_t)1 << order;
> > igt_assert(!__gem_create(fd, size - 1));
> > igt_assert(!__gem_create(fd, size + 1));
> > if (order < 12)
> > igt_assert(!__gem_create(fd, size + 1));
> >}
> >
> >Still enshrines knowlege of PAGE_SIZE into the ABI. Meh.
> 
> We round up for the user transparently which I am actually making
> the other subtest in this file test in a later patch.

Bah, I keep creating objects at too low a level where that rounding
doesn't occur automatically :)
-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 v10] drm/i915: Implement Link Rate fallback on Link training failure

[Jani Nikula]

On Fri, 31 Mar 2017, Manasi Navare  wrote:
> Hi Jani,
>
> I have reviewed your recent DP link rate / lane count
> refactoring patch series and I believe that it will soon get merged.

I haven't received reviews on all of the patches in my series yet, in
particular the first patches are missing reviews so I can't even get
started pushing them.

BR,
Jani.


>
> Are you waiting on merging this patch so that your refactoring
> series gets merged first? Or can we merge this patch since
> it already has ACKs and R-bs.
>
> Please advise on next steps for this patch, since some
> of the PSR related patches are pending merge because of this.
>
> Regards
> Manasi
>
>
> On Wed, Mar 22, 2017 at 08:44:36AM -0700, Manasi Navare wrote:
>> Hi Jani/Ville,
>> 
>> I need to add another quick fix which would be required for the fallback
>> to happen as expected. Should I respin this patch to add that fix or
>> should I wait for this to get landed?
>> 
>> I have mentioned the fix suggested below, please let me know your thoughts 
>> on that.
>> 
>> 
>> On Tue, Mar 14, 2017 at 03:11:51PM -0700, Manasi Navare wrote:
>> > 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, update the link status property
>> > to "BAD" and use a lower link rate to prune the modes. It will redo
>> > the modeset on the current mode at lower link rate or if the current
>> > mode gets pruned due to lower link constraints then, it will send a
>> > hotplug uevent for userspace to handle it.
>> > 
>> > This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
>> > 4.3.1.6.
>> > 
>> > This patch is a resend of the original commit id (233ce881dd91fb
>> > "drm/i915: Implement Link Rate fallback on Link training failure")
>> > which got reverted in this commit id (afc1ebf4562a14 Revert
>> > "drm/i915: Implement Link Rate fallback on Link training failure")
>> > due to CI failures.
>> > 
>> > After investigating the CI failures it was found that these
>> > were essentially the failures which were always there but hidden because
>> > they used to be DRM_DEBUG_KMS messages for link failures so never got
>> > caught by CI. But now this patch actually throws DRM_ERROR if the link
>> > training fails at RBR and 1 lane. So it caught these link train failures.
>> > 
>> > There were two failures:
>> > 1. On SKL 6700k this was because the machine in CI lab is a SKL desktop
>> > without eDP on Port A. But our VBT initialization code in the driver writes
>> > VBT defaults in a way that it always sets DP flag on Port A and this does
>> > not get cleared after parsing the VBT outputs. This has been fixed in
>> > commit id (bb1d132935c2f8 "drm/i915/vbt: split out defaults that are set
>> > when there is no VBT) and (665788572c6410b "drm/i915/vbt: don't propagate
>> > errors from intel_bios_init())
>> > 
>> > 2. On ILK-650 desktop - This was happening because of a bad monitor desktop
>> > combination. I switched the monitor in the CI lab and that helped get rid
>> > of the link failures on ILK system.
>> > 
>> > v10:
>> > * Rebase on drm-tip and resend after revert
>> > v9:
>> > * Use the trimmed max values of link rate/lane count based on
>> > link train fallback (Daniel Vetter)
>> > v8:
>> > * Set link_status to BAD first and then call mode_valid (Jani Nikula)
>> > v7:
>> > Remove the redundant variable in previous patch itself
>> > v6:
>> > * Obtain link rate index from fallback_link_rate using
>> > the helper intel_dp_link_rate_index (Jani Nikula)
>> > * Include fallback within intel_dp_start_link_train (Jani Nikula)
>> > v5:
>> > * Move set link status to drm core (Daniel Vetter, Jani Nikula)
>> > v4:
>> > * Add fallback support for non DDI platforms too
>> > * Set connector->link status inside set_link_status function
>> > (Jani Nikula)
>> > v3:
>> > * Set link status property to BAd unconditionally (Jani Nikula)
>> > * Dont use two separate variables link_train_failed and link_status
>> > to indicate same thing (Jani Nikula)
>> > v2:
>> > * Squashed a few patches (Jani Nikula)
>> > 
>> > Acked-by: Tony Cheng 
>> > Acked-by: Harry Wentland 
>> > Cc: Jani Nikula 
>> > Cc: Daniel Vetter 
>> > Cc: Ville Syrjala 
>> > Signed-off-by: Manasi Navare 
>> > Reviewed-by: Jani Nikula 
>> > Signed-off-by: Jani Nikula 
>> > ---
>> >  drivers/gpu/drm/i915/intel_dp.c   | 27 
>> > +++
>> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 22 --
>> >  drivers/gpu/drm/i915/intel_drv.h  |  3 +++
>> >  3 files changed, 50 insertions(+), 2 deletions(-)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> > 

Re: [Intel-gfx] [PATCH] drm/i915: disable KASAN for handlers

[Jani Nikula]

On Fri, 31 Mar 2017, Zhenyu Wang  wrote:
> On 2017.03.30 11:46:27 +0200, Jiri Slaby wrote:
>> Handlers are currently the only blocker to compile the kernel with gcc 7
>> and KASAN+use-after-scope enabled:
>> drivers/gpu/drm/i915/gvt/handlers.c:2200:1: error: the frame size of 43760 
>> bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
>> drivers/gpu/drm/i915/gvt/handlers.c:2402:1: error: the frame size of 9400 
>> bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
>> drivers/gpu/drm/i915/gvt/handlers.c:2628:1: error: the frame size of 11256 
>> bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
>> 
>> It is due to many expansions of MMIO_* macros in init_generic_mmio_info.
>> INTEL_GVT_MMIO_OFFSET generates for each such line a __reg and an
>> offset. There are too many for KASAN to keep up.
>> 
>> So disable KASAN for this file.
>> 
>> Signed-off-by: Jiri Slaby 
>> Cc: Martin Liska 
>> Cc: Zhenyu Wang 
>> Cc: Zhi Wang 
>> Cc: Daniel Vetter 
>> Cc: Jani Nikula 
>> Cc: David Airlie 
>> Cc: intel-gvt-...@lists.freedesktop.org
>> Cc: intel-gfx@lists.freedesktop.org
>> Cc: dri-de...@lists.freedesktop.org
>> ---
>>  drivers/gpu/drm/i915/gvt/Makefile | 2 ++
>>  1 file changed, 2 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
>> b/drivers/gpu/drm/i915/gvt/Makefile
>> index b123c20e2097..942f1849d194 100644
>> --- a/drivers/gpu/drm/i915/gvt/Makefile
>> +++ b/drivers/gpu/drm/i915/gvt/Makefile
>> @@ -6,3 +6,5 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o 
>> trace_points.o firmware.o \
>>  ccflags-y   += -I$(src) -I$(src)/$(GVT_DIR) -Wall
>>  i915-y  += $(addprefix $(GVT_DIR)/, 
>> $(GVT_SOURCE))
>>  obj-$(CONFIG_DRM_I915_GVT_KVMGT)+= $(GVT_DIR)/kvmgt.o
>> +
>> +KASAN_SANITIZE_handlers.o := n
>> -- 
>> 2.12.2
>> 
>
> Applied this, we'd better cleanup legacy usage to current i915 mmio
> reg define. Thanks!

Hmmh, that was a bit fast, there was a related discussion going in [1].

BR,
Jani.


[1] 20170320215713.3086140-1-arnd@arndb.de">http://mid.mail-archive.com/20170320215713.3086140-1-arnd@arndb.de




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

[Intel-gfx] [PATCH] drm/i915/uc: Drop use of MISSING_CASE on trivial enums

[Michal Wajdeczko]

We can rely on compiler to notify us if we miss any case.
This approach may also reduce driver size (reported ~4K).

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_uc.h | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index d2dcde7..4b7f73a 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -114,10 +114,8 @@ const char *intel_uc_fw_status_repr(enum 
intel_uc_fw_status status)
return "PENDING";
case INTEL_UC_FIRMWARE_SUCCESS:
return "SUCCESS";
-   default:
-   MISSING_CASE(status);
-   return "";
}
+   return "";
 }
 
 enum intel_uc_fw_type {
@@ -133,10 +131,8 @@ static inline const char *intel_uc_fw_type_repr(enum 
intel_uc_fw_type type)
return "GuC";
case INTEL_UC_FW_TYPE_HUC:
return "HuC";
-   default:
-   MISSING_CASE(type);
-   return "";
}
+   return "uC";
 }
 
 /*
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH] drm/i915: make a few DDI functions static

[Ville Syrjälä]

On Thu, Mar 30, 2017 at 05:57:52PM -0300, Paulo Zanoni wrote:
> We don't need to export them since they're not being used outside the
> file. The next time I try to find the callers for these things I will
> know I won't need to look outside intel_ddi.c.

You don't do cscope/ctags/whatever?

But anyway static is good since it hands the compiler a bit more rope.

Reviewed-by: Ville Syrjälä 

> 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 8 
>  drivers/gpu/drm/i915/intel_drv.h | 4 
>  2 files changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 83abab9..0914ad9 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -539,7 +539,7 @@ intel_ddi_get_buf_trans_fdi(struct drm_i915_private 
> *dev_priv,
>   * values in advance. This function programs the correct values for
>   * DP/eDP/FDI use cases.
>   */
> -void intel_prepare_dp_ddi_buffers(struct intel_encoder *encoder)
> +static void intel_prepare_dp_ddi_buffers(struct intel_encoder *encoder)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   u32 iboost_bit = 0;
> @@ -806,7 +806,7 @@ void hsw_fdi_link_train(struct intel_crtc *crtc,
>  DP_TP_CTL_ENABLE);
>  }
>  
> -void intel_ddi_init_dp_buf_reg(struct intel_encoder *encoder)
> +static void intel_ddi_init_dp_buf_reg(struct intel_encoder *encoder)
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
>   struct intel_digital_port *intel_dig_port =
> @@ -1616,8 +1616,8 @@ uint32_t ddi_signal_levels(struct intel_dp *intel_dp)
>   return DDI_BUF_TRANS_SELECT(level);
>  }
>  
> -void intel_ddi_clk_select(struct intel_encoder *encoder,
> -   struct intel_shared_dpll *pll)
> +static void intel_ddi_clk_select(struct intel_encoder *encoder,
> +  struct intel_shared_dpll *pll)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   enum port port = intel_ddi_get_encoder_port(encoder);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index e24641b..313fad0 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1229,12 +1229,9 @@ void intel_crt_init(struct drm_i915_private *dev_priv);
>  void intel_crt_reset(struct drm_encoder *encoder);
>  
>  /* intel_ddi.c */
> -void intel_ddi_clk_select(struct intel_encoder *encoder,
> -   struct intel_shared_dpll *pll);
>  void intel_ddi_fdi_post_disable(struct intel_encoder *intel_encoder,
>   struct intel_crtc_state *old_crtc_state,
>   struct drm_connector_state *old_conn_state);
> -void intel_prepare_dp_ddi_buffers(struct intel_encoder *encoder);
>  void hsw_fdi_link_train(struct intel_crtc *crtc,
>   const struct intel_crtc_state *crtc_state);
>  void intel_ddi_init(struct drm_i915_private *dev_priv, enum port port);
> @@ -1255,7 +1252,6 @@ bool intel_ddi_is_audio_enabled(struct drm_i915_private 
> *dev_priv,
>  void intel_ddi_get_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config);
>  
> -void intel_ddi_init_dp_buf_reg(struct intel_encoder *encoder);
>  void intel_ddi_clock_get(struct intel_encoder *encoder,
>struct intel_crtc_state *pipe_config);
>  void intel_ddi_set_vc_payload_alloc(const struct intel_crtc_state 
> *crtc_state,
> -- 
> 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

Re: [Intel-gfx] [PATCH 06/13] drm/i915: Store a direct lookup from object handle to vma

[Joonas Lahtinen]

On ke, 2017-03-29 at 16:56 +0100, Chris Wilson wrote:
> The advent of full-ppgtt lead to an extra indirection between the object
> and its binding. That extra indirection has a noticeable impact on how
> fast we can convert from the user handles to our internal vma for
> execbuffer. In order to bypass the extra indirection, we use a
> resizable hashtable to jump from the object to the per-ctx vma.
> rhashtable was considered but we don't need the online resizing feature
> and the extra complexity proved to undermine its usefulness. Instead, we
> simply reallocate the hastable on demand in a background task and
> serialize it before iterating.
> 
> In non-full-ppgtt modes, multiple files and multiple contexts can share
> the same vma. This leads to having multiple possible handle->vma links,
> so we only use the first to establish the fast path. The majority of
> buffers are not shared and so we should still be able to realise
> speedups with multiple clients.
> 
> v2: Prettier names, more magic.
> v3: Many style tweaks, notable hiding the misuse of execobj[].rsvd2
> 
> Signed-off-by: Chris Wilson 

Changelog checks out.

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 0/2] drm/i915/scheduler: add gvt force-single-submission and notification for guc

[Dong, Chuanxiao]

Hi, ping for review. Would like to know if this serial patches are OK to be 
taken or I need to drive more comments here :)

Thanks
Chuanxiao

> -Original Message-
> From: Dong, Chuanxiao
> Sent: Tuesday, March 28, 2017 5:39 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel-gvt-...@lists.freedesktop.org; Dong, Chuanxiao
> 
> Subject: [PATCH v2 0/2] drm/i915/scheduler: add gvt force-single-submission
> and notification for guc
> 
> GVT requires force-single-submission and notification when i915 using
> execlist submit, and these should be extended to GuC when
> i915 using GuC submit. Below two patches are used to implement this
> 
> Chuanxiao Dong (2):
>   drm/i915/scheduler: add gvt force-single-submission for guc
>   drm/i915/scheduler: add gvt notification for guc
> 
>  drivers/gpu/drm/i915/i915_guc_submission.c | 11 ++-
>  drivers/gpu/drm/i915/intel_gvt.h   | 23 +++
>  drivers/gpu/drm/i915/intel_lrc.c   | 46 
> +-
>  3 files changed, 40 insertions(+), 40 deletions(-)
> 
> --
> 2.7.4

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

Re: [Intel-gfx] [PATCH] drm/i915: Setting pch_id for Gen7.5+ in virtual environment

[Martin Peres]

On 30/03/17 08:39, Zhang, Xiong Y wrote:

On Wed, Mar 29, 2017 at 05:02:47PM +0800, Xiong Zhang wrote:

In a virtual passthrough environment, the ISA bridge isn't able to
be passed through. So pch_id couldn't be gotten from ISA bridge, but
pch_id is used to identify LPT_H and LPT_LP, this patch set pch_id
according to IGD type.

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

Signed-off-by: Xiong Zhang 
---
 drivers/gpu/drm/i915/i915_drv.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c

b/drivers/gpu/drm/i915/i915_drv.c

index 8b807a9..32a9bff 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -135,9 +135,17 @@ static enum intel_pch intel_virt_detect_pch(struct

drm_i915_private *dev_priv)

DRM_DEBUG_KMS("Assuming CouarPoint PCH\n");
} else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
ret = PCH_LPT;
+   if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
+   dev_priv->pch_id = INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
+   else
+   dev_priv->pch_id = INTEL_PCH_LPT_DEVICE_ID_TYPE;
DRM_DEBUG_KMS("Assuming LynxPoint PCH\n");
} else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
ret = PCH_SPT;
+   if (IS_SKL_ULT(dev_priv) || IS_KBL_ULT(dev_priv))
+   dev_priv->pch_id = INTEL_PCH_SPT_LP_DEVICE_ID_TYPE;
+   else
+   dev_priv->pch_id = INTEL_PCH_SPT_DEVICE_ID_TYPE;


I'm not 100% sure the ULT/ULX <=> LP thing always holds. I *think* it
should but I've never been able to convince myself totally.

[Zhang, Xiong Y] For BDW ULT/ULX, it should be LP. A picture from 
https://gfxspecs.intel.com/Predator/Home/Index/4216 could confirm this.
For HSW ULT/ULX, I couldn't find a material to confirm this.
Anyway I copy this condition from the WARN_ON() in intel_detect_pch()

For SKL/KBL ULT/ULX, I couldn't find a material to confirm this neither.


As far as KBL goes, maybe we want PCH_KBP for it? Although I don't actually
know why we even make the distinction between the two since they seem
identical for us, and we don't distinguish LPT vs. WPT either. Rodrigo?

[Zhang, Xiong Y] For PCH_KBP, I couldn't find out which KBL type will co-work 
with it.
As the real ISA Bridge doesn't exist in a emulated guest machine, we couldn't 
get the real and accurate pch_id in guest. In such passthrough virtual 
environment, the only real HW is IGD which is passed through to guest, we could 
only assume the pch_id from this IGD.
Fortunately pch_id is only used to identify LPT_LP and LPT_H currently.
Without this patch, pch_id is totally wrong. And on LPT_LP platform without 
this patch, the local HDMI/DP display couldn't lightup when guest boot up. But 
this patch could only remedy part of pch_id. Currently I have two plans to 
improve this patch:
1) only remain pch_id assuming for HSW and BDW, as this is really we need to 
fix the bug.
  Delete pch_id assuming for SKL and KBL, as currently i915 driver don't use it.
2) Claim this patch's limitation in commit message.
Any suggestion ?


Guys, any updates on this?

This blocks the testing of the following tests on fi-bdw-gvtdvm:
igt@drv_module_reload@basic-reload
igt@drv_module_reload@basic-reload-final
igt@drv_module_reload@basic-reload-inject
igt@gem_exec_suspend@basic-s3
igt@gem_exec_suspend@basic-s4-devices
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c

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

Re: [Intel-gfx] [PATCH 04/13] drm/i915: Use vma->exec_entry as our double-entry placeholder

[Joonas Lahtinen]

Did you intend to rename too, or where did the title come from?

On ke, 2017-03-29 at 16:56 +0100, Chris Wilson wrote:
> This has the benefit of not requiring us to manipulate the
> vma->exec_link list when tearing down the execbuffer, and is a
> marginally cheaper test to detect the user error.
> 
> Signed-off-by: Chris Wilson 



> @@ -85,7 +85,6 @@ vma_create(struct drm_i915_gem_object *obj,
>   if (vma == NULL)
>   return ERR_PTR(-ENOMEM);
>  
> - INIT_LIST_HEAD(>exec_list);

Dunno if it would be worth poisoning the pointer, maybe not.

With correct title;

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Wait for all engines to be idle as part of i915_gem_wait_for_idle()

[Chris Wilson]

On Fri, Mar 31, 2017 at 11:31:50AM +0300, Joonas Lahtinen wrote:
> On to, 2017-03-30 at 15:50 +0100, Chris Wilson wrote:
> > Make i915_gem_wait_for_idle() be a little heavier in order to try and
> > guarantee that the GPU is indeed idle (by checking each engine
> > individually is idle, i.e. all writes are complete and the rings
> > stopped) after waiting for in-flight requests to be completed.
> > 
> > v2: And return the final error.
> > v3: Break the wait_for() out from under the WARN -- the macro expansion
> > is hideous and unreadable in the warning message
> > v4: If wait_for_engine() fails the result is catastrophic, mark the
> > device as wedged and wait for the repair team.
> > 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=98836
> > Signed-off-by: Chris Wilson 
> 
> That's more accurate yep, but is our other bookkeeping broken then?

Not as far as I can tell. It's just that the engines can be alive a
little bit longer than the breadcrumb write, and in some circumstances
that is an important distinction.

Just just wtf is going on with Baytrail elludes me. It's like the GPU is
doing a timewarp.
-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 6/6] drm/i915: Combine reset_all_global_seqno() loops into one

[Joonas Lahtinen]

On to, 2017-03-30 at 15:50 +0100, Chris Wilson wrote:
> We can merge the pair of loops over the engines and their timelines into
> a single loop, making it easier to read and more consistent with the
> commentary.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Remove redudant wait for each engine to idle from seqno wrap

[Joonas Lahtinen]

On to, 2017-03-30 at 15:50 +0100, Chris Wilson wrote:
> Having added the wait upon each engine to idle into the central
> i915_gem_wait_for_idle(), we can remove the now redundant wait from
> reset_all_global_seqno(). This has the advantage of removing the late
> detection of an error (an engine still busy) which left the seqno reset
> only partially complete (though it should be safe enough!).
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Wait for all engines to be idle as part of i915_gem_wait_for_idle()

[Joonas Lahtinen]

On to, 2017-03-30 at 15:50 +0100, Chris Wilson wrote:
> Make i915_gem_wait_for_idle() be a little heavier in order to try and
> guarantee that the GPU is indeed idle (by checking each engine
> individually is idle, i.e. all writes are complete and the rings
> stopped) after waiting for in-flight requests to be completed.
> 
> v2: And return the final error.
> v3: Break the wait_for() out from under the WARN -- the macro expansion
> is hideous and unreadable in the warning message
> v4: If wait_for_engine() fails the result is catastrophic, mark the
> device as wedged and wait for the repair team.
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=98836
> Signed-off-by: Chris Wilson 

That's more accurate yep, but is our other bookkeeping broken then?

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Move retire-requests into i915_gem_wait_for_idle()

[Joonas Lahtinen]

On to, 2017-03-30 at 15:50 +0100, Chris Wilson wrote:
> As we now distinguish everywhere that can call
> i915_gem_retire_requests() following a successful wait_for_idle, we can
> remove the duplication by moving that call into i915_gem_wait_for_idle()
> itself.
> 
> Signed-off-by: Chris Wilson 



> @@ -4180,8 +4180,6 @@ fault_irq_set(struct drm_i915_private *i915,
>   goto err_unlock;
>  
>   /* Retire to kick idle work */

Stale comment, best before date was yesterday.

i915_gem_idle_gpu or something might be more descriptive now.

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Drop verbose and archaic "ring" from our internal engine names

[Mika Kuoppala]

Chris Wilson  writes:

> We pretty print the name of an engine in several places, mostly for
> debug, but also in the GPU hang report. Using "ring" in the name is
> archaic (we call those engines now to differentiate them from the
> multiple rings of commands we execute on each engine), quite verbose and
> often tautological. We run out of room in our GPU hang report for
> instance if we have more than a couple of engines hung simultaneously.
> Bit the bullet and update the strings to reflect the common internal names.
>
> Signed-off-by: Chris Wilson 
Acked-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index ff6d0e1d1306..7100ac688be5 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -36,7 +36,7 @@ static const struct engine_info {
>   int (*init_execlists)(struct intel_engine_cs *engine);
>  } intel_engines[] = {
>   [RCS] = {
> - .name = "render ring",
> + .name = "rcs",
>   .uabi_id = I915_EXEC_RENDER,
>   .hw_id = RCS_HW,
>   .mmio_base = RENDER_RING_BASE,
> @@ -45,7 +45,7 @@ static const struct engine_info {
>   .init_legacy = intel_init_render_ring_buffer,
>   },
>   [BCS] = {
> - .name = "blitter ring",
> + .name = "bcs",
>   .uabi_id = I915_EXEC_BLT,
>   .hw_id = BCS_HW,
>   .mmio_base = BLT_RING_BASE,
> @@ -54,7 +54,7 @@ static const struct engine_info {
>   .init_legacy = intel_init_blt_ring_buffer,
>   },
>   [VCS] = {
> - .name = "bsd ring",
> + .name = "vcs",
>   .uabi_id = I915_EXEC_BSD,
>   .hw_id = VCS_HW,
>   .mmio_base = GEN6_BSD_RING_BASE,
> @@ -63,7 +63,7 @@ static const struct engine_info {
>   .init_legacy = intel_init_bsd_ring_buffer,
>   },
>   [VCS2] = {
> - .name = "bsd2 ring",
> + .name = "vcs2",
>   .uabi_id = I915_EXEC_BSD2,
>   .hw_id = VCS2_HW,
>   .mmio_base = GEN8_BSD2_RING_BASE,
> @@ -72,7 +72,7 @@ static const struct engine_info {
>   .init_legacy = intel_init_bsd2_ring_buffer,
>   },
>   [VECS] = {
> - .name = "video enhancement ring",
> + .name = "vecs",
>   .uabi_id = I915_EXEC_VEBOX,
>   .hw_id = VECS_HW,
>   .mmio_base = VEBOX_RING_BASE,
> -- 
> 2.11.0
>
> ___
> 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] ✓ Fi.CI.BAT: success for drm/i915/uc: Misc cleanups

[Joonas Lahtinen]

Merging this series, thanks for the patches and reviews.

On to, 2017-03-30 at 13:31 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/uc: Misc cleanups
> URL   : https://patchwork.freedesktop.org/series/22194/
> State : success
> 
> == Summary ==
> 
> Series 22194v1 drm/i915/uc: Misc cleanups
> https://patchwork.freedesktop.org/api/1.0/series/22194/revisions/1/mbox/
> 
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-uc:
> fail   -> PASS   (fi-snb-2600) fdo#17
> Test gem_exec_suspend:
> Subgroup basic-s4-devices:
> pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
> Test kms_cursor_legacy:
> Subgroup basic-flip-before-cursor-varying-size:
> pass   -> DMESG-WARN (fi-byt-n2820) fdo#100415
> 
> fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
> fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
> fdo#100415 https://bugs.freedesktop.org/show_bug.cgi?id=100415
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
> time: 429s
> fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
> time: 430s
> fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
> time: 570s
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
> time: 513s
> fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
> time: 560s
> fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
> time: 487s
> fi-byt-n2820 total:278  pass:246  dwarn:1   dfail:0   fail:0   skip:31  
> time: 487s
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time: 405s
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time: 402s
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
> time: 418s
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time: 488s
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time: 462s
> fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time: 450s
> fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
> time: 563s
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time: 449s
> fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
> time: 569s
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
> time: 459s
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time: 492s
> fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
> time: 431s
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time: 528s
> fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
> time: 414s
> 
> 71dab8f683b2d609926524f9a6a60b00e4bfa543 drm-tip: 2017y-03m-30d-11h-44m-46s 
> UTC integration manifest
> 477339e drm/i915/uc: Move fw path check to fetch_uc_fw()
> fc83f6f drm/i915/huc: Remove unused intel_huc_fini()
> 105b67d drm/i915/uc: Add intel_uc_fw_fini()
> 6da3ed4 drm/i915/uc: Add intel_uc_fw_type_repr()
> fce14b3 drm/i915/uc: Move intel_uc_fw_status_repr() to intel_uc.h
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4360/
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: disable KASAN for handlers

[Zhenyu Wang]

On 2017.03.30 11:46:27 +0200, Jiri Slaby wrote:
> Handlers are currently the only blocker to compile the kernel with gcc 7
> and KASAN+use-after-scope enabled:
> drivers/gpu/drm/i915/gvt/handlers.c:2200:1: error: the frame size of 43760 
> bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
> drivers/gpu/drm/i915/gvt/handlers.c:2402:1: error: the frame size of 9400 
> bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
> drivers/gpu/drm/i915/gvt/handlers.c:2628:1: error: the frame size of 11256 
> bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
> 
> It is due to many expansions of MMIO_* macros in init_generic_mmio_info.
> INTEL_GVT_MMIO_OFFSET generates for each such line a __reg and an
> offset. There are too many for KASAN to keep up.
> 
> So disable KASAN for this file.
> 
> Signed-off-by: Jiri Slaby 
> Cc: Martin Liska 
> Cc: Zhenyu Wang 
> Cc: Zhi Wang 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: David Airlie 
> Cc: intel-gvt-...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> ---
>  drivers/gpu/drm/i915/gvt/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
> b/drivers/gpu/drm/i915/gvt/Makefile
> index b123c20e2097..942f1849d194 100644
> --- a/drivers/gpu/drm/i915/gvt/Makefile
> +++ b/drivers/gpu/drm/i915/gvt/Makefile
> @@ -6,3 +6,5 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o 
> trace_points.o firmware.o \
>  ccflags-y+= -I$(src) -I$(src)/$(GVT_DIR) -Wall
>  i915-y   += $(addprefix $(GVT_DIR)/, 
> $(GVT_SOURCE))
>  obj-$(CONFIG_DRM_I915_GVT_KVMGT) += $(GVT_DIR)/kvmgt.o
> +
> +KASAN_SANITIZE_handlers.o := n
> -- 
> 2.12.2
> 

Applied this, we'd better cleanup legacy usage to current i915 mmio reg define. 
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 i-g-t 4/4] gem_create: Convert stolen test to uABI checking

[Tvrtko Ursulin]

On 30/03/2017 18:25, Chris Wilson wrote:

On Thu, Mar 30, 2017 at 05:58:09PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Stolen never materialized so convert this test into checking
that the garbage in padding remains legal.

Signed-off-by: Tvrtko Ursulin 
---
 tests/gem_create.c | 39 ---
 1 file changed, 12 insertions(+), 27 deletions(-)

diff --git a/tests/gem_create.c b/tests/gem_create.c
index 21df13f7b655..0dad06c784c5 100644
--- a/tests/gem_create.c
+++ b/tests/gem_create.c
@@ -27,8 +27,7 @@

 /** @file gem_create.c
  *
- * This is a test for the extended and old gem_create ioctl, that
- * includes allocation of object from stolen memory and shmem.
+ * This is a test for the gem_create ioctl.
  *
  * The goal is to simply ensure that basics work and invalid input
  * combinations are rejected.
@@ -62,36 +61,22 @@ IGT_TEST_DESCRIPTION("This is a test for the extended & old 
gem_create ioctl,"
 " that includes allocation of object from stolen memory"
 " and shmem.");

-#define CLEAR(s) memset(, 0, sizeof(s))
 #define PAGE_SIZE 4096

-struct local_i915_gem_create_v2 {
-   uint64_t size;
-   uint32_t handle;
-   uint32_t pad;
-#define I915_CREATE_PLACEMENT_STOLEN (1<<0)
-   uint32_t flags;
-} create;
-
-#define LOCAL_IOCTL_I915_GEM_CREATE   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_CREATE, struct local_i915_gem_create_v2)
-
-static void invalid_flag_test(int fd)
+/*
+ * Verify that historical omission of checking for garbage in the padding
+ * field still holds.
+ */
+static void test_pad_garbage(int fd)
 {
+   struct drm_i915_gem_create create = { };
int ret;

-   gem_require_stolen_support(fd);
-
create.handle = 0;
create.size = PAGE_SIZE;
-   create.flags = ~I915_CREATE_PLACEMENT_STOLEN;
-   ret = drmIoctl(fd, LOCAL_IOCTL_I915_GEM_CREATE, );
-
-   igt_assert(ret <= 0);
-
-   create.flags = ~0;
-   ret = drmIoctl(fd, LOCAL_IOCTL_I915_GEM_CREATE, );
-
-   igt_assert(ret <= 0);
+   create.pad = 1;
+   ret = drmIoctl(fd, DRM_IOCTL_I915_GEM_CREATE, );
+   igt_assert_eq(ret, 0);
 }

 static void invalid_size_test(int fd)
@@ -134,8 +119,8 @@ igt_main
fd = drm_open_driver(DRIVER_INTEL);
}

-   igt_subtest("stolen-invalid-flag")
-   invalid_flag_test(fd);
+   igt_subtest("basic-pad-garbage")
+   test_pad_garbage(fd);


Not basic though. I just dislike having negative tests that we intend to
break be part of basic. (I dislike negative tests in general as they are
restrictive and limit creativity, a false limitation in terms of ABI.)


My understanding is that we can never break this now. I mean that we 
have to allow userspace putting garbage in the padding field forever now.


I don't fully understand right now then how createv2 implementation was 
suggesting to re-purpose half of the padding for flags at the moment as 
well.


Regards,

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

Re: [Intel-gfx] [PATCH i-g-t 2/4] gem_create: Test huge object creation as a basic test

[Tvrtko Ursulin]

On 30/03/2017 18:22, Chris Wilson wrote:

On Thu, Mar 30, 2017 at 05:58:07PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

It is hard to imagine a more basic test than this one.

Also removed the skip on simulation since I don't know why
would that be needed here.

Signed-off-by: Tvrtko Ursulin 
---
 tests/gem_create.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/tests/gem_create.c b/tests/gem_create.c
index de7b82094545..f687b7b40be4 100644
--- a/tests/gem_create.c
+++ b/tests/gem_create.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 

@@ -95,10 +96,13 @@ static void invalid_flag_test(int fd)

 static void invalid_size_test(int fd)
 {
-   int handle;
+   uint32_t handle;

handle = __gem_create(fd, 0);
igt_assert(!handle);
+
+   handle = __gem_create(fd, INT_MAX * 4096UL + 1);


Why is that an invalid size? Invalid huge in terms of API might arguably
be 1<0 and page aligned.


Because of the comment above the WARN I am removing in "drm/i915: Remove 
user triggerable WARN from i915_gem_object_create". We cannot support 
larger ones with the combination of sg_table data types and how we use 
them (unsigned int nents).



/* Only multiples of page size (4096) are allowed. Check all likely
 * misalignments from pot boundaries to check validity and possibility
 * of incorrect overflow.
 */
 for (int order = 0; order < 64; order++) {
uint64_t size = (uint64_t)1 << order;
igt_assert(!__gem_create(fd, size - 1));
igt_assert(!__gem_create(fd, size + 1));
if (order < 12)
igt_assert(!__gem_create(fd, size + 1));
}

Still enshrines knowlege of PAGE_SIZE into the ABI. Meh.


We round up for the user transparently which I am actually making the 
other subtest in this file test in a later patch.


Regards,

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

Re: [Intel-gfx] [PATCH 0/7] DisplayPort audio support on Cherrytrail

[Takashi Iwai]

On Fri, 31 Mar 2017 08:29:55 +0200,
Daniel Vetter wrote:
> 
> On Mon, Mar 13, 2017 at 9:33 AM, Daniel Vetter  wrote:
> > On Tue, Jan 31, 2017 at 10:36:42PM +0100, Takashi Iwai wrote:
> >> Hi,
> >>
> >> the following patches enable DisplayPort Audio on Cherrytrail machines
> >> when applied on top of my topic/intel-lpe-audio branch.  Tests of DP
> >> audio were run on Dell Wyse 3040.  The regression test were performed
> >> on Baytrail (Compute Stick) and Cherrytrail (Zotac PI330) in HDMI
> >> mode.  On Cherrytrail there were no issues changing between HDMI and
> >> DP connectors dynamically.
> >>
> >> Could you i915 people review and give ACK if they are OK?
> >> The changes in drm/i915 side are fairly trivial, so I'd like to take
> >> them through sound git tree once after I receive your ACKs.
> >>
> >>
> >> Changes since RFC:
> >>  - reordered and squashed patches
> >>  - clean-up of register definitions and offsets (based on feedback from
> >>Jani/Ville)
> >>  - unmute amp for both HDMI and DP unconditionally
> >>  - mute amp on invalid ELD (unplug)
> >>  - remove test for chicken bit which seems to have no effect in hardware
> >>  - cosmetic edits to make checkpatch happy
> >>  - change i915 notification argument to pass the plataform device
> >>instead
> >>
> >>
> >> Most of hard work in this patchset has been done by Pierre, so all
> >> credits go to him.
> >
> > Please build the htmldocs and fix the new fallout these patches create:
> >
> > $ make   DOCBOOKS="" htmldocs
> >
> > 0day should be reporting these (if it scans your mailing list), but
> > there's been a hiccup recently.
> >
> > Good docs matter and all that ...
> 
> Apparently this is still not fixed, I applied a fixup patch now from
> someone else. Tsk.

Ah, sorry, this felt into crack during my vacation.
Good that it was already fixed.  Thanks.


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

Re: [Intel-gfx] [PATCH] drm/i915: fix build error without CONFIG_BACKLIGHT_CLASS_DEVICE

[Tobias Regnery]

On 30.03.17, Jani Nikula wrote:
> On Wed, 29 Mar 2017, Tobias Regnery  wrote:
> > With CONFIG_ACPI=n and CONFIG_BACKLIGHT_CLASS_DEVICE=n we see the following
> > link error in the i915 driver:
> >
> > drivers/built-in.o: In function 'intel_backlight_device_register':
> > (.text+0x2a921d): undefined reference to 'backlight_device_register'
> >
> > Fix this by removing the condition on ACPI from the appropriate select
> > statement.
> 
> The right fix for the build problem is to add empty stub functions for
> BACKLIGHT_CLASS_DEVICE=n in include/linux/backlight.h. I'm frankly
> surprised nobody's done that yet.

Thanks for the advice, I will try to come up with a patch.

--
Tobias

> 
> It's another question whether we should support and select backlight for
> ACPI=n, and yet another question whether we should support ACPI=n.
> 
> Also, selecting BACKLIGHT_CLASS_DEVICE is fundamentally broken, but
> people aren't interested [1].
> 
> 
> BR,
> Jani.
> 
> [1] 
> http://mid.mail-archive.com/1413580403-16225-1-git-send-email-jani.nikula@intel.com
> 
> >
> > Signed-off-by: Tobias Regnery 
> > ---
> >  drivers/gpu/drm/i915/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> > index a5cd5dacf055..532df4bb9283 100644
> > --- a/drivers/gpu/drm/i915/Kconfig
> > +++ b/drivers/gpu/drm/i915/Kconfig
> > @@ -15,7 +15,7 @@ config DRM_I915
> > # i915 depends on ACPI_VIDEO when ACPI is enabled
> > # but for select to work, need to select ACPI_VIDEO's dependencies, ick
> > select BACKLIGHT_LCD_SUPPORT if ACPI
> > -   select BACKLIGHT_CLASS_DEVICE if ACPI
> > +   select BACKLIGHT_CLASS_DEVICE
> > select INPUT if ACPI
> > select ACPI_VIDEO if ACPI
> > select ACPI_BUTTON if ACPI
> 
> -- 
> 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] drivers: gpu: drm: i915L intel_lpe_audio: Fix kerneldoc comments

[Daniel Vetter]

On Thu, Mar 30, 2017 at 02:55:10PM +0300, Tamara Diaconita wrote:
> Add description for existing parameter 'pipe' to fix the build
> warning: ./drivers/gpu/drm/i915/intel_lpe_audio.c:342: warning: No
> description found for parameter 'pipe'.
> 
> Signed-off-by: Tamara Diaconita 

Applied, thanks.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_lpe_audio.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c 
> b/drivers/gpu/drm/i915/intel_lpe_audio.c
> index 7a5b41b..d8ca187 100644
> --- a/drivers/gpu/drm/i915/intel_lpe_audio.c
> +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
> @@ -331,6 +331,7 @@ void intel_lpe_audio_teardown(struct drm_i915_private 
> *dev_priv)
>   * audio driver and i915
>   * @dev_priv: the i915 drm device private data
>   * @eld : ELD data
> + * @pipe: pipe id
>   * @port: port id
>   * @tmds_clk_speed: tmds clock frequency in Hz
>   *
> -- 
> 2.9.3
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/7] DisplayPort audio support on Cherrytrail

[Daniel Vetter]

On Mon, Mar 13, 2017 at 9:33 AM, Daniel Vetter  wrote:
> On Tue, Jan 31, 2017 at 10:36:42PM +0100, Takashi Iwai wrote:
>> Hi,
>>
>> the following patches enable DisplayPort Audio on Cherrytrail machines
>> when applied on top of my topic/intel-lpe-audio branch.  Tests of DP
>> audio were run on Dell Wyse 3040.  The regression test were performed
>> on Baytrail (Compute Stick) and Cherrytrail (Zotac PI330) in HDMI
>> mode.  On Cherrytrail there were no issues changing between HDMI and
>> DP connectors dynamically.
>>
>> Could you i915 people review and give ACK if they are OK?
>> The changes in drm/i915 side are fairly trivial, so I'd like to take
>> them through sound git tree once after I receive your ACKs.
>>
>>
>> Changes since RFC:
>>  - reordered and squashed patches
>>  - clean-up of register definitions and offsets (based on feedback from
>>Jani/Ville)
>>  - unmute amp for both HDMI and DP unconditionally
>>  - mute amp on invalid ELD (unplug)
>>  - remove test for chicken bit which seems to have no effect in hardware
>>  - cosmetic edits to make checkpatch happy
>>  - change i915 notification argument to pass the plataform device
>>instead
>>
>>
>> Most of hard work in this patchset has been done by Pierre, so all
>> credits go to him.
>
> Please build the htmldocs and fix the new fallout these patches create:
>
> $ make   DOCBOOKS="" htmldocs
>
> 0day should be reporting these (if it scans your mailing list), but
> there's been a hiccup recently.
>
> Good docs matter and all that ...

Apparently this is still not fixed, I applied a fixup patch now from
someone else. Tsk.
-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] [PULL] drm-misc-fixes

[Daniel Vetter]

Hi Dave,

drm-misc-fixes-2017-03-31:
Just one vc4 fix from Eric, cc: stable

Cheers, Daniel


The following changes since commit c02ed2e75ef4c74e41e421acb4ef1494671585e8:

  Linux 4.11-rc4 (2017-03-26 14:15:16 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-03-31

for you to fetch changes up to 6d6e500391875cc372336c88e9a8af377be19c36:

  drm/vc4: Allocate the right amount of space for boot-time CRTC state. 
(2017-03-30 08:41:38 -0700)


Just one vc4 fix from Eric, cc: stable


Eric Anholt (1):
  drm/vc4: Allocate the right amount of space for boot-time CRTC state.

 drivers/gpu/drm/vc4/vc4_crtc.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx