[Intel-gfx] ✗ Fi.CI.BAT: failure for Handle link training failure during modeset for DDI (rev3)

2016-11-02 Thread Patchwork 
== Series Details ==

Series: Handle link training failure during modeset for DDI (rev3)
URL   : https://patchwork.freedesktop.org/series/14556/
State : failure

== Summary ==

Series 14556v3 Handle link training failure during modeset for DDI
https://patchwork.freedesktop.org/api/1.0/series/14556/revisions/3/mbox/

Test drv_module_reload_basic:
pass   -> INCOMPLETE (fi-skl-6770hq)
dmesg-warn -> INCOMPLETE (fi-skl-6700k)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:187  dwarn:0   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:6pass:5dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-6770hqtotal:6pass:5dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

bf6b989af8b0fde56a352d9005c97b2d8e3bbbe3 drm-intel-nightly: 
2016y-11m-02d-15h-44m-03s UTC integration manifest
06564f1 drm/i915: Implement Link Rate fallback on Link training failure
3e2e35f drm/i915: Find fallback link rate/lane count
a4fc113 drm/i915: Set link status property for DP connector
0abe534 drm: Add a new connector property for link status

== Logs ==

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

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

2016-11-02 Thread Manasi Navare 
If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed, 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.

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)

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

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 75ad01d..94b0b3a 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
   connector_state);
if (ret)
return ret;
+
+   if (connector->state->crtc) {
+   crtc_state = drm_atomic_get_existing_crtc_state(state,
+   
connector->state->crtc);
+   if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
+   crtc_state->connectors_changed = true;
+   }
}
 
/*
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 938ac4d..a59f8d2 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1684,6 +1684,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum port port = intel_ddi_get_encoder_port(encoder);
+   struct intel_connector *intel_connector = intel_dp->attached_connector;
+   struct drm_connector *connector = _connector->base;
 
intel_dp_set_link_params(intel_dp, link_rate, lane_count,
 link_mst);
@@ -1694,7 +1696,25 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
intel_prepare_dp_ddi_buffers(encoder);
intel_ddi_init_dp_buf_reg(encoder);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
-   intel_dp_start_link_train(intel_dp);
+   if (!intel_dp_start_link_train(intel_dp)) {
+   DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane 
count = %d",
+ link_rate, lane_count);
+   connector->link_status = DRM_MODE_LINK_STATUS_BAD;
+   intel_dp_get_link_train_fallback_values(intel_dp, link_rate,
+   lane_count);
+   /* Schedule a Hotplug Uevent to userspace to start modeset */
+   schedule_work(_connector->modeset_retry_work);
+   } else {
+   DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane 
count = %d",
+ link_rate, lane_count);
+   intel_dp->fallback_link_rate_index = -1;
+   intel_dp->fallback_link_rate = 0;
+   intel_dp->fallback_lane_count = 0;
+   connector->link_status = DRM_MODE_LINK_STATUS_GOOD;
+   intel_dp_set_link_status_property(connector,
+ DRM_MODE_LINK_STATUS_GOOD);
+   }
+
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
 }
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fb4fcdd..659b17f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -310,9 +310,6 @@ void intel_dp_get_link_train_fallback_values(struct 
intel_dp *intel_dp,
int common_len;
int link_rate_index = -1;
 
-   if (!intel_dp->link_train_failed)
-   return;
-
common_len = intel_dp_common_rates(intel_dp, common_rates);
link_rate_index = intel_dp_link_rate_index(intel_dp,
   common_rates,
@@

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v4,1/2] drm/i915/dp: BDW cdclk fix for DP audio (rev2)

2016-11-02 Thread Patchwork 
== Series Details ==

Series: series starting with [v4,1/2] drm/i915/dp: BDW cdclk fix for DP audio 
(rev2)
URL   : https://patchwork.freedesktop.org/series/14688/
State : warning

== Summary ==

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

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-skl-6770hq)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:187  dwarn:0   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:226  dwarn:1   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

bf6b989af8b0fde56a352d9005c97b2d8e3bbbe3 drm-intel-nightly: 
2016y-11m-02d-15h-44m-03s UTC integration manifest
6346fda drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms
884d02ce drm/i915/dp: BDW cdclk fix for DP audio

== Logs ==

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

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms

2016-11-02 Thread Pandiyan, Dhinakaran 
On Tue, 2016-11-01 at 21:50 +0200, Jani Nikula wrote:
> On Tue, 01 Nov 2016, "Pandiyan, Dhinakaran"  
> wrote:
> > On Tue, 2016-11-01 at 21:35 +0200, Jani Nikula wrote:
> >> On Tue, 01 Nov 2016, Dhinakaran Pandiyan  
> >> wrote:
> >> > According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP
> >> > audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk 
> >> > less
> >> > than 432 MHz, enabling audio leads to pipe FIFO underruns and displays
> >> > cycling on/off.
> >> >
> >> > Let's apply this work around to GEN9 platforms too, as it fixes the same
> >> > issue.
> >> 
> >> I'm too tired to read bspec now, but is gen9 really the answer, or just
> >> Skylake?
> >> 
> >> 
> >
> > Gen9, applies to BXT and KBL as well.
> 
> I'll take your word for it, and with that,
> 
> Reviewed-by: Jani Nikula 
> 
> 
> 

Thanks for the review. 
> >
> > -DK
> >
> >> >
> >> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97907
> >> > Cc: sta...@vger.kernel.org
> >> > Cc: Libin Yang 
> >> > Signed-off-by: Dhinakaran Pandiyan 
> >> > ---
> >> >  drivers/gpu/drm/i915/intel_display.c | 6 --
> >> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >> > b/drivers/gpu/drm/i915/intel_display.c
> >> > index 37483ee..c0ae147 100644
> >> > --- a/drivers/gpu/drm/i915/intel_display.c
> >> > +++ b/drivers/gpu/drm/i915/intel_display.c
> >> > @@ -10264,8 +10264,10 @@ static void bxt_modeset_commit_cdclk(struct 
> >> > drm_atomic_state *old_state)
> >> >  static int bdw_adjust_min_pipe_pixel_rate(struct intel_crtc_state 
> >> > *crtc_state,
> >> >int pixel_rate)
> >> >  {
> >> > +struct drm_device *dev = crtc_state->base.crtc->dev;
> >> 
> >> Nitpick, I guess I'd make that
> >> 
> >>struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> >> 
> >> but no big deal.
> >> 
> >> > +
> >> >  /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
> >> > -if (crtc_state->ips_enabled)
> >> > +if (IS_BROADWELL(to_i915(dev)) && crtc_state->ips_enabled)
> >> >  pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
> >> >  
> >> >  /* BSpec says "Do not use DisplayPort with CDCLK less than
> >> > @@ -10307,7 +10309,7 @@ static int ilk_max_pixel_rate(struct 
> >> > drm_atomic_state *state)
> >> >  
> >> >  pixel_rate = ilk_pipe_pixel_rate(crtc_state);
> >> >  
> >> > -if (IS_BROADWELL(dev_priv))
> >> > +if (IS_BROADWELL(dev_priv) || IS_GEN9(dev_priv))
> >> >  pixel_rate = 
> >> > bdw_adjust_min_pipe_pixel_rate(crtc_state,
> >> >  
> >> > pixel_rate);
> >> 
> >
> 

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

[Intel-gfx] [PATCH v5 2/2] drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms

2016-11-02 Thread Dhinakaran Pandiyan 
According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP
audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less
than 432 MHz, enabling audio leads to pipe FIFO underruns and displays
cycling on/off.

Let's apply this work around to GEN9 platforms too, as it fixes the same
issue.

v2: Move drm_device to drm_i915_private conversion

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97907
Cc: sta...@vger.kernel.org
Cc: Libin Yang 
Signed-off-by: Dhinakaran Pandiyan 
Reviewed-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_display.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 37483ee..0d95a2e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10264,8 +10264,10 @@ static void bxt_modeset_commit_cdclk(struct 
drm_atomic_state *old_state)
 static int bdw_adjust_min_pipe_pixel_rate(struct intel_crtc_state *crtc_state,
  int pixel_rate)
 {
+   struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
+
/* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
-   if (crtc_state->ips_enabled)
+   if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
 
/* BSpec says "Do not use DisplayPort with CDCLK less than
@@ -10307,7 +10309,7 @@ static int ilk_max_pixel_rate(struct drm_atomic_state 
*state)
 
pixel_rate = ilk_pipe_pixel_rate(crtc_state);
 
-   if (IS_BROADWELL(dev_priv))
+   if (IS_BROADWELL(dev_priv) || IS_GEN9(dev_priv))
pixel_rate = bdw_adjust_min_pipe_pixel_rate(crtc_state,
pixel_rate);
 
-- 
2.7.4

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/12] drm/i915: Split request submit/execute phase into two

2016-11-02 Thread Patchwork 
== Series Details ==

Series: series starting with [01/12] drm/i915: Split request submit/execute 
phase into two
URL   : https://patchwork.freedesktop.org/series/14751/
State : success

== Summary ==

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


fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:187  dwarn:0   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

bf6b989af8b0fde56a352d9005c97b2d8e3bbbe3 drm-intel-nightly: 
2016y-11m-02d-15h-44m-03s UTC integration manifest
164f390 drm/i915: Support explicit fencing for execbuf
9811cdb drm/i915: Enable userspace to opt-out of implicit fencing
4d35615 drm/i915/scheduler: Support user-defined priorities
675e7ea HACK drm/i915/scheduler: emulate a scheduler for guc
224c9f8 drm/i915/guc: Cache the client mapping
b1c5a70 drm/i915/scheduler: Boost priorities for flips
2ad0f8b drm/i915/scheduler: Execute requests in order of priorities
f2881be drm/i915/scheduler: Record all dependencies upon request construction
c822ff5 drm/i915/scheduler: Signal the arrival of a new request
b707ee3 drm/i915: Remove engine->execlist_lock
9943660 drm/i915: Defer transfer onto execution timeline to actual hw submission
332bc0d drm/i915: Split request submit/execute phase into two

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2894/
___
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/sw_fence: Allocate callbacks from dedicates slab caches

2016-11-02 Thread Patchwork 
== Series Details ==

Series: drm/i915/sw_fence: Allocate callbacks from dedicates slab caches
URL   : https://patchwork.freedesktop.org/series/14750/
State : success

== Summary ==

Series 14750v1 drm/i915/sw_fence: Allocate callbacks from dedicates slab caches
https://patchwork.freedesktop.org/api/1.0/series/14750/revisions/1/mbox/


fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:187  dwarn:0   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

bf6b989af8b0fde56a352d9005c97b2d8e3bbbe3 drm-intel-nightly: 
2016y-11m-02d-15h-44m-03s UTC integration manifest
7adc7ac drm/i915/sw_fence: Allocate callbacks from dedicates slab caches

== Logs ==

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

Re: [Intel-gfx] [RFC] drm/i915/sw_fence: Allocate callbacks from dedicates slab caches

2016-11-02 Thread Chris Wilson 
On Wed, Nov 02, 2016 at 05:44:07PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Not sure if it matters for performance at all but it should
> save some wastage and enable a better insight into the usage.

With the caveat of avoiding the plug into the i915.ko...

This should wait until after kernel/fence.c, as the split will make this
a little more interesting.

> +int i915_init_sw_fences(void)
> +{
> + struct kmem_cache *wq_cache, *cb_cache;
> +
> + mutex_lock(_sw_fence_mutex);

If switched over to init ctor, the mutex is then redundant.

> + if (i915_sw_fence_usecnt == 0) {
> + wq_cache = kmem_cache_create("i915_sw_fence_wq",
> +  sizeof(wait_queue_t),
> +  __alignof__(wait_queue_head_t),
> +  0, NULL);
> + if (!wq_cache)
> + goto err;
> +
> + cb_cache = kmem_cache_create("i915_sw_fence_cb",
> +  sizeof(struct 
> i915_sw_dma_fence_cb),
> +  __alignof__(struct 
> i915_sw_dma_fence_cb),
> +  0, NULL);

For example, this cache will need to end up in
drivers/dma-buf/dma-fence.c
-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] Trivial priority scheduler

2016-11-02 Thread Chris Wilson 
Now that the tree has caught up, we can now look at the next steps
towards a basic scheduler. No timeslicing, no preemption, no fairness,
we simply choose the highest priority request to execute next. (An
incoming high priority request will bump the priority on its
prerequisites so that it will execute at the earliest opportunity.)

Changes since the preview: a weekend of testing with lockdep and by
popular demand plug GuC into to a software scheduler.
-Chris

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

[Intel-gfx] [PATCH 10/12] drm/i915/scheduler: Support user-defined priorities

2016-11-02 Thread Chris Wilson 
Use a priority stored in the context as the initial value when
submitting a request. This allows us to change the default priority on a
per-context basis, allowing different contexts to be favoured with GPU
time at the expense of lower importance work. The user can adjust the
context's priority via I915_CONTEXT_PARAM_PRIORITY, with more positive
values being higher priority (they will be serviced earlier, after their
dependencies have been resolved). Any prerequisite work for an execbuf
will have its priority raised to match the new request as required.

Normal users can specify any value in the range of -1023 to 0 [default],
i.e. they can reduce the priority of their workloads (and temporarily
boost it back to normal if so desired).

Privileged users can specify any value in the range of -1023 to 1023,
[default is 0], i.e. they can raise their priority above all overs and
so potentially starve the system.

Note that the existing schedulers are not fair, nor load balancing, the
execution is strictly by priority on a first-come, first-served basis,
and the driver may choose to boost some requests above the range
available to users.

This priority was originally based around nice(2), but evolved to allow
clients to adjust their priority within a small range, and allow for a
privileged high priority range.

For example, this can be used to implement EGL_IMG_context_priority
https://www.khronos.org/registry/egl/extensions/IMG/EGL_IMG_context_priority.txt

EGL_CONTEXT_PRIORITY_LEVEL_IMG determines the priority level of
the context to be created. This attribute is a hint, as an
implementation may not support multiple contexts at some
priority levels and system policy may limit access to high
priority contexts to appropriate system privilege level. The
default value for EGL_CONTEXT_PRIORITY_LEVEL_IMG is
EGL_CONTEXT_PRIORITY_MEDIUM_IMG."

so we can map

PRIORITY_HIGH -> 1023 [privileged, will failback to 0]
PRIORITY_MED -> 0 [default]
PRIORITY_LOW -> -1023

They also map onto the priorities used by VkQueue (and a VkQueue is
essentially a timeline, our i915_gem_context under full-ppgtt).

Testcase: igt/gem_exec_schedule
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem_context.c | 21 +
 drivers/gpu/drm/i915/i915_gem_request.c |  2 +-
 include/uapi/drm/i915_drm.h |  3 +++
 4 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 738ec44fe6af..7431c72beccc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -948,6 +948,7 @@ struct i915_gem_context {
/* Unique identifier for this context, used by the hw for tracking */
unsigned int hw_id;
u32 user_handle;
+   int priority; /* greater priorities are serviced first */
 
u32 ggtt_alignment;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 6dd475735f0a..48b5aacf5fc2 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -476,6 +476,7 @@ int i915_gem_context_init(struct drm_device *dev)
return PTR_ERR(ctx);
}
 
+   ctx->priority = -I915_PRIORITY_MAX; /* lowest priority; idle task */
dev_priv->kernel_context = ctx;
 
DRM_DEBUG_DRIVER("%s context support initialized\n",
@@ -1100,6 +1101,9 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
case I915_CONTEXT_PARAM_NO_ERROR_CAPTURE:
args->value = !!(ctx->flags & CONTEXT_NO_ERROR_CAPTURE);
break;
+   case I915_CONTEXT_PARAM_PRIORITY:
+   args->value = ctx->priority;
+   break;
default:
ret = -EINVAL;
break;
@@ -1155,6 +1159,23 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,
ctx->flags &= ~CONTEXT_NO_ERROR_CAPTURE;
}
break;
+
+   case I915_CONTEXT_PARAM_PRIORITY:
+   {
+   int priority = args->value;
+
+   if (args->size)
+   ret = -EINVAL;
+   else if (priority >= I915_PRIORITY_MAX ||
+priority <= -I915_PRIORITY_MAX)
+   ret = -EINVAL;
+   else if (priority > 0 && !capable(CAP_SYS_ADMIN))
+   ret = -EPERM;
+   else
+   ctx->priority = priority;
+   }
+   break;
+
default:
ret = -EINVAL;
break;
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index

[Intel-gfx] [PATCH 02/12] drm/i915: Defer transfer onto execution timeline to actual hw submission

2016-11-02 Thread Chris Wilson 
Defer the transfer from the client's timeline onto the execution
timeline from the point of readiness to the point of actual submission.
For example, in execlists, a request is finally submitted to hardware
when the hardware is ready, and only put onto the hardware queue when
the request is ready. By deferring the transfer, we ensure that the
timeline is maintained in retirement order if we decide to queue the
requests onto the hardware in a different order than fifo.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_request.c| 36 ++
 drivers/gpu/drm/i915/i915_gem_request.h|  2 ++
 drivers/gpu/drm/i915/i915_guc_submission.c |  2 ++
 drivers/gpu/drm/i915/intel_lrc.c   |  5 +
 drivers/gpu/drm/i915/intel_ringbuffer.c|  2 ++
 5 files changed, 33 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 1ae5a2f8953f..05544dec5de9 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -307,25 +307,16 @@ static u32 timeline_get_seqno(struct i915_gem_timeline 
*tl)
return atomic_inc_return(>next_seqno);
 }
 
-static int __i915_sw_fence_call
-submit_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
+void __i915_gem_request_submit(struct drm_i915_gem_request *request)
 {
-   struct drm_i915_gem_request *request =
-   container_of(fence, typeof(*request), submit);
struct intel_engine_cs *engine = request->engine;
struct intel_timeline *timeline;
-   unsigned long flags;
u32 seqno;
 
-   if (state != FENCE_COMPLETE)
-   return NOTIFY_DONE;
-
/* Transfer from per-context onto the global per-engine timeline */
timeline = engine->timeline;
GEM_BUG_ON(timeline == request->timeline);
-
-   /* Will be called from irq-context when using foreign DMA fences */
-   spin_lock_irqsave(>lock, flags);
+   assert_spin_locked(>lock);
 
seqno = timeline_get_seqno(timeline->common);
GEM_BUG_ON(!seqno);
@@ -345,15 +336,32 @@ submit_notify(struct i915_sw_fence *fence, enum 
i915_sw_fence_notify state)
GEM_BUG_ON(!request->global_seqno);
engine->emit_breadcrumb(request,
request->ring->vaddr + request->postfix);
-   engine->submit_request(request);
 
-   spin_lock_nested(>timeline->lock, SINGLE_DEPTH_NESTING);
+   /* nested from submit_notify */
+   spin_lock_nested(>timeline->lock, 2);
list_move_tail(>link, >requests);
spin_unlock(>timeline->lock);
 
i915_sw_fence_commit(>execute);
+}
 
-   spin_unlock_irqrestore(>lock, flags);
+static int __i915_sw_fence_call
+submit_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
+{
+   if (state == FENCE_COMPLETE) {
+   struct drm_i915_gem_request *request =
+   container_of(fence, typeof(*request), submit);
+   struct intel_engine_cs *engine = request->engine;
+   unsigned long flags;
+
+   /* Will be called from irq-context when using foreign fences,
+* and may be called from the execution callback of another
+* engine.
+*/
+   spin_lock_irqsave_nested(>timeline->lock, flags, 1);
+   engine->submit_request(request);
+   spin_unlock_irqrestore(>timeline->lock, flags);
+   }
 
return NOTIFY_DONE;
 }
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index ed13f37fea0f..725d04128eaf 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -228,6 +228,8 @@ void __i915_add_request(struct drm_i915_gem_request *req, 
bool flush_caches);
 #define i915_add_request_no_flush(req) \
__i915_add_request(req, false)
 
+void __i915_gem_request_submit(struct drm_i915_gem_request *request);
+
 struct intel_rps_client;
 #define NO_WAITBOOST ERR_PTR(-1)
 #define IS_RPS_CLIENT(p) (!IS_ERR(p))
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 857ef914cae7..ddb574d5ceda 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -640,6 +640,8 @@ static void i915_guc_submit(struct drm_i915_gem_request *rq)
struct i915_guc_client *client = guc->execbuf_client;
int b_ret;
 
+   __i915_gem_request_submit(rq);
+
spin_lock(>wq_lock);
guc_wq_item_append(client, rq);
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index fa3012c342cc..b9aba16851ac 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -434,6 +434,7 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
 {
struct

[Intel-gfx] [PATCH 06/12] drm/i915/scheduler: Execute requests in order of priorities

2016-11-02 Thread Chris Wilson 
Track the priority of each request and use it to determine the order in
which we submit requests to the hardware via execlists.

The priority of the request is determined by the user (eventually via
the context) but may be overridden at any time by the driver. When we set
the priority of the request, we bump the priority of all of its
dependencies to match - so that a high priority drawing operation is not
stuck behind a background task.

When the request is ready to execute (i.e. we have signaled the submit
fence following completion of all its dependencies, including third
party fences), we put the request into a priority sorted rbtree to be
submitted to the hardware. If the request is higher priority than all
pending requests, it will be submitted on the next context-switch
interrupt as soon as the hardware has completed the current request. We
do not currently preempt any current execution to immediately run a very
high priority request, at least not yet.

One more limitation, is that this is first implementation is for
execlists only so currently limited to gen8/gen9.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c|   7 +-
 drivers/gpu/drm/i915/i915_gem.c|   3 +-
 drivers/gpu/drm/i915/i915_gem_request.c|   4 ++
 drivers/gpu/drm/i915/i915_gem_request.h|   6 +-
 drivers/gpu/drm/i915/i915_guc_submission.c |   4 ++
 drivers/gpu/drm/i915/intel_engine_cs.c |   3 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 104 -
 drivers/gpu/drm/i915/intel_ringbuffer.h|   3 +-
 8 files changed, 109 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3cb96d260dfb..dac435680e98 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -631,8 +631,9 @@ static void print_request(struct seq_file *m,
  struct drm_i915_gem_request *rq,
  const char *prefix)
 {
-   seq_printf(m, "%s%x [%x:%x] @ %d: %s\n", prefix,
+   seq_printf(m, "%s%x [%x:%x] prio=%d @ %dms: %s\n", prefix,
   rq->global_seqno, rq->ctx->hw_id, rq->fence.seqno,
+  rq->priotree.priority,
   jiffies_to_msecs(jiffies - rq->emitted_jiffies),
   rq->timeline->common->name);
 }
@@ -3218,6 +3219,7 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
 
if (i915.enable_execlists) {
u32 ptr, read, write;
+   struct rb_node *rb;
 
seq_printf(m, "\tExeclist status: 0x%08x %08x\n",
   I915_READ(RING_EXECLIST_STATUS_LO(engine)),
@@ -3257,7 +3259,8 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
rcu_read_unlock();
 
spin_lock_irq(>timeline->lock);
-   list_for_each_entry(rq, >execlist_queue, 
execlist_link) {
+   for (rb = engine->execlist_first; rb; rb = rb_next(rb)) 
{
+   rq = rb_entry(rb, typeof(*rq), priotree.node);
print_request(m, rq, "\t\tQ ");
}
spin_unlock_irq(>timeline->lock);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index cf28666021f8..4697848ecfd9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2687,10 +2687,11 @@ static void i915_gem_cleanup_engine(struct 
intel_engine_cs *engine)
 
if (i915.enable_execlists) {
spin_lock_irq(>timeline->lock);
-   INIT_LIST_HEAD(>execlist_queue);
i915_gem_request_put(engine->execlist_port[0].request);
i915_gem_request_put(engine->execlist_port[1].request);
memset(engine->execlist_port, 0, sizeof(engine->execlist_port));
+   engine->execlist_queue = RB_ROOT;
+   engine->execlist_first = NULL;
spin_unlock_irq(>timeline->lock);
}
 }
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 13090f226203..5f0068fac3e9 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -141,6 +141,8 @@ i915_priotree_fini(struct i915_priotree *pt)
 {
struct i915_dependency *dep, *next;
 
+   GEM_BUG_ON(!RB_EMPTY_NODE(>node));
+
/* Everyone we depended upon should retire before us and remove
 * themselves from our list. However, retirement is run independently
 * on each timeline and so we may be called out-of-order.
@@ -164,6 +166,8 @@ i915_priotree_init(struct i915_priotree *pt)
 {
INIT_LIST_HEAD(>pre_list);
INIT_LIST_HEAD(>post_list);
+   RB_CLEAR_NODE(>node);
+   pt->priority = INT_MIN;
 }
 
 void

[Intel-gfx] [PATCH 04/12] drm/i915/scheduler: Signal the arrival of a new request

2016-11-02 Thread Chris Wilson 
The start of the scheduler, add a hook into request submission for the
scheduler to see the arrival of new requests and prepare its runqueues.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c |  4 
 drivers/gpu/drm/i915/i915_gem_request.c | 13 +
 drivers/gpu/drm/i915/intel_engine_cs.c  |  3 +++
 drivers/gpu/drm/i915/intel_ringbuffer.h |  9 +
 include/uapi/drm/i915_drm.h |  5 +
 5 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 79cea49183b3..5a0e885e6104 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -323,6 +323,10 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
 */
value = i915_gem_mmap_gtt_version();
break;
+   case I915_PARAM_HAS_SCHEDULER:
+   value = dev_priv->engine[RCS] &&
+   dev_priv->engine[RCS]->schedule;
+   break;
case I915_PARAM_MMAP_VERSION:
/* Remember to bump this if the version changes! */
case I915_PARAM_HAS_GEM:
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 05544dec5de9..9c8605c834f9 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -759,6 +759,19 @@ void __i915_add_request(struct drm_i915_gem_request 
*request, bool flush_caches)
 
i915_gem_mark_busy(engine);
 
+   /* Let the backend know a new request has arrived that may need
+* to adjust the existing execution schedule due to a high priority
+* request - i.e. we may want to preempt the current request in order
+* to run a high priority dependency chain *before* we can execute this
+* request.
+*
+* This is called before the request is ready to run so that we can
+* decide whether to preempt the entire chain so that it is ready to
+* run at the earliest possible convenience.
+*/
+   if (engine->schedule)
+   engine->schedule(request, 0);
+
local_bh_disable();
i915_sw_fence_commit(>submit);
local_bh_enable(); /* Kick the execlists tasklet if just scheduled */
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 298f0f95dd3f..c9171a058478 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -102,6 +102,9 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
engine->mmio_base = info->mmio_base;
engine->irq_shift = info->irq_shift;
 
+   /* Nothing to do here, execute in order of dependencies */
+   engine->schedule = NULL;
+
dev_priv->engine[id] = engine;
return 0;
 }
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 062bc8e1872a..75991a3c694b 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -267,6 +267,15 @@ struct intel_engine_cs {
 */
void(*submit_request)(struct drm_i915_gem_request *req);
 
+   /* Call when the priority on a request has changed and it and its
+* dependencies may need rescheduling. Note the request itself may
+* not be ready to run!
+*
+* Called under the struct_mutex.
+*/
+   void(*schedule)(struct drm_i915_gem_request *request,
+   int priority);
+
/* Some chipsets are not quite as coherent as advertised and need
 * an expensive kick to force a true read of the up-to-date seqno.
 * However, the up-to-date seqno is not always required and the last
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 03725fe89859..1c12a350eca3 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -389,6 +389,11 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_MIN_EU_IN_POOL   39
 #define I915_PARAM_MMAP_GTT_VERSION 40
 
+/* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
+ * priorities and the driver will attempt to execute batches in priority order.
+ */
+#define I915_PARAM_HAS_SCHEDULER41
+
 typedef struct drm_i915_getparam {
__s32 param;
/*
-- 
2.10.2

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

[Intel-gfx] [PATCH 01/12] drm/i915: Split request submit/execute phase into two

2016-11-02 Thread Chris Wilson 
In order to support deferred scheduling, we need to differentiate
between when the request is ready to run (i.e. the submit fence is
signaled) and when the request is actually run (a new execute fence).
This is typically split between the request itself wanting to wait upon
others (for which we use the submit fence) and the CPU wanting to wait
upon the request, for which we use the execute fence to be sure the
hardware is ready to signal completion.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 33 -
 drivers/gpu/drm/i915/i915_gem_request.h |  2 ++
 2 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 79b0046d9a57..1ae5a2f8953f 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -351,11 +351,19 @@ submit_notify(struct i915_sw_fence *fence, enum 
i915_sw_fence_notify state)
list_move_tail(>link, >requests);
spin_unlock(>timeline->lock);
 
+   i915_sw_fence_commit(>execute);
+
spin_unlock_irqrestore(>lock, flags);
 
return NOTIFY_DONE;
 }
 
+static int __i915_sw_fence_call
+execute_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
+{
+   return NOTIFY_DONE;
+}
+
 /**
  * i915_gem_request_alloc - allocate a request structure
  *
@@ -441,6 +449,12 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
   __timeline_get_seqno(req->timeline->common));
 
i915_sw_fence_init(>submit, submit_notify);
+   i915_sw_fence_init(>execute, execute_notify);
+   /* Ensure that the execute fence completes after the submit fence -
+* as we complete the execute fence from within the submit fence
+* callback, its completion would otherwise be visible first.
+*/
+   i915_sw_fence_await_sw_fence(>execute, >submit, >execq);
 
INIT_LIST_HEAD(>active_list);
req->i915 = dev_priv;
@@ -817,9 +831,9 @@ bool __i915_spin_request(const struct drm_i915_gem_request 
*req,
 }
 
 static long
-__i915_request_wait_for_submit(struct drm_i915_gem_request *request,
-  unsigned int flags,
-  long timeout)
+__i915_request_wait_for_execute(struct drm_i915_gem_request *request,
+   unsigned int flags,
+   long timeout)
 {
const int state = flags & I915_WAIT_INTERRUPTIBLE ?
TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
@@ -831,9 +845,9 @@ __i915_request_wait_for_submit(struct drm_i915_gem_request 
*request,
add_wait_queue(q, );
 
do {
-   prepare_to_wait(>submit.wait, , state);
+   prepare_to_wait(>execute.wait, , state);
 
-   if (i915_sw_fence_done(>submit))
+   if (i915_sw_fence_done(>execute))
break;
 
if (flags & I915_WAIT_LOCKED &&
@@ -851,7 +865,7 @@ __i915_request_wait_for_submit(struct drm_i915_gem_request 
*request,
 
timeout = io_schedule_timeout(timeout);
} while (timeout);
-   finish_wait(>submit.wait, );
+   finish_wait(>execute.wait, );
 
if (flags & I915_WAIT_LOCKED)
remove_wait_queue(q, );
@@ -903,13 +917,14 @@ long i915_wait_request(struct drm_i915_gem_request *req,
 
trace_i915_gem_request_wait_begin(req);
 
-   if (!i915_sw_fence_done(>submit)) {
-   timeout = __i915_request_wait_for_submit(req, flags, timeout);
+   if (!i915_sw_fence_done(>execute)) {
+   timeout = __i915_request_wait_for_execute(req, flags, timeout);
if (timeout < 0)
goto complete;
 
-   GEM_BUG_ON(!i915_sw_fence_done(>submit));
+   GEM_BUG_ON(!i915_sw_fence_done(>execute));
}
+   GEM_BUG_ON(!i915_sw_fence_done(>submit));
GEM_BUG_ON(!req->global_seqno);
 
/* Optimistic short spin before touching IRQs */
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index 75f8360b3421..ed13f37fea0f 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -85,7 +85,9 @@ struct drm_i915_gem_request {
struct intel_signal_node signaling;
 
struct i915_sw_fence submit;
+   struct i915_sw_fence execute;
wait_queue_t submitq;
+   wait_queue_t execq;
 
u32 global_seqno;
 
-- 
2.10.2

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

[Intel-gfx] [PATCH 11/12] drm/i915: Enable userspace to opt-out of implicit fencing

2016-11-02 Thread Chris Wilson 
Userspace is faced with a dilemma. The kernel requires implicit fencing
to manage resource usage (we always must wait for the GPU to finish
before releasing its PTE) and for third parties. However, userspace may
wish to avoid this serialisation if it is either using explicit fencing
between parties and wants more fine-grained access to buffers (e.g. it
may partition the buffer between uses and track fences on ranges rather
than the implicit fences tracking the whole object). It follows that
userspace needs a mechanism to avoid the kernel's serialisation on its
implicit fences before execbuf execution.

The next question is whether this is an object, execbuf or context flag.
Hybrid users (such as using explicit EGL_ANDROID_native_sync fencing on
shared winsys buffers, but implicit fencing on internal surfaces)
require a per-object level flag. Given that this flag need to be only
set once for the lifetime of the object, this reduces the convenience of
having an execbuf or context level flag (and avoids having multiple
pieces of uABI controlling the same feature).

Incorrect use of this flag will result in rendering corruption and GPU
hangs - but will not result in use-after-free or similar resource
tracking issues.

Serious caveat: write ordering is not strictly correct after setting
this flag on a render target on multiple engines. This affects all
subsequent GEM operations (execbuf, set-domain, pread) and shared
dma-buf operations. A fix is possible - but costly (both in terms of
further ABI changes and runtime overhead).

Testcase: igt/gem_exec_async
Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.c|  1 +
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  3 +++
 include/uapi/drm/i915_drm.h| 29 -
 3 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5a0e885e6104..4bfd5a582aa2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -343,6 +343,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_EXEC_HANDLE_LUT:
case I915_PARAM_HAS_COHERENT_PHYS_GTT:
case I915_PARAM_HAS_EXEC_SOFTPIN:
+   case I915_PARAM_HAS_EXEC_ASYNC:
/* For the time being all of these are always true;
 * if some supported hardware does not have one of these
 * features this value needs to be provided from
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index c35e847bb8bc..0ae2feb24632 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1110,6 +1110,9 @@ i915_gem_execbuffer_move_to_gpu(struct 
drm_i915_gem_request *req,
list_for_each_entry(vma, vmas, exec_list) {
struct drm_i915_gem_object *obj = vma->obj;
 
+   if (vma->exec_entry->flags & EXEC_OBJECT_ASYNC)
+   continue;
+
ret = i915_gem_request_await_object
(req, obj, obj->base.pending_write_domain);
if (ret)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 47901a8ad682..4bd83c0b07db 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -396,6 +396,12 @@ typedef struct drm_i915_irq_wait {
  */
 #define I915_PARAM_HAS_SCHEDULER41
 
+/* Query whether DRM_I915_GEM_EXECBUFFER2 supports the ability to opt-out of
+ * synchronisation with implicit fencing on individual objects.
+ */
+#define I915_PARAM_HAS_EXEC_ASYNC   42
+
+
 typedef struct drm_i915_getparam {
__s32 param;
/*
@@ -736,8 +742,29 @@ struct drm_i915_gem_exec_object2 {
 #define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3)
 #define EXEC_OBJECT_PINNED  (1<<4)
 #define EXEC_OBJECT_PAD_TO_SIZE (1<<5)
+/* The kernel implicitly tracks GPU activity on all GEM objects, and
+ * synchronises operations with outstanding rendering. This includes
+ * rendering on other devices if exported via dma-buf. However, sometimes
+ * this tracking is too coarse and the user knows better. For example,
+ * if the object is split into non-overlapping ranges shared between different
+ * clients or engines (i.e. suballocating objects), the implicit tracking
+ * by kernel assumes that each operation affects the whole object rather
+ * than an individual range, causing needless synchronisation between clients.
+ * The kernel will also forgo any CPU cache flushes prior to rendering from
+ * the object as the client is expected to be also handling such domain
+ * tracking.
+ *
+ * The kernel maintains the implicit tracking in order to manage resources
+ * used by the GPU - this flag only disables the synchronisation prior to
+ * rendering with this object in this

[Intel-gfx] [PATCH 12/12] drm/i915: Support explicit fencing for execbuf

2016-11-02 Thread Chris Wilson 
Now that the user can opt-out of implicit fencing, we need to give them
back control over the fencing. We employ sync_file to wrap our
drm_i915_gem_request and provide an fd that userspace can merge with
other sync_file fds and pass back to the kernel to wait upon before
future execution.

Testcase: igt/gem_exec_fence
Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/Kconfig   |  1 +
 drivers/gpu/drm/i915/i915_drv.c|  3 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 54 +++---
 include/uapi/drm/i915_drm.h| 35 ++-
 4 files changed, 86 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index df96aed6975a..8e93b61bd8c3 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -19,6 +19,7 @@ config DRM_I915
select INPUT if ACPI
select ACPI_VIDEO if ACPI
select ACPI_BUTTON if ACPI
+   select SYNC_FILE
help
  Choose this option if you have a system that has "Intel Graphics
  Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4bfd5a582aa2..d022fb207a42 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -344,6 +344,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_COHERENT_PHYS_GTT:
case I915_PARAM_HAS_EXEC_SOFTPIN:
case I915_PARAM_HAS_EXEC_ASYNC:
+   case I915_PARAM_HAS_EXEC_FENCE:
/* For the time being all of these are always true;
 * if some supported hardware does not have one of these
 * features this value needs to be provided from
@@ -2534,7 +2535,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, drm_noop, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GEM_INIT, drm_noop, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer, DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2_WR, i915_gem_execbuffer2, 
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_reject_pin_ioctl, 
DRM_AUTH|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_reject_pin_ioctl, 
DRM_AUTH|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
DRM_AUTH|DRM_RENDER_ALLOW),
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 0ae2feb24632..83533fb6cf46 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -28,6 +28,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -1588,6 +1589,9 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct i915_execbuffer_params *params = _master;
const u32 ctx_id = i915_execbuffer2_get_context_id(*args);
u32 dispatch_flags;
+   struct dma_fence *in_fence = NULL;
+   struct sync_file *out_fence = NULL;
+   int out_fence_fd = -1;
int ret;
bool need_relocs;
 
@@ -1631,6 +1635,23 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
*data,
dispatch_flags |= I915_DISPATCH_RS;
}
 
+   if (args->flags & I915_EXEC_FENCE_IN) {
+   in_fence = sync_file_get_fence(lower_32_bits(args->rsvd2));
+   if (!in_fence) {
+   ret = -EINVAL;
+   goto pre_mutex_err;
+   }
+   }
+
+   if (args->flags & I915_EXEC_FENCE_OUT) {
+   out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
+   if (out_fence_fd < 0) {
+   ret = out_fence_fd;
+   out_fence_fd = -1;
+   goto pre_mutex_err;
+   }
+   }
+
/* Take a local wakeref for preparing to dispatch the execbuf as
 * we expect to access the hardware fairly frequently in the
 * process. Upon first dispatch, we acquire another prolonged
@@ -1775,6 +1796,21 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
*data,
goto err_batch_unpin;
}
 
+   if (in_fence) {
+   ret = i915_gem_request_await_dma_fence(params->request,
+  in_fence);
+   if (ret < 0)
+   goto err_request;
+   }
+
+   if (out_fence_fd != -1) {
+   out_fence = sync_file_create(>request->fence);
+   if (!out_fence) {
+   ret = -ENOMEM;
+   goto err_request;
+   }
+   }
+
/* Whilst

[Intel-gfx] [PATCH 09/12] HACK drm/i915/scheduler: emulate a scheduler for guc

2016-11-02 Thread Chris Wilson 
This emulates execlists on top of the GuC in order to defer submission of
requests to the hardware. This deferral allows time for high priority
requests to gazump their way to the head of the queue, however it nerfs
the GuC by converting it back into a simple execlist (where the CPU has
to wake up after every request to feed new commands into the GuC).
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 83 ++
 drivers/gpu/drm/i915/i915_irq.c|  4 +-
 drivers/gpu/drm/i915/intel_lrc.c   |  3 --
 3 files changed, 75 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index bab0c2fc3bce..601b8777d3fd 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -469,7 +469,7 @@ int i915_guc_wq_reserve(struct drm_i915_gem_request 
*request)
u32 freespace;
int ret;
 
-   spin_lock(>wq_lock);
+   spin_lock_irq(>wq_lock);
freespace = CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size);
freespace -= gc->wq_rsvd;
if (likely(freespace >= wqi_size)) {
@@ -479,7 +479,7 @@ int i915_guc_wq_reserve(struct drm_i915_gem_request 
*request)
gc->no_wq_space++;
ret = -EAGAIN;
}
-   spin_unlock(>wq_lock);
+   spin_unlock_irq(>wq_lock);
 
return ret;
 }
@@ -491,9 +491,9 @@ void i915_guc_wq_unreserve(struct drm_i915_gem_request 
*request)
 
GEM_BUG_ON(READ_ONCE(gc->wq_rsvd) < wqi_size);
 
-   spin_lock(>wq_lock);
+   spin_lock_irq(>wq_lock);
gc->wq_rsvd -= wqi_size;
-   spin_unlock(>wq_lock);
+   spin_unlock_irq(>wq_lock);
 }
 
 /* Construct a Work Item and append it to the GuC's Work Queue */
@@ -658,6 +658,70 @@ static void i915_guc_submit(struct drm_i915_gem_request 
*rq)
spin_unlock(>wq_lock);
 }
 
+static bool i915_guc_dequeue(struct intel_engine_cs *engine)
+{
+   struct execlist_port *port = engine->execlist_port;
+   struct drm_i915_gem_request *last = port[0].request;
+   unsigned long flags;
+   struct rb_node *rb;
+   bool submit = false;
+
+   spin_lock_irqsave(>timeline->lock, flags);
+   rb = engine->execlist_first;
+   while (rb) {
+   struct drm_i915_gem_request *cursor =
+   rb_entry(rb, typeof(*cursor), priotree.node);
+
+   if (last && cursor->ctx != last->ctx) {
+   if (port != engine->execlist_port)
+   break;
+
+   i915_gem_request_assign(>request, last);
+   dma_fence_enable_sw_signaling(>fence);
+   port++;
+   }
+
+   rb = rb_next(rb);
+   rb_erase(>priotree.node, >execlist_queue);
+   RB_CLEAR_NODE(>priotree.node);
+   cursor->priotree.priority = INT_MAX;
+
+   i915_guc_submit(cursor);
+   last = cursor;
+   submit = true;
+   }
+   if (submit) {
+   i915_gem_request_assign(>request, last);
+   dma_fence_enable_sw_signaling(>fence);
+   engine->execlist_first = rb;
+   }
+   spin_unlock_irqrestore(>timeline->lock, flags);
+
+   return submit;
+}
+
+static void i915_guc_irq_handler(unsigned long data)
+{
+   struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
+   struct execlist_port *port = engine->execlist_port;
+   struct drm_i915_gem_request *rq;
+   bool submit;
+
+   do {
+   rq = port[0].request;
+   while (rq && i915_gem_request_completed(rq)) {
+   i915_gem_request_put(rq);
+   rq = port[1].request;
+   port[0].request = rq;
+   port[1].request = NULL;
+   }
+
+   submit = false;
+   if (!port[1].request)
+   submit = i915_guc_dequeue(engine);
+   } while (submit);
+}
+
 /*
  * Everything below here is concerned with setup & teardown, and is
  * therefore not part of the somewhat time-critical batch-submission
@@ -1524,16 +1588,13 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
 
/* Take over from manual control of ELSP (execlists) */
for_each_engine(engine, dev_priv, id) {
-   engine->submit_request = i915_guc_submit;
-   engine->schedule = NULL;
+   tasklet_init(>irq_tasklet,
+i915_guc_irq_handler,
+(unsigned long)engine);
 
/* Replay the current set of previously submitted requests */
-   list_for_each_entry(request,
-   >timeline->requests, link) {
+   list_for_each_entry(request, >timeline->requests, link)
client->wq_rsvd += sizeof(struct

[Intel-gfx] [PATCH 08/12] drm/i915/guc: Cache the client mapping

2016-11-02 Thread Chris Wilson 
Use i915_gem_object_pin_map() for the guc client's lifetime to replace
the peristent kmap + frequent kmap_atomic with a permanent vmapping.
This avoids taking the obj->mm.lock mutex whilst inside irq context
later.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 38 +++---
 drivers/gpu/drm/i915/intel_guc.h   |  2 +-
 2 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index b31573a825fa..bab0c2fc3bce 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -220,7 +220,7 @@ static int guc_update_doorbell_id(struct intel_guc *guc,
struct guc_context_desc desc;
size_t len;
 
-   doorbell = client->client_base + client->doorbell_offset;
+   doorbell = client->vaddr + client->doorbell_offset;
 
if (client->doorbell_id != GUC_INVALID_DOORBELL_ID &&
test_bit(client->doorbell_id, doorbell_bitmap)) {
@@ -326,7 +326,7 @@ static void guc_proc_desc_init(struct intel_guc *guc,
 {
struct guc_process_desc *desc;
 
-   desc = client->client_base + client->proc_desc_offset;
+   desc = client->vaddr + client->proc_desc_offset;
 
memset(desc, 0, sizeof(*desc));
 
@@ -413,8 +413,8 @@ static void guc_ctx_desc_init(struct intel_guc *guc,
gfx_addr = i915_ggtt_offset(client->vma);
desc.db_trigger_phy = sg_dma_address(client->vma->pages->sgl) +
client->doorbell_offset;
-   desc.db_trigger_cpu = (uintptr_t)client->client_base +
-   client->doorbell_offset;
+   desc.db_trigger_cpu =
+   (uintptr_t)client->vaddr + client->doorbell_offset;
desc.db_trigger_uk = gfx_addr + client->doorbell_offset;
desc.process_desc = gfx_addr + client->proc_desc_offset;
desc.wq_addr = gfx_addr + client->wq_offset;
@@ -465,7 +465,7 @@ int i915_guc_wq_reserve(struct drm_i915_gem_request 
*request)
 {
const size_t wqi_size = sizeof(struct guc_wq_item);
struct i915_guc_client *gc = request->i915->guc.execbuf_client;
-   struct guc_process_desc *desc = gc->client_base + gc->proc_desc_offset;
+   struct guc_process_desc *desc = gc->vaddr + gc->proc_desc_offset;
u32 freespace;
int ret;
 
@@ -506,10 +506,9 @@ static void guc_wq_item_append(struct i915_guc_client *gc,
struct intel_engine_cs *engine = rq->engine;
struct guc_process_desc *desc;
struct guc_wq_item *wqi;
-   void *base;
-   u32 freespace, tail, wq_off, wq_page;
+   u32 freespace, tail, wq_off;
 
-   desc = gc->client_base + gc->proc_desc_offset;
+   desc = gc->vaddr + gc->proc_desc_offset;
 
/* Free space is guaranteed, see i915_guc_wq_reserve() above */
freespace = CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size);
@@ -539,10 +538,7 @@ static void guc_wq_item_append(struct i915_guc_client *gc,
gc->wq_rsvd -= wqi_size;
 
/* WQ starts from the page after doorbell / process_desc */
-   wq_page = (wq_off + GUC_DB_SIZE) >> PAGE_SHIFT;
-   wq_off &= PAGE_SIZE - 1;
-   base = kmap_atomic(i915_gem_object_get_page(gc->vma->obj, wq_page));
-   wqi = (struct guc_wq_item *)((char *)base + wq_off);
+   wqi = gc->vaddr + wq_off + GUC_DB_SIZE;
 
/* Now fill in the 4-word work queue item */
wqi->header = WQ_TYPE_INORDER |
@@ -555,8 +551,6 @@ static void guc_wq_item_append(struct i915_guc_client *gc,
 
wqi->ring_tail = tail << WQ_RING_TAIL_SHIFT;
wqi->fence_id = rq->global_seqno;
-
-   kunmap_atomic(base);
 }
 
 static int guc_ring_doorbell(struct i915_guc_client *gc)
@@ -566,7 +560,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
union guc_doorbell_qw *db;
int attempt = 2, ret = -EAGAIN;
 
-   desc = gc->client_base + gc->proc_desc_offset;
+   desc = gc->vaddr + gc->proc_desc_offset;
 
/* Update the tail so it is visible to GuC */
desc->tail = gc->wq_tail;
@@ -582,7 +576,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
db_exc.cookie = 1;
 
/* pointer of current doorbell cacheline */
-   db = gc->client_base + gc->doorbell_offset;
+   db = gc->vaddr + gc->doorbell_offset;
 
while (attempt--) {
/* lets ring the doorbell */
@@ -729,14 +723,14 @@ guc_client_free(struct drm_i915_private *dev_priv,
 * Be sure to drop any locks
 */
 
-   if (client->client_base) {
+   if (client->vaddr) {
/*
 * If we got as far as setting up a doorbell, make sure we
 * shut it down before unmapping & deallocating the memory.
 */
guc_disable_doorbell(guc, client);
 
-   kunmap(kmap_to_page(client->client_base));
+

[Intel-gfx] [PATCH 05/12] drm/i915/scheduler: Record all dependencies upon request construction

2016-11-02 Thread Chris Wilson 
The scheduler needs to know the dependencies of each request for the
lifetime of the request, as it may choose to reschedule the requests at
any time and must ensure the dependency tree is not broken. This is in
additional to using the fence to only allow execution after all
dependencies have been completed.

One option was to extend the fence to support the bidirectional
dependency tracking required by the scheduler. However the mismatch in
lifetimes between the submit fence and the request essentially meant
that we had to build a completely separate struct (and we could not
simply reuse the existing waitqueue in the fence for one half of the
dependency tracking). The extra dependency tracking simply did not mesh
well with the fence, and keeping it separate both keeps the fence
implementation simpler and allows us to extend the dependency tracking
into a priority tree (whilst maintaining support for reordering the
tree).

To avoid the additional allocations and list manipulations, the use of
the priotree is disabled when there are no schedulers to use it.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 72 -
 drivers/gpu/drm/i915/i915_gem_request.h | 23 +++
 2 files changed, 94 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 9c8605c834f9..13090f226203 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -113,6 +113,59 @@ i915_gem_request_remove_from_client(struct 
drm_i915_gem_request *request)
spin_unlock(_priv->mm.lock);
 }
 
+static int
+i915_priotree_add_dependency(struct i915_priotree *pt,
+struct i915_priotree *signal,
+struct i915_dependency *dep)
+{
+   unsigned long flags = 0;
+
+   if (!dep) {
+   dep = kmalloc(sizeof(*dep), GFP_KERNEL);
+   if (!dep)
+   return -ENOMEM;
+
+   flags |= I915_DEPENDENCY_ALLOC;
+   }
+
+   dep->signal = signal;
+   dep->flags = flags;
+
+   list_add(>post_link, >post_list);
+   list_add(>pre_link, >pre_list);
+   return 0;
+}
+
+static void
+i915_priotree_fini(struct i915_priotree *pt)
+{
+   struct i915_dependency *dep, *next;
+
+   /* Everyone we depended upon should retire before us and remove
+* themselves from our list. However, retirement is run independently
+* on each timeline and so we may be called out-of-order.
+*/
+   list_for_each_entry_safe(dep, next, >pre_list, pre_link) {
+   list_del(>post_link);
+   if (dep->flags & I915_DEPENDENCY_ALLOC)
+   kfree(dep);
+   }
+
+   /* Remove ourselves from everyone who depends upon us */
+   list_for_each_entry_safe(dep, next, >post_list, post_link) {
+   list_del(>pre_link);
+   if (dep->flags & I915_DEPENDENCY_ALLOC)
+   kfree(dep);
+   }
+}
+
+static void
+i915_priotree_init(struct i915_priotree *pt)
+{
+   INIT_LIST_HEAD(>pre_list);
+   INIT_LIST_HEAD(>post_list);
+}
+
 void i915_gem_retire_noop(struct i915_gem_active *active,
  struct drm_i915_gem_request *request)
 {
@@ -182,6 +235,8 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
i915_gem_context_put(request->ctx);
 
dma_fence_signal(>fence);
+
+   i915_priotree_fini(>priotree);
i915_gem_request_put(request);
 }
 
@@ -464,6 +519,8 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
 */
i915_sw_fence_await_sw_fence(>execute, >submit, >execq);
 
+   i915_priotree_init(>priotree);
+
INIT_LIST_HEAD(>active_list);
req->i915 = dev_priv;
req->engine = engine;
@@ -517,6 +574,14 @@ i915_gem_request_await_request(struct drm_i915_gem_request 
*to,
 
GEM_BUG_ON(to == from);
 
+   if (to->engine->schedule) {
+   ret = i915_priotree_add_dependency(>priotree,
+  >priotree,
+  NULL);
+   if (ret < 0)
+   return ret;
+   }
+
if (to->timeline == from->timeline)
return 0;
 
@@ -740,9 +805,14 @@ void __i915_add_request(struct drm_i915_gem_request 
*request, bool flush_caches)
 
prev = i915_gem_active_raw(>last_request,
   >i915->drm.struct_mutex);
-   if (prev)
+   if (prev) {
i915_sw_fence_await_sw_fence(>submit, >submit,
 >submitq);
+   if (engine->schedule)
+   i915_priotree_add_dependency(>priotree,
+>priotree,
+

[Intel-gfx] [PATCH 07/12] drm/i915/scheduler: Boost priorities for flips

2016-11-02 Thread Chris Wilson 
Boost the priority of any rendering required to show the next pageflip
as we want to avoid missing the vblank by being delayed by invisible
workload. We prioritise avoiding jank and jitter in the GUI over
starving background tasks.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h  |  5 
 drivers/gpu/drm/i915/i915_gem.c  | 50 
 drivers/gpu/drm/i915/intel_display.c |  2 ++
 3 files changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 61fee0b0c302..738ec44fe6af 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3416,6 +3416,11 @@ int i915_gem_object_wait(struct drm_i915_gem_object *obj,
 unsigned int flags,
 long timeout,
 struct intel_rps_client *rps);
+int i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
+ unsigned int flags,
+ int priority);
+#define I915_PRIORITY_DISPLAY I915_PRIORITY_MAX
+
 int __must_check
 i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj,
  bool write);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4697848ecfd9..4287c51fb461 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -433,6 +433,56 @@ i915_gem_object_wait_reservation(struct reservation_object 
*resv,
return timeout;
 }
 
+static void fence_set_priority(struct dma_fence *fence, int prio)
+{
+   struct drm_i915_gem_request *rq;
+   struct intel_engine_cs *engine;
+
+   if (!dma_fence_is_i915(fence))
+   return;
+
+   rq = to_request(fence);
+   engine = rq->engine;
+   if (!engine->schedule)
+   return;
+
+   engine->schedule(rq, prio);
+}
+
+int
+i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
+ unsigned int flags,
+ int prio)
+{
+   struct dma_fence *excl;
+
+   if (flags & I915_WAIT_ALL) {
+   struct dma_fence **shared;
+   unsigned int count, i;
+   int ret;
+
+   ret = reservation_object_get_fences_rcu(obj->resv,
+   , , );
+   if (ret)
+   return ret;
+
+   for (i = 0; i < count; i++) {
+   fence_set_priority(shared[i], prio);
+   dma_fence_put(shared[i]);
+   }
+
+   kfree(shared);
+   } else {
+   excl = reservation_object_get_excl_rcu(obj->resv);
+   }
+
+   if (excl) {
+   fence_set_priority(excl, prio);
+   dma_fence_put(excl);
+   }
+   return 0;
+}
+
 /**
  * Waits for rendering to the object to be completed
  * @obj: i915 gem object
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 97589102442c..8df9554432a9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14761,6 +14761,8 @@ intel_prepare_plane_fb(struct drm_plane *plane,
  GFP_KERNEL);
if (ret < 0)
return ret;
+
+   i915_gem_object_wait_priority(obj, 0, I915_PRIORITY_DISPLAY);
}
 
if (plane->type == DRM_PLANE_TYPE_CURSOR &&
-- 
2.10.2

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

[Intel-gfx] [PATCH 03/12] drm/i915: Remove engine->execlist_lock

2016-11-02 Thread Chris Wilson 
The execlist_lock is now completely subsumed by the engine->timeline->lock,
and so we can remove the redundant layer of locking.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
 drivers/gpu/drm/i915/i915_gem.c | 4 ++--
 drivers/gpu/drm/i915/intel_engine_cs.c  | 1 -
 drivers/gpu/drm/i915/intel_lrc.c| 7 +--
 drivers/gpu/drm/i915/intel_ringbuffer.h | 1 -
 5 files changed, 5 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index c9465fbff2df..3cb96d260dfb 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3256,11 +3256,11 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
seq_printf(m, "\t\tELSP[1] idle\n");
rcu_read_unlock();
 
-   spin_lock_irq(>execlist_lock);
+   spin_lock_irq(>timeline->lock);
list_for_each_entry(rq, >execlist_queue, 
execlist_link) {
print_request(m, rq, "\t\tQ ");
}
-   spin_unlock_irq(>execlist_lock);
+   spin_unlock_irq(>timeline->lock);
} else if (INTEL_GEN(dev_priv) > 6) {
seq_printf(m, "\tPP_DIR_BASE: 0x%08x\n",
   I915_READ(RING_PP_DIR_BASE(engine)));
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5839bebba64a..cf28666021f8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2686,12 +2686,12 @@ static void i915_gem_cleanup_engine(struct 
intel_engine_cs *engine)
 */
 
if (i915.enable_execlists) {
-   spin_lock(>execlist_lock);
+   spin_lock_irq(>timeline->lock);
INIT_LIST_HEAD(>execlist_queue);
i915_gem_request_put(engine->execlist_port[0].request);
i915_gem_request_put(engine->execlist_port[1].request);
memset(engine->execlist_port, 0, sizeof(engine->execlist_port));
-   spin_unlock(>execlist_lock);
+   spin_unlock_irq(>timeline->lock);
}
 }
 
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 841f8d1e1410..298f0f95dd3f 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -237,7 +237,6 @@ static void intel_engine_init_timeline(struct 
intel_engine_cs *engine)
 void intel_engine_setup_common(struct intel_engine_cs *engine)
 {
INIT_LIST_HEAD(>execlist_queue);
-   spin_lock_init(>execlist_lock);
 
intel_engine_init_timeline(engine);
intel_engine_init_hangcheck(engine);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b9aba16851ac..186c3ccb2c34 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -471,7 +471,6 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
 */
 
spin_lock_irqsave(>timeline->lock, flags);
-   spin_lock(>execlist_lock);
list_for_each_entry(cursor, >execlist_queue, execlist_link) {
/* Can we combine this request with the current port? It has to
 * be the same context/ringbuffer and not have any exceptions
@@ -515,7 +514,6 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
 
i915_gem_request_assign(>request, last);
}
-   spin_unlock(>execlist_lock);
spin_unlock_irqrestore(>timeline->lock, flags);
 
if (submit)
@@ -600,9 +598,8 @@ static void intel_lrc_irq_handler(unsigned long data)
 static void execlists_submit_request(struct drm_i915_gem_request *request)
 {
struct intel_engine_cs *engine = request->engine;
-   unsigned long flags;
 
-   spin_lock_irqsave(>execlist_lock, flags);
+   assert_spin_locked(>timeline->lock);
 
/* We keep the previous context alive until we retire the following
 * request. This ensures that any the context object is still pinned
@@ -616,8 +613,6 @@ static void execlists_submit_request(struct 
drm_i915_gem_request *request)
list_add_tail(>execlist_link, >execlist_queue);
if (execlists_elsp_idle(engine))
tasklet_hi_schedule(>irq_tasklet);
-
-   spin_unlock_irqrestore(>execlist_lock, flags);
 }
 
 int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request 
*request)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 642b54692d0d..062bc8e1872a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -335,7 +335,6 @@ struct intel_engine_cs {
 
/* Execlists */
struct tasklet_struct irq_tasklet;
-   spinlock_t execlist_lock; /*

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/sw_fence: Replace private use of wq->flags with bit zero in wq->private

2016-11-02 Thread Patchwork 
== Series Details ==

Series: drm/i915/sw_fence: Replace private use of wq->flags with bit zero in 
wq->private
URL   : https://patchwork.freedesktop.org/series/14745/
State : success

== Summary ==

Series 14745v1 drm/i915/sw_fence: Replace private use of wq->flags with bit 
zero in wq->private
https://patchwork.freedesktop.org/api/1.0/series/14745/revisions/1/mbox/


fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:187  dwarn:0   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

bf6b989af8b0fde56a352d9005c97b2d8e3bbbe3 drm-intel-nightly: 
2016y-11m-02d-15h-44m-03s UTC integration manifest
9067391 drm/i915/sw_fence: Replace private use of wq->flags with bit zero in 
wq->private

== Logs ==

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

[Intel-gfx] [RFC] drm/i915/sw_fence: Allocate callbacks from dedicates slab caches

2016-11-02 Thread Tvrtko Ursulin 
From: Tvrtko Ursulin 

Not sure if it matters for performance at all but it should
save some wastage and enable a better insight into the usage.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c  | 10 +-
 drivers/gpu/drm/i915/i915_sw_fence.c | 67 +---
 drivers/gpu/drm/i915/i915_sw_fence.h |  3 ++
 3 files changed, 75 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5839bebba64a..57e550449992 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4748,6 +4748,10 @@ i915_gem_load_init(struct drm_device *dev)
goto err_vmas;
}
 
+   err = i915_init_sw_fences();
+   if (err)
+   goto err_requests;
+
mutex_lock(_priv->drm.struct_mutex);
INIT_LIST_HEAD(_priv->gt.timelines);
err = i915_gem_timeline_init(dev_priv,
@@ -4755,7 +4759,7 @@ i915_gem_load_init(struct drm_device *dev)
 "[execution]");
mutex_unlock(_priv->drm.struct_mutex);
if (err)
-   goto err_requests;
+   goto err_sw_fences;
 
INIT_LIST_HEAD(_priv->context_list);
INIT_WORK(_priv->mm.free_work, __i915_gem_free_work);
@@ -4783,6 +4787,8 @@ i915_gem_load_init(struct drm_device *dev)
 
return 0;
 
+err_sw_fences:
+   i915_fini_sw_fences();
 err_requests:
kmem_cache_destroy(dev_priv->requests);
 err_vmas:
@@ -4799,6 +4805,8 @@ void i915_gem_load_cleanup(struct drm_device *dev)
 
WARN_ON(!llist_empty(_priv->mm.free_list));
 
+   i915_fini_sw_fences();
+
kmem_cache_destroy(dev_priv->requests);
kmem_cache_destroy(dev_priv->vmas);
kmem_cache_destroy(dev_priv->objects);
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c 
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 95f2f12e0917..5f814b60e2c0 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -17,6 +17,11 @@
 
 static DEFINE_SPINLOCK(i915_sw_fence_lock);
 
+static DEFINE_MUTEX(i915_sw_fence_mutex);
+static unsigned int i915_sw_fence_usecnt;
+static struct kmem_cache *i915_sw_fence_wq_cache;
+static struct kmem_cache *i915_sw_fence_cb_cache;
+
 static int __i915_sw_fence_notify(struct i915_sw_fence *fence,
  enum i915_sw_fence_notify state)
 {
@@ -138,7 +143,7 @@ static int i915_sw_fence_wake(wait_queue_t *wq, unsigned 
mode, int flags, void *
__i915_sw_fence_complete(wq->private, key);
i915_sw_fence_put(wq->private);
if (wq->flags & I915_SW_FENCE_FLAG_ALLOC)
-   kfree(wq);
+   kmem_cache_free(i915_sw_fence_wq_cache, wq);
return 0;
 }
 
@@ -212,7 +217,7 @@ static int __i915_sw_fence_await_sw_fence(struct 
i915_sw_fence *fence,
 
pending = 0;
if (!wq) {
-   wq = kmalloc(sizeof(*wq), gfp);
+   wq = kmem_cache_alloc(i915_sw_fence_wq_cache, gfp);
if (!wq) {
if (!gfpflags_allow_blocking(gfp))
return -ENOMEM;
@@ -290,7 +295,7 @@ static void dma_i915_sw_fence_wake(struct dma_fence *dma,
i915_sw_fence_commit(cb->fence);
dma_fence_put(cb->dma);
 
-   kfree(cb);
+   kmem_cache_free(i915_sw_fence_cb_cache, cb);
 }
 
 int i915_sw_fence_await_dma_fence(struct i915_sw_fence *fence,
@@ -304,7 +309,7 @@ int i915_sw_fence_await_dma_fence(struct i915_sw_fence 
*fence,
if (dma_fence_is_signaled(dma))
return 0;
 
-   cb = kmalloc(sizeof(*cb), gfp);
+   cb = kmem_cache_alloc(i915_sw_fence_cb_cache, gfp);
if (!cb) {
if (!gfpflags_allow_blocking(gfp))
return -ENOMEM;
@@ -393,3 +398,57 @@ int i915_sw_fence_await_reservation(struct i915_sw_fence 
*fence,
 
return ret;
 }
+
+int i915_init_sw_fences(void)
+{
+   struct kmem_cache *wq_cache, *cb_cache;
+
+   mutex_lock(_sw_fence_mutex);
+
+   if (i915_sw_fence_usecnt == 0) {
+   wq_cache = kmem_cache_create("i915_sw_fence_wq",
+sizeof(wait_queue_t),
+__alignof__(wait_queue_head_t),
+0, NULL);
+   if (!wq_cache)
+   goto err;
+
+   cb_cache = kmem_cache_create("i915_sw_fence_cb",
+sizeof(struct 
i915_sw_dma_fence_cb),
+__alignof__(struct 
i915_sw_dma_fence_cb),
+0, NULL);
+   if (!cb_cache) {
+   kmem_cache_destroy(wq_cache);
+   goto err;
+   }
+
+   i915_sw_fence_wq_cache

Re: [Intel-gfx] [PATCH] drm/i915/sw_fence: Replace private use of wq->flags with bit zero in wq->private

2016-11-02 Thread Chris Wilson 
On Wed, Nov 02, 2016 at 05:00:28PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Use of an un-allocated bit in flags is making me nervous so I
> thought to use the bit zero of the private pointer instead.
> 
> That should be safer against the core kernel changes and safe
> since I can't imagine we can get a fence at the odd address.

I'm not squeamish about using flags ;)

> Signed-off-by: Tvrtko Ursulin 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_sw_fence.c | 24 
>  1 file changed, 16 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c 
> b/drivers/gpu/drm/i915/i915_sw_fence.c
> index 95f2f12e0917..cd4d6b915848 100644
> --- a/drivers/gpu/drm/i915/i915_sw_fence.c
> +++ b/drivers/gpu/drm/i915/i915_sw_fence.c
> @@ -13,7 +13,8 @@
>  
>  #include "i915_sw_fence.h"
>  
> -#define I915_SW_FENCE_FLAG_ALLOC BIT(3) /* after WQ_FLAG_* for safety */
> +#define I915_SW_FENCE_FLAG_ALLOC (1)

BIT(0) before Joonas notices.

> +#define I915_SW_FENCE_PRIVATE_MASK   ~(I915_SW_FENCE_FLAG_ALLOC)
>  
>  static DEFINE_SPINLOCK(i915_sw_fence_lock);
>  
> @@ -132,12 +133,17 @@ void i915_sw_fence_commit(struct i915_sw_fence *fence)
>   i915_sw_fence_put(fence);
>  }
>  
> +#define wq_to_i915_sw_fence(wq) (struct i915_sw_fence *) \
> + ((unsigned long)(wq)->private & I915_SW_FENCE_PRIVATE_MASK)

I quite like:

#define wq_to_i915_sw_fence(wq) ({
unsigned long __v = (unsigned long)(wq)->private;
(struct i915_sw_fence *)(__v & I915_SW_FENCE_PRIVATE_MASK);
)}

or better

static inline struct i915_sw_fence *
wq_to_i915_sw_fence(const wait_queue_t *wq)
{
unsigned long __v = (unsigned long)wq->private;
return (struct i915_sw_fence *)(__v & I915_SW_FENCE_PRIVATE_MASK);
}

static inline bool
wq_is_alloc(const wait_queue_t *wq)
{
unsigned long __v = (unsigned long)wq->private;
return __v & I915_SW_FENCE_FLAG_ALLOC;
}

> +
>  static int i915_sw_fence_wake(wait_queue_t *wq, unsigned mode, int flags, 
> void *key)
>  {
> + struct i915_sw_fence *fence = wq_to_i915_sw_fence(wq);
> +
>   list_del(>task_list);
> - __i915_sw_fence_complete(wq->private, key);
> - i915_sw_fence_put(wq->private);
> - if (wq->flags & I915_SW_FENCE_FLAG_ALLOC)
> + __i915_sw_fence_complete(fence, key);
> + i915_sw_fence_put(fence);
> + if ((unsigned long)wq->private & I915_SW_FENCE_FLAG_ALLOC)
>   kfree(wq);
>   return 0;
>  }
> @@ -157,7 +163,8 @@ static bool __i915_sw_fence_check_if_after(struct 
> i915_sw_fence *fence,
>   if (wq->func != i915_sw_fence_wake)
>   continue;
>  
> - if (__i915_sw_fence_check_if_after(wq->private, signaler))
> + if (__i915_sw_fence_check_if_after(wq_to_i915_sw_fence(wq),
> +signaler))
>   return true;
>   }
>  
> @@ -175,7 +182,7 @@ static void __i915_sw_fence_clear_checked_bit(struct 
> i915_sw_fence *fence)
>   if (wq->func != i915_sw_fence_wake)
>   continue;
>  
> - __i915_sw_fence_clear_checked_bit(wq->private);
> + __i915_sw_fence_clear_checked_bit(wq_to_i915_sw_fence(wq));
>   }
>  }
>  
> @@ -221,13 +228,14 @@ static int __i915_sw_fence_await_sw_fence(struct 
> i915_sw_fence *fence,
>   return 0;
>   }
>  
> - pending |= I915_SW_FENCE_FLAG_ALLOC;
> + pending = I915_SW_FENCE_FLAG_ALLOC;
>   }
>  
>   INIT_LIST_HEAD(>task_list);
> - wq->flags = pending;

We still need to set wq->flags to 0.

It looks ok, but I just don't see the point. wq->flags is private to the
wq->func callback.
-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/sw_fence: Replace private use of wq->flags with bit zero in wq->private

2016-11-02 Thread Tvrtko Ursulin 
From: Tvrtko Ursulin 

Use of an un-allocated bit in flags is making me nervous so I
thought to use the bit zero of the private pointer instead.

That should be safer against the core kernel changes and safe
since I can't imagine we can get a fence at the odd address.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_sw_fence.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c 
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 95f2f12e0917..cd4d6b915848 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -13,7 +13,8 @@
 
 #include "i915_sw_fence.h"
 
-#define I915_SW_FENCE_FLAG_ALLOC BIT(3) /* after WQ_FLAG_* for safety */
+#define I915_SW_FENCE_FLAG_ALLOC   (1)
+#define I915_SW_FENCE_PRIVATE_MASK ~(I915_SW_FENCE_FLAG_ALLOC)
 
 static DEFINE_SPINLOCK(i915_sw_fence_lock);
 
@@ -132,12 +133,17 @@ void i915_sw_fence_commit(struct i915_sw_fence *fence)
i915_sw_fence_put(fence);
 }
 
+#define wq_to_i915_sw_fence(wq) (struct i915_sw_fence *) \
+   ((unsigned long)(wq)->private & I915_SW_FENCE_PRIVATE_MASK)
+
 static int i915_sw_fence_wake(wait_queue_t *wq, unsigned mode, int flags, void 
*key)
 {
+   struct i915_sw_fence *fence = wq_to_i915_sw_fence(wq);
+
list_del(>task_list);
-   __i915_sw_fence_complete(wq->private, key);
-   i915_sw_fence_put(wq->private);
-   if (wq->flags & I915_SW_FENCE_FLAG_ALLOC)
+   __i915_sw_fence_complete(fence, key);
+   i915_sw_fence_put(fence);
+   if ((unsigned long)wq->private & I915_SW_FENCE_FLAG_ALLOC)
kfree(wq);
return 0;
 }
@@ -157,7 +163,8 @@ static bool __i915_sw_fence_check_if_after(struct 
i915_sw_fence *fence,
if (wq->func != i915_sw_fence_wake)
continue;
 
-   if (__i915_sw_fence_check_if_after(wq->private, signaler))
+   if (__i915_sw_fence_check_if_after(wq_to_i915_sw_fence(wq),
+  signaler))
return true;
}
 
@@ -175,7 +182,7 @@ static void __i915_sw_fence_clear_checked_bit(struct 
i915_sw_fence *fence)
if (wq->func != i915_sw_fence_wake)
continue;
 
-   __i915_sw_fence_clear_checked_bit(wq->private);
+   __i915_sw_fence_clear_checked_bit(wq_to_i915_sw_fence(wq));
}
 }
 
@@ -221,13 +228,14 @@ static int __i915_sw_fence_await_sw_fence(struct 
i915_sw_fence *fence,
return 0;
}
 
-   pending |= I915_SW_FENCE_FLAG_ALLOC;
+   pending = I915_SW_FENCE_FLAG_ALLOC;
}
 
INIT_LIST_HEAD(>task_list);
-   wq->flags = pending;
wq->func = i915_sw_fence_wake;
wq->private = i915_sw_fence_get(fence);
+   BUG_ON((unsigned long)wq->private & I915_SW_FENCE_FLAG_ALLOC);
+   wq->private = (void *)((unsigned long)wq->private | pending);
 
i915_sw_fence_await(fence);
 
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Sharma, Shashank 

Regards

Shashank


On 11/2/2016 10:27 PM, Ville Syrjälä wrote:

On Wed, Nov 02, 2016 at 03:16:10PM +0530, Shashank Sharma wrote:

CEA-861-F specs defines new 4k video modes to be used with
HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
way till VIC=107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse 4k modes using the existing techniques, we have
to complete the modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

Signed-off-by: Shashank Sharma 
Signed-off-by: Sonika Jindal 
Reviewed-by: Jose Abreu 
Reviewed-by: Alex Deucher 

Cc: Jose Abreu 
Cc: Alex Deucher 

V2: Addressed review comments from Jose:
- fix the timings for VIC 83, 90 and 91
- fix formatting for VIC 93-107
---
  drivers/gpu/drm/drm_edid.c | 215 +
  1 file changed, 215 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9506933..d18602c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -994,6 +994,221 @@ struct minimode {



+   /* 77 - 1920x1080@100Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 297000, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1094, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },

My script gave me:
{ DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 297000, 1920, 2448,
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
  .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },

Manual reading of the spec agrees with my script.



+   /* 104 - 3840x2160p@25Hz 64:27 */
+   { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000, 3840, 4016,
+   4104, 4400, 0, 2160, 2168, 2178, 2250, 0,
+   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27},

My script gave me:
{ DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000, 3840, 4896,
   4984, 5280, 0, 2160, 2168, 2178, 2250, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
  .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },

Manual reading of the spec agrees with my script.

Outside those two I don't see any errors in your table when compared to my
script's output. I do see some differences in the already existing modes though.
I'll look those over and send a patch if necessary.


Got it, Thanks.
Will cross check, correct and re-send.

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Tidy slab cache allocations (rev2)

2016-11-02 Thread Patchwork 
== Series Details ==

Series: drm/i915: Tidy slab cache allocations (rev2)
URL   : https://patchwork.freedesktop.org/series/14731/
State : warning

== Summary ==

Series 14731v2 drm/i915: Tidy slab cache allocations
https://patchwork.freedesktop.org/api/1.0/series/14731/revisions/2/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-skl-6770hq)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:187  dwarn:0   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:226  dwarn:1   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

bf6b989af8b0fde56a352d9005c97b2d8e3bbbe3 drm-intel-nightly: 
2016y-11m-02d-15h-44m-03s UTC integration manifest
eb3aa67 drm/i915: Tidy slab cache allocations

== Logs ==

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

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Ville Syrjälä 
On Wed, Nov 02, 2016 at 03:16:10PM +0530, Shashank Sharma wrote:
> CEA-861-F specs defines new 4k video modes to be used with
> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
> way till VIC=107.
> 
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to parse 4k modes using the existing techniques, we have
> to complete the modedb (VIC=65 onwards).
> 
> This patch adds:
> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> - Newly added 4k modes (from VIC=93 to VIC=107).
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Sonika Jindal 
> Reviewed-by: Jose Abreu 
> Reviewed-by: Alex Deucher 
> 
> Cc: Jose Abreu 
> Cc: Alex Deucher 
> 
> V2: Addressed review comments from Jose:
>   - fix the timings for VIC 83, 90 and 91
>   - fix formatting for VIC 93-107
> ---
>  drivers/gpu/drm/drm_edid.c | 215 
> +
>  1 file changed, 215 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9506933..d18602c 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -994,6 +994,221 @@ struct minimode {

> + /* 77 - 1920x1080@100Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 297000, 1920, 2448,
> +2492, 2640, 0, 1080, 1084, 1094, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +  .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },

My script gave me:
   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 297000, 1920, 2448,
  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },

Manual reading of the spec agrees with my script.


> + /* 104 - 3840x2160p@25Hz 64:27 */
> + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000, 3840, 4016,
> + 4104, 4400, 0, 2160, 2168, 2178, 2250, 0,
> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27},

My script gave me:
   { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000, 3840, 4896,
  4984, 5280, 0, 2160, 2168, 2178, 2250, 0,
  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },

Manual reading of the spec agrees with my script.

Outside those two I don't see any errors in your table when compared to my
script's output. I do see some differences in the already existing modes though.
I'll look those over and send a patch if necessary.

-- 
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 v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Sharma, Shashank 

Regards

Shashank


On 11/2/2016 10:04 PM, Ville Syrjälä wrote:

On Wed, Nov 02, 2016 at 03:16:10PM +0530, Shashank Sharma wrote:

CEA-861-F specs defines new 4k video modes to be used with
HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
way till VIC=107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse 4k modes using the existing techniques, we have
to complete the modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

Signed-off-by: Shashank Sharma 
Signed-off-by: Sonika Jindal 
Reviewed-by: Jose Abreu 
Reviewed-by: Alex Deucher 

Cc: Jose Abreu 
Cc: Alex Deucher 

V2: Addressed review comments from Jose:
- fix the timings for VIC 83, 90 and 91
- fix formatting for VIC 93-107
---
  drivers/gpu/drm/drm_edid.c | 215 +
  1 file changed, 215 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9506933..d18602c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -994,6 +994,221 @@ struct minimode {
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720@24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720@25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720@30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 - 1280x720@50Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 69 - 1280x720@60Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 70 - 1280x720@100Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 71 - 1280x720@120Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 72 - 1920x1080@24Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
+  2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 73 - 1920x1080@25Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 74 - 1920x1080@30Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 75 - 1920x1080@50Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 76 - 1920x1080@60Hz */
+

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Ville Syrjälä 
On Wed, Nov 02, 2016 at 09:57:12PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/2/2016 9:50 PM, Ville Syrjälä wrote:
> > On Wed, Nov 02, 2016 at 09:39:48PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 11/2/2016 9:32 PM, Ville Syrjälä wrote:
> >>> On Wed, Nov 02, 2016 at 08:14:22PM +0530, Sharma, Shashank wrote:
>  Regards
> 
>  Shashank
> 
> 
>  On 11/2/2016 7:58 PM, Andrzej Hajda wrote:
> > On 02.11.2016 10:46, Shashank Sharma wrote:
> >> CEA-861-F specs defines new 4k video modes to be used with
> >> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
> >> way till VIC=107.
> >>
> >> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> >> to be able to parse 4k modes using the existing techniques, we have
> >> to complete the modedb (VIC=65 onwards).
> >>
> >> This patch adds:
> >> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> >> - Newly added 4k modes (from VIC=93 to VIC=107).
> > As I understand it modifies edid_cea_modes array. This array
> > is used by couple of functions, particularly by drm_match_cea_mode,
> > which is used by drm_hdmi_avi_infoframe_from_display_mode.
> > I.e. since this patch AVI infoframes generated using drm core code will
> > be different - they can contain VIC codes unknown to TV.
> > I am not sure if it is harmful, but for sure this patch has visible
> > impact on drivers behavior.
> >
> > Maybe it would be good to allow drivers to keep full compatibility with
> > HDMI 1.4?
>  Hello Andrzej,
>  Thanks for the comment.
>  If you watch the code flow carefully, this is driven by EDID. So any
>  VIC, which is translated/transformed using this array, would be coming
>  from the EDID itself.
> >>> No. The user is free to specify any mode they wish. It doesn't have to
> >>> come from the EDID. Not sure specifying a modern VIC for an older
> >>> display is a good idea or not. If not, we could always check the cea_rev
> >>> assuming it changed whenever the list if VICs was expanded.
> >> I agree, that user can specify a mode, out of EDID too.
> >> I am anyways planning to add a patch, where before loading HDMI 2.0 VICs
> >> in AVI IF, we are checking the EDID rev.
> >> That should solve our problem.
> >>
> >> So if edid_rev < 2.0
> >>   do_not_load VICs from 93 - 107, but keep it 0.
> > Why edid_rev and not cea_rev?
> We can do that also, but in the current structure, we are already 
> caching EDID rev, its just about re-using it.
> AFAIK, we don't have CEA extension cached anywhere.

Yes we do.

> 
> Shashank
> >> Shashank
>  So I dont think there would be a problem if the mode is defined in the
>  EDID section itself, coz we are expecting the TV to know what its
>  mentioning in EDID.
> 
>  This is how a typical flow would look:
>  - hot-plug
>  - driver reads modes specified in EDID basic.
>  - driver parses various CEA extension blocks.
> - For both of the above mentioned steps, driver will probe the
>  functions like do_cea_modes which uses edid_cea_modes[] array.
>  - driver will add the probed modes in EDID, into connector
>  - driver will pass the connector to userspace
>  - userspace will pick one of the probed modes for modeset.
>  - during modeset, we will set VIC part for a CEA mode, in the AVI
>  infoframe section.
> 
>  So in other words, the only source of a VIC (cea_mode) is from TV's own
>  EDID.
>  This means we should never run into an unknown VIC. There can be a 0 VIC
>  (for non CEA modes), but not unknown one.
> 
>  Regards
>  Shashank
> > Regards
> > Andrzej
> >
> >
> >> Signed-off-by: Shashank Sharma 
> >> Signed-off-by: Sonika Jindal 
> >> Reviewed-by: Jose Abreu 
> >> Reviewed-by: Alex Deucher 
> >>
> >> Cc: Jose Abreu 
> >> Cc: Alex Deucher 
> >>
> >> V2: Addressed review comments from Jose:
> >>- fix the timings for VIC 83, 90 and 91
> >>- fix formatting for VIC 93-107
> >> ---
> >> drivers/gpu/drm/drm_edid.c | 215 
> >> +
> >> 1 file changed, 215 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 9506933..d18602c 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -994,6 +994,221 @@ struct minimode {
> >>   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> >>   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> .vrefresh = 100, .picture_aspect_ratio = 
> >>

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Ville Syrjälä 
On Wed, Nov 02, 2016 at 03:16:10PM +0530, Shashank Sharma wrote:
> CEA-861-F specs defines new 4k video modes to be used with
> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
> way till VIC=107.
> 
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to parse 4k modes using the existing techniques, we have
> to complete the modedb (VIC=65 onwards).
> 
> This patch adds:
> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> - Newly added 4k modes (from VIC=93 to VIC=107).
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Sonika Jindal 
> Reviewed-by: Jose Abreu 
> Reviewed-by: Alex Deucher 
> 
> Cc: Jose Abreu 
> Cc: Alex Deucher 
> 
> V2: Addressed review comments from Jose:
>   - fix the timings for VIC 83, 90 and 91
>   - fix formatting for VIC 93-107
> ---
>  drivers/gpu/drm/drm_edid.c | 215 
> +
>  1 file changed, 215 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9506933..d18602c 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -994,6 +994,221 @@ struct minimode {
>  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 65 - 1280x720@24Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 66 - 1280x720@25Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
> +3740, 3960, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 67 - 1280x720@30Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 68 - 1280x720@50Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 69 - 1280x720@60Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 70 - 1280x720@100Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 71 - 1280x720@120Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 72 - 1920x1080@24Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
> +2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 73 - 1920x1080@25Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
> +2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 74 - 1920x1080@30Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
> +2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 75 - 1920x1080@50Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
> +2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 76 - 1920x1080@60Hz */
> + {

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Deucher, Alexander 
> -Original Message-
> From: Shashank Sharma [mailto:shashank.sha...@intel.com]
> Sent: Wednesday, November 02, 2016 5:46 AM
> To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Cc: airl...@redhat.com; daniel.vet...@intel.com;
> jose.ab...@synopsys.com; Shashank Sharma; Deucher, Alexander
> Subject: [PATCH v2] drm: Complete CEA modedb(VIC 1-107)
> 
> CEA-861-F specs defines new 4k video modes to be used with
> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
> way till VIC=107.
> 
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to parse 4k modes using the existing techniques, we have
> to complete the modedb (VIC=65 onwards).
> 
> This patch adds:
> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> - Newly added 4k modes (from VIC=93 to VIC=107).

I don't have the spec in front of me to double check the timings, but assuming 
the previous typos were addressed, the patch is:
Reviewed-by: Alex Deucher 

> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Sonika Jindal 
> Reviewed-by: Jose Abreu 
> Reviewed-by: Alex Deucher 
> 
> Cc: Jose Abreu 
> Cc: Alex Deucher 
> 
> V2: Addressed review comments from Jose:
>   - fix the timings for VIC 83, 90 and 91
>   - fix formatting for VIC 93-107
> ---
>  drivers/gpu/drm/drm_edid.c | 215
> +
>  1 file changed, 215 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9506933..d18602c 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -994,6 +994,221 @@ struct minimode {
>  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>  DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
>.vrefresh = 100, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_16_9, },
> + /* 65 - 1280x720@24Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280,
> 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 66 - 1280x720@25Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280,
> 3700,
> +3740, 3960, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 67 - 1280x720@30Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280,
> 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 30, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 68 - 1280x720@50Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280,
> 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 50, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 69 - 1280x720@60Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280,
> 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 60, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 70 - 1280x720@100Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280,
> 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 100, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 71 - 1280x720@120Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280,
> 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 120, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 72 - 1920x1080@24Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920,
> 2558,
> +2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 73 - 1920x1080@25Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920,
> 2448,
> +2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 74 - 1920x1080@30Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920,
> 2008,
> +

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Sharma, Shashank 

Regards

Shashank


On 11/2/2016 9:50 PM, Ville Syrjälä wrote:

On Wed, Nov 02, 2016 at 09:39:48PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 11/2/2016 9:32 PM, Ville Syrjälä wrote:

On Wed, Nov 02, 2016 at 08:14:22PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 11/2/2016 7:58 PM, Andrzej Hajda wrote:

On 02.11.2016 10:46, Shashank Sharma wrote:

CEA-861-F specs defines new 4k video modes to be used with
HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
way till VIC=107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse 4k modes using the existing techniques, we have
to complete the modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

As I understand it modifies edid_cea_modes array. This array
is used by couple of functions, particularly by drm_match_cea_mode,
which is used by drm_hdmi_avi_infoframe_from_display_mode.
I.e. since this patch AVI infoframes generated using drm core code will
be different - they can contain VIC codes unknown to TV.
I am not sure if it is harmful, but for sure this patch has visible
impact on drivers behavior.

Maybe it would be good to allow drivers to keep full compatibility with
HDMI 1.4?

Hello Andrzej,
Thanks for the comment.
If you watch the code flow carefully, this is driven by EDID. So any
VIC, which is translated/transformed using this array, would be coming
from the EDID itself.

No. The user is free to specify any mode they wish. It doesn't have to
come from the EDID. Not sure specifying a modern VIC for an older
display is a good idea or not. If not, we could always check the cea_rev
assuming it changed whenever the list if VICs was expanded.

I agree, that user can specify a mode, out of EDID too.
I am anyways planning to add a patch, where before loading HDMI 2.0 VICs
in AVI IF, we are checking the EDID rev.
That should solve our problem.

So if edid_rev < 2.0
  do_not_load VICs from 93 - 107, but keep it 0.

Why edid_rev and not cea_rev?
We can do that also, but in the current structure, we are already 
caching EDID rev, its just about re-using it.

AFAIK, we don't have CEA extension cached anywhere.

Shashank

Shashank

So I dont think there would be a problem if the mode is defined in the
EDID section itself, coz we are expecting the TV to know what its
mentioning in EDID.

This is how a typical flow would look:
- hot-plug
- driver reads modes specified in EDID basic.
- driver parses various CEA extension blocks.
   - For both of the above mentioned steps, driver will probe the
functions like do_cea_modes which uses edid_cea_modes[] array.
- driver will add the probed modes in EDID, into connector
- driver will pass the connector to userspace
- userspace will pick one of the probed modes for modeset.
- during modeset, we will set VIC part for a CEA mode, in the AVI
infoframe section.

So in other words, the only source of a VIC (cea_mode) is from TV's own
EDID.
This means we should never run into an unknown VIC. There can be a 0 VIC
(for non CEA modes), but not unknown one.

Regards
Shashank

Regards
Andrzej



Signed-off-by: Shashank Sharma 
Signed-off-by: Sonika Jindal 
Reviewed-by: Jose Abreu 
Reviewed-by: Alex Deucher 

Cc: Jose Abreu 
Cc: Alex Deucher 

V2: Addressed review comments from Jose:
- fix the timings for VIC 83, 90 and 91
- fix formatting for VIC 93-107
---
drivers/gpu/drm/drm_edid.c | 215 
+
1 file changed, 215 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9506933..d18602c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -994,6 +994,221 @@ struct minimode {
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720@24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720@25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720@30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC |

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Ville Syrjälä 
On Wed, Nov 02, 2016 at 09:39:48PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/2/2016 9:32 PM, Ville Syrjälä wrote:
> > On Wed, Nov 02, 2016 at 08:14:22PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 11/2/2016 7:58 PM, Andrzej Hajda wrote:
> >>> On 02.11.2016 10:46, Shashank Sharma wrote:
>  CEA-861-F specs defines new 4k video modes to be used with
>  HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
>  way till VIC=107.
> 
>  Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
>  to be able to parse 4k modes using the existing techniques, we have
>  to complete the modedb (VIC=65 onwards).
> 
>  This patch adds:
>  - Timings for existing CEA video modes (from VIC=65 till VIC=92)
>  - Newly added 4k modes (from VIC=93 to VIC=107).
> >>> As I understand it modifies edid_cea_modes array. This array
> >>> is used by couple of functions, particularly by drm_match_cea_mode,
> >>> which is used by drm_hdmi_avi_infoframe_from_display_mode.
> >>> I.e. since this patch AVI infoframes generated using drm core code will
> >>> be different - they can contain VIC codes unknown to TV.
> >>> I am not sure if it is harmful, but for sure this patch has visible
> >>> impact on drivers behavior.
> >>>
> >>> Maybe it would be good to allow drivers to keep full compatibility with
> >>> HDMI 1.4?
> >> Hello Andrzej,
> >> Thanks for the comment.
> >> If you watch the code flow carefully, this is driven by EDID. So any
> >> VIC, which is translated/transformed using this array, would be coming
> >> from the EDID itself.
> > No. The user is free to specify any mode they wish. It doesn't have to
> > come from the EDID. Not sure specifying a modern VIC for an older
> > display is a good idea or not. If not, we could always check the cea_rev
> > assuming it changed whenever the list if VICs was expanded.
> I agree, that user can specify a mode, out of EDID too.
> I am anyways planning to add a patch, where before loading HDMI 2.0 VICs 
> in AVI IF, we are checking the EDID rev.
> That should solve our problem.
> 
> So if edid_rev < 2.0
>  do_not_load VICs from 93 - 107, but keep it 0.

Why edid_rev and not cea_rev?

> 
> Shashank
> >> So I dont think there would be a problem if the mode is defined in the
> >> EDID section itself, coz we are expecting the TV to know what its
> >> mentioning in EDID.
> >>
> >> This is how a typical flow would look:
> >> - hot-plug
> >> - driver reads modes specified in EDID basic.
> >> - driver parses various CEA extension blocks.
> >>   - For both of the above mentioned steps, driver will probe the
> >> functions like do_cea_modes which uses edid_cea_modes[] array.
> >> - driver will add the probed modes in EDID, into connector
> >> - driver will pass the connector to userspace
> >> - userspace will pick one of the probed modes for modeset.
> >> - during modeset, we will set VIC part for a CEA mode, in the AVI
> >> infoframe section.
> >>
> >> So in other words, the only source of a VIC (cea_mode) is from TV's own
> >> EDID.
> >> This means we should never run into an unknown VIC. There can be a 0 VIC
> >> (for non CEA modes), but not unknown one.
> >>
> >> Regards
> >> Shashank
> >>> Regards
> >>> Andrzej
> >>>
> >>>
>  Signed-off-by: Shashank Sharma 
>  Signed-off-by: Sonika Jindal 
>  Reviewed-by: Jose Abreu 
>  Reviewed-by: Alex Deucher 
> 
>  Cc: Jose Abreu 
>  Cc: Alex Deucher 
> 
>  V2: Addressed review comments from Jose:
>   - fix the timings for VIC 83, 90 and 91
>   - fix formatting for VIC 93-107
>  ---
> drivers/gpu/drm/drm_edid.c | 215 
>  +
> 1 file changed, 215 insertions(+)
> 
>  diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>  index 9506933..d18602c 100644
>  --- a/drivers/gpu/drm/drm_edid.c
>  +++ b/drivers/gpu/drm/drm_edid.c
>  @@ -994,6 +994,221 @@ struct minimode {
>  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>    .vrefresh = 100, .picture_aspect_ratio = 
>  HDMI_PICTURE_ASPECT_16_9, },
>  +/* 65 - 1280x720@24Hz */
>  +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
>  +   3080, 3300, 0, 720, 725, 730, 750, 0,
>  +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>  +  .vrefresh = 24, .picture_aspect_ratio = 
>  HDMI_PICTURE_ASPECT_64_27, },
>  +/* 66 - 1280x720@25Hz */
>  +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
>  +   3740, 3960, 0, 720, 725, 730, 750, 0,
>

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Sharma, Shashank 

Regards

Shashank


On 11/2/2016 9:32 PM, Ville Syrjälä wrote:

On Wed, Nov 02, 2016 at 08:14:22PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 11/2/2016 7:58 PM, Andrzej Hajda wrote:

On 02.11.2016 10:46, Shashank Sharma wrote:

CEA-861-F specs defines new 4k video modes to be used with
HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
way till VIC=107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse 4k modes using the existing techniques, we have
to complete the modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

As I understand it modifies edid_cea_modes array. This array
is used by couple of functions, particularly by drm_match_cea_mode,
which is used by drm_hdmi_avi_infoframe_from_display_mode.
I.e. since this patch AVI infoframes generated using drm core code will
be different - they can contain VIC codes unknown to TV.
I am not sure if it is harmful, but for sure this patch has visible
impact on drivers behavior.

Maybe it would be good to allow drivers to keep full compatibility with
HDMI 1.4?

Hello Andrzej,
Thanks for the comment.
If you watch the code flow carefully, this is driven by EDID. So any
VIC, which is translated/transformed using this array, would be coming
from the EDID itself.

No. The user is free to specify any mode they wish. It doesn't have to
come from the EDID. Not sure specifying a modern VIC for an older
display is a good idea or not. If not, we could always check the cea_rev
assuming it changed whenever the list if VICs was expanded.

I agree, that user can specify a mode, out of EDID too.
I am anyways planning to add a patch, where before loading HDMI 2.0 VICs 
in AVI IF, we are checking the EDID rev.

That should solve our problem.

So if edid_rev < 2.0
do_not_load VICs from 93 - 107, but keep it 0.

Shashank

So I dont think there would be a problem if the mode is defined in the
EDID section itself, coz we are expecting the TV to know what its
mentioning in EDID.

This is how a typical flow would look:
- hot-plug
- driver reads modes specified in EDID basic.
- driver parses various CEA extension blocks.
  - For both of the above mentioned steps, driver will probe the
functions like do_cea_modes which uses edid_cea_modes[] array.
- driver will add the probed modes in EDID, into connector
- driver will pass the connector to userspace
- userspace will pick one of the probed modes for modeset.
- during modeset, we will set VIC part for a CEA mode, in the AVI
infoframe section.

So in other words, the only source of a VIC (cea_mode) is from TV's own
EDID.
This means we should never run into an unknown VIC. There can be a 0 VIC
(for non CEA modes), but not unknown one.

Regards
Shashank

Regards
Andrzej



Signed-off-by: Shashank Sharma 
Signed-off-by: Sonika Jindal 
Reviewed-by: Jose Abreu 
Reviewed-by: Alex Deucher 

Cc: Jose Abreu 
Cc: Alex Deucher 

V2: Addressed review comments from Jose:
- fix the timings for VIC 83, 90 and 91
- fix formatting for VIC 93-107
---
   drivers/gpu/drm/drm_edid.c | 215 
+
   1 file changed, 215 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9506933..d18602c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -994,6 +994,221 @@ struct minimode {
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720@24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720@25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720@30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 - 1280x720@50Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Ville Syrjälä 
On Wed, Nov 02, 2016 at 08:14:22PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/2/2016 7:58 PM, Andrzej Hajda wrote:
> > On 02.11.2016 10:46, Shashank Sharma wrote:
> >> CEA-861-F specs defines new 4k video modes to be used with
> >> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
> >> way till VIC=107.
> >>
> >> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> >> to be able to parse 4k modes using the existing techniques, we have
> >> to complete the modedb (VIC=65 onwards).
> >>
> >> This patch adds:
> >> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> >> - Newly added 4k modes (from VIC=93 to VIC=107).
> > As I understand it modifies edid_cea_modes array. This array
> > is used by couple of functions, particularly by drm_match_cea_mode,
> > which is used by drm_hdmi_avi_infoframe_from_display_mode.
> > I.e. since this patch AVI infoframes generated using drm core code will
> > be different - they can contain VIC codes unknown to TV.
> > I am not sure if it is harmful, but for sure this patch has visible
> > impact on drivers behavior.
> >
> > Maybe it would be good to allow drivers to keep full compatibility with
> > HDMI 1.4?
> Hello Andrzej,
> Thanks for the comment.
> If you watch the code flow carefully, this is driven by EDID. So any 
> VIC, which is translated/transformed using this array, would be coming 
> from the EDID itself.

No. The user is free to specify any mode they wish. It doesn't have to
come from the EDID. Not sure specifying a modern VIC for an older
display is a good idea or not. If not, we could always check the cea_rev
assuming it changed whenever the list if VICs was expanded.

> So I dont think there would be a problem if the mode is defined in the 
> EDID section itself, coz we are expecting the TV to know what its 
> mentioning in EDID.
> 
> This is how a typical flow would look:
> - hot-plug
> - driver reads modes specified in EDID basic.
> - driver parses various CEA extension blocks.
>  - For both of the above mentioned steps, driver will probe the 
> functions like do_cea_modes which uses edid_cea_modes[] array.
> - driver will add the probed modes in EDID, into connector
> - driver will pass the connector to userspace
> - userspace will pick one of the probed modes for modeset.
> - during modeset, we will set VIC part for a CEA mode, in the AVI 
> infoframe section.
> 
> So in other words, the only source of a VIC (cea_mode) is from TV's own 
> EDID.
> This means we should never run into an unknown VIC. There can be a 0 VIC 
> (for non CEA modes), but not unknown one.
> 
> Regards
> Shashank
> > Regards
> > Andrzej
> >
> >
> >> Signed-off-by: Shashank Sharma 
> >> Signed-off-by: Sonika Jindal 
> >> Reviewed-by: Jose Abreu 
> >> Reviewed-by: Alex Deucher 
> >>
> >> Cc: Jose Abreu 
> >> Cc: Alex Deucher 
> >>
> >> V2: Addressed review comments from Jose:
> >>- fix the timings for VIC 83, 90 and 91
> >>- fix formatting for VIC 93-107
> >> ---
> >>   drivers/gpu/drm/drm_edid.c | 215 
> >> +
> >>   1 file changed, 215 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 9506933..d18602c 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -994,6 +994,221 @@ struct minimode {
> >>   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> >>   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> >> +  /* 65 - 1280x720@24Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
> >> + 3080, 3300, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 66 - 1280x720@25Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
> >> + 3740, 3960, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 67 - 1280x720@30Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
> >> + 3080, 3300, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 68 - 1280x720@50Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
> >> + 1760, 1980, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 69 -

Re: [Intel-gfx] [RFC PATCH] drm: define drm_compat_ioctl NULL on CONFIG_COMPAT=n and reduce #ifdefs

2016-11-02 Thread Sean Paul 
On Wed, Nov 2, 2016 at 2:03 AM, Patrik Jakobsson
 wrote:
> On Tue, Nov 1, 2016 at 4:40 PM, Jani Nikula  wrote:
>> If we define drm_compat_ioctl NULL on CONFIG_COMPAT=n, we don't have to
>> check for the config everywhere.
>>
>> Signed-off-by: Jani Nikula 
>
> Looks good and I like the idea.
>
> Reviewed-by: Patrik Jakobsson 
>


Applied to drm-misc, thanks

Sean

>> ---
>>
>> Just an idea on top of Patrik's patch.
>> ---
>>  drivers/gpu/drm/arc/arcpgu_drv.c|  2 --
>>  drivers/gpu/drm/arm/hdlcd_drv.c |  2 --
>>  drivers/gpu/drm/arm/malidp_drv.c|  2 --
>>  drivers/gpu/drm/ast/ast_drv.c   |  2 --
>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c|  2 --
>>  drivers/gpu/drm/bochs/bochs_drv.c   |  2 --
>>  drivers/gpu/drm/cirrus/cirrus_drv.c |  2 --
>>  drivers/gpu/drm/drm_fops.c  | 13 ++---
>>  drivers/gpu/drm/etnaviv/etnaviv_drv.c   |  2 --
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c |  2 --
>>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c   |  2 --
>>  drivers/gpu/drm/gma500/psb_drv.c|  2 --
>>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  2 --
>>  drivers/gpu/drm/i810/i810_dma.c |  2 --
>>  drivers/gpu/drm/i810/i810_drv.c |  2 --
>>  drivers/gpu/drm/i915/i915_drv.c |  2 --
>>  drivers/gpu/drm/i915/i915_drv.h |  2 ++
>>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  2 --
>>  drivers/gpu/drm/mgag200/mgag200_drv.c   |  2 --
>>  drivers/gpu/drm/msm/msm_drv.c   |  2 --
>>  drivers/gpu/drm/rcar-du/rcar_du_drv.c   |  2 --
>>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |  2 --
>>  drivers/gpu/drm/savage/savage_drv.c |  2 --
>>  drivers/gpu/drm/shmobile/shmob_drm_drv.c|  2 --
>>  drivers/gpu/drm/sis/sis_drv.c   |  2 --
>>  drivers/gpu/drm/sti/sti_drv.c   |  2 --
>>  drivers/gpu/drm/sun4i/sun4i_drv.c   |  2 --
>>  drivers/gpu/drm/tdfx/tdfx_drv.c |  2 --
>>  drivers/gpu/drm/tegra/drm.c |  2 --
>>  drivers/gpu/drm/tilcdc/tilcdc_drv.c |  2 --
>>  drivers/gpu/drm/udl/udl_drv.c   |  2 --
>>  drivers/gpu/drm/vc4/vc4_drv.c   |  2 --
>>  drivers/gpu/drm/via/via_drv.c   |  2 --
>>  drivers/gpu/drm/virtio/virtgpu_drv.c|  2 --
>>  include/drm/drmP.h  |  5 +
>>  35 files changed, 13 insertions(+), 71 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c 
>> b/drivers/gpu/drm/arc/arcpgu_drv.c
>> index 28e6471257d0..0b6eaa49a1db 100644
>> --- a/drivers/gpu/drm/arc/arcpgu_drv.c
>> +++ b/drivers/gpu/drm/arc/arcpgu_drv.c
>> @@ -65,9 +65,7 @@ static const struct file_operations arcpgu_drm_ops = {
>> .open = drm_open,
>> .release = drm_release,
>> .unlocked_ioctl = drm_ioctl,
>> -#ifdef CONFIG_COMPAT
>> .compat_ioctl = drm_compat_ioctl,
>> -#endif
>> .poll = drm_poll,
>> .read = drm_read,
>> .llseek = no_llseek,
>> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c 
>> b/drivers/gpu/drm/arm/hdlcd_drv.c
>> index 6477d1a65266..59747ecaad54 100644
>> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
>> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
>> @@ -268,9 +268,7 @@ static const struct file_operations fops = {
>> .open   = drm_open,
>> .release= drm_release,
>> .unlocked_ioctl = drm_ioctl,
>> -#ifdef CONFIG_COMPAT
>> .compat_ioctl   = drm_compat_ioctl,
>> -#endif
>> .poll   = drm_poll,
>> .read   = drm_read,
>> .llseek = noop_llseek,
>> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
>> b/drivers/gpu/drm/arm/malidp_drv.c
>> index 9f4739452a25..d53b625b14fe 100644
>> --- a/drivers/gpu/drm/arm/malidp_drv.c
>> +++ b/drivers/gpu/drm/arm/malidp_drv.c
>> @@ -197,9 +197,7 @@ static const struct file_operations fops = {
>> .open = drm_open,
>> .release = drm_release,
>> .unlocked_ioctl = drm_ioctl,
>> -#ifdef CONFIG_COMPAT
>> .compat_ioctl = drm_compat_ioctl,
>> -#endif
>> .poll = drm_poll,
>> .read = drm_read,
>> .llseek = noop_llseek,
>> diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
>> index f54afd2113a9..fd7c9eec92e4 100644
>> --- a/drivers/gpu/drm/ast/ast_drv.c
>> +++ b/drivers/gpu/drm/ast/ast_drv.c
>> @@ -188,9 +188,7 @@ static const struct file_operations ast_fops = {
>> .unlocked_ioctl = drm_ioctl,
>> .mmap = ast_mmap,
>> .poll = drm_poll,
>> -#ifdef CONFIG_COMPAT
>> .compat_ioctl = drm_compat_ioctl,
>> -#endif
>> .read = drm_read,
>>  };
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
>>

Re: [Intel-gfx] [PATCH v2] drm/i915: Tidy slab cache allocations

2016-11-02 Thread Joonas Lahtinen 
On ke, 2016-11-02 at 15:14 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> We can use the preferred KMEM_CACHE helper for brevity.
> 
> Also simplifiy error unwind by only setting the ENOMEM
> error code once.
> 
> v2: Add forgotten changes. (Joonas Lahtinen)
> 
> Signed-off-by: Tvrtko Ursulin 
> Reviewed-by: Joonas Lahtinen  (v1)

Reviewed-by: Joonas Lahtinen 

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

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Sharma, Shashank 

Regards

Shashank


On 11/2/2016 8:44 PM, Andrzej Hajda wrote:

On 02.11.2016 15:44, Sharma, Shashank wrote:

Regards

Shashank


On 11/2/2016 7:58 PM, Andrzej Hajda wrote:

On 02.11.2016 10:46, Shashank Sharma wrote:

CEA-861-F specs defines new 4k video modes to be used with
HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
way till VIC=107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse 4k modes using the existing techniques, we have
to complete the modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

As I understand it modifies edid_cea_modes array. This array
is used by couple of functions, particularly by drm_match_cea_mode,
which is used by drm_hdmi_avi_infoframe_from_display_mode.
I.e. since this patch AVI infoframes generated using drm core code will
be different - they can contain VIC codes unknown to TV.
I am not sure if it is harmful, but for sure this patch has visible
impact on drivers behavior.

Maybe it would be good to allow drivers to keep full compatibility with
HDMI 1.4?

Hello Andrzej,
Thanks for the comment.
If you watch the code flow carefully, this is driven by EDID. So any
VIC, which is translated/transformed using this array, would be coming
from the EDID itself.
So I dont think there would be a problem if the mode is defined in the
EDID section itself, coz we are expecting the TV to know what its
mentioning in EDID.

This is how a typical flow would look:
- hot-plug
- driver reads modes specified in EDID basic.
- driver parses various CEA extension blocks.
  - For both of the above mentioned steps, driver will probe the
functions like do_cea_modes which uses edid_cea_modes[] array.
- driver will add the probed modes in EDID, into connector
- driver will pass the connector to userspace
- userspace will pick one of the probed modes for modeset.
- during modeset, we will set VIC part for a CEA mode, in the AVI
infoframe section.

So in other words, the only source of a VIC (cea_mode) is from TV's own
EDID.
This means we should never run into an unknown VIC. There can be a 0 VIC
(for non CEA modes), but not unknown one.

For example 3840x2160@30Hz has no VIC in HDMI 1.4 but it can
be present in HDMI vendor specific block with HDMI_VIC 1, on the
other side it has VIC 95 in HDMI 2.0. So before your patch
AVI infoframe.video_code is set to 0, after your patch is set to 95.
I agree, this particular case is true only for 4k@30 mode can be present 
in vendor specific blocks.
But as per HDMI compliance test cases, if all the timings match to the 
mode specified, the VIC should

be 95.
I was going through the HDMI 1.4 spec, and CEA-861-D/E specs with these 
corner cases, and we saw that its ok

to specify the right VIC, as per the CEA specs.

Do you also think this is the right thing to do ?
I have another patch coming up, where we can check the EDID version 
before setting VIC in AVI IF.


- Shashank


Regards
Andrzej



Regards
Shashank

Regards
Andrzej



Signed-off-by: Shashank Sharma 
Signed-off-by: Sonika Jindal 
Reviewed-by: Jose Abreu 
Reviewed-by: Alex Deucher 

Cc: Jose Abreu 
Cc: Alex Deucher 

V2: Addressed review comments from Jose:
- fix the timings for VIC 83, 90 and 91
- fix formatting for VIC 93-107
---
   drivers/gpu/drm/drm_edid.c | 215 
+
   1 file changed, 215 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9506933..d18602c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -994,6 +994,221 @@ struct minimode {
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720@24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720@25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720@30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 -

[Intel-gfx] [PATCH v2] drm/i915: Tidy slab cache allocations

2016-11-02 Thread Tvrtko Ursulin 
From: Tvrtko Ursulin 

We can use the preferred KMEM_CACHE helper for brevity.

Also simplifiy error unwind by only setting the ENOMEM
error code once.

v2: Add forgotten changes. (Joonas Lahtinen)

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Joonas Lahtinen  (v1)
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 37 ++---
 1 file changed, 10 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5839bebba64a..1f995ced524e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4714,39 +4714,22 @@ int
 i915_gem_load_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
-   int err;
+   int err = -ENOMEM;
 
-   dev_priv->objects =
-   kmem_cache_create("i915_gem_object",
- sizeof(struct drm_i915_gem_object), 0,
- SLAB_HWCACHE_ALIGN,
- NULL);
-   if (!dev_priv->objects) {
-   err = -ENOMEM;
+   dev_priv->objects = KMEM_CACHE(drm_i915_gem_object, SLAB_HWCACHE_ALIGN);
+   if (!dev_priv->objects)
goto err_out;
-   }
 
-   dev_priv->vmas =
-   kmem_cache_create("i915_gem_vma",
- sizeof(struct i915_vma), 0,
- SLAB_HWCACHE_ALIGN,
- NULL);
-   if (!dev_priv->vmas) {
-   err = -ENOMEM;
+   dev_priv->vmas = KMEM_CACHE(i915_vma, SLAB_HWCACHE_ALIGN);
+   if (!dev_priv->vmas)
goto err_objects;
-   }
 
-   dev_priv->requests =
-   kmem_cache_create("i915_gem_request",
- sizeof(struct drm_i915_gem_request), 0,
- SLAB_HWCACHE_ALIGN |
- SLAB_RECLAIM_ACCOUNT |
- SLAB_DESTROY_BY_RCU,
- NULL);
-   if (!dev_priv->requests) {
-   err = -ENOMEM;
+   dev_priv->requests = KMEM_CACHE(drm_i915_gem_request,
+   SLAB_HWCACHE_ALIGN |
+   SLAB_RECLAIM_ACCOUNT |
+   SLAB_DESTROY_BY_RCU);
+   if (!dev_priv->requests)
goto err_vmas;
-   }
 
mutex_lock(_priv->drm.struct_mutex);
INIT_LIST_HEAD(_priv->gt.timelines);
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Andrzej Hajda 
On 02.11.2016 15:44, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 11/2/2016 7:58 PM, Andrzej Hajda wrote:
>> On 02.11.2016 10:46, Shashank Sharma wrote:
>>> CEA-861-F specs defines new 4k video modes to be used with
>>> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
>>> way till VIC=107.
>>>
>>> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
>>> to be able to parse 4k modes using the existing techniques, we have
>>> to complete the modedb (VIC=65 onwards).
>>>
>>> This patch adds:
>>> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
>>> - Newly added 4k modes (from VIC=93 to VIC=107).
>> As I understand it modifies edid_cea_modes array. This array
>> is used by couple of functions, particularly by drm_match_cea_mode,
>> which is used by drm_hdmi_avi_infoframe_from_display_mode.
>> I.e. since this patch AVI infoframes generated using drm core code will
>> be different - they can contain VIC codes unknown to TV.
>> I am not sure if it is harmful, but for sure this patch has visible
>> impact on drivers behavior.
>>
>> Maybe it would be good to allow drivers to keep full compatibility with
>> HDMI 1.4?
> Hello Andrzej,
> Thanks for the comment.
> If you watch the code flow carefully, this is driven by EDID. So any 
> VIC, which is translated/transformed using this array, would be coming 
> from the EDID itself.
> So I dont think there would be a problem if the mode is defined in the 
> EDID section itself, coz we are expecting the TV to know what its 
> mentioning in EDID.
>
> This is how a typical flow would look:
> - hot-plug
> - driver reads modes specified in EDID basic.
> - driver parses various CEA extension blocks.
>  - For both of the above mentioned steps, driver will probe the 
> functions like do_cea_modes which uses edid_cea_modes[] array.
> - driver will add the probed modes in EDID, into connector
> - driver will pass the connector to userspace
> - userspace will pick one of the probed modes for modeset.
> - during modeset, we will set VIC part for a CEA mode, in the AVI 
> infoframe section.
>
> So in other words, the only source of a VIC (cea_mode) is from TV's own 
> EDID.
> This means we should never run into an unknown VIC. There can be a 0 VIC 
> (for non CEA modes), but not unknown one.

For example 3840x2160@30Hz has no VIC in HDMI 1.4 but it can
be present in HDMI vendor specific block with HDMI_VIC 1, on the
other side it has VIC 95 in HDMI 2.0. So before your patch
AVI infoframe.video_code is set to 0, after your patch is set to 95.

Regards
Andrzej


>
> Regards
> Shashank
>> Regards
>> Andrzej
>>
>>
>>> Signed-off-by: Shashank Sharma 
>>> Signed-off-by: Sonika Jindal 
>>> Reviewed-by: Jose Abreu 
>>> Reviewed-by: Alex Deucher 
>>>
>>> Cc: Jose Abreu 
>>> Cc: Alex Deucher 
>>>
>>> V2: Addressed review comments from Jose:
>>> - fix the timings for VIC 83, 90 and 91
>>> - fix formatting for VIC 93-107
>>> ---
>>>   drivers/gpu/drm/drm_edid.c | 215 
>>> +
>>>   1 file changed, 215 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>>> index 9506933..d18602c 100644
>>> --- a/drivers/gpu/drm/drm_edid.c
>>> +++ b/drivers/gpu/drm/drm_edid.c
>>> @@ -994,6 +994,221 @@ struct minimode {
>>>2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>>>DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>>>  .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
>>> +   /* 65 - 1280x720@24Hz */
>>> +   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
>>> +  3080, 3300, 0, 720, 725, 730, 750, 0,
>>> +  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>>> + .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>>> +   /* 66 - 1280x720@25Hz */
>>> +   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
>>> +  3740, 3960, 0, 720, 725, 730, 750, 0,
>>> +  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>>> + .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>>> +   /* 67 - 1280x720@30Hz */
>>> +   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
>>> +  3080, 3300, 0, 720, 725, 730, 750, 0,
>>> +  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>>> + .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>>> +   /* 68 - 1280x720@50Hz */
>>> +   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
>>> +  1760, 1980, 0, 720, 725, 730, 750, 0,
>>> +  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>>> + .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>>> +   /* 69 - 1280x720@60Hz */
>>> +   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250,

Re: [Intel-gfx] [PATCH v2] drm/i915: Introduce HAS_64BIT_RELOC

2016-11-02 Thread Joonas Lahtinen 
On ke, 2016-11-02 at 13:25 +, Chris Wilson wrote:
> On Wed, Nov 02, 2016 at 02:55:36PM +0200, Joonas Lahtinen wrote:
> > 
> > Move has_64bit_reloc into dev_priv->info.
> 
> ... so that it is shown in the feature list for debugging

Ok, I'll add more detail.

> > @@ -288,7 +288,8 @@ static const struct intel_device_info 
> > intel_haswell_info = {
> >  #define BDW_FEATURES \
> >     HSW_FEATURES, \
> >     BDW_COLORS, \
> > -   .has_logical_ring_contexts = 1
> > +   .has_logical_ring_contexts = 1, \
> > +   .has_64bit_reloc = 1
> >  
> >  static const struct intel_device_info intel_broadwell_info = {
> >     BDW_FEATURES,
> 
> Missed:
>   intel_cherryview_info
>   intel_broxton_info

Yea, I was kinda overly optimistic about us cascading the features.
Time to add GEN8_FEATURES...

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: Tidy slab cache allocations

2016-11-02 Thread Joonas Lahtinen 
On ke, 2016-11-02 at 14:07 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> We can use the preferred KMEM_CACHE helper for brevity.
> 
> Also simplifiy error unwind by only setting the ENOMEM
> error code once.

You did not do this part in this patch.

> 
> Signed-off-by: Tvrtko Ursulin 

Nice cleanup. For the KMEM_CACHE itself;

Reviewed-by: Joonas Lahtinen 

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Tidy slab cache allocations

2016-11-02 Thread Patchwork 
== Series Details ==

Series: drm/i915: Tidy slab cache allocations
URL   : https://patchwork.freedesktop.org/series/14731/
State : success

== Summary ==

Series 14731v1 drm/i915: Tidy slab cache allocations
https://patchwork.freedesktop.org/api/1.0/series/14731/revisions/1/mbox/

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
skip   -> PASS   (fi-byt-n2820)
Test kms_force_connector_basic:
Subgroup force-connector-state:
dmesg-warn -> PASS   (fi-snb-2520m)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2600)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:187  dwarn:0   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

72d7f92850af037485a5ad6bc820d26a9ee97cd6 drm-intel-nightly: 
2016y-11m-02d-13h-17m-31s UTC integration manifest
c4bb4e3 drm/i915: Tidy slab cache allocations

== Logs ==

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

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Sharma, Shashank 

Regards

Shashank


On 11/2/2016 7:58 PM, Andrzej Hajda wrote:

On 02.11.2016 10:46, Shashank Sharma wrote:

CEA-861-F specs defines new 4k video modes to be used with
HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
way till VIC=107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse 4k modes using the existing techniques, we have
to complete the modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

As I understand it modifies edid_cea_modes array. This array
is used by couple of functions, particularly by drm_match_cea_mode,
which is used by drm_hdmi_avi_infoframe_from_display_mode.
I.e. since this patch AVI infoframes generated using drm core code will
be different - they can contain VIC codes unknown to TV.
I am not sure if it is harmful, but for sure this patch has visible
impact on drivers behavior.

Maybe it would be good to allow drivers to keep full compatibility with
HDMI 1.4?

Hello Andrzej,
Thanks for the comment.
If you watch the code flow carefully, this is driven by EDID. So any 
VIC, which is translated/transformed using this array, would be coming 
from the EDID itself.
So I dont think there would be a problem if the mode is defined in the 
EDID section itself, coz we are expecting the TV to know what its 
mentioning in EDID.


This is how a typical flow would look:
- hot-plug
- driver reads modes specified in EDID basic.
- driver parses various CEA extension blocks.
- For both of the above mentioned steps, driver will probe the 
functions like do_cea_modes which uses edid_cea_modes[] array.

- driver will add the probed modes in EDID, into connector
- driver will pass the connector to userspace
- userspace will pick one of the probed modes for modeset.
- during modeset, we will set VIC part for a CEA mode, in the AVI 
infoframe section.


So in other words, the only source of a VIC (cea_mode) is from TV's own 
EDID.
This means we should never run into an unknown VIC. There can be a 0 VIC 
(for non CEA modes), but not unknown one.


Regards
Shashank

Regards
Andrzej



Signed-off-by: Shashank Sharma 
Signed-off-by: Sonika Jindal 
Reviewed-by: Jose Abreu 
Reviewed-by: Alex Deucher 

Cc: Jose Abreu 
Cc: Alex Deucher 

V2: Addressed review comments from Jose:
- fix the timings for VIC 83, 90 and 91
- fix formatting for VIC 93-107
---
  drivers/gpu/drm/drm_edid.c | 215 +
  1 file changed, 215 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9506933..d18602c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -994,6 +994,221 @@ struct minimode {
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720@24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720@25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720@30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 - 1280x720@50Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 69 - 1280x720@60Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 70 - 1280x720@100Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+

Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Andrzej Hajda 
On 02.11.2016 10:46, Shashank Sharma wrote:
> CEA-861-F specs defines new 4k video modes to be used with
> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
> way till VIC=107.
>
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to parse 4k modes using the existing techniques, we have
> to complete the modedb (VIC=65 onwards).
>
> This patch adds:
> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> - Newly added 4k modes (from VIC=93 to VIC=107).

As I understand it modifies edid_cea_modes array. This array
is used by couple of functions, particularly by drm_match_cea_mode,
which is used by drm_hdmi_avi_infoframe_from_display_mode.
I.e. since this patch AVI infoframes generated using drm core code will
be different - they can contain VIC codes unknown to TV.
I am not sure if it is harmful, but for sure this patch has visible
impact on drivers behavior.

Maybe it would be good to allow drivers to keep full compatibility with
HDMI 1.4?

Regards
Andrzej


>
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Sonika Jindal 
> Reviewed-by: Jose Abreu 
> Reviewed-by: Alex Deucher 
>
> Cc: Jose Abreu 
> Cc: Alex Deucher 
>
> V2: Addressed review comments from Jose:
>   - fix the timings for VIC 83, 90 and 91
>   - fix formatting for VIC 93-107
> ---
>  drivers/gpu/drm/drm_edid.c | 215 
> +
>  1 file changed, 215 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9506933..d18602c 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -994,6 +994,221 @@ struct minimode {
>  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 65 - 1280x720@24Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 66 - 1280x720@25Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
> +3740, 3960, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 67 - 1280x720@30Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 68 - 1280x720@50Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 69 - 1280x720@60Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 70 - 1280x720@100Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 71 - 1280x720@120Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 72 - 1920x1080@24Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
> +2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 73 - 1920x1080@25Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
> +2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 74 - 1920x1080@30Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
> +2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
> +

[Intel-gfx] [PATCH] drm/i915: Tidy slab cache allocations

2016-11-02 Thread Tvrtko Ursulin 
From: Tvrtko Ursulin 

We can use the preferred KMEM_CACHE helper for brevity.

Also simplifiy error unwind by only setting the ENOMEM
error code once.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 23 ++-
 1 file changed, 6 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5839bebba64a..a6da5b55764a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4716,33 +4716,22 @@ i915_gem_load_init(struct drm_device *dev)
struct drm_i915_private *dev_priv = to_i915(dev);
int err;
 
-   dev_priv->objects =
-   kmem_cache_create("i915_gem_object",
- sizeof(struct drm_i915_gem_object), 0,
- SLAB_HWCACHE_ALIGN,
- NULL);
+   dev_priv->objects = KMEM_CACHE(drm_i915_gem_object, SLAB_HWCACHE_ALIGN);
if (!dev_priv->objects) {
err = -ENOMEM;
goto err_out;
}
 
-   dev_priv->vmas =
-   kmem_cache_create("i915_gem_vma",
- sizeof(struct i915_vma), 0,
- SLAB_HWCACHE_ALIGN,
- NULL);
+   dev_priv->vmas = KMEM_CACHE(i915_vma, SLAB_HWCACHE_ALIGN);
if (!dev_priv->vmas) {
err = -ENOMEM;
goto err_objects;
}
 
-   dev_priv->requests =
-   kmem_cache_create("i915_gem_request",
- sizeof(struct drm_i915_gem_request), 0,
- SLAB_HWCACHE_ALIGN |
- SLAB_RECLAIM_ACCOUNT |
- SLAB_DESTROY_BY_RCU,
- NULL);
+   dev_priv->requests = KMEM_CACHE(drm_i915_gem_request,
+   SLAB_HWCACHE_ALIGN |
+   SLAB_RECLAIM_ACCOUNT |
+   SLAB_DESTROY_BY_RCU);
if (!dev_priv->requests) {
err = -ENOMEM;
goto err_vmas;
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Show the execlist queue in debugfs/i915_engine_info

2016-11-02 Thread Joonas Lahtinen 
On to, 2016-10-27 at 01:03 +0100, Chris Wilson wrote:
> When looking at freezes whilst working on execlists, knowing the order
> of the pending requests in the driver is useful.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

I think this can be merged already.

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: Introduce HAS_64BIT_RELOC

2016-11-02 Thread Chris Wilson 
On Wed, Nov 02, 2016 at 02:32:54PM +0200, Joonas Lahtinen wrote:
> Unify {use,has}_64bit_reloc into dev_priv->info.
> 
> Cc: Chris Wilson 
> Signed-off-by: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  | 3 +++
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c   | 8 +++-
>  drivers/gpu/drm/i915/i915_gem_render_state.c | 3 +--
>  drivers/gpu/drm/i915/i915_pci.c  | 3 ++-
>  4 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index eaa01da..ae0217d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -670,6 +670,7 @@ struct intel_csr {
>   func(is_kabylake); \
>   func(is_preliminary); \
>   /* Keep has_* in alphabetical order */ \
> + func(has_64bit_reloc); \
>   func(has_csr); \
>   func(has_ddi); \
>   func(has_dp_mst); \
> @@ -2917,6 +2918,8 @@ struct drm_i915_cmd_table {
>  #define HAS_CSR(dev) (INTEL_INFO(dev)->has_csr)
>  
>  #define HAS_RUNTIME_PM(dev_priv) ((dev_priv)->info.has_runtime_pm)
> +#define HAS_64BIT_RELOC(dev_priv) ((dev_priv)->info.has_64bit_reloc)
> +
>  /*
>   * For now, anything with a GuC requires uCode loading, and then supports
>   * command submission once loaded. But these are logically independent
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index c35e847..3e73f77 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -322,7 +322,6 @@ struct reloc_cache {
>   struct drm_mm_node node;
>   unsigned long vaddr;
>   unsigned int page;
> - bool use_64bit_reloc;
>  };
>  
>  static void reloc_cache_init(struct reloc_cache *cache,
> @@ -331,7 +330,6 @@ static void reloc_cache_init(struct reloc_cache *cache,
>   cache->page = -1;
>   cache->vaddr = 0;
>   cache->i915 = i915;
> - cache->use_64bit_reloc = INTEL_GEN(cache->i915) >= 8;
>   cache->node.allocated = false;
>  }
>  
> @@ -519,7 +517,7 @@ relocate_entry(struct drm_i915_gem_object *obj,
>  u64 target_offset)
>  {
>   u64 offset = reloc->offset;
> - bool wide = cache->use_64bit_reloc;
> + bool wide = HAS_64BIT_RELOC(cache->i915);
Nak.
-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: Introduce HAS_64BIT_RELOC

2016-11-02 Thread Joonas Lahtinen 
Unify {use,has}_64bit_reloc into dev_priv->info.

Cc: Chris Wilson 
Signed-off-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h  | 3 +++
 drivers/gpu/drm/i915/i915_gem_execbuffer.c   | 8 +++-
 drivers/gpu/drm/i915/i915_gem_render_state.c | 3 +--
 drivers/gpu/drm/i915/i915_pci.c  | 3 ++-
 4 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eaa01da..ae0217d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -670,6 +670,7 @@ struct intel_csr {
func(is_kabylake); \
func(is_preliminary); \
/* Keep has_* in alphabetical order */ \
+   func(has_64bit_reloc); \
func(has_csr); \
func(has_ddi); \
func(has_dp_mst); \
@@ -2917,6 +2918,8 @@ struct drm_i915_cmd_table {
 #define HAS_CSR(dev)   (INTEL_INFO(dev)->has_csr)
 
 #define HAS_RUNTIME_PM(dev_priv) ((dev_priv)->info.has_runtime_pm)
+#define HAS_64BIT_RELOC(dev_priv) ((dev_priv)->info.has_64bit_reloc)
+
 /*
  * For now, anything with a GuC requires uCode loading, and then supports
  * command submission once loaded. But these are logically independent
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index c35e847..3e73f77 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -322,7 +322,6 @@ struct reloc_cache {
struct drm_mm_node node;
unsigned long vaddr;
unsigned int page;
-   bool use_64bit_reloc;
 };
 
 static void reloc_cache_init(struct reloc_cache *cache,
@@ -331,7 +330,6 @@ static void reloc_cache_init(struct reloc_cache *cache,
cache->page = -1;
cache->vaddr = 0;
cache->i915 = i915;
-   cache->use_64bit_reloc = INTEL_GEN(cache->i915) >= 8;
cache->node.allocated = false;
 }
 
@@ -519,7 +517,7 @@ relocate_entry(struct drm_i915_gem_object *obj,
   u64 target_offset)
 {
u64 offset = reloc->offset;
-   bool wide = cache->use_64bit_reloc;
+   bool wide = HAS_64BIT_RELOC(cache->i915);
void *vaddr;
 
target_offset = relocation_target(reloc, target_offset);
@@ -552,6 +550,7 @@ i915_gem_execbuffer_relocate_entry(struct 
drm_i915_gem_object *obj,
struct drm_gem_object *target_obj;
struct drm_i915_gem_object *target_i915_obj;
struct i915_vma *target_vma;
+   const size_t reloc_w = HAS_64BIT_RELOC(dev_priv) ? 8 : 4;
uint64_t target_offset;
int ret;
 
@@ -608,8 +607,7 @@ i915_gem_execbuffer_relocate_entry(struct 
drm_i915_gem_object *obj,
return 0;
 
/* Check that the relocation address is valid... */
-   if (unlikely(reloc->offset >
-obj->base.size - (cache->use_64bit_reloc ? 8 : 4))) {
+   if (unlikely(reloc->offset > obj->base.size - reloc_w)) {
DRM_DEBUG("Relocation beyond object bounds: "
  "obj %p target %d offset %d size %d.\n",
  obj, reloc->target_handle,
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c 
b/drivers/gpu/drm/i915/i915_gem_render_state.c
index 57918f2..5af19b0 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
@@ -74,7 +74,6 @@ static int render_state_setup(struct intel_render_state *so,
  struct drm_i915_private *i915)
 {
const struct intel_renderstate_rodata *rodata = so->rodata;
-   const bool has_64bit_reloc = INTEL_GEN(i915) >= 8;
struct drm_i915_gem_object *obj = so->vma->obj;
unsigned int i = 0, reloc_index = 0;
unsigned int needs_clflush;
@@ -93,7 +92,7 @@ static int render_state_setup(struct intel_render_state *so,
if (i * 4  == rodata->reloc[reloc_index]) {
u64 r = s + so->vma->node.start;
s = lower_32_bits(r);
-   if (has_64bit_reloc) {
+   if (HAS_64BIT_RELOC(i915)) {
if (i + 1 >= rodata->batch_items ||
rodata->batch[i + 1] != 0)
goto err;
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 31e6edd..9d2b5d3 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -288,7 +288,8 @@ static const struct intel_device_info intel_haswell_info = {
 #define BDW_FEATURES \
HSW_FEATURES, \
BDW_COLORS, \
-   .has_logical_ring_contexts = 1
+   .has_logical_ring_contexts = 1, \
+   .has_64bit_reloc = 1
 
 static const struct intel_device_info intel_broadwell_info = {
BDW_FEATURES,
-- 
2.7.4

___
Intel-gfx mailing list

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Unify global_list into global_link

2016-11-02 Thread Patchwork 
== Series Details ==

Series: drm/i915: Unify global_list into global_link
URL   : https://patchwork.freedesktop.org/series/14722/
State : warning

== Summary ==

Series 14722v1 drm/i915: Unify global_list into global_link
https://patchwork.freedesktop.org/api/1.0/series/14722/revisions/1/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-skl-6770hq)
Test gem_ctx_switch:
Subgroup basic-default:
timeout-> PASS   (fi-bsw-n3050)
Subgroup basic-default-heavy:
incomplete -> PASS   (fi-bsw-n3050)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:187  dwarn:0   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:226  dwarn:1   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

179f2b207ffc86fad387e7d102912b6c897abc4e drm-intel-nightly: 
2016y-11m-02d-10h-06m-52s UTC integration manifest
a52f61d drm/i915: Unify global_list into global_link

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix pages pin counting around swizzle quirk

2016-11-02 Thread Patchwork 
== Series Details ==

Series: drm/i915: Fix pages pin counting around swizzle quirk
URL   : https://patchwork.freedesktop.org/series/14720/
State : success

== Summary ==

Series 14720v1 drm/i915: Fix pages pin counting around swizzle quirk
https://patchwork.freedesktop.org/api/1.0/series/14720/revisions/1/mbox/

Test gem_ctx_switch:
Subgroup basic-default:
timeout-> PASS   (fi-bsw-n3050)
Subgroup basic-default-heavy:
incomplete -> PASS   (fi-bsw-n3050)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:187  dwarn:0   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

179f2b207ffc86fad387e7d102912b6c897abc4e drm-intel-nightly: 
2016y-11m-02d-10h-06m-52s UTC integration manifest
a2c3d69e drm/i915: Fix pages pin counting around swizzle quirk

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Unify global_list into global_link

2016-11-02 Thread Chris Wilson 
On Wed, Nov 02, 2016 at 12:16:04PM +0200, Joonas Lahtinen wrote:
> $ sed -i -r 's/\bglobal_list\b/global_link/g' *.c *.h
> 
> Cc: Chris Wilson 
> Signed-off-by: Joonas Lahtinen 

Ok, I keep trying to find a better name than global_*, but it falls into
the "when we fix the shrinker" category.

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] ✗ Fi.CI.BAT: warning for drm: Complete CEA modedb(VIC 1-107) (rev3)

2016-11-02 Thread Sharma, Shashank 
The failure has nothing to do with the patch, seems irrelevant. 

Regards
Shashank
-Original Message-
From: Patchwork [mailto:patchw...@emeril.freedesktop.org] 
Sent: Wednesday, November 2, 2016 3:48 PM
To: Sharma, Shashank 
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.BAT: warning for drm: Complete CEA modedb(VIC 1-107) (rev3)

== Series Details ==

Series: drm: Complete CEA modedb(VIC 1-107) (rev3)
URL   : https://patchwork.freedesktop.org/series/14090/
State : warning

== Summary ==

Series 14090v3 drm: Complete CEA modedb(VIC 1-107) 
https://patchwork.freedesktop.org/api/1.0/series/14090/revisions/3/mbox/

Test gem_mmap_gtt:
Subgroup basic-wc:
fail   -> PASS   (fi-byt-n2820)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> SKIP   (fi-byt-n2820)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

ee4d94ad08355b213e125a35cb3ae5f40c51314c drm-intel-nightly: 
2016y-11m-02d-07h-37m-43s UTC integration manifest
0eb8834 drm: Complete CEA modedb(VIC 1-107)

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: Complete CEA modedb(VIC 1-107) (rev3)

2016-11-02 Thread Patchwork 
== Series Details ==

Series: drm: Complete CEA modedb(VIC 1-107) (rev3)
URL   : https://patchwork.freedesktop.org/series/14090/
State : warning

== Summary ==

Series 14090v3 drm: Complete CEA modedb(VIC 1-107)
https://patchwork.freedesktop.org/api/1.0/series/14090/revisions/3/mbox/

Test gem_mmap_gtt:
Subgroup basic-wc:
fail   -> PASS   (fi-byt-n2820)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> SKIP   (fi-byt-n2820)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

ee4d94ad08355b213e125a35cb3ae5f40c51314c drm-intel-nightly: 
2016y-11m-02d-07h-37m-43s UTC integration manifest
0eb8834 drm: Complete CEA modedb(VIC 1-107)

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Unify global_list into global_link

2016-11-02 Thread Joonas Lahtinen 
$ sed -i -r 's/\bglobal_list\b/global_link/g' *.c *.h

Cc: Chris Wilson 
Signed-off-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 10 +-
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 drivers/gpu/drm/i915/i915_gem.c  | 12 ++--
 drivers/gpu/drm/i915/i915_gem_gtt.c  |  4 ++--
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 16 
 drivers/gpu/drm/i915/i915_gem_stolen.c   |  2 +-
 6 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index a13ff47..bc9c0cd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -217,7 +217,7 @@ static int i915_gem_stolen_list_info(struct seq_file *m, 
void *data)
return ret;
 
total_obj_size = total_gtt_size = count = 0;
-   list_for_each_entry(obj, _priv->mm.bound_list, global_list) {
+   list_for_each_entry(obj, _priv->mm.bound_list, global_link) {
if (obj->stolen == NULL)
continue;
 
@@ -227,7 +227,7 @@ static int i915_gem_stolen_list_info(struct seq_file *m, 
void *data)
total_gtt_size += i915_gem_obj_total_ggtt_size(obj);
count++;
}
-   list_for_each_entry(obj, _priv->mm.unbound_list, global_list) {
+   list_for_each_entry(obj, _priv->mm.unbound_list, global_link) {
if (obj->stolen == NULL)
continue;
 
@@ -390,7 +390,7 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
size = count = 0;
mapped_size = mapped_count = 0;
purgeable_size = purgeable_count = 0;
-   list_for_each_entry(obj, _priv->mm.unbound_list, global_list) {
+   list_for_each_entry(obj, _priv->mm.unbound_list, global_link) {
size += obj->base.size;
++count;
 
@@ -407,7 +407,7 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
seq_printf(m, "%u unbound objects, %llu bytes\n", count, size);
 
size = count = dpy_size = dpy_count = 0;
-   list_for_each_entry(obj, _priv->mm.bound_list, global_list) {
+   list_for_each_entry(obj, _priv->mm.bound_list, global_link) {
size += obj->base.size;
++count;
 
@@ -493,7 +493,7 @@ static int i915_gem_gtt_info(struct seq_file *m, void *data)
return ret;
 
total_obj_size = total_gtt_size = count = 0;
-   list_for_each_entry(obj, _priv->mm.bound_list, global_list) {
+   list_for_each_entry(obj, _priv->mm.bound_list, global_link) {
if (show_pin_display_only && !obj->pin_display)
continue;
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d868979..eaa01da 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2235,7 +2235,7 @@ struct drm_i915_gem_object {
 
/** Stolen memory for this object, instead of being backed by shmem. */
struct drm_mm_node *stolen;
-   struct list_head global_list;
+   struct list_head global_link;
union {
struct rcu_head rcu;
struct llist_node freed;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a97fdfa..5839beb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1446,7 +1446,7 @@ static void i915_gem_object_bump_inactive_ggtt(struct 
drm_i915_gem_object *obj)
 
i915 = to_i915(obj->base.dev);
list = obj->bind_count ? >mm.bound_list : >mm.unbound_list;
-   list_move_tail(>global_list, list);
+   list_move_tail(>global_link, list);
 }
 
 /**
@@ -2967,7 +2967,7 @@ int i915_vma_unbind(struct i915_vma *vma)
/* Since the unbound list is global, only move to that list if
 * no more VMAs exist. */
if (--obj->bind_count == 0)
-   list_move_tail(>global_list,
+   list_move_tail(>global_link,
   _i915(obj->base.dev)->mm.unbound_list);
 
/* And finally now the object is completely decoupled from this vma,
@@ -3164,7 +3164,7 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
}
GEM_BUG_ON(!i915_gem_valid_gtt_space(vma, obj->cache_level));
 
-   list_move_tail(>global_list, _priv->mm.bound_list);
+   list_move_tail(>global_link, _priv->mm.bound_list);
list_move_tail(>vm_link, >vm->inactive_list);
obj->bind_count++;
 
@@ -4125,7 +4125,7 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
 {
mutex_init(>mm.lock);
 
-   INIT_LIST_HEAD(>global_list);
+   INIT_LIST_HEAD(>global_link);
INIT_LIST_HEAD(>userfault_link);
INIT_LIST_HEAD(>obj_exec_link);
INIT_LIST_HEAD(>vma_list);
@@ -4272,7 +4272,7 @@ static void

[Intel-gfx] [PATCH] drm/i915: Fix pages pin counting around swizzle quirk

2016-11-02 Thread Chris Wilson 
commit bc0629a76726 ("drm/i915: Track pages pinned due to swizzling
quirk") fixed one problem, but revealed a whole lot more. The root cause
of the pin count mismatch for the swizzle quirk (for L-shaped memory on
gen3/4) was that we were incrementing the pages_pin_count upon getting
the backing pages but then overwriting the pages_pin_count to set it to
1 afterwards. With a little bit of adjustment to satisfy the GEM_BUG_ON
sanitychecks, the fix is to replace the explicit atomic_set with an
atomic_inc.

Fixes: 1233e2db199d ("drm/i915: Move object backing storage manipulation")
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c| 40 ++
 drivers/gpu/drm/i915/i915_gem_gtt.c|  1 +
 drivers/gpu/drm/i915/i915_gem_tiling.c |  1 +
 3 files changed, 23 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 993fb90da104..5fe7562aefbd 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2386,12 +2386,6 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
if (i915_gem_object_needs_bit17_swizzle(obj))
i915_gem_object_do_bit_17_swizzle(obj, st);
 
-   if (i915_gem_object_is_tiled(obj) &&
-   dev_priv->quirks & QUIRK_PIN_SWIZZLED_PAGES) {
-   __i915_gem_object_pin_pages(obj);
-   obj->mm.quirked = true;
-   }
-
return st;
 
 err_pages:
@@ -2424,6 +2418,13 @@ void __i915_gem_object_set_pages(struct 
drm_i915_gem_object *obj,
obj->mm.get_page.sg_idx = 0;
 
obj->mm.pages = pages;
+
+   if (i915_gem_object_is_tiled(obj) &&
+   to_i915(obj->base.dev)->quirks & QUIRK_PIN_SWIZZLED_PAGES) {
+   GEM_BUG_ON(obj->mm.quirked);
+   __i915_gem_object_pin_pages(obj);
+   obj->mm.quirked = true;
+   }
 }
 
 static int i915_gem_object_get_pages(struct drm_i915_gem_object *obj)
@@ -2458,17 +2459,16 @@ int __i915_gem_object_get_pages(struct 
drm_i915_gem_object *obj)
if (err)
return err;
 
-   if (likely(obj->mm.pages)) {
-   __i915_gem_object_pin_pages(obj);
-   goto unlock;
-   }
-
-   GEM_BUG_ON(i915_gem_object_has_pinned_pages(obj));
+   if (unlikely(!obj->mm.pages)) {
+   GEM_BUG_ON(i915_gem_object_has_pinned_pages(obj));
+   err = i915_gem_object_get_pages(obj);
+   if (err)
+   goto unlock;
 
-   err = i915_gem_object_get_pages(obj);
-   if (!err)
-   atomic_set_release(>mm.pages_pin_count, 1);
+   smp_mb__before_atomic();
+   }
 
+   __i915_gem_object_pin_pages(obj);
 unlock:
mutex_unlock(>mm.lock);
return err;
@@ -2542,8 +2542,8 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object 
*obj,
if (ret)
goto err_unlock;
 
-   GEM_BUG_ON(atomic_read(>mm.pages_pin_count));
-   atomic_set_release(>mm.pages_pin_count, 1);
+   smp_mb__before_atomic();
+   __i915_gem_object_pin_pages(obj);
pinned = false;
}
GEM_BUG_ON(!obj->mm.pages);
@@ -2578,7 +2578,7 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object 
*obj,
return ptr;
 
 err_unpin:
-   atomic_dec(>mm.pages_pin_count);
+   __i915_gem_object_unpin_pages(obj);
 err_unlock:
ptr = ERR_PTR(ret);
goto out_unlock;
@@ -2996,7 +2996,7 @@ int i915_vma_unbind(struct i915_vma *vma)
goto destroy;
 
GEM_BUG_ON(obj->bind_count == 0);
-   GEM_BUG_ON(!obj->mm.pages);
+   GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
 
if (i915_vma_is_map_and_fenceable(vma)) {
/* release the fence reg _after_ flushing */
@@ -3230,6 +3230,7 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
list_move_tail(>global_list, _priv->mm.bound_list);
list_move_tail(>vm_link, >vm->inactive_list);
obj->bind_count++;
+   GEM_BUG_ON(atomic_read(>mm.pages_pin_count) < obj->bind_count);
 
return 0;
 
@@ -4282,6 +4283,7 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void *data,
obj->mm.quirked = false;
}
if (args->madv == I915_MADV_WILLNEED) {
+   GEM_BUG_ON(obj->mm.quirked);
__i915_gem_object_pin_pages(obj);
obj->mm.quirked = true;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index dfc40f16f149..4dc1a463ef4c 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3707,6 +3707,7 @@ i915_get_ggtt_vma_pages(struct i915_vma

[Intel-gfx] [PATCH i-g-t v5] tests/kms_plane_multiple: CRC based atomic correctness test

2016-11-02 Thread Mika Kahola 
This is a testcase with multiple planes. The idea here is the following

 - draw a uniform frame with blue color
 - grab crc for reference
 - put planes randomly on top with the same blue color
 - punch holes with black color into the primary framebuffer
 - ideally the planes should cover these holes so that the output is the
   identical to reference crc
 - composite all with one ioctl call
 - grab crc and verify that the reference crc is equal
 - repeat this for dozen iterations to maximize coverage

v5: Remove limit for max number of iterations and add possibility to
loop forever (Daniel)
Remove IN_RANGE() macro (Maarten)
Remove log file and show random number seed on screen instead (Maarten)
Split legacy and atomic plane tests on own functions (Maarten)
remove test_atomic() function and pass test mode info as
parameter (Maarten)
Use bigger rectangle size (256x256) for non-cursor planes and
smaller (128x128) size for cursor plane (Maarten)

v4: For atomic test enable crc capturing before entering into a
iteration loop. After each iteration, check that page flip
didn't take no more than 1 vblank, fetch all crc's and check
the values.

Introduce new command line parameter for the number of iterations.
The test run from 1 to 256 iterations.

v3: Cleanup by removing separate plane array
For atomic, pass DRM_MODE_PAGE_FLIP_EVENT
Grab crc by using igt_pipe_crc_get_crc instead of igt_pipe_crc_collect_crc
Rename nplanes variable to max_planes
To optimize test execution, run iterations after the modeset

v2: Keep a logfile on random number seeds per subtest that are not skipped
due to unmet test requirements

Signed-off-by: Mika Kahola 
---
 tests/Makefile.sources |   1 +
 tests/kms_plane_multiple.c | 506 +
 2 files changed, 507 insertions(+)
 create mode 100644 tests/kms_plane_multiple.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 6d081c3..ffd59c1 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -105,6 +105,7 @@ TESTS_progs_M = \
kms_pipe_color \
kms_pipe_crc_basic \
kms_plane \
+   kms_plane_multiple \
kms_properties \
kms_psr_sink_crc \
kms_render \
diff --git a/tests/kms_plane_multiple.c b/tests/kms_plane_multiple.c
new file mode 100644
index 000..d13ce1c
--- /dev/null
+++ b/tests/kms_plane_multiple.c
@@ -0,0 +1,506 @@
+/*
+ * Copyright © 2016 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 "igt.h"
+#include "drmtest.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+IGT_TEST_DESCRIPTION("Test atomic mode setting with multiple planes ");
+
+#define MAX_CRCS  1
+#define SIZE_PLANE  256
+#define SIZE_CURSOR 128
+#define LOOP_FOREVER -1
+
+typedef struct {
+   float red;
+   float green;
+   float blue;
+} color_t;
+
+typedef struct {
+   int drm_fd;
+   igt_display_t display;
+   igt_pipe_crc_t *pipe_crc;
+   igt_plane_t *plane[IGT_MAX_PLANES];
+   struct igt_fb fb[IGT_MAX_PLANES];
+} data_t;
+
+typedef struct {
+   data_t *data;
+   igt_crc_t reference_crc;
+} test_position_t;
+
+/* Command line parameters. */
+struct {
+   int iterations;
+   bool user_seed;
+   int seed;
+} opt = {
+   .iterations = 64,
+   .user_seed = false,
+   .seed = 1,
+};
+
+static inline uint32_t pipe_select(int pipe)
+{
+   if (pipe > 1)
+   return pipe << DRM_VBLANK_HIGH_CRTC_SHIFT;
+   else if (pipe > 0)
+   return DRM_VBLANK_SECONDARY;
+   else
+   return 0;
+}
+
+static unsigned int get_vblank(int fd, int pipe, unsigned int flags)
+{
+   union drm_wait_vblank vbl;
+
+   memset(, 0, sizeof(vbl));
+   vbl.request.type = DRM_VBLANK_RELATIVE |

[Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)

2016-11-02 Thread Shashank Sharma 
CEA-861-F specs defines new 4k video modes to be used with
HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
way till VIC=107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse 4k modes using the existing techniques, we have
to complete the modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

Signed-off-by: Shashank Sharma 
Signed-off-by: Sonika Jindal 
Reviewed-by: Jose Abreu 
Reviewed-by: Alex Deucher 

Cc: Jose Abreu 
Cc: Alex Deucher 

V2: Addressed review comments from Jose:
- fix the timings for VIC 83, 90 and 91
- fix formatting for VIC 93-107
---
 drivers/gpu/drm/drm_edid.c | 215 +
 1 file changed, 215 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9506933..d18602c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -994,6 +994,221 @@ struct minimode {
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720@24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720@25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720@30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 - 1280x720@50Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 69 - 1280x720@60Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 70 - 1280x720@100Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 71 - 1280x720@120Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 72 - 1920x1080@24Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
+  2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 73 - 1920x1080@25Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 74 - 1920x1080@30Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 75 - 1920x1080@50Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 76 - 1920x1080@60Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gtt: Fix pte clear range

2016-11-02 Thread Joonas Lahtinen 
On ti, 2016-11-01 at 15:27 +0200, Mika Kuoppala wrote:
> Comparing pte index to a number of entries is wrong
> when clearing a range of pte entries. Use end marker
> of 'one past' to correctly point adequate number of
> ptes to the scratch page.
> 
> v2: assert early instead of warning late (Chris)
> v3: removed consts (Joonas)
> 
> Fixes: d209b9c3cd28 ("drm/i915/gtt: Split gen8_ppgtt_clear_pte_range")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98282
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Michel Thierry 
> Cc: Michał Winiarski 
> Reported-by: Mike Lothian 
> Signed-off-by: Mika Kuoppala 
> Reviewed-by: Chris Wilson 
> Tested-by: Mike Lothian 

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] ✗ Fi.CI.BAT: warning for drm/i915: Allow shrinking of userptr objects once again (rev2)

2016-11-02 Thread Tvrtko Ursulin 


On 02/11/2016 08:37, Chris Wilson wrote:

On Wed, Nov 02, 2016 at 08:33:56AM +, Tvrtko Ursulin wrote:


On 01/11/2016 16:41, Chris Wilson wrote:

On Tue, Nov 01, 2016 at 04:36:34PM +, Tvrtko Ursulin wrote:


Merged to dinq, thanks for the review!


Almost as bad as me in forgetting to add the r-b. dim save us! :)


Took me some time to figure out what is bad in this case. :)

For the reference of others, Chris gave the r-b, I downloaded the
patch from PW and pushed it, but did not check the tags to notice
r-b wasn't actually registered because of the missing colon.


Ha, still my fault then. :)


No, didn't mean to suggest that at all - fully my fault for missing it.

In my defense, I probably did eyeball it after applying since I always 
do that, but I suspect I just was not systematic enough.


Regards,

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allow shrinking of userptr objects once again (rev2)

2016-11-02 Thread Chris Wilson 
On Wed, Nov 02, 2016 at 08:33:56AM +, Tvrtko Ursulin wrote:
> 
> On 01/11/2016 16:41, Chris Wilson wrote:
> >On Tue, Nov 01, 2016 at 04:36:34PM +, Tvrtko Ursulin wrote:
> >>
> >>Merged to dinq, thanks for the review!
> >
> >Almost as bad as me in forgetting to add the r-b. dim save us! :)
> 
> Took me some time to figure out what is bad in this case. :)
> 
> For the reference of others, Chris gave the r-b, I downloaded the
> patch from PW and pushed it, but did not check the tags to notice
> r-b wasn't actually registered because of the missing colon.

Ha, still my fault then. :)
-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: warning for drm/i915: Allow shrinking of userptr objects once again (rev2)

2016-11-02 Thread Tvrtko Ursulin 


On 01/11/2016 16:41, Chris Wilson wrote:

On Tue, Nov 01, 2016 at 04:36:34PM +, Tvrtko Ursulin wrote:


Merged to dinq, thanks for the review!


Almost as bad as me in forgetting to add the r-b. dim save us! :)


Took me some time to figure out what is bad in this case. :)

For the reference of others, Chris gave the r-b, I downloaded the patch 
from PW and pushed it, but did not check the tags to notice r-b wasn't 
actually registered because of the missing colon.


Regards,

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

Re: [Intel-gfx] [PATCH 01/19] drm/atomic: Add new iterators over all state

2016-11-02 Thread Maarten Lankhorst 
Op 01-11-16 om 14:41 schreef Ville Syrjälä:
> On Tue, Nov 01, 2016 at 02:34:00PM +0100, Maarten Lankhorst wrote:
>> Op 01-11-16 om 14:09 schreef Ville Syrjälä:
>>> On Mon, Oct 17, 2016 at 02:37:00PM +0200, Maarten Lankhorst wrote:
 Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to
 replace the old for_each_xxx_in_state ones. This is useful for >1 flip
 depth and getting rid of all xxx->state dereferences.

 Signed-off-by: Maarten Lankhorst 
 ---
  drivers/gpu/drm/drm_atomic.c |  6 +++
  drivers/gpu/drm/drm_atomic_helper.c  | 52 +--
  drivers/gpu/drm/i915/intel_display.c | 11 ++---
  include/drm/drm_atomic.h | 81 
 ++--
  include/drm/drm_atomic_helper.h  |  3 ++
  5 files changed, 142 insertions(+), 11 deletions(-)

 diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
 index 5dd70540219c..120775fcfb70 100644
 --- a/drivers/gpu/drm/drm_atomic.c
 +++ b/drivers/gpu/drm/drm_atomic.c
 @@ -278,6 +278,8 @@ drm_atomic_get_crtc_state(struct drm_atomic_state 
 *state,
return ERR_PTR(-ENOMEM);
  
state->crtcs[index].state = crtc_state;
 +  state->crtcs[index].old_state = crtc->state;
 +  state->crtcs[index].new_state = crtc_state;
state->crtcs[index].ptr = crtc;
crtc_state->state = state;
  
 @@ -640,6 +642,8 @@ drm_atomic_get_plane_state(struct drm_atomic_state 
 *state,
  
state->planes[index].state = plane_state;
state->planes[index].ptr = plane;
 +  state->planes[index].old_state = plane->state;
 +  state->planes[index].new_state = plane_state;
plane_state->state = state;
  
DRM_DEBUG_ATOMIC("Added [PLANE:%d:%s] %p state to %p\n",
 @@ -931,6 +935,8 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
 *state,
  
drm_connector_reference(connector);
state->connectors[index].state = connector_state;
 +  state->connectors[index].old_state = connector->state;
 +  state->connectors[index].new_state = connector_state;
state->connectors[index].ptr = connector;
connector_state->state = state;
  
 diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
 b/drivers/gpu/drm/drm_atomic_helper.c
 index 07b432f43b98..fcb6e5b55217 100644
 --- a/drivers/gpu/drm/drm_atomic_helper.c
 +++ b/drivers/gpu/drm/drm_atomic_helper.c
 @@ -2495,7 +2495,7 @@ EXPORT_SYMBOL(drm_atomic_helper_disable_all);
   *
   * See also:
   * drm_atomic_helper_duplicate_state(), drm_atomic_helper_disable_all(),
 - * drm_atomic_helper_resume()
 + * drm_atomic_helper_resume(), drm_atomic_helper_commit_duplicated_state()
   */
  struct drm_atomic_state *drm_atomic_helper_suspend(struct drm_device *dev)
  {
 @@ -2536,6 +2536,52 @@ unlock:
  EXPORT_SYMBOL(drm_atomic_helper_suspend);
  
  /**
 + * drm_atomic_helper_commit_duplicated_state - commit duplicated state
 + * @state: duplicated atomic state to commit
 + * @ctx: pointer to acquire_ctx to use for commit.
 + * @nonblock: commit the state non-blocking.
 + *
 + * The state returned by drm_atomic_helper_duplicate_state() and
 + * drm_atomic_helper_suspend() is partially invalid, and needs to
 + * be fixed up before commit.
>>> So the old_state pointers are potentially invalid because whatever->state
>>> may have changed since we duplicated the state?
>> Yes when you use drm_atomic_helper_duplicate_state, and commit a different 
>> state before committing the duplicated state.
>> This only happens during suspend/resume and gpu reset.
> Should we maybe have something like drm_atomic_refresh_old_state(state)?
> Would allow the caller then to check something in the old vs. new state
> before committing?

iirc that was the first approach I took, but then you shouldn't do anything 
with a duplicated state after
creating a except commit it, so creating a commit_duplicated_state should be 
enough.

Can you think of any case where you do the following?

Duplicate state
commit different state
Look at duplicated state, tinker with it, commit it.

~Maarten

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: Fix workload status after wait (rev2)

2016-11-02 Thread Patchwork 
== Series Details ==

Series: drm/i915/gvt: Fix workload status after wait (rev2)
URL   : https://patchwork.freedesktop.org/series/14711/
State : failure

== Summary ==

Series 14711v2 drm/i915/gvt: Fix workload status after wait
https://patchwork.freedesktop.org/api/1.0/series/14711/revisions/2/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-skl-6770hq)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-skl-6770hq)
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> FAIL   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-3:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup bad-source:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup hang-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:187  dwarn:0   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:224  dwarn:2   dfail:0   fail:1   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

c5ad9c11e819eebcad5b9be5aa5e991e89b26965 drm-intel-nightly: 
2016y-11m-01d-16h-36m-25s UTC integration manifest
12fd6ca drm/i915/gvt: Fix workload status after wait

== Logs ==

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence (rev2)

2016-11-02 Thread Ander Conselvan De Oliveira 
On Wed, 2016-11-02 at 07:24 +, Saarinen, Jani wrote:
> > 
> > == Series Details ==
> > 
> > Series: drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init
> > sequence (rev2)
> > URL   : https://patchwork.freedesktop.org/series/14669/
> > State : warning
> > 
> > == Summary ==
> > 
> > Series 14669v2 drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy
> > init sequence
> > https://patchwork.freedesktop.org/api/1.0/series/14669/revisions/2/mbox/
> > 
> > Test drv_module_reload_basic:
> > pass   -> DMESG-WARN (fi-skl-6770hq)
> Still using IGT 1.16-g5bfbbea that has no Jani's patches. But CI builds done
> today should have that fix.
> 
> > 
> > Test kms_cursor_legacy:
> > Subgroup basic-busy-flip-before-cursor-varying-size:
> > pass   -> DMESG-WARN (fi-ilk-650)
> > Test kms_pipe_crc_basic:
> > Subgroup bad-nb-words-3:
> > dmesg-warn -> PASS   (fi-ilk-650)
> > Subgroup bad-source:
> > dmesg-warn -> PASS   (fi-ilk-650)
> > Subgroup nonblocking-crc-pipe-a-frame-sequence:
> > dmesg-warn -> PASS   (fi-ilk-650)
> > Subgroup nonblocking-crc-pipe-b-frame-sequence:
> > pass   -> DMESG-WARN (fi-ilk-650)
> > Subgroup read-crc-pipe-b:
> > pass   -> DMESG-WARN (fi-ilk-650)
> > Subgroup suspend-read-crc-pipe-a:
> > dmesg-warn -> PASS   (fi-ilk-650)
> For ILK-650 Dwarns: https://bugs.freedesktop.org/show_bug.cgi?id=98531

Thanks. Patch pushed.

Ander

> 
> > 
> > fi-ilk-650   total:241  pass:183  dwarn:4   dfail:0   fail:0   skip:54
> > 
> > c5ad9c11e819eebcad5b9be5aa5e991e89b26965 drm-intel-nightly: 2016y-
> > 11m-01d-16h-36m-25s UTC integration manifest
> > 4a635f6 drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init
> > sequence
> > 
> > == Logs ==
> > 
> > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2884/
> 
> Jani Saarinen
> Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
> 
> 
> 
> ___
> 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: warning for drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence (rev2)

2016-11-02 Thread Saarinen, Jani 
> == Series Details ==
> 
> Series: drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init
> sequence (rev2)
> URL   : https://patchwork.freedesktop.org/series/14669/
> State : warning
> 
> == Summary ==
> 
> Series 14669v2 drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy
> init sequence
> https://patchwork.freedesktop.org/api/1.0/series/14669/revisions/2/mbox/
> 
> Test drv_module_reload_basic:
> pass   -> DMESG-WARN (fi-skl-6770hq)
Still using IGT 1.16-g5bfbbea that has no Jani's patches. But CI builds done 
today should have that fix.

> Test kms_cursor_legacy:
> Subgroup basic-busy-flip-before-cursor-varying-size:
> pass   -> DMESG-WARN (fi-ilk-650)
> Test kms_pipe_crc_basic:
> Subgroup bad-nb-words-3:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup bad-source:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup nonblocking-crc-pipe-a-frame-sequence:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup nonblocking-crc-pipe-b-frame-sequence:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup read-crc-pipe-b:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup suspend-read-crc-pipe-a:
> dmesg-warn -> PASS   (fi-ilk-650)
For ILK-650 Dwarns: https://bugs.freedesktop.org/show_bug.cgi?id=98531

> fi-ilk-650   total:241  pass:183  dwarn:4   dfail:0   fail:0   skip:54
> 
> c5ad9c11e819eebcad5b9be5aa5e991e89b26965 drm-intel-nightly: 2016y-
> 11m-01d-16h-36m-25s UTC integration manifest
> 4a635f6 drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init
> sequence
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2884/


Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence (rev2)

2016-11-02 Thread Patchwork 
== Series Details ==

Series: drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence 
(rev2)
URL   : https://patchwork.freedesktop.org/series/14669/
State : warning

== Summary ==

Series 14669v2 drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init 
sequence
https://patchwork.freedesktop.org/api/1.0/series/14669/revisions/2/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-skl-6770hq)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-varying-size:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-3:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup bad-source:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:183  dwarn:4   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:226  dwarn:1   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

c5ad9c11e819eebcad5b9be5aa5e991e89b26965 drm-intel-nightly: 
2016y-11m-01d-16h-36m-25s UTC integration manifest
4a635f6 drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Fix workload status after wait

2016-11-02 Thread Zhenyu Wang 
On 2016.11.02 08:47:52 +0200, Joonas Lahtinen wrote:
> On ke, 2016-11-02 at 13:41 +0800, Zhenyu Wang wrote:
> > From commit e95433c73a11759203af1cae5958f998c9673370, workload status 
> > setting
> > was changed to only capture on error path, but we need to set it properly in
> > normal path too, otherwise we'll fail to complete workload which could lead
> > guest VM vGPU reset.
> > 
> 
> Should have Fixes tag with the above commit.
> 
> > @@ -455,7 +455,8 @@ static int workload_thread(void *priv)
> >     if (lret < 0) {
> >     workload->status = lret;
> >     gvt_err("fail to wait workload, skip\n");
> > -   }
> > +   } else
> > +   workload->status = 0;
> 
> All branches of if-else continuum must use braces if one does, so
> "} else {" here
> 

Thanks for the review. I'll queue this up in gvt-linux tree as it stopped
our testing and will be included in next pull request.

-- 
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] ✗ Fi.CI.BAT: failure for drm/i915/gvt: Fix workload status after wait

2016-11-02 Thread Saarinen, Jani 
> == Series Details ==
> 
> Series: drm/i915/gvt: Fix workload status after wait
> URL   : https://patchwork.freedesktop.org/series/14711/
> State : failure
> 
> == Summary ==
> 
> Series 14711v1 drm/i915/gvt: Fix workload status after wait
> https://patchwork.freedesktop.org/api/1.0/series/14711/revisions/1/mbox/
> 
> Test drv_module_reload_basic:
> pass   -> DMESG-WARN (fi-ilk-650)
> Test gem_ctx_switch:
> Subgroup basic-default:
> pass   -> TIMEOUT(fi-bsw-n3050)
Seen also on CI: https://intel-gfx-ci.01.org/CI/fi-bsw-n3050.html => 
(CI_DRM_1772 / Oct 27).

running: igt/gem_ctx_switch/basic-default
[021/241] pass: 21 / 
timeout: igt/gem_ctx_switch/basic-default
[022/241] pass: 21, timeout: 1 /
running: igt/gem_ctx_switch/basic-default-heavy
[022/241] pass: 21, timeout: 1 -   
Build timed out (after 17 minutes). Marking the build as aborted.

> Subgroup basic-default-heavy:
> pass   -> INCOMPLETE (fi-bsw-n3050)
> Test gem_exec_suspend:
> Subgroup basic-s3:
> pass   -> DMESG-WARN (fi-ilk-650)
> Test kms_busy:
> Subgroup basic-flip-default-a:
> pass   -> DMESG-WARN (fi-ilk-650)
> Test kms_pipe_crc_basic:
> Subgroup bad-nb-words-1:
> pass   -> DMESG-WARN (fi-ilk-650)
These all ILK-650 cases seems to be 
https://bugs.freedesktop.org/show_bug.cgi?id=98531 ?

> Subgroup bad-source:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup hang-read-crc-pipe-a:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup nonblocking-crc-pipe-a-frame-sequence:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup read-crc-pipe-a:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup suspend-read-crc-pipe-a:
> dmesg-warn -> PASS   (fi-ilk-650)
> 
> fi-bsw-n3050 total:23   pass:21   dwarn:0   dfail:0   fail:0   skip:0
> fi-ilk-650   total:241  pass:181  dwarn:6   dfail:0   fail:0   skip:54
> 
> c5ad9c11e819eebcad5b9be5aa5e991e89b26965 drm-intel-nightly: 2016y-
> 11m-01d-16h-36m-25s UTC integration manifest
> 6995b34 drm/i915/gvt: Fix workload status after wait
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2883/


Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo


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

[Intel-gfx] [PATCH v2] drm/i915/gvt: Fix workload status after wait

2016-11-02 Thread Zhenyu Wang 
From commit e95433c73a11759203af1cae5958f998c9673370, workload status setting
was changed to only capture on error path, but we need to set it properly in
normal path too, otherwise we'll fail to complete workload which could lead
guest VM vGPU reset.

v2: uses braces and add Fixes tag.

Fixes: e95433c73a11 ("drm/i915: Rearrange i915_wait_request() accounting with 
callers")
Cc: Chris Wilson 
Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/scheduler.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 18acb45..843a5de 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -455,6 +455,8 @@ static int workload_thread(void *priv)
if (lret < 0) {
workload->status = lret;
gvt_err("fail to wait workload, skip\n");
+   } else {
+   workload->status = 0;
}
 
 complete:
-- 
2.10.2

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

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Fix workload status after wait

2016-11-02 Thread Joonas Lahtinen 
On ke, 2016-11-02 at 13:41 +0800, Zhenyu Wang wrote:
> From commit e95433c73a11759203af1cae5958f998c9673370, workload status setting
> was changed to only capture on error path, but we need to set it properly in
> normal path too, otherwise we'll fail to complete workload which could lead
> guest VM vGPU reset.
> 

Should have Fixes tag with the above commit.

> @@ -455,7 +455,8 @@ static int workload_thread(void *priv)
>   if (lret < 0) {
>   workload->status = lret;
>   gvt_err("fail to wait workload, skip\n");
> - }
> + } else
> + workload->status = 0;

All branches of if-else continuum must use braces if one does, so
"} else {" here

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

[Intel-gfx] [PATCH v2] drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence

2016-11-02 Thread Ander Conselvan de Oliveira 
Hardware engineers confirmed that writing to it has no effect, as implied by
the FIXME comment.

v2: Also remove comment from bxt_ddi_phy_verify_state(). (Imre)
Cc: Imre Deak 
Signed-off-by: Ander Conselvan de Oliveira 

Reviewed-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_dpio_phy.c | 21 -
 1 file changed, 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
b/drivers/gpu/drm/i915/intel_dpio_phy.c
index 4a6164a..7a8e82d 100644
--- a/drivers/gpu/drm/i915/intel_dpio_phy.c
+++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
@@ -365,22 +365,6 @@ static void _bxt_ddi_phy_init(struct drm_i915_private 
*dev_priv,
I915_WRITE(BXT_PORT_CL2CM_DW6(phy), val);
}
 
-   val = I915_READ(BXT_PORT_CL1CM_DW30(phy));
-   val &= ~OCL2_LDOFUSE_PWR_DIS;
-   /*
-* On PHY1 disable power on the second channel, since no port is
-* connected there. On PHY0 both channels have a port, so leave it
-* enabled.
-* TODO: port C is only connected on BXT-P, so on BXT0/1 we should
-* power down the second channel on PHY0 as well.
-*
-* FIXME: Clarify programming of the following, the register is
-* read-only with bit 6 fixed at 0 at least in stepping A.
-*/
-   if (!phy_info->dual_channel)
-   val |= OCL2_LDOFUSE_PWR_DIS;
-   I915_WRITE(BXT_PORT_CL1CM_DW30(phy), val);
-
if (phy_info->rcomp_phy != -1) {
uint32_t grc_code;
/*
@@ -508,11 +492,6 @@ bool bxt_ddi_phy_verify_state(struct drm_i915_private 
*dev_priv,
   DW6_OLDO_DYN_PWR_DOWN_EN, DW6_OLDO_DYN_PWR_DOWN_EN,
   "BXT_PORT_CL2CM_DW6(%d)", phy);
 
-   /*
-* TODO: Verify BXT_PORT_CL1CM_DW30 bit OCL2_LDOFUSE_PWR_DIS,
-* at least on stepping A this bit is read-only and fixed at 0.
-*/
-
if (phy_info->rcomp_phy != -1) {
u32 grc_code = dev_priv->bxt_phy_grc;
 
-- 
2.5.5

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

Re: [Intel-gfx] [PATCH v8 03/12] drm/i915: rename OACONTROL GEN7_OACONTROL

2016-11-02 Thread sourab gupta 
On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> OACONTROL changes quite a bit for gen8, with some bits split out into a
> per-context OACTXCONTROL register. Rename now before adding more gen7 OA
> registers
> 
> Signed-off-by: Robert Bragg 
> Reviewed-by: Matthew Auld 
Reviewed-by: Sourab Gupta 

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

Re: [Intel-gfx] [PATCH v8 10/12] drm/i915: add oa_event_min_timer_exponent sysctl

2016-11-02 Thread sourab gupta 
On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> The minimal sampling period is now configurable via a
> dev.i915.oa_min_timer_exponent sysctl parameter.
> 
> Following the precedent set by perf, the default is the minimum that
> won't (on its own) exceed the default kernel.perf_event_max_sample_rate
> default of 10 samples/s.
> 
> Signed-off-by: Robert Bragg 
> Reviewed-by: Matthew Auld 
> ---
>  drivers/gpu/drm/i915/i915_perf.c | 42 
> 
>  1 file changed, 30 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index 4e42073..e3c6f51 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -82,6 +82,22 @@ static u32 i915_perf_stream_paranoid = true;
>  #define INVALID_CTX_ID 0x
>  
> 
> +/* for sysctl proc_dointvec_minmax of i915_oa_min_timer_exponent */
> +static int oa_exponent_max = OA_EXPONENT_MAX;
> +
> +/* Theoretically we can program the OA unit to sample every 160ns but don't
> + * allow that by default unless root...
> + *
> + * The period is derived from the exponent as:
> + *
> + *   period = 80ns * 2^(exponent + 1)
> + *
> + * Referring to perf's kernel.perf_event_max_sample_rate for a precedent
> + * (10 by default); with an OA exponent of 6 we get a period of 10.240
> + * microseconds - just under 10Hz
> + */
> +static u32 i915_oa_min_timer_exponent = 6;

For HSW, the timestamp period is 80ns, so the exponent of 6 translates
to sampling rate of ~10Hz. But the timestamp period may change for
other platforms, leading to different values of oa_min_timer_exponent
corresponding to sampling rate of ~10Hz. Do we plan to have this
value platform specific subsequently, or the guidance value of ~10Hz
min sampling rate needn't be strictly followed?

> +
>  /* XXX: beware if future OA HW adds new report formats that the current
>   * code assumes all reports have a power-of-two size and ~(size - 1) can
>   * be used as a mask to align the OA tail pointer.
> @@ -1353,21 +1369,14 @@ static int read_properties_unlocked(struct 
> drm_i915_private *dev_priv,
>   return -EINVAL;
>   }
>  
> - /* NB: The exponent represents a period as follows:
> -  *
> -  *   80ns * 2^(period_exponent + 1)
> -  *
> -  * Theoretically we can program the OA unit to sample
> + /* Theoretically we can program the OA unit to sample
>* every 160ns but don't allow that by default unless
>* root.
> -  *
> -  * Referring to perf's
> -  * kernel.perf_event_max_sample_rate for a precedent
> -  * (10 by default); with an OA exponent of 6 we get
> -  * a period of 10.240 microseconds -just under 10Hz
>*/
> - if (value < 6 && !capable(CAP_SYS_ADMIN)) {
> - DRM_ERROR("Minimum OA sampling exponent is 6 
> without root privileges\n");
> + if (value < i915_oa_min_timer_exponent &&
> + !capable(CAP_SYS_ADMIN)) {
> + DRM_ERROR("Minimum OA sampling exponent (sysctl 
> dev.i915.oa_min_timer_exponent) is %u without root privileges\n",
> +   i915_oa_min_timer_exponent);
>   return -EACCES;
>   }
>  
> @@ -1475,6 +1484,15 @@ static struct ctl_table oa_table[] = {
>.extra1 = ,
>.extra2 = ,
>},
> + {
> +  .procname = "oa_min_timer_exponent",
> +  .data = _oa_min_timer_exponent,
> +  .maxlen = sizeof(i915_oa_min_timer_exponent),
> +  .mode = 0644,
> +  .proc_handler = proc_dointvec_minmax,
> +  .extra1 = ,
> +  .extra2 = _exponent_max,
> +  },
>   {}
>  };
>  


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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: Fix workload status after wait

2016-11-02 Thread Patchwork 
== Series Details ==

Series: drm/i915/gvt: Fix workload status after wait
URL   : https://patchwork.freedesktop.org/series/14711/
State : failure

== Summary ==

Series 14711v1 drm/i915/gvt: Fix workload status after wait
https://patchwork.freedesktop.org/api/1.0/series/14711/revisions/1/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-ilk-650)
Test gem_ctx_switch:
Subgroup basic-default:
pass   -> TIMEOUT(fi-bsw-n3050)
Subgroup basic-default-heavy:
pass   -> INCOMPLETE (fi-bsw-n3050)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_busy:
Subgroup basic-flip-default-a:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-1:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup bad-source:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup hang-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup read-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:23   pass:21   dwarn:0   dfail:0   fail:0   skip:0  
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:181  dwarn:6   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

c5ad9c11e819eebcad5b9be5aa5e991e89b26965 drm-intel-nightly: 
2016y-11m-01d-16h-36m-25s UTC integration manifest
6995b34 drm/i915/gvt: Fix workload status after wait

== Logs ==

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

Re: [Intel-gfx] [RFC PATCH] drm: define drm_compat_ioctl NULL on CONFIG_COMPAT=n and reduce #ifdefs

2016-11-02 Thread Patrik Jakobsson 
On Tue, Nov 1, 2016 at 4:40 PM, Jani Nikula  wrote:
> If we define drm_compat_ioctl NULL on CONFIG_COMPAT=n, we don't have to
> check for the config everywhere.
>
> Signed-off-by: Jani Nikula 

Looks good and I like the idea.

Reviewed-by: Patrik Jakobsson 

> ---
>
> Just an idea on top of Patrik's patch.
> ---
>  drivers/gpu/drm/arc/arcpgu_drv.c|  2 --
>  drivers/gpu/drm/arm/hdlcd_drv.c |  2 --
>  drivers/gpu/drm/arm/malidp_drv.c|  2 --
>  drivers/gpu/drm/ast/ast_drv.c   |  2 --
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c|  2 --
>  drivers/gpu/drm/bochs/bochs_drv.c   |  2 --
>  drivers/gpu/drm/cirrus/cirrus_drv.c |  2 --
>  drivers/gpu/drm/drm_fops.c  | 13 ++---
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c   |  2 --
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |  2 --
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c   |  2 --
>  drivers/gpu/drm/gma500/psb_drv.c|  2 --
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  2 --
>  drivers/gpu/drm/i810/i810_dma.c |  2 --
>  drivers/gpu/drm/i810/i810_drv.c |  2 --
>  drivers/gpu/drm/i915/i915_drv.c |  2 --
>  drivers/gpu/drm/i915/i915_drv.h |  2 ++
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  2 --
>  drivers/gpu/drm/mgag200/mgag200_drv.c   |  2 --
>  drivers/gpu/drm/msm/msm_drv.c   |  2 --
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c   |  2 --
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |  2 --
>  drivers/gpu/drm/savage/savage_drv.c |  2 --
>  drivers/gpu/drm/shmobile/shmob_drm_drv.c|  2 --
>  drivers/gpu/drm/sis/sis_drv.c   |  2 --
>  drivers/gpu/drm/sti/sti_drv.c   |  2 --
>  drivers/gpu/drm/sun4i/sun4i_drv.c   |  2 --
>  drivers/gpu/drm/tdfx/tdfx_drv.c |  2 --
>  drivers/gpu/drm/tegra/drm.c |  2 --
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c |  2 --
>  drivers/gpu/drm/udl/udl_drv.c   |  2 --
>  drivers/gpu/drm/vc4/vc4_drv.c   |  2 --
>  drivers/gpu/drm/via/via_drv.c   |  2 --
>  drivers/gpu/drm/virtio/virtgpu_drv.c|  2 --
>  include/drm/drmP.h  |  5 +
>  35 files changed, 13 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c 
> b/drivers/gpu/drm/arc/arcpgu_drv.c
> index 28e6471257d0..0b6eaa49a1db 100644
> --- a/drivers/gpu/drm/arc/arcpgu_drv.c
> +++ b/drivers/gpu/drm/arc/arcpgu_drv.c
> @@ -65,9 +65,7 @@ static const struct file_operations arcpgu_drm_ops = {
> .open = drm_open,
> .release = drm_release,
> .unlocked_ioctl = drm_ioctl,
> -#ifdef CONFIG_COMPAT
> .compat_ioctl = drm_compat_ioctl,
> -#endif
> .poll = drm_poll,
> .read = drm_read,
> .llseek = no_llseek,
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index 6477d1a65266..59747ecaad54 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -268,9 +268,7 @@ static const struct file_operations fops = {
> .open   = drm_open,
> .release= drm_release,
> .unlocked_ioctl = drm_ioctl,
> -#ifdef CONFIG_COMPAT
> .compat_ioctl   = drm_compat_ioctl,
> -#endif
> .poll   = drm_poll,
> .read   = drm_read,
> .llseek = noop_llseek,
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 9f4739452a25..d53b625b14fe 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -197,9 +197,7 @@ static const struct file_operations fops = {
> .open = drm_open,
> .release = drm_release,
> .unlocked_ioctl = drm_ioctl,
> -#ifdef CONFIG_COMPAT
> .compat_ioctl = drm_compat_ioctl,
> -#endif
> .poll = drm_poll,
> .read = drm_read,
> .llseek = noop_llseek,
> diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
> index f54afd2113a9..fd7c9eec92e4 100644
> --- a/drivers/gpu/drm/ast/ast_drv.c
> +++ b/drivers/gpu/drm/ast/ast_drv.c
> @@ -188,9 +188,7 @@ static const struct file_operations ast_fops = {
> .unlocked_ioctl = drm_ioctl,
> .mmap = ast_mmap,
> .poll = drm_poll,
> -#ifdef CONFIG_COMPAT
> .compat_ioctl = drm_compat_ioctl,
> -#endif
> .read = drm_read,
>  };
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 9f6222895212..cbd0070265c9 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -749,9 +749,7 @@ static const struct file_operations