Re: [Intel-gfx] [PATCH] drm/i915: Enable FBC for non X-tiled FBs

2017-03-17 Thread kbuild test robot
Hi Praveen,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.11-rc2 next-20170310]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Praveen-Paneri/drm-i915-Enable-FBC-for-non-X-tiled-FBs/20170318-084727
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x003-201711 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/async.h:15,
from drivers/gpu/drm/i915/intel_drv.h:28,
from drivers/gpu/drm/i915/intel_fbc.c:41:
   drivers/gpu/drm/i915/intel_fbc.c: In function 'gen7_fbc_activate':
>> drivers/gpu/drm/i915/intel_fbc.c:305:33: error: 'cache' undeclared (first 
>> use in this function)
 i915_gem_object_get_tiling(cache->vma->obj) != I915_TILING_X) {
^
   include/linux/compiler.h:160:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/gpu/drm/i915/intel_fbc.c:304:2: note: in expansion of macro 'if'
 if (INTEL_GEN(dev_priv) >= 9 &&
 ^~
   drivers/gpu/drm/i915/intel_fbc.c:305:33: note: each undeclared identifier is 
reported only once for each function it appears in
 i915_gem_object_get_tiling(cache->vma->obj) != I915_TILING_X) {
^
   include/linux/compiler.h:160:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/gpu/drm/i915/intel_fbc.c:304:2: note: in expansion of macro 'if'
 if (INTEL_GEN(dev_priv) >= 9 &&
 ^~

vim +/cache +305 drivers/gpu/drm/i915/intel_fbc.c

   298  static void gen7_fbc_activate(struct drm_i915_private *dev_priv)
   299  {
   300  struct intel_fbc_reg_params *params = _priv->fbc.params;
   301  u32 dpfc_ctl;
   302  int threshold = dev_priv->fbc.threshold;
   303  
 > 304  if (INTEL_GEN(dev_priv) >= 9 &&
 > 305  i915_gem_object_get_tiling(cache->vma->obj) != 
 > I915_TILING_X) {
   306  struct intel_fbc_state_cache *cache = 
_priv->fbc.state_cache;
   307  int cfb_stride = DIV_ROUND_UP(cache->plane.src_w,
   308(32 * threshold)) * 8;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/2] drm/i915: Initialise i915_gem_object_create_from_data() directly

2017-03-17 Thread Chris Wilson
On Fri, Mar 17, 2017 at 10:41:42PM +, Matthew Auld wrote:
> On 17 March 2017 at 19:46, Chris Wilson  wrote:
> > Use pagecache_write to avoid shmemfs clearing the pages prior to us
> > immediately overwriting them with our data.
> >
> > Signed-off-by: Chris Wilson 
> Interesting...
> Reviewed-by: Matthew Auld 

Double checked I didn't break the guc, and pushed. Thanks,
-Chris

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


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915: i915_gem_object_create_from_data() doesn't require struct_mutex

2017-03-17 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/4] drm/i915: 
i915_gem_object_create_from_data() doesn't require struct_mutex
URL   : https://patchwork.freedesktop.org/series/21478/
State : success

== Summary ==

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

Test kms_cursor_legacy:
Subgroup basic-flip-before-cursor-varying-size:
dmesg-warn -> PASS   (fi-byt-n2820) fdo#100094
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-bsw-n3050) fdo#100113

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 467s
fi-bsw-n3050 total:278  pass:238  dwarn:1   dfail:0   fail:0   skip:39  
time: 573s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 516s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 531s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 507s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 503s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 444s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 439s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 441s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 515s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 496s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 470s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 470s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 597s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 473s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 510s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 558s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 425s

ca3e896e9cf4e4c3319bbb51843daa45902927a7 drm-tip: 2017y-03m-17d-18h-26m-58s UTC 
integration manifest
10e6423 HAX enable guc submission for CI
4d7622b drm/i915: Initialise i915_gem_object_create_from_data() directly
12458ee drm/i915: Correct error handling for i915_gem_object_create_from_data()
0a9db8a drm/i915: i915_gem_object_create_from_data() doesn't require 
struct_mutex

== Logs ==

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


[Intel-gfx] [CI 2/4] drm/i915: Correct error handling for i915_gem_object_create_from_data()

2017-03-17 Thread Chris Wilson
i915_gem_object_create_from_data() always returns an error pointer on
failure, there is no need to check against NULL.

Signed-off-by: Chris Wilson 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170317205317.7885-1-ch...@chris-wilson.co.uk
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/intel_uc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 86530c92337a..d15a7d9d4eb0 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -377,8 +377,8 @@ void intel_uc_prepare_fw(struct drm_i915_private *dev_priv,
uc_fw->major_ver_wanted, uc_fw->minor_ver_wanted);
 
obj = i915_gem_object_create_from_data(dev_priv, fw->data, fw->size);
-   if (IS_ERR_OR_NULL(obj)) {
-   err = obj ? PTR_ERR(obj) : -ENOMEM;
+   if (IS_ERR(obj)) {
+   err = PTR_ERR(obj);
goto fail;
}
 
-- 
2.11.0

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


[Intel-gfx] [CI 4/4] HAX enable guc submission for CI

2017-03-17 Thread Chris Wilson
---
 drivers/gpu/drm/i915/i915_params.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e363d076..9dcc8a0dd3c0 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -56,8 +56,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_loading = 0,
-   .enable_guc_submission = 0,
+   .enable_guc_loading = 1,
+   .enable_guc_submission = 1,
.guc_log_level = -1,
.guc_firmware_path = NULL,
.huc_firmware_path = NULL,
-- 
2.11.0

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


[Intel-gfx] [CI 3/4] drm/i915: Initialise i915_gem_object_create_from_data() directly

2017-03-17 Thread Chris Wilson
Use pagecache_write to avoid shmemfs clearing the pages prior to us
immediately overwriting them with our data.

Signed-off-by: Chris Wilson 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170317194648.12468-2-ch...@chris-wilson.co.uk
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem.c | 45 ++---
 1 file changed, 29 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3492f8d27c32..58e1db77d70e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4953,9 +4953,9 @@ i915_gem_object_create_from_data(struct drm_i915_private 
*dev_priv,
 const void *data, size_t size)
 {
struct drm_i915_gem_object *obj;
-   struct sg_table *sg;
-   size_t bytes;
-   int ret;
+   struct file *file;
+   size_t offset;
+   int err;
 
obj = i915_gem_object_create(dev_priv, round_up(size, PAGE_SIZE));
if (IS_ERR(obj))
@@ -4963,26 +4963,39 @@ i915_gem_object_create_from_data(struct 
drm_i915_private *dev_priv,
 
GEM_BUG_ON(obj->base.write_domain != I915_GEM_DOMAIN_CPU);
 
-   ret = i915_gem_object_pin_pages(obj);
-   if (ret)
-   goto fail;
+   file = obj->base.filp;
+   offset = 0;
+   do {
+   unsigned int len = min_t(typeof(size), size, PAGE_SIZE);
+   struct page *page;
+   void *pgdata, *vaddr;
 
-   sg = obj->mm.pages;
-   bytes = sg_copy_from_buffer(sg->sgl, sg->nents, (void *)data, size);
-   obj->mm.dirty = true; /* Backing store is now out of date */
-   i915_gem_object_unpin_pages(obj);
+   err = pagecache_write_begin(file, file->f_mapping,
+   offset, len, 0,
+   , );
+   if (err < 0)
+   goto fail;
 
-   if (WARN_ON(bytes != size)) {
-   DRM_ERROR("Incomplete copy, wrote %zu of %zu", bytes, size);
-   ret = -EFAULT;
-   goto fail;
-   }
+   vaddr = kmap(page);
+   memcpy(vaddr, data, len);
+   kunmap(page);
+
+   err = pagecache_write_end(file, file->f_mapping,
+ offset, len, len,
+ page, pgdata);
+   if (err < 0)
+   goto fail;
+
+   size -= len;
+   data += len;
+   offset += len;
+   } while (size);
 
return obj;
 
 fail:
i915_gem_object_put(obj);
-   return ERR_PTR(ret);
+   return ERR_PTR(err);
 }
 
 struct scatterlist *
-- 
2.11.0

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


[Intel-gfx] [CI 1/4] drm/i915: i915_gem_object_create_from_data() doesn't require struct_mutex

2017-03-17 Thread Chris Wilson
Both object creation and backing storage page allocation do not require
struct_mutex, so do not require the caller to take it.

Signed-off-by: Chris Wilson 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170317194648.12468-1-ch...@chris-wilson.co.uk
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem.c | 4 +---
 drivers/gpu/drm/i915/intel_uc.c | 2 --
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fd611b4c1a2c..3492f8d27c32 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4961,9 +4961,7 @@ i915_gem_object_create_from_data(struct drm_i915_private 
*dev_priv,
if (IS_ERR(obj))
return obj;
 
-   ret = i915_gem_object_set_to_cpu_domain(obj, true);
-   if (ret)
-   goto fail;
+   GEM_BUG_ON(obj->base.write_domain != I915_GEM_DOMAIN_CPU);
 
ret = i915_gem_object_pin_pages(obj);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 21f6d822194d..86530c92337a 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -376,9 +376,7 @@ void intel_uc_prepare_fw(struct drm_i915_private *dev_priv,
uc_fw->major_ver_found, uc_fw->minor_ver_found,
uc_fw->major_ver_wanted, uc_fw->minor_ver_wanted);
 
-   mutex_lock(_priv->drm.struct_mutex);
obj = i915_gem_object_create_from_data(dev_priv, fw->data, fw->size);
-   mutex_unlock(_priv->drm.struct_mutex);
if (IS_ERR_OR_NULL(obj)) {
err = obj ? PTR_ERR(obj) : -ENOMEM;
goto fail;
-- 
2.11.0

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


Re: [Intel-gfx] [PATCH] drm/i915: Correct error handling for i915_gem_object_create_from_data()

2017-03-17 Thread Matthew Auld
On 17 March 2017 at 20:53, Chris Wilson  wrote:
> i915_gem_object_create_from_data() always returns and error pointer on
an error

> failure, there is no need to check against NULL.
>
> Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/2] drm/i915: Initialise i915_gem_object_create_from_data() directly

2017-03-17 Thread Matthew Auld
On 17 March 2017 at 19:46, Chris Wilson  wrote:
> Use pagecache_write to avoid shmemfs clearing the pages prior to us
> immediately overwriting them with our data.
>
> Signed-off-by: Chris Wilson 
Interesting...
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 1/2] drm/i915: i915_gem_object_create_from_data() doesn't require struct_mutex

2017-03-17 Thread Matthew Auld
On 17 March 2017 at 19:46, Chris Wilson  wrote:
> Both object creation and backing storage page allocation do not require
> struct_mutex, so do not require the caller to take it.
>
> Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [RFC][PATCH 14/14] WIP/drm/i915: Nuke posting reads from plane updates

2017-03-17 Thread Chris Wilson
On Fri, Mar 17, 2017 at 11:18:08PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> We'll maybe want just one posting read at the end? This does seem to
> potentially shave a few usec off from the update.

They are all superfluous until proven otherwise. The only cases where I
would (quietly) argue for a post is before a latch (to document the
serialisation of the latch with the controls that go before) and before
completing the transaction and waiting for the hw/irq.
-Chris

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


Re: [Intel-gfx] [PATCH 10/14] drm/i915: Eliminate ironlake_update_primary_plane()

2017-03-17 Thread Chris Wilson
On Fri, Mar 17, 2017 at 11:18:04PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> The effective difference between i9xx_update_primary_plane()
> and ironlake_update_primary_plane() is only the HSW/BDW
> DSPOFFSET special case. So bring that over into
> i9xx_update_primary_plane() and eliminate the duplicated code.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 55 
> 
>  1 file changed, 6 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 024614cb47b6..c7f6bc4e605a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3109,7 +3109,12 @@ static void i9xx_update_primary_plane(struct drm_plane 
> *primary,
>   I915_WRITE_FW(reg, dspcntr);
>  
>   I915_WRITE_FW(DSPSTRIDE(plane), fb->pitches[0]);
> - if (INTEL_GEN(dev_priv) >= 4) {
> + if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> + I915_WRITE_FW(DSPSURF(plane),
> +   intel_plane_ggtt_offset(plane_state) +
> +   intel_crtc->dspaddr_offset);
> + I915_WRITE_FW(DSPOFFSET(plane), (y << 16) | x);
> + } else if (INTEL_GEN(dev_priv) >= 4) {
>   I915_WRITE_FW(DSPSURF(plane),
> intel_plane_ggtt_offset(plane_state) +
> intel_crtc->dspaddr_offset);
> @@ -3146,48 +3151,6 @@ static void i9xx_disable_primary_plane(struct 
> drm_plane *primary,
>   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
>  }
>  
> -static void ironlake_update_primary_plane(struct drm_plane *primary,
> -   const struct intel_crtc_state 
> *crtc_state,
> -   const struct intel_plane_state 
> *plane_state)
> -{
> - struct drm_device *dev = primary->dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
> - struct drm_framebuffer *fb = plane_state->base.fb;
> - int plane = intel_crtc->plane;
> - u32 linear_offset;
> - u32 dspcntr = plane_state->ctl;
> - i915_reg_t reg = DSPCNTR(plane);
> - int x = plane_state->main.x;
> - int y = plane_state->main.y;
> - unsigned long irqflags;
> -
> - linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
> -
> - intel_crtc->dspaddr_offset = plane_state->main.offset;
> -
> - intel_crtc->adjusted_x = x;
> - intel_crtc->adjusted_y = y;
> -
> - spin_lock_irqsave(_priv->uncore.lock, irqflags);
> -
> - I915_WRITE_FW(reg, dspcntr);
> -
> - I915_WRITE_FW(DSPSTRIDE(plane), fb->pitches[0]);
> - I915_WRITE_FW(DSPSURF(plane),
> -   intel_plane_ggtt_offset(plane_state) +
> -   intel_crtc->dspaddr_offset);
> - if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> - I915_WRITE_FW(DSPOFFSET(plane), (y << 16) | x);
> - } else {
> - I915_WRITE_FW(DSPTILEOFF(plane), (y << 16) | x);
> - I915_WRITE_FW(DSPLINOFF(plane), linear_offset);
> - }
> - POSTING_READ_FW(reg);
> -
> - spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
> -}
> -
>  static u32
>  intel_fb_stride_alignment(const struct drm_framebuffer *fb, int plane)
>  {
> @@ -13642,12 +13605,6 @@ intel_primary_plane_create(struct drm_i915_private 
> *dev_priv, enum pipe pipe)
>  
>   primary->update_plane = skylake_update_primary_plane;
>   primary->disable_plane = skylake_disable_primary_plane;
> - } else if (HAS_PCH_SPLIT(dev_priv)) {
> - intel_primary_formats = i965_primary_formats;
> - num_formats = ARRAY_SIZE(i965_primary_formats);
> -
> - primary->update_plane = ironlake_update_primary_plane;
> - primary->disable_plane = i9xx_disable_primary_plane;
>   } else if (INTEL_GEN(dev_priv) >= 4) {

Oh, that looks quite odd, but it checks out.
Reviewed-by: Chris Wilson 
-Chris

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


Re: [Intel-gfx] [PATCH 09/14] drm/i915: Introduce i9xx_check_plane_surface()

2017-03-17 Thread Chris Wilson
On Fri, Mar 17, 2017 at 11:18:03PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Extract the primary plane surfae offset/x/y calculations for
> pre-SKL platforms into a common function, and call it during the
> atomic check phase to reduce the amount of stuff we have to do
> during the commit phase. SKL is already doing this.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 82 
> ++--
>  1 file changed, 50 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 2e0106a11f8f..024614cb47b6 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3026,6 +3026,43 @@ static u32 i9xx_plane_ctl(const struct 
> intel_crtc_state *crtc_state,
>   return dspcntr;
>  }
>  
> +static int i9xx_check_plane_surface(struct intel_plane_state *plane_state)
> +{
> + struct drm_i915_private *dev_priv =
> + to_i915(plane_state->base.plane->dev);
> + int src_x = plane_state->base.src.x1 >> 16;
> + int src_y = plane_state->base.src.y1 >> 16;
> + u32 offset;
> +
> + intel_add_fb_offsets(_x, _y, plane_state, 0);
> +
> + if (INTEL_GEN(dev_priv) >= 4)
> + offset = intel_compute_tile_offset(_x, _y,
> +plane_state, 0);
> + else
> + offset = 0;
> +
> + /* HSW+ does this automagically in hardware */
> + if (!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv)) {

if (INTEL_GEN() <= 7 && !IS_HASWELL()) {

would match the comment better.

> + unsigned int rotation = plane_state->base.rotation;
> + int src_w = drm_rect_width(_state->base.src) >> 16;
> + int src_h = drm_rect_height(_state->base.src) >> 16;
> +
> + if (rotation & DRM_ROTATE_180) {
> + src_x += src_w - 1;
> + src_y += src_h - 1;
> + } else if (rotation & DRM_REFLECT_X) {
> + src_x += src_w - 1;
> + }
> + }
> +
> + plane_state->main.offset = offset;
> + plane_state->main.x = src_x;
> + plane_state->main.y = src_y;

plane_state->actual.offset, ->actual.x, ->actual.y ?
plane_state->commit.offset, ->commit.x, ->commit.y ?

Movement looks fine,
Reviewed-by: Chris Wilson 
-Chris

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


Re: [Intel-gfx] [PATCH 08/14] drm/i915: Pre-compute plane control register value

2017-03-17 Thread Chris Wilson
On Fri, Mar 17, 2017 at 11:18:02PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Computing the plane control register value is branchy so moving it out
> from the plane commit hook seems prudent. Let's pre-compute it during
> the atomic check phase and store the result in the plane state.

i845_cursor_ctl parameters starting to look more sensible.

> @@ -986,6 +978,14 @@ intel_check_sprite_plane(struct drm_plane *plane,

This function still doesn't do what it says on the tin!!!

>   ret = skl_check_plane_surface(state);
>   if (ret)
>   return ret;
> +
> + state->ctl = skl_plane_ctl(crtc_state, state);
> + } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> + state->ctl = vlv_sprite_ctl(crtc_state, state);
> + } else if (INTEL_GEN(dev_priv) >= 7) {
> + state->ctl = ivb_sprite_ctl(crtc_state, state);
> + } else {
> + state->ctl = ilk_sprite_ctl(crtc_state, state);
>   }

Precomputing these is a very good idea.
Reviewed-by: Chris Wilson 
-Chris

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


Re: [Intel-gfx] [PATCH 07/14] drm/i915: Extract i845_cursor_ctl() and i9xx_cursor_ctl()

2017-03-17 Thread Chris Wilson
On Fri, Mar 17, 2017 at 11:18:01PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Pull the code to calculate the cursor control register value into
> separate functions. Allows us to pre-compute them in the future.

Want to comment on the benefit of passing struct intel_crtc_state?
 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 119 
> +--
>  1 file changed, 72 insertions(+), 47 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 99b72c4219a8..040978e704f3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9161,7 +9161,33 @@ static bool haswell_get_pipe_config(struct intel_crtc 
> *crtc,
>   return active;
>  }
>  
> +static u32 i845_cursor_ctl(const struct intel_crtc_state *crtc_state,
> +const struct intel_plane_state *plane_state)
> +{

>  static void i845_update_cursor(struct drm_crtc *crtc, u32 base,
> +const struct intel_crtc_state *crtc_state,
>  const struct intel_plane_state *plane_state)
>  {

Odd mishmap of parameters as both functions seem to use the same state
in the end. (i845/i915_cursor_ctl recovering crtc, dev etc).

Reviewed-by: Chris Wilson 
-Chris

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


Re: [Intel-gfx] [PATCH 06/14] drm/i915: Extract ilk_sprite_ctl()

2017-03-17 Thread Chris Wilson
On Fri, Mar 17, 2017 at 11:18:00PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Pull the code to calculate the ILK-SNB sprite control register value
> into a separate function. Allows us to pre-compute it in the future.
> 
> Signed-off-by: Ville Syrjälä 
Reviewed-by: Chris Wilson 
-Chris

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


Re: [Intel-gfx] [PATCH 01/14] drm/i915: Extract skl_plane_ctl()

2017-03-17 Thread Chris Wilson
On Fri, Mar 17, 2017 at 11:17:55PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Pull the code to calculate the SKL plane control register value into
> a separate function. Allows us to pre-compute it in the future.
> 
> Signed-off-by: Ville Syrjälä 
Reviewed-by: Chris Wilson 
-Chris

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


Re: [Intel-gfx] [PATCH 05/14] drm/i915: Extract ivb_sprite_ctl()

2017-03-17 Thread Chris Wilson
On Fri, Mar 17, 2017 at 11:17:59PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Pull the code to calculate the IVB-BDW sprite control register value
> into a separate function. Allows us to pre-compute it in the future.
> 
> Signed-off-by: Ville Syrjälä 
Reviewed-by: Chris Wilson 

> +static void
> +ivb_update_plane(struct drm_plane *plane,
> +  const struct intel_crtc_state *crtc_state,
> +  const struct intel_plane_state *plane_state)
> +{
> + struct drm_device *dev = plane->dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + struct intel_plane *intel_plane = to_intel_plane(plane);
> + struct drm_framebuffer *fb = plane_state->base.fb;
> + enum pipe pipe = intel_plane->pipe;
> + u32 sprctl, sprscale = 0;
> + u32 sprsurf_offset, linear_offset;
> + unsigned int rotation = plane_state->base.rotation;
> + const struct drm_intel_sprite_colorkey *key = _state->ckey;
> + int crtc_x = plane_state->base.dst.x1;
> + int crtc_y = plane_state->base.dst.y1;
> + uint32_t crtc_w = drm_rect_width(_state->base.dst);
> + uint32_t crtc_h = drm_rect_height(_state->base.dst);
> + uint32_t x = plane_state->base.src.x1 >> 16;
> + uint32_t y = plane_state->base.src.y1 >> 16;
> + uint32_t src_w = drm_rect_width(_state->base.src) >> 16;
> + uint32_t src_h = drm_rect_height(_state->base.src) >> 16;

struct crtc_rectangle { int x, y; u32 w, h; } crtc_r = 
crtc_rectangle(plane_state);
struct source_rectangle { int x, y; u32 w, h; } src_r = 
source_rectangle(plane_state);

c_rect / s_rect?
crtc_rect / src_rect.

Just idly mentioning the large blocks of repeated code.
-Chris

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


Re: [Intel-gfx] [PATCH 04/14] drm/i915: Extract vlv_sprite_ctl()

2017-03-17 Thread Chris Wilson
On Fri, Mar 17, 2017 at 11:17:58PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Pull the code to calculate the VLV/CHV sprite control register value
> into a separate function. Allows us to pre-compute it in the future.
> 
> Signed-off-by: Ville Syrjälä 
Reviewed-by: Chris Wilson 
-Chris

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


Re: [Intel-gfx] [PATCH 03/14] drm/i915: Extract i9xx_plane_ctl()

2017-03-17 Thread Chris Wilson
On Fri, Mar 17, 2017 at 11:17:57PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Pull the code to calculate the pre-SKL primary plane control register
> value into a separate function. Allows us to pre-compute it in the
> future.
> 
> We can also share the code between the i9xx and ilk codepaths as the
> differences are minimal. Actually there are no differences between
> g4x and ilk, so the current split doesn't really make any sense.

Could you do this as 2 passes? I started to freak out seeing hsw/bdw
when checking for no changes from the i9xx_update_primary_plane.
-Chris

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


Re: [Intel-gfx] [PATCH 02/14] drm/i915: Use skl_plane_ctl() for the SKL "sprite" planes

2017-03-17 Thread Chris Wilson
On Fri, Mar 17, 2017 at 11:17:56PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> On SKL the planes are uniform so the "sprites" can use the
> primary plane code perfectly fine. The only difference we
> have is the color key handling, but since we never enable that
> for the primary plane the same code works just fine.

Rationale works for me. Does setting the color key report an -EINVAL on
the primary? Even via the legacy setcolorkey ioctl?
-Chris

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Moar plane update optimizations

2017-03-17 Thread Patchwork
== Series Details ==

Series: drm/i915: Moar plane update optimizations
URL   : https://patchwork.freedesktop.org/series/21475/
State : success

== Summary ==

Series 21475v1 drm/i915: Moar plane update optimizations
https://patchwork.freedesktop.org/api/1.0/series/21475/revisions/1/mbox/

Test kms_cursor_legacy:
Subgroup basic-flip-before-cursor-varying-size:
dmesg-warn -> PASS   (fi-byt-n2820) fdo#100094

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 462s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 585s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 502s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 504s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 440s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 436s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 438s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 517s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 496s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 549s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 419s

ca3e896e9cf4e4c3319bbb51843daa45902927a7 drm-tip: 2017y-03m-17d-18h-26m-58s UTC 
integration manifest
01176d4 WIP/drm/i915: Nuke posting reads from plane updates
eda4237 WIP/drm/i915: Protect the entire pipe update with uncore.lock
859d84b drm/i915: Keep vblanks enabled during the entire pipe update
d2b9e89 drm/i915: Use i9xx_check_plane_surface() for sprite planes as well
db96ecb drm/i915: Eliminate ironlake_update_primary_plane()
44bdc9a drm/i915: Introduce i9xx_check_plane_surface()
1f3f57d drm/i915: Pre-compute plane control register value
68c38ec drm/i915: Extract i845_cursor_ctl() and i9xx_cursor_ctl()
00b8e71 drm/i915: Extract ilk_sprite_ctl()
bc22047 drm/i915: Extract ivb_sprite_ctl()
61284a8 drm/i915: Extract vlv_sprite_ctl()
d9d52a0 drm/i915: Extract i9xx_plane_ctl()
2db4f23 drm/i915: Use skl_plane_ctl() for the SKL "sprite" planes
d9063a1 drm/i915: Extract skl_plane_ctl()

== Logs ==

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


Re: [Intel-gfx] [RFC][PATCH 13/14] WIP/drm/i915: Protect the entire pipe update with uncore.lock

2017-03-17 Thread Chris Wilson
On Fri, Mar 17, 2017 at 11:18:07PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> I'm thinking we'll want to actually spliut the uncore.lock into
> two locks (display vs. gt).

Yes, a single lock for display seems reasonable, esp. given the proof of
principle here.

Hmm, I was thinking we would need a separate one for fw_domains handling,
but that's actually just GT. Splitting into two seems doable.
-Chris

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


Re: [Intel-gfx] [PATCH 12/14] drm/i915: Keep vblanks enabled during the entire pipe update

2017-03-17 Thread Chris Wilson
On Fri, Mar 17, 2017 at 11:18:06PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> We currently hold a vblank referenced while trying to evade the
> vblank, but we drop it as soon as we've done that. After all the
> planes have been committed we are quite likely to grab a new vblank
> reference for delivering the flip event. This causes the vblank
> interrupt to do a enable->enable->disable ping-pong during many
> commits. If we instead hang on to the original vblank reference
> across the entire commit we can eliminate that ping-pong.

Does it make sense to take an an extra vblank_get() only if we have an
event to deliver?

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_sprite.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 26c8bdcd7e72..337e884252e5 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -137,8 +137,6 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
>  
>   finish_wait(wq, );
>  
if (crtc->base.state->event)
drm_crtc_vblank_get(>base);

drm_crtc_vblank_put(>base);

>   crtc->debug.scanline_start = scanline;
>   crtc->debug.start_vbl_time = ktime_get();
>   crtc->debug.start_vbl_count = intel_crtc_get_vblank_counter(crtc);

> @@ -185,6 +183,15 @@ void intel_pipe_update_end(struct intel_crtc *crtc, 
> struct intel_flip_work *work
>   crtc->base.state->event = NULL;
>  
> + /*
> +  * The reference was taken in intel_pipe_update_start(). It could
> +  * have been dropped as soon as the vblank was evaded, but we hold
> +  * on to it until this time to avoid the extra vblank interrupt
> +  * enable->disable->enable ping-pong whenever we have to deliver
> +  * an event.
> +  */
> + drm_crtc_vblank_put(>base);

}

>   local_irq_enable();

-- 
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 07/14] drm/i915: Extract i845_cursor_ctl() and i9xx_cursor_ctl()

2017-03-17 Thread ville . syrjala
From: Ville Syrjälä 

Pull the code to calculate the cursor control register value into
separate functions. Allows us to pre-compute them in the future.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 119 +--
 1 file changed, 72 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 99b72c4219a8..040978e704f3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9161,7 +9161,33 @@ static bool haswell_get_pipe_config(struct intel_crtc 
*crtc,
return active;
 }
 
+static u32 i845_cursor_ctl(const struct intel_crtc_state *crtc_state,
+  const struct intel_plane_state *plane_state)
+{
+   unsigned int width = plane_state->base.crtc_w;
+   unsigned int stride = roundup_pow_of_two(width) * 4;
+
+   switch (stride) {
+   default:
+   WARN_ONCE(1, "Invalid cursor width/stride, width=%u, 
stride=%u\n",
+ width, stride);
+   stride = 256;
+   /* fallthrough */
+   case 256:
+   case 512:
+   case 1024:
+   case 2048:
+   break;
+   }
+
+   return CURSOR_ENABLE |
+   CURSOR_GAMMA_ENABLE |
+   CURSOR_FORMAT_ARGB |
+   CURSOR_STRIDE(stride);
+}
+
 static void i845_update_cursor(struct drm_crtc *crtc, u32 base,
+  const struct intel_crtc_state *crtc_state,
   const struct intel_plane_state *plane_state)
 {
struct drm_device *dev = crtc->dev;
@@ -9172,26 +9198,8 @@ static void i845_update_cursor(struct drm_crtc *crtc, 
u32 base,
if (plane_state && plane_state->base.visible) {
unsigned int width = plane_state->base.crtc_w;
unsigned int height = plane_state->base.crtc_h;
-   unsigned int stride = roundup_pow_of_two(width) * 4;
-
-   switch (stride) {
-   default:
-   WARN_ONCE(1, "Invalid cursor width/stride, width=%u, 
stride=%u\n",
- width, stride);
-   stride = 256;
-   /* fallthrough */
-   case 256:
-   case 512:
-   case 1024:
-   case 2048:
-   break;
-   }
-
-   cntl |= CURSOR_ENABLE |
-   CURSOR_GAMMA_ENABLE |
-   CURSOR_FORMAT_ARGB |
-   CURSOR_STRIDE(stride);
 
+   cntl = i845_cursor_ctl(crtc_state, plane_state);
size = (height << 12) | width;
}
 
@@ -9224,7 +9232,45 @@ static void i845_update_cursor(struct drm_crtc *crtc, 
u32 base,
}
 }
 
+static u32 i9xx_cursor_ctl(const struct intel_crtc_state *crtc_state,
+  const struct intel_plane_state *plane_state)
+{
+   struct drm_i915_private *dev_priv =
+   to_i915(plane_state->base.plane->dev);
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+   enum pipe pipe = crtc->pipe;
+   uint32_t cntl = 0;
+
+   cntl = MCURSOR_GAMMA_ENABLE;
+
+   if (HAS_DDI(dev_priv))
+   cntl |= CURSOR_PIPE_CSC_ENABLE;
+
+   cntl |= pipe << 28; /* Connect to correct pipe */
+
+   switch (plane_state->base.crtc_w) {
+   case 64:
+   cntl |= CURSOR_MODE_64_ARGB_AX;
+   break;
+   case 128:
+   cntl |= CURSOR_MODE_128_ARGB_AX;
+   break;
+   case 256:
+   cntl |= CURSOR_MODE_256_ARGB_AX;
+   break;
+   default:
+   MISSING_CASE(plane_state->base.crtc_w);
+   return 0;
+   }
+
+   if (plane_state->base.rotation & DRM_ROTATE_180)
+   cntl |= CURSOR_ROTATE_180;
+
+   return cntl;
+}
+
 static void i9xx_update_cursor(struct drm_crtc *crtc, u32 base,
+  const struct intel_crtc_state *crtc_state,
   const struct intel_plane_state *plane_state)
 {
struct drm_device *dev = crtc->dev;
@@ -9233,30 +9279,8 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, 
u32 base,
int pipe = intel_crtc->pipe;
uint32_t cntl = 0;
 
-   if (plane_state && plane_state->base.visible) {
-   cntl = MCURSOR_GAMMA_ENABLE;
-   switch (plane_state->base.crtc_w) {
-   case 64:
-   cntl |= CURSOR_MODE_64_ARGB_AX;
-   break;
-   case 128:
-   cntl |= CURSOR_MODE_128_ARGB_AX;
-   break;
-   case 256:
-   cntl |= CURSOR_MODE_256_ARGB_AX;
-  

[Intel-gfx] [PATCH 08/14] drm/i915: Pre-compute plane control register value

2017-03-17 Thread ville . syrjala
From: Ville Syrjälä 

Computing the plane control register value is branchy so moving it out
from the plane commit hook seems prudent. Let's pre-compute it during
the atomic check phase and store the result in the plane state.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 41 ++--
 drivers/gpu/drm/i915/intel_drv.h |  3 +++
 drivers/gpu/drm/i915/intel_sprite.c  | 24 ++---
 3 files changed, 36 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 040978e704f3..2e0106a11f8f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3035,15 +3035,13 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
struct drm_framebuffer *fb = plane_state->base.fb;
int plane = intel_crtc->plane;
u32 linear_offset;
-   u32 dspcntr;
+   u32 dspcntr = plane_state->ctl;
i915_reg_t reg = DSPCNTR(plane);
unsigned int rotation = plane_state->base.rotation;
int x = plane_state->base.src.x1 >> 16;
int y = plane_state->base.src.y1 >> 16;
unsigned long irqflags;
 
-   dspcntr = i9xx_plane_ctl(crtc_state, plane_state);
-
intel_add_fb_offsets(, , plane_state, 0);
 
if (INTEL_GEN(dev_priv) >= 4)
@@ -3133,15 +3131,13 @@ static void ironlake_update_primary_plane(struct 
drm_plane *primary,
struct drm_framebuffer *fb = plane_state->base.fb;
int plane = intel_crtc->plane;
u32 linear_offset;
-   u32 dspcntr;
+   u32 dspcntr = plane_state->ctl;
i915_reg_t reg = DSPCNTR(plane);
unsigned int rotation = plane_state->base.rotation;
int x = plane_state->base.src.x1 >> 16;
int y = plane_state->base.src.y1 >> 16;
unsigned long irqflags;
 
-   dspcntr = i9xx_plane_ctl(crtc_state, plane_state);
-
intel_add_fb_offsets(, , plane_state, 0);
 
intel_crtc->dspaddr_offset =
@@ -3358,7 +3354,7 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
struct drm_framebuffer *fb = plane_state->base.fb;
enum plane_id plane_id = to_intel_plane(plane)->id;
enum pipe pipe = to_intel_plane(plane)->pipe;
-   u32 plane_ctl;
+   u32 plane_ctl = plane_state->ctl;
unsigned int rotation = plane_state->base.rotation;
u32 stride = skl_plane_stride(fb, 0, rotation);
u32 surf_addr = plane_state->main.offset;
@@ -3373,8 +3369,6 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
int dst_h = drm_rect_height(_state->base.dst);
unsigned long irqflags;
 
-   plane_ctl = skl_plane_ctl(crtc_state, plane_state);
-
/* Sizes are 0 based */
src_w--;
src_h--;
@@ -9187,7 +9181,6 @@ static u32 i845_cursor_ctl(const struct intel_crtc_state 
*crtc_state,
 }
 
 static void i845_update_cursor(struct drm_crtc *crtc, u32 base,
-  const struct intel_crtc_state *crtc_state,
   const struct intel_plane_state *plane_state)
 {
struct drm_device *dev = crtc->dev;
@@ -9199,7 +9192,7 @@ static void i845_update_cursor(struct drm_crtc *crtc, u32 
base,
unsigned int width = plane_state->base.crtc_w;
unsigned int height = plane_state->base.crtc_h;
 
-   cntl = i845_cursor_ctl(crtc_state, plane_state);
+   cntl = plane_state->ctl;
size = (height << 12) | width;
}
 
@@ -9270,7 +9263,6 @@ static u32 i9xx_cursor_ctl(const struct intel_crtc_state 
*crtc_state,
 }
 
 static void i9xx_update_cursor(struct drm_crtc *crtc, u32 base,
-  const struct intel_crtc_state *crtc_state,
   const struct intel_plane_state *plane_state)
 {
struct drm_device *dev = crtc->dev;
@@ -9280,7 +9272,7 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32 
base,
uint32_t cntl = 0;
 
if (plane_state && plane_state->base.visible)
-   cntl = i9xx_cursor_ctl(crtc_state, plane_state);
+   cntl = plane_state->ctl;
 
if (intel_crtc->cursor_cntl != cntl) {
I915_WRITE_FW(CURCNTR(pipe), cntl);
@@ -9297,7 +9289,6 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32 
base,
 
 /* If no-part of the cursor is visible on the framebuffer, then the GPU may 
hang... */
 static void intel_crtc_update_cursor(struct drm_crtc *crtc,
-const struct intel_crtc_state *crtc_state,
 const struct intel_plane_state 
*plane_state)
 {
struct drm_device *dev = crtc->dev;
@@ -9337,9 +9328,9 @@ static void intel_crtc_update_cursor(struct drm_crtc 
*crtc,
I915_WRITE_FW(CURPOS(pipe), pos);
 
if (IS_I845G(dev_priv) || 

[Intel-gfx] [RFC][PATCH 14/14] WIP/drm/i915: Nuke posting reads from plane updates

2017-03-17 Thread ville . syrjala
From: Ville Syrjälä 

We'll maybe want just one posting read at the end? This does seem to
potentially shave a few usec off from the update.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 8 
 drivers/gpu/drm/i915/intel_sprite.c  | 8 
 2 files changed, 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index c35818b42762..d9ec654db5a3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3125,7 +3125,6 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
  intel_plane_ggtt_offset(plane_state) +
  intel_crtc->dspaddr_offset);
}
-   POSTING_READ_FW(reg);
 }
 
 static void i9xx_disable_primary_plane(struct drm_plane *primary,
@@ -3141,7 +3140,6 @@ static void i9xx_disable_primary_plane(struct drm_plane 
*primary,
I915_WRITE_FW(DSPSURF(plane), 0);
else
I915_WRITE_FW(DSPADDR(plane), 0);
-   POSTING_READ_FW(DSPCNTR(plane));
 }
 
 static u32
@@ -3379,7 +3377,6 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
I915_WRITE_FW(PLANE_SURF(pipe, plane_id),
  intel_plane_ggtt_offset(plane_state) + surf_addr);
 
-   POSTING_READ_FW(PLANE_SURF(pipe, plane_id));
 }
 
 static void skylake_disable_primary_plane(struct drm_plane *primary,
@@ -3392,7 +3389,6 @@ static void skylake_disable_primary_plane(struct 
drm_plane *primary,
 
I915_WRITE_FW(PLANE_CTL(pipe, plane_id), 0);
I915_WRITE_FW(PLANE_SURF(pipe, plane_id), 0);
-   POSTING_READ_FW(PLANE_SURF(pipe, plane_id));
 }
 
 /* Assume fb object is pinned & idle & fenced and just update base pointers */
@@ -9171,7 +9167,6 @@ static void i845_update_cursor(struct drm_crtc *crtc, u32 
base,
 * whilst the cursor is disabled.
 */
I915_WRITE_FW(CURCNTR(PIPE_A), 0);
-   POSTING_READ_FW(CURCNTR(PIPE_A));
intel_crtc->cursor_cntl = 0;
}
 
@@ -9187,7 +9182,6 @@ static void i845_update_cursor(struct drm_crtc *crtc, u32 
base,
 
if (intel_crtc->cursor_cntl != cntl) {
I915_WRITE_FW(CURCNTR(PIPE_A), cntl);
-   POSTING_READ_FW(CURCNTR(PIPE_A));
intel_crtc->cursor_cntl = cntl;
}
 }
@@ -9243,13 +9237,11 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, 
u32 base,
 
if (intel_crtc->cursor_cntl != cntl) {
I915_WRITE_FW(CURCNTR(pipe), cntl);
-   POSTING_READ_FW(CURCNTR(pipe));
intel_crtc->cursor_cntl = cntl;
}
 
/* and commit changes on next vblank */
I915_WRITE_FW(CURBASE(pipe), base);
-   POSTING_READ_FW(CURBASE(pipe));
 
intel_crtc->cursor_base = base;
 }
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 06c89deca36b..5cf88f95c23e 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -288,7 +288,6 @@ skl_update_plane(struct drm_plane *drm_plane,
I915_WRITE_FW(PLANE_CTL(pipe, plane_id), plane_ctl);
I915_WRITE_FW(PLANE_SURF(pipe, plane_id),
  intel_plane_ggtt_offset(plane_state) + surf_addr);
-   POSTING_READ_FW(PLANE_SURF(pipe, plane_id));
 }
 
 static void
@@ -303,7 +302,6 @@ skl_disable_plane(struct drm_plane *dplane, struct drm_crtc 
*crtc)
I915_WRITE_FW(PLANE_CTL(pipe, plane_id), 0);
 
I915_WRITE_FW(PLANE_SURF(pipe, plane_id), 0);
-   POSTING_READ_FW(PLANE_SURF(pipe, plane_id));
 }
 
 static void
@@ -459,7 +457,6 @@ vlv_update_plane(struct drm_plane *dplane,
I915_WRITE_FW(SPCNTR(pipe, plane_id), sprctl);
I915_WRITE_FW(SPSURF(pipe, plane_id),
  intel_plane_ggtt_offset(plane_state) + sprsurf_offset);
-   POSTING_READ_FW(SPSURF(pipe, plane_id));
 }
 
 static void
@@ -474,7 +471,6 @@ vlv_disable_plane(struct drm_plane *dplane, struct drm_crtc 
*crtc)
I915_WRITE_FW(SPCNTR(pipe, plane_id), 0);
 
I915_WRITE_FW(SPSURF(pipe, plane_id), 0);
-   POSTING_READ_FW(SPSURF(pipe, plane_id));
 }
 
 static u32 ivb_sprite_ctl(const struct intel_crtc_state *crtc_state,
@@ -591,7 +587,6 @@ ivb_update_plane(struct drm_plane *plane,
I915_WRITE_FW(SPRCTL(pipe), sprctl);
I915_WRITE_FW(SPRSURF(pipe),
  intel_plane_ggtt_offset(plane_state) + sprsurf_offset);
-   POSTING_READ_FW(SPRSURF(pipe));
 }
 
 static void
@@ -608,7 +603,6 @@ ivb_disable_plane(struct drm_plane *plane, struct drm_crtc 
*crtc)
I915_WRITE_FW(SPRSCALE(pipe), 0);
 
I915_WRITE_FW(SPRSURF(pipe), 0);
-   POSTING_READ_FW(SPRSURF(pipe));
 }
 
 static u32 ilk_sprite_ctl(const struct intel_crtc_state *crtc_state,
@@ -717,7 +711,6 @@ ilk_update_plane(struct 

[Intel-gfx] [PATCH 12/14] drm/i915: Keep vblanks enabled during the entire pipe update

2017-03-17 Thread ville . syrjala
From: Ville Syrjälä 

We currently hold a vblank referenced while trying to evade the
vblank, but we drop it as soon as we've done that. After all the
planes have been committed we are quite likely to grab a new vblank
reference for delivering the flip event. This causes the vblank
interrupt to do a enable->enable->disable ping-pong during many
commits. If we instead hang on to the original vblank reference
across the entire commit we can eliminate that ping-pong.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_sprite.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 26c8bdcd7e72..337e884252e5 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -137,8 +137,6 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
 
finish_wait(wq, );
 
-   drm_crtc_vblank_put(>base);
-
crtc->debug.scanline_start = scanline;
crtc->debug.start_vbl_time = ktime_get();
crtc->debug.start_vbl_count = intel_crtc_get_vblank_counter(crtc);
@@ -185,6 +183,15 @@ void intel_pipe_update_end(struct intel_crtc *crtc, struct 
intel_flip_work *work
crtc->base.state->event = NULL;
}
 
+   /*
+* The reference was taken in intel_pipe_update_start(). It could
+* have been dropped as soon as the vblank was evaded, but we hold
+* on to it until this time to avoid the extra vblank interrupt
+* enable->disable->enable ping-pong whenever we have to deliver
+* an event.
+*/
+   drm_crtc_vblank_put(>base);
+
local_irq_enable();
 
if (intel_vgpu_active(dev_priv))
-- 
2.10.2

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


[Intel-gfx] [PATCH 10/14] drm/i915: Eliminate ironlake_update_primary_plane()

2017-03-17 Thread ville . syrjala
From: Ville Syrjälä 

The effective difference between i9xx_update_primary_plane()
and ironlake_update_primary_plane() is only the HSW/BDW
DSPOFFSET special case. So bring that over into
i9xx_update_primary_plane() and eliminate the duplicated code.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 55 
 1 file changed, 6 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 024614cb47b6..c7f6bc4e605a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3109,7 +3109,12 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
I915_WRITE_FW(reg, dspcntr);
 
I915_WRITE_FW(DSPSTRIDE(plane), fb->pitches[0]);
-   if (INTEL_GEN(dev_priv) >= 4) {
+   if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
+   I915_WRITE_FW(DSPSURF(plane),
+ intel_plane_ggtt_offset(plane_state) +
+ intel_crtc->dspaddr_offset);
+   I915_WRITE_FW(DSPOFFSET(plane), (y << 16) | x);
+   } else if (INTEL_GEN(dev_priv) >= 4) {
I915_WRITE_FW(DSPSURF(plane),
  intel_plane_ggtt_offset(plane_state) +
  intel_crtc->dspaddr_offset);
@@ -3146,48 +3151,6 @@ static void i9xx_disable_primary_plane(struct drm_plane 
*primary,
spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
 }
 
-static void ironlake_update_primary_plane(struct drm_plane *primary,
- const struct intel_crtc_state 
*crtc_state,
- const struct intel_plane_state 
*plane_state)
-{
-   struct drm_device *dev = primary->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
-   struct drm_framebuffer *fb = plane_state->base.fb;
-   int plane = intel_crtc->plane;
-   u32 linear_offset;
-   u32 dspcntr = plane_state->ctl;
-   i915_reg_t reg = DSPCNTR(plane);
-   int x = plane_state->main.x;
-   int y = plane_state->main.y;
-   unsigned long irqflags;
-
-   linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
-
-   intel_crtc->dspaddr_offset = plane_state->main.offset;
-
-   intel_crtc->adjusted_x = x;
-   intel_crtc->adjusted_y = y;
-
-   spin_lock_irqsave(_priv->uncore.lock, irqflags);
-
-   I915_WRITE_FW(reg, dspcntr);
-
-   I915_WRITE_FW(DSPSTRIDE(plane), fb->pitches[0]);
-   I915_WRITE_FW(DSPSURF(plane),
- intel_plane_ggtt_offset(plane_state) +
- intel_crtc->dspaddr_offset);
-   if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
-   I915_WRITE_FW(DSPOFFSET(plane), (y << 16) | x);
-   } else {
-   I915_WRITE_FW(DSPTILEOFF(plane), (y << 16) | x);
-   I915_WRITE_FW(DSPLINOFF(plane), linear_offset);
-   }
-   POSTING_READ_FW(reg);
-
-   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
-}
-
 static u32
 intel_fb_stride_alignment(const struct drm_framebuffer *fb, int plane)
 {
@@ -13642,12 +13605,6 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
 
primary->update_plane = skylake_update_primary_plane;
primary->disable_plane = skylake_disable_primary_plane;
-   } else if (HAS_PCH_SPLIT(dev_priv)) {
-   intel_primary_formats = i965_primary_formats;
-   num_formats = ARRAY_SIZE(i965_primary_formats);
-
-   primary->update_plane = ironlake_update_primary_plane;
-   primary->disable_plane = i9xx_disable_primary_plane;
} else if (INTEL_GEN(dev_priv) >= 4) {
intel_primary_formats = i965_primary_formats;
num_formats = ARRAY_SIZE(i965_primary_formats);
-- 
2.10.2

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


[Intel-gfx] [RFC][PATCH 13/14] WIP/drm/i915: Protect the entire pipe update with uncore.lock

2017-03-17 Thread ville . syrjala
From: Ville Syrjälä 

I'm thinking we'll want to actually spliut the uncore.lock into
two locks (display vs. gt). But this is just a proof of concept and
it is indeed quote effective, especially with lockdep and whatnot
enabled.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_irq.c  | 66 
 drivers/gpu/drm/i915/i915_trace.h| 28 +++
 drivers/gpu/drm/i915/intel_display.c | 51 
 drivers/gpu/drm/i915/intel_drv.h |  7 ++--
 drivers/gpu/drm/i915/intel_pm.c  | 11 +++---
 drivers/gpu/drm/i915/intel_sprite.c  | 57 ++-
 6 files changed, 104 insertions(+), 116 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index cb20c9408b12..113de4309b41 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -715,15 +715,13 @@ static void i915_enable_asle_pipestat(struct 
drm_i915_private *dev_priv)
 /* Called from drm generic code, passed a 'crtc', which
  * we use as a pipe index
  */
-static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int pipe)
+static u32 __i915_get_vblank_counter(struct intel_crtc *crtc)
 {
-   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
i915_reg_t high_frame, low_frame;
u32 high1, high2, low, pixel, vbl_start, hsync_start, htotal;
-   struct intel_crtc *intel_crtc = intel_get_crtc_for_pipe(dev_priv,
-   pipe);
-   const struct drm_display_mode *mode = _crtc->base.hwmode;
-   unsigned long irqflags;
+   const struct drm_display_mode *mode = >base.hwmode;
 
htotal = mode->crtc_htotal;
hsync_start = mode->crtc_hsync_start;
@@ -740,8 +738,6 @@ static u32 i915_get_vblank_counter(struct drm_device *dev, 
unsigned int pipe)
high_frame = PIPEFRAME(pipe);
low_frame = PIPEFRAMEPIXEL(pipe);
 
-   spin_lock_irqsave(_priv->uncore.lock, irqflags);
-
/*
 * High & low register fields aren't synchronized, so make sure
 * we get a low value that's stable across two reads of the high
@@ -753,8 +749,6 @@ static u32 i915_get_vblank_counter(struct drm_device *dev, 
unsigned int pipe)
high2 = I915_READ_FW(high_frame) & PIPE_FRAME_HIGH_MASK;
} while (high1 != high2);
 
-   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
-
high1 >>= PIPE_FRAME_HIGH_SHIFT;
pixel = low & PIPE_PIXEL_MASK;
low >>= PIPE_FRAME_LOW_SHIFT;
@@ -767,15 +761,57 @@ static u32 i915_get_vblank_counter(struct drm_device 
*dev, unsigned int pipe)
return (((high1 << 8) | low) + (pixel >= vbl_start)) & 0xff;
 }
 
+static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int pipe)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+   unsigned long irqflags;
+   u32 ret;
+
+   spin_lock_irqsave(_priv->uncore.lock, irqflags);
+   ret = __i915_get_vblank_counter(crtc);
+   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
+
+   return ret;
+}
+
+static u32 __g4x_get_vblank_counter(struct intel_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
+
+   return I915_READ_FW(PIPE_FRMCOUNT_G4X(pipe));
+}
+
 static u32 g4x_get_vblank_counter(struct drm_device *dev, unsigned int pipe)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+   unsigned long irqflags;
+   u32 ret;
+
+   spin_lock_irqsave(_priv->uncore.lock, irqflags);
+   ret = __g4x_get_vblank_counter(crtc);
+   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
+
+   return ret;
+}
 
-   return I915_READ(PIPE_FRMCOUNT_G4X(pipe));
+u32 __intel_crtc_get_vblank_counter(struct intel_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+
+   if (IS_GEN2(dev_priv)) {
+   return 0;
+   } else if (IS_G4X(dev_priv) || INTEL_GEN(dev_priv) >= 5) {
+   return __g4x_get_vblank_counter(crtc);
+   } else {
+   return __i915_get_vblank_counter(crtc);
+   }
 }
 
 /* I915_READ_FW, only for fast reads of display block, no need for forcewake 
etc. */
-static int __intel_get_crtc_scanline(struct intel_crtc *crtc)
+int __intel_crtc_get_scanline(struct intel_crtc *crtc)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -878,7 +914,7 @@ static int i915_get_crtc_scanoutpos(struct drm_device *dev, 
unsigned int pipe,
/* No obvious pixelcount register. Only 

[Intel-gfx] [PATCH 11/14] drm/i915: Use i9xx_check_plane_surface() for sprite planes as well

2017-03-17 Thread ville . syrjala
From: Ville Syrjälä 

All the pre-SKL sprite planes compute the x/y/tile offsets in a
similar way. There are a couple of minor differences but the primary
planes have those as well. Thus i9xx_check_plane_surface()
already does what we need, so let's use it.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c |  2 +-
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_sprite.c  | 70 +---
 3 files changed, 26 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index c7f6bc4e605a..34d833975b32 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3026,7 +3026,7 @@ static u32 i9xx_plane_ctl(const struct intel_crtc_state 
*crtc_state,
return dspcntr;
 }
 
-static int i9xx_check_plane_surface(struct intel_plane_state *plane_state)
+int i9xx_check_plane_surface(struct intel_plane_state *plane_state)
 {
struct drm_i915_private *dev_priv =
to_i915(plane_state->base.plane->dev);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a35442eadd36..15e3eb2824e3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1453,6 +1453,7 @@ u32 skl_plane_ctl(const struct intel_crtc_state 
*crtc_state,
 u32 skl_plane_stride(const struct drm_framebuffer *fb, int plane,
 unsigned int rotation);
 int skl_check_plane_surface(struct intel_plane_state *plane_state);
+int i9xx_check_plane_surface(struct intel_plane_state *plane_state);
 
 /* intel_csr.c */
 void intel_csr_ucode_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 6b76012ded1a..26c8bdcd7e72 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -419,35 +419,21 @@ vlv_update_plane(struct drm_plane *dplane,
enum pipe pipe = intel_plane->pipe;
enum plane_id plane_id = intel_plane->id;
u32 sprctl = plane_state->ctl;
-   u32 sprsurf_offset, linear_offset;
-   unsigned int rotation = plane_state->base.rotation;
+   u32 sprsurf_offset = plane_state->main.offset;
+   u32 linear_offset;
const struct drm_intel_sprite_colorkey *key = _state->ckey;
int crtc_x = plane_state->base.dst.x1;
int crtc_y = plane_state->base.dst.y1;
uint32_t crtc_w = drm_rect_width(_state->base.dst);
uint32_t crtc_h = drm_rect_height(_state->base.dst);
-   uint32_t x = plane_state->base.src.x1 >> 16;
-   uint32_t y = plane_state->base.src.y1 >> 16;
-   uint32_t src_w = drm_rect_width(_state->base.src) >> 16;
-   uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
+   uint32_t x = plane_state->main.x;
+   uint32_t y = plane_state->main.y;
unsigned long irqflags;
 
/* Sizes are 0 based */
-   src_w--;
-   src_h--;
crtc_w--;
crtc_h--;
 
-   intel_add_fb_offsets(, , plane_state, 0);
-   sprsurf_offset = intel_compute_tile_offset(, , plane_state, 0);
-
-   if (rotation & DRM_ROTATE_180) {
-   x += src_w;
-   y += src_h;
-   } else if (rotation & DRM_REFLECT_X) {
-   x += src_w;
-   }
-
linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
 
spin_lock_irqsave(_priv->uncore.lock, irqflags);
@@ -566,15 +552,15 @@ ivb_update_plane(struct drm_plane *plane,
struct drm_framebuffer *fb = plane_state->base.fb;
enum pipe pipe = intel_plane->pipe;
u32 sprctl = plane_state->ctl, sprscale = 0;
-   u32 sprsurf_offset, linear_offset;
-   unsigned int rotation = plane_state->base.rotation;
+   u32 sprsurf_offset = plane_state->main.offset;
+   u32 linear_offset;
const struct drm_intel_sprite_colorkey *key = _state->ckey;
int crtc_x = plane_state->base.dst.x1;
int crtc_y = plane_state->base.dst.y1;
uint32_t crtc_w = drm_rect_width(_state->base.dst);
uint32_t crtc_h = drm_rect_height(_state->base.dst);
-   uint32_t x = plane_state->base.src.x1 >> 16;
-   uint32_t y = plane_state->base.src.y1 >> 16;
+   uint32_t x = plane_state->main.x;
+   uint32_t y = plane_state->main.y;
uint32_t src_w = drm_rect_width(_state->base.src) >> 16;
uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
unsigned long irqflags;
@@ -588,16 +574,6 @@ ivb_update_plane(struct drm_plane *plane,
if (crtc_w != src_w || crtc_h != src_h)
sprscale = SPRITE_SCALE_ENABLE | (src_w << 16) | src_h;
 
-   intel_add_fb_offsets(, , plane_state, 0);
-   sprsurf_offset = intel_compute_tile_offset(, , plane_state, 0);
-
-   /* HSW+ does this automagically in hardware */
-   if (!IS_HASWELL(dev_priv) && 

[Intel-gfx] [PATCH 06/14] drm/i915: Extract ilk_sprite_ctl()

2017-03-17 Thread ville . syrjala
From: Ville Syrjälä 

Pull the code to calculate the ILK-SNB sprite control register value
into a separate function. Allows us to pre-compute it in the future.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_sprite.c | 72 +
 1 file changed, 41 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index a3a847a3b39f..12e33bc149e4 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -659,31 +659,20 @@ ivb_disable_plane(struct drm_plane *plane, struct 
drm_crtc *crtc)
spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
 }
 
-static void
-ilk_update_plane(struct drm_plane *plane,
-const struct intel_crtc_state *crtc_state,
-const struct intel_plane_state *plane_state)
+static u32 ilk_sprite_ctl(const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
 {
-   struct drm_device *dev = plane->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_plane *intel_plane = to_intel_plane(plane);
-   struct drm_framebuffer *fb = plane_state->base.fb;
-   int pipe = intel_plane->pipe;
-   u32 dvscntr, dvsscale;
-   u32 dvssurf_offset, linear_offset;
+   struct drm_i915_private *dev_priv =
+   to_i915(plane_state->base.plane->dev);
+   const struct drm_framebuffer *fb = plane_state->base.fb;
unsigned int rotation = plane_state->base.rotation;
const struct drm_intel_sprite_colorkey *key = _state->ckey;
-   int crtc_x = plane_state->base.dst.x1;
-   int crtc_y = plane_state->base.dst.y1;
-   uint32_t crtc_w = drm_rect_width(_state->base.dst);
-   uint32_t crtc_h = drm_rect_height(_state->base.dst);
-   uint32_t x = plane_state->base.src.x1 >> 16;
-   uint32_t y = plane_state->base.src.y1 >> 16;
-   uint32_t src_w = drm_rect_width(_state->base.src) >> 16;
-   uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
-   unsigned long irqflags;
+   u32 dvscntr;
+
+   dvscntr = DVS_ENABLE | DVS_GAMMA_ENABLE;
 
-   dvscntr = DVS_ENABLE;
+   if (IS_GEN6(dev_priv))
+   dvscntr |= DVS_TRICKLE_FEED_DISABLE;
 
switch (fb->format->format) {
case DRM_FORMAT_XBGR:
@@ -705,29 +694,50 @@ ilk_update_plane(struct drm_plane *plane,
dvscntr |= DVS_FORMAT_YUV422 | DVS_YUV_ORDER_VYUY;
break;
default:
-   BUG();
+   MISSING_CASE(fb->format->format);
+   return 0;
}
 
-   /*
-* Enable gamma to match primary/cursor plane behaviour.
-* FIXME should be user controllable via propertiesa.
-*/
-   dvscntr |= DVS_GAMMA_ENABLE;
-
if (fb->modifier == I915_FORMAT_MOD_X_TILED)
dvscntr |= DVS_TILED;
 
if (rotation & DRM_ROTATE_180)
dvscntr |= DVS_ROTATE_180;
 
-   if (IS_GEN6(dev_priv))
-   dvscntr |= DVS_TRICKLE_FEED_DISABLE; /* must disable */
-
if (key->flags & I915_SET_COLORKEY_DESTINATION)
dvscntr |= DVS_DEST_KEY;
else if (key->flags & I915_SET_COLORKEY_SOURCE)
dvscntr |= DVS_SOURCE_KEY;
 
+   return dvscntr;
+}
+
+static void
+ilk_update_plane(struct drm_plane *plane,
+const struct intel_crtc_state *crtc_state,
+const struct intel_plane_state *plane_state)
+{
+   struct drm_device *dev = plane->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_plane *intel_plane = to_intel_plane(plane);
+   struct drm_framebuffer *fb = plane_state->base.fb;
+   int pipe = intel_plane->pipe;
+   u32 dvscntr, dvsscale;
+   u32 dvssurf_offset, linear_offset;
+   unsigned int rotation = plane_state->base.rotation;
+   const struct drm_intel_sprite_colorkey *key = _state->ckey;
+   int crtc_x = plane_state->base.dst.x1;
+   int crtc_y = plane_state->base.dst.y1;
+   uint32_t crtc_w = drm_rect_width(_state->base.dst);
+   uint32_t crtc_h = drm_rect_height(_state->base.dst);
+   uint32_t x = plane_state->base.src.x1 >> 16;
+   uint32_t y = plane_state->base.src.y1 >> 16;
+   uint32_t src_w = drm_rect_width(_state->base.src) >> 16;
+   uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
+   unsigned long irqflags;
+
+   dvscntr = ilk_sprite_ctl(crtc_state, plane_state);
+
/* Sizes are 0 based */
src_w--;
src_h--;
-- 
2.10.2

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


[Intel-gfx] [PATCH 09/14] drm/i915: Introduce i9xx_check_plane_surface()

2017-03-17 Thread ville . syrjala
From: Ville Syrjälä 

Extract the primary plane surfae offset/x/y calculations for
pre-SKL platforms into a common function, and call it during the
atomic check phase to reduce the amount of stuff we have to do
during the commit phase. SKL is already doing this.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 82 ++--
 1 file changed, 50 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 2e0106a11f8f..024614cb47b6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3026,6 +3026,43 @@ static u32 i9xx_plane_ctl(const struct intel_crtc_state 
*crtc_state,
return dspcntr;
 }
 
+static int i9xx_check_plane_surface(struct intel_plane_state *plane_state)
+{
+   struct drm_i915_private *dev_priv =
+   to_i915(plane_state->base.plane->dev);
+   int src_x = plane_state->base.src.x1 >> 16;
+   int src_y = plane_state->base.src.y1 >> 16;
+   u32 offset;
+
+   intel_add_fb_offsets(_x, _y, plane_state, 0);
+
+   if (INTEL_GEN(dev_priv) >= 4)
+   offset = intel_compute_tile_offset(_x, _y,
+  plane_state, 0);
+   else
+   offset = 0;
+
+   /* HSW+ does this automagically in hardware */
+   if (!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv)) {
+   unsigned int rotation = plane_state->base.rotation;
+   int src_w = drm_rect_width(_state->base.src) >> 16;
+   int src_h = drm_rect_height(_state->base.src) >> 16;
+
+   if (rotation & DRM_ROTATE_180) {
+   src_x += src_w - 1;
+   src_y += src_h - 1;
+   } else if (rotation & DRM_REFLECT_X) {
+   src_x += src_w - 1;
+   }
+   }
+
+   plane_state->main.offset = offset;
+   plane_state->main.x = src_x;
+   plane_state->main.y = src_y;
+
+   return 0;
+}
+
 static void i9xx_update_primary_plane(struct drm_plane *primary,
  const struct intel_crtc_state *crtc_state,
  const struct intel_plane_state 
*plane_state)
@@ -3037,27 +3074,15 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
u32 linear_offset;
u32 dspcntr = plane_state->ctl;
i915_reg_t reg = DSPCNTR(plane);
-   unsigned int rotation = plane_state->base.rotation;
-   int x = plane_state->base.src.x1 >> 16;
-   int y = plane_state->base.src.y1 >> 16;
+   int x = plane_state->main.x;
+   int y = plane_state->main.y;
unsigned long irqflags;
 
-   intel_add_fb_offsets(, , plane_state, 0);
-
-   if (INTEL_GEN(dev_priv) >= 4)
-   intel_crtc->dspaddr_offset =
-   intel_compute_tile_offset(, , plane_state, 0);
-
-   if (rotation & DRM_ROTATE_180) {
-   x += crtc_state->pipe_src_w - 1;
-   y += crtc_state->pipe_src_h - 1;
-   } else if (rotation & DRM_REFLECT_X) {
-   x += crtc_state->pipe_src_w - 1;
-   }
-
linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
 
-   if (INTEL_GEN(dev_priv) < 4)
+   if (INTEL_GEN(dev_priv) >= 4)
+   intel_crtc->dspaddr_offset = plane_state->main.offset;
+   else
intel_crtc->dspaddr_offset = linear_offset;
 
intel_crtc->adjusted_x = x;
@@ -3133,25 +3158,14 @@ static void ironlake_update_primary_plane(struct 
drm_plane *primary,
u32 linear_offset;
u32 dspcntr = plane_state->ctl;
i915_reg_t reg = DSPCNTR(plane);
-   unsigned int rotation = plane_state->base.rotation;
-   int x = plane_state->base.src.x1 >> 16;
-   int y = plane_state->base.src.y1 >> 16;
+   int x = plane_state->main.x;
+   int y = plane_state->main.y;
unsigned long irqflags;
 
-   intel_add_fb_offsets(, , plane_state, 0);
-
-   intel_crtc->dspaddr_offset =
-   intel_compute_tile_offset(, , plane_state, 0);
-
-   /* HSW+ does this automagically in hardware */
-   if (!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv) &&
-   rotation & DRM_ROTATE_180) {
-   x += crtc_state->pipe_src_w - 1;
-   y += crtc_state->pipe_src_h - 1;
-   }
-
linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
 
+   intel_crtc->dspaddr_offset = plane_state->main.offset;
+
intel_crtc->adjusted_x = x;
intel_crtc->adjusted_y = y;
 
@@ -13365,6 +13379,10 @@ intel_check_primary_plane(struct drm_plane *plane,
 
state->ctl = skl_plane_ctl(crtc_state, state);
} else {
+   ret = i9xx_check_plane_surface(state);
+   if (ret)
+   return ret;
+
   

[Intel-gfx] [PATCH 04/14] drm/i915: Extract vlv_sprite_ctl()

2017-03-17 Thread ville . syrjala
From: Ville Syrjälä 

Pull the code to calculate the VLV/CHV sprite control register value
into a separate function. Allows us to pre-compute it in the future.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_sprite.c | 71 +++--
 1 file changed, 37 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 455a9ed44204..ed4db9276c59 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -345,32 +345,15 @@ chv_update_csc(struct intel_plane *intel_plane, uint32_t 
format)
I915_WRITE_FW(SPCSCCROCLAMP(plane_id), SPCSC_OMAX(1023) | 
SPCSC_OMIN(0));
 }
 
-static void
-vlv_update_plane(struct drm_plane *dplane,
-const struct intel_crtc_state *crtc_state,
-const struct intel_plane_state *plane_state)
+static u32 vlv_sprite_ctl(const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
 {
-   struct drm_device *dev = dplane->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_plane *intel_plane = to_intel_plane(dplane);
-   struct drm_framebuffer *fb = plane_state->base.fb;
-   enum pipe pipe = intel_plane->pipe;
-   enum plane_id plane_id = intel_plane->id;
-   u32 sprctl;
-   u32 sprsurf_offset, linear_offset;
+   const struct drm_framebuffer *fb = plane_state->base.fb;
unsigned int rotation = plane_state->base.rotation;
const struct drm_intel_sprite_colorkey *key = _state->ckey;
-   int crtc_x = plane_state->base.dst.x1;
-   int crtc_y = plane_state->base.dst.y1;
-   uint32_t crtc_w = drm_rect_width(_state->base.dst);
-   uint32_t crtc_h = drm_rect_height(_state->base.dst);
-   uint32_t x = plane_state->base.src.x1 >> 16;
-   uint32_t y = plane_state->base.src.y1 >> 16;
-   uint32_t src_w = drm_rect_width(_state->base.src) >> 16;
-   uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
-   unsigned long irqflags;
+   u32 sprctl;
 
-   sprctl = SP_ENABLE;
+   sprctl = SP_ENABLE | SP_GAMMA_ENABLE;
 
switch (fb->format->format) {
case DRM_FORMAT_YUYV:
@@ -407,20 +390,10 @@ vlv_update_plane(struct drm_plane *dplane,
sprctl |= SP_FORMAT_RGBA;
break;
default:
-   /*
-* If we get here one of the upper layers failed to filter
-* out the unsupported plane formats
-*/
-   BUG();
-   break;
+   MISSING_CASE(fb->format->format);
+   return 0;
}
 
-   /*
-* Enable gamma to match primary/cursor plane behaviour.
-* FIXME should be user controllable via propertiesa.
-*/
-   sprctl |= SP_GAMMA_ENABLE;
-
if (fb->modifier == I915_FORMAT_MOD_X_TILED)
sprctl |= SP_TILED;
 
@@ -433,6 +406,36 @@ vlv_update_plane(struct drm_plane *dplane,
if (key->flags & I915_SET_COLORKEY_SOURCE)
sprctl |= SP_SOURCE_KEY;
 
+   return sprctl;
+}
+
+static void
+vlv_update_plane(struct drm_plane *dplane,
+const struct intel_crtc_state *crtc_state,
+const struct intel_plane_state *plane_state)
+{
+   struct drm_device *dev = dplane->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_plane *intel_plane = to_intel_plane(dplane);
+   struct drm_framebuffer *fb = plane_state->base.fb;
+   enum pipe pipe = intel_plane->pipe;
+   enum plane_id plane_id = intel_plane->id;
+   u32 sprctl;
+   u32 sprsurf_offset, linear_offset;
+   unsigned int rotation = plane_state->base.rotation;
+   const struct drm_intel_sprite_colorkey *key = _state->ckey;
+   int crtc_x = plane_state->base.dst.x1;
+   int crtc_y = plane_state->base.dst.y1;
+   uint32_t crtc_w = drm_rect_width(_state->base.dst);
+   uint32_t crtc_h = drm_rect_height(_state->base.dst);
+   uint32_t x = plane_state->base.src.x1 >> 16;
+   uint32_t y = plane_state->base.src.y1 >> 16;
+   uint32_t src_w = drm_rect_width(_state->base.src) >> 16;
+   uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
+   unsigned long irqflags;
+
+   sprctl = vlv_sprite_ctl(crtc_state, plane_state);
+
/* Sizes are 0 based */
src_w--;
src_h--;
-- 
2.10.2

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


[Intel-gfx] [PATCH 03/14] drm/i915: Extract i9xx_plane_ctl()

2017-03-17 Thread ville . syrjala
From: Ville Syrjälä 

Pull the code to calculate the pre-SKL primary plane control register
value into a separate function. Allows us to pre-compute it in the
future.

We can also share the code between the i9xx and ilk codepaths as the
differences are minimal. Actually there are no differences between
g4x and ilk, so the current split doesn't really make any sense.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 94 +++-
 1 file changed, 38 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8a9f1bd21e0e..99b72c4219a8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2962,28 +2962,27 @@ int skl_check_plane_surface(struct intel_plane_state 
*plane_state)
return 0;
 }
 
-static void i9xx_update_primary_plane(struct drm_plane *primary,
- const struct intel_crtc_state *crtc_state,
- const struct intel_plane_state 
*plane_state)
+static u32 i9xx_plane_ctl(const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
 {
-   struct drm_i915_private *dev_priv = to_i915(primary->dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
-   struct drm_framebuffer *fb = plane_state->base.fb;
-   int plane = intel_crtc->plane;
-   u32 linear_offset;
-   u32 dspcntr;
-   i915_reg_t reg = DSPCNTR(plane);
+   struct drm_i915_private *dev_priv =
+   to_i915(plane_state->base.plane->dev);
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+   const struct drm_framebuffer *fb = plane_state->base.fb;
unsigned int rotation = plane_state->base.rotation;
-   int x = plane_state->base.src.x1 >> 16;
-   int y = plane_state->base.src.y1 >> 16;
-   unsigned long irqflags;
+   u32 dspcntr;
 
-   dspcntr = DISPPLANE_GAMMA_ENABLE;
+   dspcntr = DISPLAY_PLANE_ENABLE | DISPPLANE_GAMMA_ENABLE;
 
-   dspcntr |= DISPLAY_PLANE_ENABLE;
+   if (IS_G4X(dev_priv) || IS_GEN5(dev_priv) ||
+   IS_GEN6(dev_priv) || IS_IVYBRIDGE(dev_priv))
+   dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
+
+   if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
+   dspcntr |= DISPPLANE_PIPE_CSC_ENABLE;
 
if (INTEL_GEN(dev_priv) < 4) {
-   if (intel_crtc->pipe == PIPE_B)
+   if (crtc->pipe == PIPE_B)
dspcntr |= DISPPLANE_SEL_PIPE_B;
}
 
@@ -3010,7 +3009,8 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
dspcntr |= DISPPLANE_RGBX101010;
break;
default:
-   BUG();
+   MISSING_CASE(fb->format->format);
+   return 0;
}
 
if (INTEL_GEN(dev_priv) >= 4 &&
@@ -3023,8 +3023,26 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
if (rotation & DRM_REFLECT_X)
dspcntr |= DISPPLANE_MIRROR;
 
-   if (IS_G4X(dev_priv))
-   dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
+   return dspcntr;
+}
+
+static void i9xx_update_primary_plane(struct drm_plane *primary,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state 
*plane_state)
+{
+   struct drm_i915_private *dev_priv = to_i915(primary->dev);
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
+   struct drm_framebuffer *fb = plane_state->base.fb;
+   int plane = intel_crtc->plane;
+   u32 linear_offset;
+   u32 dspcntr;
+   i915_reg_t reg = DSPCNTR(plane);
+   unsigned int rotation = plane_state->base.rotation;
+   int x = plane_state->base.src.x1 >> 16;
+   int y = plane_state->base.src.y1 >> 16;
+   unsigned long irqflags;
+
+   dspcntr = i9xx_plane_ctl(crtc_state, plane_state);
 
intel_add_fb_offsets(, , plane_state, 0);
 
@@ -3122,43 +3140,7 @@ static void ironlake_update_primary_plane(struct 
drm_plane *primary,
int y = plane_state->base.src.y1 >> 16;
unsigned long irqflags;
 
-   dspcntr = DISPPLANE_GAMMA_ENABLE;
-   dspcntr |= DISPLAY_PLANE_ENABLE;
-
-   if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
-   dspcntr |= DISPPLANE_PIPE_CSC_ENABLE;
-
-   switch (fb->format->format) {
-   case DRM_FORMAT_C8:
-   dspcntr |= DISPPLANE_8BPP;
-   break;
-   case DRM_FORMAT_RGB565:
-   dspcntr |= DISPPLANE_BGRX565;
-   break;
-   case DRM_FORMAT_XRGB:
-   dspcntr |= DISPPLANE_BGRX888;
-   break;
-   case DRM_FORMAT_XBGR:
-   dspcntr |= DISPPLANE_RGBX888;

[Intel-gfx] [PATCH 02/14] drm/i915: Use skl_plane_ctl() for the SKL "sprite" planes

2017-03-17 Thread ville . syrjala
From: Ville Syrjälä 

On SKL the planes are uniform so the "sprites" can use the
primary plane code perfectly fine. The only difference we
have is the color key handling, but since we never enable that
for the primary plane the same code works just fine.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 16 +++-
 drivers/gpu/drm/i915/intel_drv.h |  5 ++---
 drivers/gpu/drm/i915/intel_sprite.c  | 18 +-
 3 files changed, 14 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 6ddf5c90d15c..8a9f1bd21e0e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3254,7 +3254,7 @@ u32 skl_plane_stride(const struct drm_framebuffer *fb, 
int plane,
return stride;
 }
 
-u32 skl_plane_ctl_format(uint32_t pixel_format)
+static u32 skl_plane_ctl_format(uint32_t pixel_format)
 {
switch (pixel_format) {
case DRM_FORMAT_C8:
@@ -3295,7 +3295,7 @@ u32 skl_plane_ctl_format(uint32_t pixel_format)
return 0;
 }
 
-u32 skl_plane_ctl_tiling(uint64_t fb_modifier)
+static u32 skl_plane_ctl_tiling(uint64_t fb_modifier)
 {
switch (fb_modifier) {
case DRM_FORMAT_MOD_NONE:
@@ -3313,7 +3313,7 @@ u32 skl_plane_ctl_tiling(uint64_t fb_modifier)
return 0;
 }
 
-u32 skl_plane_ctl_rotation(unsigned int rotation)
+static u32 skl_plane_ctl_rotation(unsigned int rotation)
 {
switch (rotation) {
case DRM_ROTATE_0:
@@ -3335,13 +3335,14 @@ u32 skl_plane_ctl_rotation(unsigned int rotation)
return 0;
 }
 
-static u32 skl_plane_ctl(const struct intel_crtc_state *crtc_state,
-const struct intel_plane_state *plane_state)
+u32 skl_plane_ctl(const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
 {
struct drm_i915_private *dev_priv =
to_i915(plane_state->base.plane->dev);
const struct drm_framebuffer *fb = plane_state->base.fb;
unsigned int rotation = plane_state->base.rotation;
+   const struct drm_intel_sprite_colorkey *key = _state->ckey;
u32 plane_ctl;
 
plane_ctl = PLANE_CTL_ENABLE;
@@ -3357,6 +3358,11 @@ static u32 skl_plane_ctl(const struct intel_crtc_state 
*crtc_state,
plane_ctl |= skl_plane_ctl_tiling(fb->modifier);
plane_ctl |= skl_plane_ctl_rotation(rotation);
 
+   if (key->flags & I915_SET_COLORKEY_DESTINATION)
+   plane_ctl |= PLANE_CTL_KEY_ENABLE_DESTINATION;
+   else if (key->flags & I915_SET_COLORKEY_SOURCE)
+   plane_ctl |= PLANE_CTL_KEY_ENABLE_SOURCE;
+
return plane_ctl;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 51228fe4283b..45e55b45e772 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1445,9 +1445,8 @@ static inline u32 intel_plane_ggtt_offset(const struct 
intel_plane_state *state)
return i915_ggtt_offset(state->vma);
 }
 
-u32 skl_plane_ctl_format(uint32_t pixel_format);
-u32 skl_plane_ctl_tiling(uint64_t fb_modifier);
-u32 skl_plane_ctl_rotation(unsigned int rotation);
+u32 skl_plane_ctl(const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state);
 u32 skl_plane_stride(const struct drm_framebuffer *fb, int plane,
 unsigned int rotation);
 int skl_check_plane_surface(struct intel_plane_state *plane_state);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index b931d0bd7a64..455a9ed44204 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -232,23 +232,7 @@ skl_update_plane(struct drm_plane *drm_plane,
uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
unsigned long irqflags;
 
-   plane_ctl = PLANE_CTL_ENABLE;
-
-   if (!IS_GEMINILAKE(dev_priv)) {
-   plane_ctl |=
-   PLANE_CTL_PIPE_GAMMA_ENABLE |
-   PLANE_CTL_PIPE_CSC_ENABLE |
-   PLANE_CTL_PLANE_GAMMA_DISABLE;
-   }
-
-   plane_ctl |= skl_plane_ctl_format(fb->format->format);
-   plane_ctl |= skl_plane_ctl_tiling(fb->modifier);
-   plane_ctl |= skl_plane_ctl_rotation(rotation);
-
-   if (key->flags & I915_SET_COLORKEY_DESTINATION)
-   plane_ctl |= PLANE_CTL_KEY_ENABLE_DESTINATION;
-   else if (key->flags & I915_SET_COLORKEY_SOURCE)
-   plane_ctl |= PLANE_CTL_KEY_ENABLE_SOURCE;
+   plane_ctl = skl_plane_ctl(crtc_state, plane_state);
 
/* Sizes are 0 based */
src_w--;
-- 
2.10.2

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


[Intel-gfx] [PATCH 05/14] drm/i915: Extract ivb_sprite_ctl()

2017-03-17 Thread ville . syrjala
From: Ville Syrjälä 

Pull the code to calculate the IVB-BDW sprite control register value
into a separate function. Allows us to pre-compute it in the future.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_sprite.c | 80 -
 1 file changed, 44 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index ed4db9276c59..a3a847a3b39f 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -503,31 +503,23 @@ vlv_disable_plane(struct drm_plane *dplane, struct 
drm_crtc *crtc)
spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
 }
 
-static void
-ivb_update_plane(struct drm_plane *plane,
-const struct intel_crtc_state *crtc_state,
-const struct intel_plane_state *plane_state)
+static u32 ivb_sprite_ctl(const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
 {
-   struct drm_device *dev = plane->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_plane *intel_plane = to_intel_plane(plane);
-   struct drm_framebuffer *fb = plane_state->base.fb;
-   enum pipe pipe = intel_plane->pipe;
-   u32 sprctl, sprscale = 0;
-   u32 sprsurf_offset, linear_offset;
+   struct drm_i915_private *dev_priv =
+   to_i915(plane_state->base.plane->dev);
+   const struct drm_framebuffer *fb = plane_state->base.fb;
unsigned int rotation = plane_state->base.rotation;
const struct drm_intel_sprite_colorkey *key = _state->ckey;
-   int crtc_x = plane_state->base.dst.x1;
-   int crtc_y = plane_state->base.dst.y1;
-   uint32_t crtc_w = drm_rect_width(_state->base.dst);
-   uint32_t crtc_h = drm_rect_height(_state->base.dst);
-   uint32_t x = plane_state->base.src.x1 >> 16;
-   uint32_t y = plane_state->base.src.y1 >> 16;
-   uint32_t src_w = drm_rect_width(_state->base.src) >> 16;
-   uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
-   unsigned long irqflags;
+   u32 sprctl;
 
-   sprctl = SPRITE_ENABLE;
+   sprctl = SPRITE_ENABLE | SPRITE_GAMMA_ENABLE;
+
+   if (IS_IVYBRIDGE(dev_priv))
+   sprctl |= SPRITE_TRICKLE_FEED_DISABLE;
+
+   if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
+   sprctl |= SPRITE_PIPE_CSC_ENABLE;
 
switch (fb->format->format) {
case DRM_FORMAT_XBGR:
@@ -549,34 +541,50 @@ ivb_update_plane(struct drm_plane *plane,
sprctl |= SPRITE_FORMAT_YUV422 | SPRITE_YUV_ORDER_VYUY;
break;
default:
-   BUG();
+   MISSING_CASE(fb->format->format);
+   return 0;
}
 
-   /*
-* Enable gamma to match primary/cursor plane behaviour.
-* FIXME should be user controllable via propertiesa.
-*/
-   sprctl |= SPRITE_GAMMA_ENABLE;
-
if (fb->modifier == I915_FORMAT_MOD_X_TILED)
sprctl |= SPRITE_TILED;
 
if (rotation & DRM_ROTATE_180)
sprctl |= SPRITE_ROTATE_180;
 
-   if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
-   sprctl &= ~SPRITE_TRICKLE_FEED_DISABLE;
-   else
-   sprctl |= SPRITE_TRICKLE_FEED_DISABLE;
-
-   if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
-   sprctl |= SPRITE_PIPE_CSC_ENABLE;
-
if (key->flags & I915_SET_COLORKEY_DESTINATION)
sprctl |= SPRITE_DEST_KEY;
else if (key->flags & I915_SET_COLORKEY_SOURCE)
sprctl |= SPRITE_SOURCE_KEY;
 
+   return sprctl;
+}
+
+static void
+ivb_update_plane(struct drm_plane *plane,
+const struct intel_crtc_state *crtc_state,
+const struct intel_plane_state *plane_state)
+{
+   struct drm_device *dev = plane->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_plane *intel_plane = to_intel_plane(plane);
+   struct drm_framebuffer *fb = plane_state->base.fb;
+   enum pipe pipe = intel_plane->pipe;
+   u32 sprctl, sprscale = 0;
+   u32 sprsurf_offset, linear_offset;
+   unsigned int rotation = plane_state->base.rotation;
+   const struct drm_intel_sprite_colorkey *key = _state->ckey;
+   int crtc_x = plane_state->base.dst.x1;
+   int crtc_y = plane_state->base.dst.y1;
+   uint32_t crtc_w = drm_rect_width(_state->base.dst);
+   uint32_t crtc_h = drm_rect_height(_state->base.dst);
+   uint32_t x = plane_state->base.src.x1 >> 16;
+   uint32_t y = plane_state->base.src.y1 >> 16;
+   uint32_t src_w = drm_rect_width(_state->base.src) >> 16;
+   uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
+   unsigned long irqflags;
+
+   sprctl = ivb_sprite_ctl(crtc_state, plane_state);
+
/* Sizes 

[Intel-gfx] [PATCH 00/14] drm/i915: Moar plane update optimizations

2017-03-17 Thread ville . syrjala
From: Ville Syrjälä 

The plane updates are still taking far too long, at least with
heavy kernel debug knobs turned on. Using kms_atomic_transitions
I'm currently seeing numbers as high as 170 usec on my VLV.

To combat lockdep the most beneficial thing is taking the
uncore.lock around the entire pipe update. Combined with all
the other optimizations here I was able to push the max
duration below 60 usec with my debug kernel.

The pre-compute stuff isn't supremely important with lockdep/etc.
turned on, but once those are turned off the few usec saved by
the other optimizations start to matter. With all the optimization
and a less debug heavy kernel I was able to get the max duration
to around 15 usec. It was around 25 usec with the current code.

Mika was saying that he's still seeing huge numbers (as high
as 400 usec) with the current drm-tip, and that wasn't even with
a particularly debug heavy kernel. One theory is that there's
contention on the uncore.lock. So I'm thinking we may want to
split the lock into two; one for gt, the other for display. Not
starving the GPU by hogging the shared lock for display stuff
might also be a good thing. I've not tried playing with more
GPU heavy scenarios yet

Anyways, running out of time to play with this more today so
I figured I'd post what I have now.

Series available here:
git://github.com/vsyrjala/linux.git plane_update_optimization

Ville Syrjälä (14):
  drm/i915: Extract skl_plane_ctl()
  drm/i915: Use skl_plane_ctl() for the SKL "sprite" planes
  drm/i915: Extract i9xx_plane_ctl()
  drm/i915: Extract vlv_sprite_ctl()
  drm/i915: Extract ivb_sprite_ctl()
  drm/i915: Extract ilk_sprite_ctl()
  drm/i915: Extract i845_cursor_ctl() and i9xx_cursor_ctl()
  drm/i915: Pre-compute plane control register value
  drm/i915: Introduce i9xx_check_plane_surface()
  drm/i915: Eliminate ironlake_update_primary_plane()
  drm/i915: Use i9xx_check_plane_surface() for sprite planes as well
  drm/i915: Keep vblanks enabled during the entire pipe update
  WIP/drm/i915: Protect the entire pipe update with uncore.lock
  WIP/drm/i915: Nuke posting reads from plane updates

 drivers/gpu/drm/i915/i915_irq.c  |  66 --
 drivers/gpu/drm/i915/i915_trace.h|  28 +--
 drivers/gpu/drm/i915/intel_display.c | 436 +--
 drivers/gpu/drm/i915/intel_drv.h |  16 +-
 drivers/gpu/drm/i915/intel_pm.c  |  11 +-
 drivers/gpu/drm/i915/intel_sprite.c  | 355 
 6 files changed, 440 insertions(+), 472 deletions(-)

-- 
2.10.2

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


[Intel-gfx] [PATCH 01/14] drm/i915: Extract skl_plane_ctl()

2017-03-17 Thread ville . syrjala
From: Ville Syrjälä 

Pull the code to calculate the SKL plane control register value into
a separate function. Allows us to pre-compute it in the future.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 38 
 1 file changed, 26 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 010e5ddb198a..6ddf5c90d15c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3335,6 +3335,31 @@ u32 skl_plane_ctl_rotation(unsigned int rotation)
return 0;
 }
 
+static u32 skl_plane_ctl(const struct intel_crtc_state *crtc_state,
+const struct intel_plane_state *plane_state)
+{
+   struct drm_i915_private *dev_priv =
+   to_i915(plane_state->base.plane->dev);
+   const struct drm_framebuffer *fb = plane_state->base.fb;
+   unsigned int rotation = plane_state->base.rotation;
+   u32 plane_ctl;
+
+   plane_ctl = PLANE_CTL_ENABLE;
+
+   if (!IS_GEMINILAKE(dev_priv)) {
+   plane_ctl |=
+   PLANE_CTL_PIPE_GAMMA_ENABLE |
+   PLANE_CTL_PIPE_CSC_ENABLE |
+   PLANE_CTL_PLANE_GAMMA_DISABLE;
+   }
+
+   plane_ctl |= skl_plane_ctl_format(fb->format->format);
+   plane_ctl |= skl_plane_ctl_tiling(fb->modifier);
+   plane_ctl |= skl_plane_ctl_rotation(rotation);
+
+   return plane_ctl;
+}
+
 static void skylake_update_primary_plane(struct drm_plane *plane,
 const struct intel_crtc_state 
*crtc_state,
 const struct intel_plane_state 
*plane_state)
@@ -3360,18 +3385,7 @@ static void skylake_update_primary_plane(struct 
drm_plane *plane,
int dst_h = drm_rect_height(_state->base.dst);
unsigned long irqflags;
 
-   plane_ctl = PLANE_CTL_ENABLE;
-
-   if (!IS_GEMINILAKE(dev_priv)) {
-   plane_ctl |=
-   PLANE_CTL_PIPE_GAMMA_ENABLE |
-   PLANE_CTL_PIPE_CSC_ENABLE |
-   PLANE_CTL_PLANE_GAMMA_DISABLE;
-   }
-
-   plane_ctl |= skl_plane_ctl_format(fb->format->format);
-   plane_ctl |= skl_plane_ctl_tiling(fb->modifier);
-   plane_ctl |= skl_plane_ctl_rotation(rotation);
+   plane_ctl = skl_plane_ctl(crtc_state, plane_state);
 
/* Sizes are 0 based */
src_w--;
-- 
2.10.2

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


[Intel-gfx] [PATCH] drm/i915: Correct error handling for i915_gem_object_create_from_data()

2017-03-17 Thread Chris Wilson
i915_gem_object_create_from_data() always returns and error pointer on
failure, there is no need to check against NULL.

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

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 86530c92337a..d15a7d9d4eb0 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -377,8 +377,8 @@ void intel_uc_prepare_fw(struct drm_i915_private *dev_priv,
uc_fw->major_ver_wanted, uc_fw->minor_ver_wanted);
 
obj = i915_gem_object_create_from_data(dev_priv, fw->data, fw->size);
-   if (IS_ERR_OR_NULL(obj)) {
-   err = obj ? PTR_ERR(obj) : -ENOMEM;
+   if (IS_ERR(obj)) {
+   err = PTR_ERR(obj);
goto fail;
}
 
-- 
2.11.0

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


Re: [Intel-gfx] [PATCH v2 1/4] drm: Mark up accesses of vblank->enabled outside of its spinlock

2017-03-17 Thread Ville Syrjälä
On Fri, Mar 17, 2017 at 08:20:27PM +, Chris Wilson wrote:
> Order the update to vblank->enabled after the timestamp is primed so
> that a concurrent unlocked reader will only see the vblank->enabled with
> the current timestamp.
> 
> v2: vblank->enable is guarded by dev->vbl_lock not
> dev->vblank_time_lock, update the READ_ONCE accordingly.

The locking is indeed very confusing, and I don't know if it even makes
sense anymore. But this looks at least as sane as anything else here :)

For the series:
Reviewed-by: Ville Syrjälä 

> 
> Do not add a READ_ONCE(vblank->enabled) inside the interrupt handler to
> avoid missing an interrupt whilst racing with enable_vblank()
> 
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_irq.c | 23 ++-
>  1 file changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 53a526c7b24d..c47e07c89136 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -325,6 +325,8 @@ static void vblank_disable_and_save(struct drm_device 
> *dev, unsigned int pipe)
>   struct drm_vblank_crtc *vblank = >vblank[pipe];
>   unsigned long irqflags;
>  
> + assert_spin_locked(>vbl_lock);
> +
>   /* Prevent vblank irq processing while disabling vblank irqs,
>* so no updates of timestamps or count can happen after we've
>* disabled. Needed to prevent races in case of delayed irq's.
> @@ -336,10 +338,8 @@ static void vblank_disable_and_save(struct drm_device 
> *dev, unsigned int pipe)
>* calling the ->disable_vblank() operation in atomic context with the
>* hardware potentially runtime suspended.
>*/
> - if (vblank->enabled) {
> + if (cmpxchg_relaxed(>enabled, true, false))
>   __disable_vblank(dev, pipe);
> - vblank->enabled = false;
> - }
>  
>   /*
>* Always update the count and timestamp to maintain the
> @@ -384,7 +384,7 @@ void drm_vblank_cleanup(struct drm_device *dev)
>   for (pipe = 0; pipe < dev->num_crtcs; pipe++) {
>   struct drm_vblank_crtc *vblank = >vblank[pipe];
>  
> - WARN_ON(vblank->enabled &&
> + WARN_ON(READ_ONCE(vblank->enabled) &&
>   drm_core_check_feature(dev, DRIVER_MODESET));
>  
>   del_timer_sync(>disable_timer);
> @@ -1105,11 +1105,16 @@ static int drm_vblank_enable(struct drm_device *dev, 
> unsigned int pipe)
>*/
>   ret = __enable_vblank(dev, pipe);
>   DRM_DEBUG("enabling vblank on crtc %u, ret: %d\n", pipe, ret);
> - if (ret)
> + if (ret) {
>   atomic_dec(>refcount);
> - else {
> - vblank->enabled = true;
> + } else {
>   drm_update_vblank_count(dev, pipe, 0);
> + /* drm_update_vblank_count() includes a wmb so we just
> +  * need to ensure that the compiler emits the write
> +  * to mark the vblank as enabled after the call
> +  * to drm_update_vblank_count().
> +  */
> + WRITE_ONCE(vblank->enabled, true);
>   }
>   }
>  
> @@ -1517,7 +1522,7 @@ static int drm_queue_vblank_event(struct drm_device 
> *dev, unsigned int pipe,
>* vblank disable, so no need for further locking.  The reference from
>* drm_vblank_get() protects against vblank disable from another source.
>*/
> - if (!vblank->enabled) {
> + if (!READ_ONCE(vblank->enabled)) {
>   ret = -EINVAL;
>   goto err_unlock;
>   }
> @@ -1644,7 +1649,7 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
>   DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
>   (((drm_vblank_count(dev, pipe) -
>  vblwait->request.sequence) <= (1 << 23)) ||
> -  !vblank->enabled ||
> +  !READ_ONCE(vblank->enabled) ||
>!dev->irq_enabled));
>   }
>  
> -- 
> 2.11.0

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


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/4] drm: Mark up accesses of vblank->enabled outside of its spinlock

2017-03-17 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/4] drm: Mark up accesses of vblank->enabled 
outside of its spinlock
URL   : https://patchwork.freedesktop.org/series/21472/
State : success

== Summary ==

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

Test gem_ctx_switch:
Subgroup basic-default-heavy:
pass   -> INCOMPLETE (fi-kbl-7500u) fdo#100253
Test kms_cursor_legacy:
Subgroup basic-flip-before-cursor-varying-size:
dmesg-warn -> PASS   (fi-byt-n2820) fdo#100094

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 462s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 584s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 540s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 554s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 498s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 500s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 436s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 436s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 442s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 519s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 493s
fi-kbl-7500u total:22   pass:21   dwarn:0   dfail:0   fail:0   skip:0   
time: 0s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 479s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 598s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 479s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 514s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 548s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 411s

ca3e896e9cf4e4c3319bbb51843daa45902927a7 drm-tip: 2017y-03m-17d-18h-26m-58s UTC 
integration manifest
3d39269 drm: Peek at the current counter/timestamp for vblank queries
7078395 drm: Refactor vblank sequence number comparison
d1bcfca drm: vblank cannot be enabled if dev->irq_enabled is false
7a9f797 drm: Mark up accesses of vblank->enabled outside of its spinlock

== Logs ==

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


Re: [Intel-gfx] [PATCH 2/2] drm/i915/vbt: split out defaults that are set when there is no VBT

2017-03-17 Thread Paulo Zanoni
Em Ter, 2017-03-14 às 11:09 +0200, Jani Nikula escreveu:
> On Mon, 13 Mar 2017, Manasi Navare  wrote:
> > 
> > On Mon, Mar 13, 2017 at 11:55:31AM +0200, Jani Nikula wrote:
> > > 
> > > On Sat, 11 Mar 2017, Manasi Navare 
> > > wrote:
> > > > 
> > > > On Fri, Mar 10, 2017 at 03:27:58PM +0200, Jani Nikula wrote:
> > > > > 
> > > > > The main thing are the DDI ports. If there's a VBT that says
> > > > > there are
> > > > > no outputs, we should trust that, and not have semi-random
> > > > > defaults. Unfortunately, the defaults have resulted in some
> > > > > Chromebooks
> > > > > without VBT to rely on this behaviour, so we split out the
> > > > > defaults for
> > > > > the missing VBT case.
> > > > > 
> > > > > Cc: Manasi Navare 
> > > > > Cc: Ville Syrjälä 
> > > > > Signed-off-by: Jani Nikula 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_bios.c | 17 -
> > > > >  1 file changed, 16 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_bios.c
> > > > > b/drivers/gpu/drm/i915/intel_bios.c
> > > > > index 710988d72253..639d45c1dd2e 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_bios.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > > > > @@ -1341,6 +1341,7 @@ parse_device_mapping(struct
> > > > > drm_i915_private *dev_priv,
> > > > >   return;
> > > > >  }
> > > > >  
> > > > > +/* Common defaults which may be overridden by VBT. */
> > > > >  static void
> > > > >  init_vbt_defaults(struct drm_i915_private *dev_priv)
> > > > >  {
> > > > > @@ -1377,6 +1378,18 @@ init_vbt_defaults(struct
> > > > > drm_i915_private *dev_priv)
> > > > >   _priv->vbt.ddi_port_info[port];
> > > > >  
> > > > >   info->hdmi_level_shift =
> > > > > HDMI_LEVEL_SHIFT_UNKNOWN;
> > > > > + }
> > > > > +}
> > > > > +
> > > > > +/* Defaults to initialize only if there is no VBT. */
> > > > > +static void
> > > > > +init_vbt_missing_defaults(struct drm_i915_private *dev_priv)
> > > > > +{
> > > > > + enum port port;
> > > > > +
> > > > > + for (port = PORT_A; port < I915_MAX_PORTS; port++) {
> > > > > + struct ddi_vbt_port_info *info =
> > > > > + _priv->vbt.ddi_port_info[port];
> > > > >  
> > > > >   info->supports_dvi = (port != PORT_A && port
> > > > > != PORT_E);
> > > > >   info->supports_hdmi = info->supports_dvi;
> > > > > @@ -1516,8 +1529,10 @@ void intel_bios_init(struct
> > > > > drm_i915_private *dev_priv)
> > > > >   parse_ddi_ports(dev_priv, bdb);
> > > > >  
> > > > >  out:
> > > > > - if (!vbt)
> > > > > + if (!vbt) {
> > > > >   DRM_INFO("Failed to find VBIOS tables
> > > > > (VBT)\n");
> > > > > + init_vbt_missing_defaults(dev_priv);
> > > > > + }
> > > > 
> > > > So in case there is no VBT, this will set supports_DP flag on
> > > > Port A.
> > > > What is there is no VBT and there is no eDP on Port A?
> > > > In this case it will still try to link train on Port A and
> > > > fail..?
> > > > I am not sure if this case exists, but just a thought looking
> > > > at it.
> > > 
> > > It's possible the case exists, but the point is that the
> > > behaviour for
> > > the no-VBT case remains the same before and after this patch.
> > > 
> > > BR,
> > > Jani.
> > > 
> > > 
> > 
> > Ok agreed. In that case Reviewed-by: Manasi Navare
> > 
> 
> Pushed to drm-intel-next-queued, thanks for the review.
> 
> I really hope there are no machines out there that have a crippled
> VBT
> with no child device config. I guess we'll find out...

I have access to this very interesting machine with DDB version 163 and
a child device size config that's 1 instead of the expected 33.

So what happens here is that since the VBT is supposed to be valid we
don't end up calling init_vbt_missing_defauilts(). We return early from
parse_device_mapping(), which means we don't set vbt.child_dev_num,
which means that parse_ddi_port() returns early. So info->supports_*
stays false, and intel_ddi_init() fails.

Given your commit message it seems that we should properly be able to
distinguish between "VBT correctly says that there's no output" and
"VBT is drunk and should go home" in order to fix this problem.

I can confirm that reverting this patch makes display great again^w^w
work again. So unfortunately I'll have to call regression on this
patch.

> 
> BR,
> Jani.
> 
> 
> > 
> > 
> > Regards
> > Manasi
> > 
> >  
> > > 
> > > > 
> > > > If such a case does not exist, then this will solve our problem
> > > > of
> > > > current failures because leaving defaults on Port A. So in that
> > > > case
> > > > it lgtm.
> > > > 
> > > > Regards
> > > > Manasi
> > > > 
> > > > 
> > > > > 
> > > > >  
> > > > >   if (bios)
> > > > >   pci_unmap_rom(pdev, bios);
> > > > > -- 
> > > > > 

[Intel-gfx] [PATCH v2 3/4] drm: Refactor vblank sequence number comparison

2017-03-17 Thread Chris Wilson
Move the repeated (a - b) <= (1 << 23) to its own function.

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_irq.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index a164cf51d093..253505da57bd 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1492,6 +1492,11 @@ int drm_legacy_modeset_ctl(struct drm_device *dev, void 
*data,
return 0;
 }
 
+static inline bool vblank_passed(u32 seq, u32 ref)
+{
+   return (seq - ref) <= (1 << 23);
+}
+
 static int drm_queue_vblank_event(struct drm_device *dev, unsigned int pipe,
  union drm_wait_vblank *vblwait,
  struct drm_file *file_priv)
@@ -1542,7 +1547,7 @@ static int drm_queue_vblank_event(struct drm_device *dev, 
unsigned int pipe,
  vblwait->request.sequence);
 
e->event.sequence = vblwait->request.sequence;
-   if ((seq - vblwait->request.sequence) <= (1 << 23)) {
+   if (vblank_passed(seq, vblwait->request.sequence)) {
drm_vblank_put(dev, pipe);
send_vblank_event(dev, e, seq, );
vblwait->reply.sequence = seq;
@@ -1632,9 +1637,8 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
}
 
if ((flags & _DRM_VBLANK_NEXTONMISS) &&
-   (seq - vblwait->request.sequence) <= (1 << 23)) {
+   vblank_passed(seq, vblwait->request.sequence))
vblwait->request.sequence = seq + 1;
-   }
 
if (flags & _DRM_VBLANK_EVENT) {
/* must hold on to the vblank ref until the event fires
@@ -1647,8 +1651,8 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
DRM_DEBUG("waiting on vblank count %u, crtc %u\n",
  vblwait->request.sequence, pipe);
DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
-   (drm_vblank_count(dev, pipe) -
-vblwait->request.sequence) <= (1 << 23) ||
+   vblank_passed(drm_vblank_count(dev, pipe),
+ vblwait->request.sequence) ||
!READ_ONCE(vblank->enabled));
}
 
-- 
2.11.0

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


[Intel-gfx] [PATCH v2 4/4] drm: Peek at the current counter/timestamp for vblank queries

2017-03-17 Thread Chris Wilson
Bypass all the spinlocks and return the last timestamp and counter from
the last vblank if the driver delcares that it is accurate (and stable
across on/off), and the vblank is currently enabled.

This is dependent upon the both the hardware and driver to provide the
proper barriers to facilitate reading our bookkeeping outside of the
vblank interrupt and outside of the explicit vblank locks.

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Michel Dänzer 
Cc: Laurent Pinchart 
Cc: Dave Airlie ,
Cc: Mario Kleiner 
---
 drivers/gpu/drm/drm_irq.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 253505da57bd..846401548ec9 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1569,6 +1569,17 @@ static int drm_queue_vblank_event(struct drm_device 
*dev, unsigned int pipe,
return ret;
 }
 
+static bool drm_wait_vblank_is_query(union drm_wait_vblank *vblwait)
+{
+   if (vblwait->request.sequence)
+   return false;
+
+   return _DRM_VBLANK_RELATIVE ==
+   (vblwait->request.type & (_DRM_VBLANK_TYPES_MASK |
+ _DRM_VBLANK_EVENT |
+ _DRM_VBLANK_NEXTONMISS));
+}
+
 /*
  * Wait for VBLANK.
  *
@@ -1618,6 +1629,21 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
 
vblank = >vblank[pipe];
 
+   /* If the counter is currently enabled and accurate, short-circuit
+* queries to return the cached timestamp of the last vblank.
+*/
+   if (dev->vblank_disable_immediate &&
+   drm_wait_vblank_is_query(vblwait) &&
+   READ_ONCE(vblank->enabled)) {
+   struct timeval now;
+
+   vblwait->reply.sequence =
+   drm_vblank_count_and_time(dev, pipe, );
+   vblwait->reply.tval_sec = now.tv_sec;
+   vblwait->reply.tval_usec = now.tv_usec;
+   return 0;
+   }
+
ret = drm_vblank_get(dev, pipe);
if (ret) {
DRM_DEBUG("crtc %d failed to acquire vblank counter, %d\n", 
pipe, ret);
-- 
2.11.0

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


[Intel-gfx] [PATCH v2 2/4] drm: vblank cannot be enabled if dev->irq_enabled is false

2017-03-17 Thread Chris Wilson
Since we cannot enable the vblank if !dev->irq_enabled, we assert that
checking for both !vblank->enabled and !dev->irq_enabled is tautological
and only need the former. The only time it may differ is when racing
with drm_irq_uninstall(), but that will then disable the vblank and
wakeup the waiters.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_irq.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index c47e07c89136..a164cf51d093 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1647,10 +1647,9 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
DRM_DEBUG("waiting on vblank count %u, crtc %u\n",
  vblwait->request.sequence, pipe);
DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
-   (((drm_vblank_count(dev, pipe) -
-  vblwait->request.sequence) <= (1 << 23)) ||
-!READ_ONCE(vblank->enabled) ||
-!dev->irq_enabled));
+   (drm_vblank_count(dev, pipe) -
+vblwait->request.sequence) <= (1 << 23) ||
+   !READ_ONCE(vblank->enabled));
}
 
if (ret != -EINTR) {
-- 
2.11.0

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


[Intel-gfx] [PATCH v2 1/4] drm: Mark up accesses of vblank->enabled outside of its spinlock

2017-03-17 Thread Chris Wilson
Order the update to vblank->enabled after the timestamp is primed so
that a concurrent unlocked reader will only see the vblank->enabled with
the current timestamp.

v2: vblank->enable is guarded by dev->vbl_lock not
dev->vblank_time_lock, update the READ_ONCE accordingly.

Do not add a READ_ONCE(vblank->enabled) inside the interrupt handler to
avoid missing an interrupt whilst racing with enable_vblank()

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_irq.c | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 53a526c7b24d..c47e07c89136 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -325,6 +325,8 @@ static void vblank_disable_and_save(struct drm_device *dev, 
unsigned int pipe)
struct drm_vblank_crtc *vblank = >vblank[pipe];
unsigned long irqflags;
 
+   assert_spin_locked(>vbl_lock);
+
/* Prevent vblank irq processing while disabling vblank irqs,
 * so no updates of timestamps or count can happen after we've
 * disabled. Needed to prevent races in case of delayed irq's.
@@ -336,10 +338,8 @@ static void vblank_disable_and_save(struct drm_device 
*dev, unsigned int pipe)
 * calling the ->disable_vblank() operation in atomic context with the
 * hardware potentially runtime suspended.
 */
-   if (vblank->enabled) {
+   if (cmpxchg_relaxed(>enabled, true, false))
__disable_vblank(dev, pipe);
-   vblank->enabled = false;
-   }
 
/*
 * Always update the count and timestamp to maintain the
@@ -384,7 +384,7 @@ void drm_vblank_cleanup(struct drm_device *dev)
for (pipe = 0; pipe < dev->num_crtcs; pipe++) {
struct drm_vblank_crtc *vblank = >vblank[pipe];
 
-   WARN_ON(vblank->enabled &&
+   WARN_ON(READ_ONCE(vblank->enabled) &&
drm_core_check_feature(dev, DRIVER_MODESET));
 
del_timer_sync(>disable_timer);
@@ -1105,11 +1105,16 @@ static int drm_vblank_enable(struct drm_device *dev, 
unsigned int pipe)
 */
ret = __enable_vblank(dev, pipe);
DRM_DEBUG("enabling vblank on crtc %u, ret: %d\n", pipe, ret);
-   if (ret)
+   if (ret) {
atomic_dec(>refcount);
-   else {
-   vblank->enabled = true;
+   } else {
drm_update_vblank_count(dev, pipe, 0);
+   /* drm_update_vblank_count() includes a wmb so we just
+* need to ensure that the compiler emits the write
+* to mark the vblank as enabled after the call
+* to drm_update_vblank_count().
+*/
+   WRITE_ONCE(vblank->enabled, true);
}
}
 
@@ -1517,7 +1522,7 @@ static int drm_queue_vblank_event(struct drm_device *dev, 
unsigned int pipe,
 * vblank disable, so no need for further locking.  The reference from
 * drm_vblank_get() protects against vblank disable from another source.
 */
-   if (!vblank->enabled) {
+   if (!READ_ONCE(vblank->enabled)) {
ret = -EINVAL;
goto err_unlock;
}
@@ -1644,7 +1649,7 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
(((drm_vblank_count(dev, pipe) -
   vblwait->request.sequence) <= (1 << 23)) ||
-!vblank->enabled ||
+!READ_ONCE(vblank->enabled) ||
 !dev->irq_enabled));
}
 
-- 
2.11.0

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


Re: [Intel-gfx] [PATCH v6 02/23] drm/i915/gen9: Separate RPS and RC6 handling

2017-03-17 Thread Chris Wilson
On Thu, Mar 16, 2017 at 11:58:06PM +0530, Sagar Arun Kamble wrote:
> With GuC based SLPC, frequency control will be moved to GuC and Host will
> continue to control RC6 and Ring frequency setup. SLPC can be enabled in
> the GuC setup path and can happen in parallel in GuC with other i915 setup.
> Hence we can do away with deferred RPS enabling. This needs separate
> handling of RPS, RC6 and ring frequencies in driver flows. We can still use
> the *gt_powersave routines with separate status variables of RPS, RC6 and
> SLPC. With this patch, RC6 and ring frequencies setup(if applicable) are
> tracked through rps.rc6_enabled and RPS through rps.enabled.
> Also, Active RPS check in suspend flow is needed for platforms with RC6
> and RPS enabling/disabling coupled together. RPM suspend depends only on
> RC6 though. Hence Active RPS check is done only for non-Gen9 platforms.
> Moved setting of rps.enabled to platform level functions as there is case
> of disabling of RPS in gen9_enable_rps.
> 
> v2: Changing parameter to dev_priv for IS_GEN9 and HAS_RUNTIME_PM and line
> spacing changes. (David)
> and commit message update for checkpatch issues.
> 
> v3: Rebase.
> 
> v4: Commit message update.
> 
> v5: Updated intel_enable_gt_powersave and intel_disable_gt_powersave
> routines with separated RPS and RC6 handling and rebase. Commit message
> update.(Sagar)
> 
> v6: Added comments at the definition of rc6_enabled.
> 
> Signed-off-by: Sagar Arun Kamble 
> ---
>  drivers/gpu/drm/i915/i915_drv.c |  6 -
>  drivers/gpu/drm/i915/i915_drv.h |  5 
>  drivers/gpu/drm/i915/intel_pm.c | 54 
> +
>  3 files changed, 54 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 9164167..0302d24 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2358,7 +2358,11 @@ static int intel_runtime_suspend(struct device *kdev)
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   int ret;
>  
> - if (WARN_ON_ONCE(!(dev_priv->rps.enabled && intel_enable_rc6(
> + if (WARN_ON_ONCE(!intel_enable_rc6()))
> + return -ENODEV;
> +
> + if (WARN_ON_ONCE((IS_GEN9(dev_priv) && !dev_priv->rps.rc6_enabled) ||
> +  (!IS_GEN9(dev_priv) && !dev_priv->rps.enabled)))
>   return -ENODEV;
>  
>   if (WARN_ON_ONCE(!HAS_RUNTIME_PM(dev_priv)))
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 355bc545..7bafcd3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1372,7 +1372,12 @@ struct intel_gen6_power_mgmt {
>   struct list_head clients;
>   bool client_boost;
>  
> + /*
> +  * For platforms prior to Gen9, RPS and RC6 status is tracked
> +  * through "enabled". For Gen9, RC6 is tracked through "rc6_enabled".
> +  */
>   bool enabled;
> + bool rc6_enabled;

Does that sound sane?

Let's have rc6_enabled mean rc6_enabled whatever the gen, and
rps_enabled mean rps_enabled whatever the gen.
-Chris

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


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: i915_gem_object_create_from_data() doesn't require struct_mutex

2017-03-17 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: i915_gem_object_create_from_data() 
doesn't require struct_mutex
URL   : https://patchwork.freedesktop.org/series/21470/
State : success

== Summary ==

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

Test kms_cursor_legacy:
Subgroup basic-flip-before-cursor-varying-size:
dmesg-warn -> PASS   (fi-byt-n2820) fdo#100094

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 456s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 565s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 539s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 555s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 501s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 502s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 436s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 433s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 442s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 510s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 493s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 484s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 482s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 601s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 486s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 520s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 548s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 431s

ca3e896e9cf4e4c3319bbb51843daa45902927a7 drm-tip: 2017y-03m-17d-18h-26m-58s UTC 
integration manifest
9fb7f1a drm/i915: Initialise i915_gem_object_create_from_data() directly
1e1a1cf drm/i915: i915_gem_object_create_from_data() doesn't require 
struct_mutex

== Logs ==

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


Re: [Intel-gfx] [PATCH 2/4] drm/i915: Check for id==PLANE_CURSOR instead of type==DRM_PLANE_TYPE_CURSOR

2017-03-17 Thread Ville Syrjälä
On Fri, Mar 17, 2017 at 07:54:30PM +, Chris Wilson wrote:
> On Fri, Mar 03, 2017 at 05:19:26PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > The VLV/CHV watermark calculation is really interested in the hardware
> > plane type rather than the plane type (which is more of a software
> > concept). Let's check plane->id rather plane->type.
> > 
> > No functional changes.
> 
> When will they differ? Is this for multipurpose planes, such as a sprite
> that we treat as a cursor for simplicity?

Yeah. Currently they never differ, but just in case someone ever decides
to break that relationship I figured it's better to be clear on which kind
of hardware plane we're dealing with.

-- 
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 2/2] drm: Peek at the current counter/timestamp for vblank queries

2017-03-17 Thread Chris Wilson
On Fri, Mar 17, 2017 at 11:49:32AM +0200, Ville Syrjälä wrote:
> On Thu, Mar 16, 2017 at 11:47:49PM +, Chris Wilson wrote:
> > Bypass all the spinlocks and return the last timestamp and counter from
> > the last vblank if the driver delcares that it is accurate (and stable
> > across on/off), and the vblank is currently enabled.
> > 
> > This is dependent upon the both the hardware and driver to provide the
> > proper barriers to facilitate reading our bookkeeping outside of the
> > vblank interrupt and outside of the explicit vblank locks.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Ville Syrjälä 
> > Cc: Daniel Vetter 
> > Cc: Michel Dänzer 
> > Cc: Laurent Pinchart 
> > Cc: Dave Airlie ,
> > Cc: Mario Kleiner 
> > ---
> >  drivers/gpu/drm/drm_irq.c | 26 ++
> >  1 file changed, 26 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index 4cc9352ab6a8..b4bd361a2bcc 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> > @@ -1562,6 +1562,17 @@ static int drm_queue_vblank_event(struct drm_device 
> > *dev, unsigned int pipe,
> > return ret;
> >  }
> >  
> > +static bool drm_wait_vblank_is_query(union drm_wait_vblank *vblwait)
> > +{
> > +   if (vblwait->request.sequence)
> > +   return false;
> > +
> > +   return _DRM_VBLANK_RELATIVE ==
> > +   (vblwait->request.type & (_DRM_VBLANK_TYPES_MASK |
> > + _DRM_VBLANK_EVENT |
> > + _DRM_VBLANK_NEXTONMISS));
> > +}
> > +
> >  /*
> >   * Wait for VBLANK.
> >   *
> > @@ -1611,6 +1622,21 @@ int drm_wait_vblank(struct drm_device *dev, void 
> > *data,
> >  
> > vblank = >vblank[pipe];
> >  
> > +   /* If the counter is currently enabled and accurate, short-circuit 
> > queries
> > +* to return the cached timestamp of the last vblank.
> > +*/
> > +   if (dev->vblank_disable_immediate &&
> > +   drm_wait_vblank_is_query(vblwait) &&
> > +   vblank->enabled) {
> > +   struct timeval now;
> > +
> 
> Do we want a comment here as well stating that the seqlock
> already has the rmb?

I didn't find it enlightening. Added READ_ONCE(vblank->enabled).
-Chris

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


Re: [Intel-gfx] [PATCH 2/4] drm/i915: Check for id==PLANE_CURSOR instead of type==DRM_PLANE_TYPE_CURSOR

2017-03-17 Thread Chris Wilson
On Fri, Mar 03, 2017 at 05:19:26PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> The VLV/CHV watermark calculation is really interested in the hardware
> plane type rather than the plane type (which is more of a software
> concept). Let's check plane->id rather plane->type.
> 
> No functional changes.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 54d211d0d29e..70eca32e4036 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -1039,7 +1039,7 @@ static uint16_t vlv_compute_wm_level(const struct 
> intel_crtc_state *crtc_state,
>   if (WARN_ON(htotal == 0))
>   htotal = 1;
>  
> - if (plane->base.type == DRM_PLANE_TYPE_CURSOR) {
> + if (plane->id == PLANE_CURSOR) {

Ok, this is bring this piece of code into line with everyone else,
Reviewed-by: Chris Wilson 
-Chris

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


Re: [Intel-gfx] [PATCH 3/4] drm/i915: Use intel_wm_plane_visible() on VLV/CHV as well

2017-03-17 Thread Chris Wilson
On Fri, Mar 03, 2017 at 05:19:27PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> VLV/CHV don't have double buffered watermarks so they need to consider
> the cursor visibility as a special case just like ILK-BDW. Let's use
> the helper we have for that.
> 
> Signed-off-by: Ville Syrjälä 
Convinced,
Reviewed-by: Chris Wilson 
-Chris

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


Re: [Intel-gfx] [PATCH 2/4] drm/i915: Check for id==PLANE_CURSOR instead of type==DRM_PLANE_TYPE_CURSOR

2017-03-17 Thread Chris Wilson
On Fri, Mar 03, 2017 at 05:19:26PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> The VLV/CHV watermark calculation is really interested in the hardware
> plane type rather than the plane type (which is more of a software
> concept). Let's check plane->id rather plane->type.
> 
> No functional changes.

When will they differ? Is this for multipurpose planes, such as a sprite
that we treat as a cursor for simplicity?
-Chris

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


Re: [Intel-gfx] [PATCH 1/4] drm/i915: Extract intel_wm_plane_visible()

2017-03-17 Thread Chris Wilson
On Fri, Mar 03, 2017 at 05:19:25PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> All platforms that lack double buffered watermarks will need to
> handle the legacy cursor updates in the same way. So let's extract the
> logic to determine the plane visibility into a small helper. For
> simplicity we'll make the function DTRT for any plane, but only apply
> the special sauce for cursor planes.
> 
> Signed-off-by: Ville Syrjälä 
Reviewed-by: Chris Wilson 
-Chris

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


[Intel-gfx] [PATCH 1/2] drm/i915: i915_gem_object_create_from_data() doesn't require struct_mutex

2017-03-17 Thread Chris Wilson
Both object creation and backing storage page allocation do not require
struct_mutex, so do not require the caller to take it.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 4 +---
 drivers/gpu/drm/i915/intel_uc.c | 2 --
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fd611b4c1a2c..3492f8d27c32 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4961,9 +4961,7 @@ i915_gem_object_create_from_data(struct drm_i915_private 
*dev_priv,
if (IS_ERR(obj))
return obj;
 
-   ret = i915_gem_object_set_to_cpu_domain(obj, true);
-   if (ret)
-   goto fail;
+   GEM_BUG_ON(obj->base.write_domain != I915_GEM_DOMAIN_CPU);
 
ret = i915_gem_object_pin_pages(obj);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 21f6d822194d..86530c92337a 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -376,9 +376,7 @@ void intel_uc_prepare_fw(struct drm_i915_private *dev_priv,
uc_fw->major_ver_found, uc_fw->minor_ver_found,
uc_fw->major_ver_wanted, uc_fw->minor_ver_wanted);
 
-   mutex_lock(_priv->drm.struct_mutex);
obj = i915_gem_object_create_from_data(dev_priv, fw->data, fw->size);
-   mutex_unlock(_priv->drm.struct_mutex);
if (IS_ERR_OR_NULL(obj)) {
err = obj ? PTR_ERR(obj) : -ENOMEM;
goto fail;
-- 
2.11.0

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


[Intel-gfx] [PATCH 2/2] drm/i915: Initialise i915_gem_object_create_from_data() directly

2017-03-17 Thread Chris Wilson
Use pagecache_write to avoid shmemfs clearing the pages prior to us
immediately overwriting them with our data.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 45 ++---
 1 file changed, 29 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3492f8d27c32..58e1db77d70e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4953,9 +4953,9 @@ i915_gem_object_create_from_data(struct drm_i915_private 
*dev_priv,
 const void *data, size_t size)
 {
struct drm_i915_gem_object *obj;
-   struct sg_table *sg;
-   size_t bytes;
-   int ret;
+   struct file *file;
+   size_t offset;
+   int err;
 
obj = i915_gem_object_create(dev_priv, round_up(size, PAGE_SIZE));
if (IS_ERR(obj))
@@ -4963,26 +4963,39 @@ i915_gem_object_create_from_data(struct 
drm_i915_private *dev_priv,
 
GEM_BUG_ON(obj->base.write_domain != I915_GEM_DOMAIN_CPU);
 
-   ret = i915_gem_object_pin_pages(obj);
-   if (ret)
-   goto fail;
+   file = obj->base.filp;
+   offset = 0;
+   do {
+   unsigned int len = min_t(typeof(size), size, PAGE_SIZE);
+   struct page *page;
+   void *pgdata, *vaddr;
 
-   sg = obj->mm.pages;
-   bytes = sg_copy_from_buffer(sg->sgl, sg->nents, (void *)data, size);
-   obj->mm.dirty = true; /* Backing store is now out of date */
-   i915_gem_object_unpin_pages(obj);
+   err = pagecache_write_begin(file, file->f_mapping,
+   offset, len, 0,
+   , );
+   if (err < 0)
+   goto fail;
 
-   if (WARN_ON(bytes != size)) {
-   DRM_ERROR("Incomplete copy, wrote %zu of %zu", bytes, size);
-   ret = -EFAULT;
-   goto fail;
-   }
+   vaddr = kmap(page);
+   memcpy(vaddr, data, len);
+   kunmap(page);
+
+   err = pagecache_write_end(file, file->f_mapping,
+ offset, len, len,
+ page, pgdata);
+   if (err < 0)
+   goto fail;
+
+   size -= len;
+   data += len;
+   offset += len;
+   } while (size);
 
return obj;
 
 fail:
i915_gem_object_put(obj);
-   return ERR_PTR(ret);
+   return ERR_PTR(err);
 }
 
 struct scatterlist *
-- 
2.11.0

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


Re: [Intel-gfx] [PATCH v3] drm/i915: Fix FBC cfb stride programming for non X-tiled FB

2017-03-17 Thread Praveen Paneri
On Fri, Mar 17, 2017 at 1:24 AM, Paulo Zanoni  wrote:
> Em Qui, 2017-03-16 às 17:38 +0530, Praveen Paneri escreveu:
>> When FBC is enabled for linear, legacy Y-tiled and Yf-tiled
>> surfaces on gen9, the cfb stride must be programmed by SW as
>>
>> cfb_stride = ceiling[(at least plane width in pixels)/
>>(32 * compression limit factor)] * 8
>>
>> v2: Minor fix for a build error
>>
>> v3: Fixed subject, register name and platform check (Ville)
>>
>> Signed-off-by: Praveen Paneri 
>> ---
>>  drivers/gpu/drm/i915/i915_reg.h  | 3 +++
>>  drivers/gpu/drm/i915/intel_fbc.c | 8 
>>  2 files changed, 11 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 5d88c35..f4f0cb5 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -6506,6 +6506,9 @@ enum {
>>  #define  GLK_CL1_PWR_DOWN(1 << 11)
>>  #define  GLK_CL2_PWR_DOWN(1 << 12)
>>
>> +#define CHICKEN_MISC_4   _MMIO(0x4208c)
>> +#define   FBC_STRIDE_OVERRIDE(1<<13)
>> +
>>  #define _CHICKEN_PIPESL_1_A  0x420b0
>>  #define _CHICKEN_PIPESL_1_B  0x420b4
>>  #define  HSW_FBCQ_DIS(1 << 22)
>> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
>> b/drivers/gpu/drm/i915/intel_fbc.c
>> index ded2add..e7f259f 100644
>> --- a/drivers/gpu/drm/i915/intel_fbc.c
>> +++ b/drivers/gpu/drm/i915/intel_fbc.c
>> @@ -298,9 +298,17 @@ static bool ilk_fbc_is_active(struct
>> drm_i915_private *dev_priv)
>>  static void gen7_fbc_activate(struct drm_i915_private *dev_priv)
>>  {
>>   struct intel_fbc_reg_params *params = _priv->fbc.params;
>> + struct intel_fbc_state_cache *cache = _priv-
>> >fbc.state_cache;
>>   u32 dpfc_ctl;
>>   int threshold = dev_priv->fbc.threshold;
>>
>
> Please add:
>
> /* Display WA #0529: skl, kbl, bxt, glk. */
>
> (and if you find the real name of the WA, please also add it)
>
> I wanted to give this patch a try with kms_frontbuffer_tracking, but I
> just couldn't find your IGT patch where Y tiling support is added to
> it. I can see your patches that touch lib/igt_draw and kms_draw_crc,
> but no patches testing kms_frontbuffer_tracking. Can you please send me
> the patchwork link?
It was just lying in my PC. I wasn't sure about the last patch for kms_fbc_crc.
Nevertheless just posted the series here
https://patchwork.kernel.org/patch/9631479/
Plz review.

>
> The corollary of the paragraph above is the question: do we maintain
> the same pass rate as X tiling when we test it against Y tiling now?
Yes we do :)
>
> My original goal was to block FBC Y tiling support until we added the
> IGT stuff, but I see it was already enabled by someone even though we
> didn't have the missing WA nor the IGT stuff... Oh, well
Anyway! hopefully we will catch-up and fix this soon
Thanks,
Praveen
>
>> + if (IS_GEN9(dev_priv) &&
>> + i915_gem_object_get_tiling(cache->vma->obj) !=
>> I915_TILING_X) {
>> + int cfb_stride = DIV_ROUND_UP(cache->plane.src_w,
>> +   (32 * threshold)) * 8;
>> + I915_WRITE(CHICKEN_MISC_4, FBC_STRIDE_OVERRIDE |
>> cfb_stride);
>> + }
>> +
>>   dpfc_ctl = 0;
>>   if (IS_IVYBRIDGE(dev_priv))
>>   dpfc_ctl |= IVB_DPFC_CTL_PLANE(params->crtc.plane);
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 7/7] igt/kms_fbc_crc.c : Add Y-tile tests

2017-03-17 Thread Praveen Paneri
Now that we have support for Y-tiled buffers, add another
iteration of tests for Y-tiled buffers.

Signed-off-by: Praveen Paneri 
---
 tests/kms_fbc_crc.c | 71 +
 1 file changed, 39 insertions(+), 32 deletions(-)

diff --git a/tests/kms_fbc_crc.c b/tests/kms_fbc_crc.c
index 96af06a..e0f9bf6 100644
--- a/tests/kms_fbc_crc.c
+++ b/tests/kms_fbc_crc.c
@@ -318,12 +318,10 @@ static void prepare_crtc(data_t *data)
igt_output_set_pipe(output, data->pipe);
 }
 
-static void create_fbs(data_t *data, bool tiled, struct igt_fb *fbs)
+static void create_fbs(data_t *data, uint64_t tiling, struct igt_fb *fbs)
 {
int rc;
drmModeModeInfo *mode = igt_output_get_mode(data->output);
-   uint64_t tiling = tiled ? LOCAL_I915_FORMAT_MOD_X_TILED :
- LOCAL_DRM_FORMAT_MOD_NONE;
 
rc = igt_create_color_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
 DRM_FORMAT_XRGB, tiling,
@@ -344,8 +342,8 @@ static void get_ref_crcs(data_t *data)
struct igt_fb fbs[4];
int i;
 
-   create_fbs(data, false, [0]);
-   create_fbs(data, false, [2]);
+   create_fbs(data, LOCAL_DRM_FORMAT_MOD_NONE, [0]);
+   create_fbs(data, LOCAL_DRM_FORMAT_MOD_NONE, [2]);
 
fill_mmap_gtt(data, fbs[2].gem_handle, 0xff);
fill_mmap_gtt(data, fbs[3].gem_handle, 0xff);
@@ -366,7 +364,7 @@ static void get_ref_crcs(data_t *data)
igt_remove_fb(data->drm_fd, [i]);
 }
 
-static bool prepare_test(data_t *data, enum test_mode test_mode)
+static bool prepare_test(data_t *data, enum test_mode test_mode, uint64_t 
tiling)
 {
igt_display_t *display = >display;
igt_output_t *output = data->output;
@@ -374,7 +372,7 @@ static bool prepare_test(data_t *data, enum test_mode 
test_mode)
 
data->primary = igt_output_get_plane_type(data->output, 
DRM_PLANE_TYPE_PRIMARY);
 
-   create_fbs(data, true, data->fb);
+   create_fbs(data, tiling, data->fb);
 
igt_pipe_crc_free(data->pipe_crc);
data->pipe_crc = NULL;
@@ -484,32 +482,41 @@ static void run_test(data_t *data, enum test_mode mode)
 
reset_display(data);
 
-   for_each_pipe_with_valid_output(display, data->pipe, data->output) {
-   prepare_crtc(data);
-
-   igt_info("Beginning %s on pipe %s, connector %s\n",
- igt_subtest_name(),
- kmstest_pipe_name(data->pipe),
- igt_output_name(data->output));
-
-   if (!prepare_test(data, mode)) {
-   igt_info("%s on pipe %s, connector %s: SKIPPED\n",
- igt_subtest_name(),
- kmstest_pipe_name(data->pipe),
- igt_output_name(data->output));
-   continue;
+   for (int tiling = I915_TILING_X;
+tiling <= I915_TILING_Y; tiling++) {
+   for_each_pipe_with_valid_output(display,
+   data->pipe, data->output) {
+   prepare_crtc(data);
+
+   igt_info("Beginning %s on pipe %s, connector "
+   "%s, %s-tiled\n",
+   igt_subtest_name(),
+   kmstest_pipe_name(data->pipe),
+   igt_output_name(data->output),
+   (tiling == I915_TILING_X) ? "x":"y" );
+
+   if (!prepare_test(data, mode,
+ igt_fb_tiling_to_mod(tiling))) {
+   igt_info("%s on pipe %s, connector %s: 
SKIPPED\n",
+   igt_subtest_name(),
+   kmstest_pipe_name(data->pipe),
+   igt_output_name(data->output));
+   continue;
+   }
+
+   valid_tests++;
+
+   test_crc(data, mode);
+
+   igt_info("%s on pipe %s, connector %s"
+   "%s-tiled: PASSED\n",
+   igt_subtest_name(),
+   kmstest_pipe_name(data->pipe),
+   igt_output_name(data->output),
+   (tiling == I915_TILING_X) ? "x":"y" );
+
+   finish_crtc(data, mode);
}
-
-   valid_tests++;
-
-   test_crc(data, mode);
-
-   igt_info("%s on pipe %s, connector %s: PASSED\n",
- igt_subtest_name(),
- kmstest_pipe_name(data->pipe),
- 

[Intel-gfx] [PATCH 4/7] lib/igt_draw: Add Y-tiling support for IGT_DRAW_BLT method

2017-03-17 Thread Praveen Paneri
From: Akash Goel 

Signed-off-by: Akash Goel 
Signed-off-by: Praveen Paneri 
---
 lib/igt_draw.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/lib/igt_draw.c b/lib/igt_draw.c
index fcf8fba..17011d8 100644
--- a/lib/igt_draw.c
+++ b/lib/igt_draw.c
@@ -31,6 +31,7 @@
 #include "igt_core.h"
 #include "igt_fb.h"
 #include "ioctl_wrappers.h"
+#include "i830_reg.h"
 
 /**
  * SECTION:igt_draw
@@ -487,6 +488,23 @@ static void draw_rect_blt(int fd, struct cmd_data 
*cmd_data,
blt_cmd_tiling = (tiling) ? XY_COLOR_BLT_TILED : 0;
pitch = (tiling) ? buf->stride / 4 : buf->stride;
 
+   if (tiling == I915_TILING_Y) {
+   /* To change the tile register, insert an MI_FLUSH_DW followed 
by an MI_LOAD_REGISTER_IMM */
+   BEGIN_BATCH(4, 0);
+   OUT_BATCH(MI_FLUSH_DW | 2);
+   OUT_BATCH(0x0);
+   OUT_BATCH(0x0);
+   OUT_BATCH(0x0);
+   ADVANCE_BATCH();
+
+   BEGIN_BATCH(4, 0);
+   OUT_BATCH(MI_LOAD_REGISTER_IMM);
+   OUT_BATCH(0x22200); /* BCS_SWCTRL */
+   OUT_BATCH(((0x3 << 16) | 0x3)); /* enable the Y tiling */
+   OUT_BATCH(MI_NOOP);
+   ADVANCE_BATCH();
+   }
+
BEGIN_BATCH(6, 1);
OUT_BATCH(XY_COLOR_BLT_CMD_NOLEN | XY_COLOR_BLT_WRITE_ALPHA |
  XY_COLOR_BLT_WRITE_RGB | blt_cmd_tiling | blt_cmd_len);
@@ -497,6 +515,23 @@ static void draw_rect_blt(int fd, struct cmd_data 
*cmd_data,
OUT_BATCH(color);
ADVANCE_BATCH();
 
+   if (tiling == I915_TILING_Y) {
+   /* To change the tile register, insert an MI_FLUSH_DW followed 
by an MI_LOAD_REGISTER_IMM */
+   BEGIN_BATCH(4, 0);
+   OUT_BATCH(MI_FLUSH_DW | 2);
+   OUT_BATCH(0x0);
+   OUT_BATCH(0x0);
+   OUT_BATCH(0x0);
+   ADVANCE_BATCH();
+
+   BEGIN_BATCH(4, 0);
+   OUT_BATCH(MI_LOAD_REGISTER_IMM);
+   OUT_BATCH(0x22200); /* BCS_SWCTRL */
+   OUT_BATCH((0x3 << 16)); /* Reset back to X-Tiling (default) */
+   OUT_BATCH(MI_NOOP);
+   ADVANCE_BATCH();
+   }
+
intel_batchbuffer_flush(batch);
intel_batchbuffer_free(batch);
 }
-- 
2.7.4

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


[Intel-gfx] [PATCH 0/7] Add Y-tiling support into IGTs

2017-03-17 Thread Praveen Paneri
This series adds Y-tiled buffer creation support into IGT libraries and
goes on to use this capability to add support into FBC tests to use
Y-tiled buffers.

Akash Goel (1):
  lib/igt_draw: Add Y-tiling support for IGT_DRAW_BLT method

Paulo Zanoni (1):
  tests/kms_draw_crc: add support for Y tiling

Praveen Paneri (5):
  lib/igt_fb: Let others use igt_get_fb_tile_size
  lib/igt_fb: Add helper function for tile_to_mod
  lib/igt_draw: Add Y-tiling support
  igt/kms_frontbuffer_tracking: Add Y-tiling support
  igt/kms_fbc_crc.c : Add Y-tile tests

 lib/igt_draw.c   | 167 ---
 lib/igt_fb.c |  29 ++-
 lib/igt_fb.h |   4 +-
 tests/kms_draw_crc.c |  58 ++
 tests/kms_fbc_crc.c  |  71 +
 tests/kms_frontbuffer_tracking.c |  46 ++-
 6 files changed, 262 insertions(+), 113 deletions(-)

-- 
2.7.4

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


[Intel-gfx] [PATCH 1/7] lib/igt_fb: Let others use igt_get_fb_tile_size

2017-03-17 Thread Praveen Paneri
This function can be used by igt_draw to get accurate
tile dimensions for all tile formats.

Signed-off-by: Praveen Paneri 
---
 lib/igt_fb.c | 2 +-
 lib/igt_fb.h | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index d2b7e9e..6ecc36b 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -74,7 +74,7 @@ static struct format_desc_struct {
 #define for_each_format(f) \
for (f = format_desc; f - format_desc < ARRAY_SIZE(format_desc); f++)
 
-static void igt_get_fb_tile_size(int fd, uint64_t tiling, int fb_bpp,
+void igt_get_fb_tile_size(int fd, uint64_t tiling, int fb_bpp,
 unsigned *width_ret, unsigned *height_ret)
 {
switch (tiling) {
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index 4a680ce..b178eba 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -94,7 +94,8 @@ enum igt_text_align {
align_vcenter   = 0x04,
align_hcenter   = 0x08,
 };
-
+void igt_get_fb_tile_size(int fd, uint64_t tiling, int fb_bpp,
+   unsigned *width_ret, unsigned *height_ret);
 void igt_calc_fb_size(int fd, int width, int height, int bpp, uint64_t tiling,
  unsigned *size_ret, unsigned *stride_ret);
 unsigned int
-- 
2.7.4

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


[Intel-gfx] [PATCH 5/7] tests/kms_draw_crc: add support for Y tiling

2017-03-17 Thread Praveen Paneri
From: Paulo Zanoni 

This is the program that's supposed to test lib/igt_draw. We just
added Y tiling support for the library, so add the tests now.

Signed-off-by: Paulo Zanoni 
Signed-off-by: Praveen Paneri 
---
 tests/kms_draw_crc.c | 58 ++--
 1 file changed, 43 insertions(+), 15 deletions(-)

diff --git a/tests/kms_draw_crc.c b/tests/kms_draw_crc.c
index e163981..d434c56 100644
--- a/tests/kms_draw_crc.c
+++ b/tests/kms_draw_crc.c
@@ -47,6 +47,13 @@ static const uint32_t formats[N_FORMATS] = {
DRM_FORMAT_XRGB2101010,
 };
 
+#define N_TILING_METHODS 3
+static const uint64_t tilings[N_TILING_METHODS] = {
+   LOCAL_DRM_FORMAT_MOD_NONE,
+   LOCAL_I915_FORMAT_MOD_X_TILED,
+   LOCAL_I915_FORMAT_MOD_Y_TILED,
+};
+
 struct base_crc {
bool set;
igt_crc_t crc;
@@ -151,6 +158,11 @@ static void draw_method_subtest(enum igt_draw_method 
method,
 {
igt_crc_t crc;
 
+   if (tiling == LOCAL_I915_FORMAT_MOD_Y_TILED)
+   igt_require(intel_gen(intel_get_drm_devid(drm_fd)) >= 9);
+
+   kmstest_unset_all_crtcs(drm_fd, drm_res);
+
/* Use IGT_DRAW_MMAP_GTT on an untiled buffer as the parameter for
 * comparison. Cache the value so we don't recompute it for every single
 * subtest. */
@@ -208,6 +220,12 @@ static void fill_fb_subtest(void)
get_fill_crc(LOCAL_I915_FORMAT_MOD_X_TILED, );
igt_assert_crc_equal(, _crc);
 
+   if (intel_gen(intel_get_drm_devid(drm_fd)) >= 9) {
+   get_fill_crc(LOCAL_I915_FORMAT_MOD_Y_TILED, );
+   igt_assert_crc_equal(, _crc);
+   }
+
+   kmstest_unset_all_crtcs(drm_fd, drm_res);
igt_remove_fb(drm_fd, );
 }
 
@@ -265,28 +283,38 @@ static const char *format_str(int format_index)
}
 }
 
+static const char *tiling_str(int tiling_index)
+{
+   switch (tilings[tiling_index]) {
+   case LOCAL_DRM_FORMAT_MOD_NONE:
+   return "untiled";
+   case LOCAL_I915_FORMAT_MOD_X_TILED:
+   return "xtiled";
+   case LOCAL_I915_FORMAT_MOD_Y_TILED:
+   return "ytiled";
+   default:
+   igt_assert(false);
+   }
+}
+
 igt_main
 {
enum igt_draw_method method;
-   int format_index;
+   int format_idx, tiling_idx;
 
igt_fixture
setup_environment();
 
-   for (format_index = 0; format_index < N_FORMATS; format_index++) {
-   for (method = 0; method < IGT_DRAW_METHOD_COUNT; method++) {
-   igt_subtest_f("draw-method-%s-%s-untiled",
- format_str(format_index),
- igt_draw_get_method_name(method))
-   draw_method_subtest(method, format_index,
-   LOCAL_DRM_FORMAT_MOD_NONE);
-   igt_subtest_f("draw-method-%s-%s-tiled",
- format_str(format_index),
- igt_draw_get_method_name(method))
-   draw_method_subtest(method, format_index,
-   LOCAL_I915_FORMAT_MOD_X_TILED);
-   }
-   }
+   for (format_idx = 0; format_idx < N_FORMATS; format_idx++) {
+   for (method = 0; method < IGT_DRAW_METHOD_COUNT; method++) {
+   for (tiling_idx = 0; tiling_idx < N_TILING_METHODS; tiling_idx++) {
+   igt_subtest_f("draw-method-%s-%s-%s",
+ format_str(format_idx),
+ igt_draw_get_method_name(method),
+ tiling_str(tiling_idx))
+   draw_method_subtest(method, format_idx,
+   tilings[tiling_idx]);
+   } } }
 
igt_subtest("fill-fb")
fill_fb_subtest();
-- 
2.7.4

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


[Intel-gfx] [PATCH 3/7] lib/igt_draw: Add Y-tiling support

2017-03-17 Thread Praveen Paneri
This patch adds Y-tiling support for igt_draw_rect function.

v2:
Use helper function to get tile sizes (Ville)

Signed-off-by: Praveen Paneri 
---
 lib/igt_draw.c | 132 +
 1 file changed, 87 insertions(+), 45 deletions(-)

diff --git a/lib/igt_draw.c b/lib/igt_draw.c
index 29aec85..fcf8fba 100644
--- a/lib/igt_draw.c
+++ b/lib/igt_draw.c
@@ -136,32 +136,47 @@ static int swizzle_addr(int addr, int swizzle)
 
 /* It's all in "pixel coordinates", so make sure you multiply/divide by the bpp
  * if you need to. */
-static int linear_x_y_to_tiled_pos(int x, int y, uint32_t stride, int swizzle,
-  int bpp)
+static int linear_x_y_to_tiled_pos(int fd, int x, int y, uint32_t stride, int 
swizzle,
+  int bpp, int tiling)
 {
-   int x_tile_size, y_tile_size;
-   int x_tile_n, y_tile_n, x_tile_off, y_tile_off;
-   int line_size, tile_size;
+   uint32_t tile_width, tile_height, tile_size;
+   int tile_x, tile_y; /* Co-ordinates of the tile holding the pixel */
+   int tile_x_off, tile_y_off; /* pixel position inside the tile */
int tile_n, tile_off;
-   int tiled_pos, tiles_per_line;
+   int line_size, tiles_per_line;
+   int tiled_pos;
int pixel_size = bpp / 8;
 
+   igt_get_fb_tile_size(fd, (uint64_t)igt_fb_tiling_to_mod(tiling), bpp,
+   _width, _height);
+
line_size = stride;
-   x_tile_size = 512;
-   y_tile_size = 8;
-   tile_size = x_tile_size * y_tile_size;
-   tiles_per_line = line_size / x_tile_size;
+   tile_size = tile_width * tile_height;
+   tiles_per_line = line_size / tile_width;
 
-   y_tile_n = y / y_tile_size;
-   y_tile_off = y % y_tile_size;
+   tile_y = y / tile_height;
+   tile_y_off = y % tile_height;
 
-   x_tile_n = (x * pixel_size) / x_tile_size;
-   x_tile_off = (x * pixel_size) % x_tile_size;
+   tile_x = (x * pixel_size) / tile_width;
+   tile_x_off = (x * pixel_size) % tile_width;
 
-   tile_n = y_tile_n * tiles_per_line + x_tile_n;
-   tile_off = y_tile_off * x_tile_size + x_tile_off;
-   tiled_pos = tile_n * tile_size + tile_off;
+   tile_n = tile_y * tiles_per_line + tile_x;
+
+   if (tiling == I915_TILING_X ) {
+   tile_off = tile_y_off * tile_width + tile_x_off;
+   } else { /* (tiling == I915_TILING_Y ) */
+   int x_oword_n, x_oword_off;
+   int oword_size = 16;
+
+   /* computation inside the tile */
+   x_oword_n = tile_x_off / oword_size;
+   x_oword_off = tile_x_off % oword_size;
+   tile_off = x_oword_n * tile_height * oword_size
+  + tile_y_off * oword_size
+  + x_oword_off;
+   }
 
+   tiled_pos = tile_n * tile_size + tile_off;
tiled_pos = swizzle_addr(tiled_pos, swizzle);
 
return tiled_pos / pixel_size;
@@ -169,34 +184,49 @@ static int linear_x_y_to_tiled_pos(int x, int y, uint32_t 
stride, int swizzle,
 
 /* It's all in "pixel coordinates", so make sure you multiply/divide by the bpp
  * if you need to. */
-static void tiled_pos_to_x_y_linear(int tiled_pos, uint32_t stride,
-   int swizzle, int bpp, int *x, int *y)
+static void tiled_pos_to_x_y_linear(int fd, int tiled_pos, uint32_t stride,
+   int swizzle, int bpp, int *x, int *y,
+   int tiling)
 {
-   int tile_n, tile_off, tiles_per_line, line_size;
-   int x_tile_off, y_tile_off;
-   int x_tile_n, y_tile_n;
-   int x_tile_size, y_tile_size, tile_size;
+   uint32_t tile_width, tile_height, tile_size;
+   int tile_x, tile_y; /* Co-ordinates of the tile holding the pixel */
+   int tile_x_off, tile_y_off; /* pixel position inside the tile */
+   int tile_n, tile_off;
+   int line_size, tiles_per_line;
int pixel_size = bpp / 8;
 
+   igt_get_fb_tile_size(fd, (uint64_t)igt_fb_tiling_to_mod(tiling), bpp,
+ _width, _height);
tiled_pos = swizzle_addr(tiled_pos, swizzle);
 
line_size = stride;
-   x_tile_size = 512;
-   y_tile_size = 8;
-   tile_size = x_tile_size * y_tile_size;
-   tiles_per_line = line_size / x_tile_size;
+   tile_size = tile_width * tile_height;
+   tiles_per_line = line_size / tile_width;
 
tile_n = tiled_pos / tile_size;
tile_off = tiled_pos % tile_size;
 
-   y_tile_off = tile_off / x_tile_size;
-   x_tile_off = tile_off % x_tile_size;
+   tile_x = tile_n % tiles_per_line;
+   tile_y = tile_n / tiles_per_line;
 
-   x_tile_n = tile_n % tiles_per_line;
-   y_tile_n = tile_n / tiles_per_line;
+   if (tiling == I915_TILING_X ) {
 
-   *x = (x_tile_n * x_tile_size + x_tile_off) / pixel_size;

[Intel-gfx] [PATCH 6/7] igt/kms_frontbuffer_tracking: Add Y-tiling support

2017-03-17 Thread Praveen Paneri
Allow tests to create Y-tiled bufferes using a separate
argument to the test without increasing the number of
subtests.

Signed-off-by: Praveen Paneri 
---
 tests/kms_frontbuffer_tracking.c | 46 +++-
 1 file changed, 27 insertions(+), 19 deletions(-)

diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index 03c7710..0597f10 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -250,6 +250,7 @@ struct {
int only_pipes;
int shared_fb_x_offset;
int shared_fb_y_offset;
+   uint64_t tiling;
 } opt = {
.check_status = true,
.check_crc = true,
@@ -262,6 +263,7 @@ struct {
.only_pipes = PIPE_COUNT,
.shared_fb_x_offset = 500,
.shared_fb_y_offset = 500,
+   .tiling = LOCAL_I915_FORMAT_MOD_X_TILED,
 };
 
 struct modeset_params {
@@ -576,7 +578,7 @@ static void create_fb(enum pixel_format pformat, int width, 
int height,
if (plane == PLANE_CUR)
tiling_for_size = LOCAL_DRM_FORMAT_MOD_NONE;
else
-   tiling_for_size = LOCAL_I915_FORMAT_MOD_X_TILED;
+   tiling_for_size = opt.tiling;
 
igt_calc_fb_size(drm.fd, width, height, bpp, tiling_for_size, ,
 );
@@ -708,7 +710,7 @@ static void create_shared_fb(enum pixel_format format)
 
big_h = prim_h + scnd_h + offs_h + opt.shared_fb_y_offset;
 
-   create_fb(format, big_w, big_h, LOCAL_I915_FORMAT_MOD_X_TILED,
+   create_fb(format, big_w, big_h, opt.tiling,
  PLANE_PRI, >big);
 }
 
@@ -742,16 +744,16 @@ static void create_fbs(enum pixel_format format)
 
create_fb(format, prim_mode_params.mode->hdisplay,
  prim_mode_params.mode->vdisplay,
- LOCAL_I915_FORMAT_MOD_X_TILED, PLANE_PRI, >prim_pri);
+ opt.tiling, PLANE_PRI, >prim_pri);
create_fb(format, prim_mode_params.cursor.w,
  prim_mode_params.cursor.h, LOCAL_DRM_FORMAT_MOD_NONE,
  PLANE_CUR, >prim_cur);
create_fb(format, prim_mode_params.sprite.w,
- prim_mode_params.sprite.h, LOCAL_I915_FORMAT_MOD_X_TILED,
+ prim_mode_params.sprite.h, opt.tiling,
  PLANE_SPR, >prim_spr);
 
create_fb(format, offscreen_fb.w, offscreen_fb.h,
- LOCAL_I915_FORMAT_MOD_X_TILED, PLANE_PRI, >offscreen);
+ opt.tiling, PLANE_PRI, >offscreen);
 
create_shared_fb(format);
 
@@ -760,11 +762,11 @@ static void create_fbs(enum pixel_format format)
 
create_fb(format, scnd_mode_params.mode->hdisplay,
  scnd_mode_params.mode->vdisplay,
- LOCAL_I915_FORMAT_MOD_X_TILED, PLANE_PRI, >scnd_pri);
+ opt.tiling, PLANE_PRI, >scnd_pri);
create_fb(format, scnd_mode_params.cursor.w, scnd_mode_params.cursor.h,
  LOCAL_DRM_FORMAT_MOD_NONE, PLANE_CUR, >scnd_cur);
create_fb(format, scnd_mode_params.sprite.w, scnd_mode_params.sprite.h,
- LOCAL_I915_FORMAT_MOD_X_TILED, PLANE_SPR, >scnd_spr);
+ opt.tiling, PLANE_SPR, >scnd_spr);
 }
 
 static bool set_mode_for_params(struct modeset_params *params)
@@ -1241,7 +1243,7 @@ static void init_blue_crc(enum pixel_format format, bool 
mandatory_sink_crc)
 
create_fb(format, prim_mode_params.mode->hdisplay,
  prim_mode_params.mode->vdisplay,
- LOCAL_I915_FORMAT_MOD_X_TILED, PLANE_PRI, );
+ opt.tiling, PLANE_PRI, );
 
fill_fb(, COLOR_PRIM_BG);
 
@@ -1276,7 +1278,7 @@ static void init_crcs(enum pixel_format format,
for (r = 0; r < pattern->n_rects; r++)
create_fb(format, prim_mode_params.mode->hdisplay,
  prim_mode_params.mode->vdisplay,
- LOCAL_I915_FORMAT_MOD_X_TILED, PLANE_PRI, 
_fbs[r]);
+ opt.tiling, PLANE_PRI, _fbs[r]);
 
for (r = 0; r < pattern->n_rects; r++)
fill_fb(_fbs[r], COLOR_PRIM_BG);
@@ -2374,7 +2376,7 @@ static void flip_subtest(const struct test_mode *t)
prepare_subtest(t, pattern);
 
create_fb(t->format, params->fb.fb->width, params->fb.fb->height,
- LOCAL_I915_FORMAT_MOD_X_TILED, t->plane, );
+ opt.tiling, t->plane, );
fill_fb(, bg_color);
orig_fb = params->fb.fb;
 
@@ -2420,7 +2422,7 @@ static void fliptrack_subtest(const struct test_mode *t, 
enum flip_type type)
prepare_subtest(t, pattern);
 
create_fb(t->format, params->fb.fb->width, params->fb.fb->height,
- LOCAL_I915_FORMAT_MOD_X_TILED, t->plane, );
+ opt.tiling, t->plane, );
fill_fb(, COLOR_PRIM_BG);
orig_fb = params->fb.fb;
 
@@ -2631,7 +2633,7 @@ static void fullscreen_plane_subtest(const struct 
test_mode *t)
prepare_subtest(t, 

[Intel-gfx] [PATCH 2/7] lib/igt_fb: Add helper function for tile_to_mod

2017-03-17 Thread Praveen Paneri
igt_get_fb_tile_size function takes modifer as an argument
This helper function will let users to convert tiling to
modifier and use igt_get_fb_tile_size()

Signed-off-by: Praveen Paneri 
---
 lib/igt_fb.c | 27 +++
 lib/igt_fb.h |  1 +
 2 files changed, 28 insertions(+)

diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index 6ecc36b..31fb918 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -206,6 +206,33 @@ uint64_t igt_fb_mod_to_tiling(uint64_t modifier)
}
 }
 
+/**
+ * igt_fb_tiling_to_mod:
+ * @tiling: DRM framebuffer tiling
+ *
+ * This function converts a DRM framebuffer tiling to its corresponding
+ * modifier constant.
+ *
+ * Returns:
+ * A tiling constant
+ */
+uint64_t igt_fb_tiling_to_mod(uint64_t tiling)
+{
+   switch (tiling) {
+   case I915_TILING_NONE:
+   return LOCAL_DRM_FORMAT_MOD_NONE;
+   case I915_TILING_X:
+   return LOCAL_I915_FORMAT_MOD_X_TILED;
+   case I915_TILING_Y:
+   return LOCAL_I915_FORMAT_MOD_Y_TILED;
+   case I915_TILING_Yf:
+   return LOCAL_I915_FORMAT_MOD_Yf_TILED;
+   default:
+   igt_assert(0);
+   }
+}
+
+
 /* helpers to create nice-looking framebuffers */
 static int create_bo_for_fb(int fd, int width, int height, uint32_t format,
uint64_t tiling, unsigned size, unsigned stride,
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index b178eba..6972a80 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -131,6 +131,7 @@ int igt_create_bo_with_dimensions(int fd, int width, int 
height, uint32_t format
  bool *is_dumb);
 
 uint64_t igt_fb_mod_to_tiling(uint64_t modifier);
+uint64_t igt_fb_tiling_to_mod(uint64_t tiling);
 
 /* cairo-based painting */
 cairo_t *igt_get_cairo_ctx(int fd, struct igt_fb *fb);
-- 
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 drm/i915: Reinstate reservation_object zapping for batch_pool objects

2017-03-17 Thread Patchwork
== Series Details ==

Series: drm/i915: Reinstate reservation_object zapping for batch_pool objects
URL   : https://patchwork.freedesktop.org/series/21464/
State : success

== Summary ==

Series 21464v1 drm/i915: Reinstate reservation_object zapping for batch_pool 
objects
https://patchwork.freedesktop.org/api/1.0/series/21464/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 457s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 574s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 530s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 546s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 506s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 502s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 538s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 431s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 436s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 520s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 488s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 490s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 478s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 591s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 481s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 514s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 549s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 418s

c515588cd91b6e4c5ed697c1b8199076a3a94e3b drm-tip: 2017y-03m-17d-17h-58m-43s UTC 
integration manifest
16cfc88 drm/i915: Reinstate reservation_object zapping for batch_pool objects

== Logs ==

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


[Intel-gfx] [PATCH] drm/i915: Reinstate reservation_object zapping for batch_pool objects

2017-03-17 Thread Chris Wilson
I removed the zapping of the reservation_object->fence array of shared
fences prematurely. We don't yet have the code to zap that array when
retiring the object, and so currently it remains possible to continually
grow the shared array trapping requests when reusing the batch_pool
object across many timelines.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_batch_pool.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c 
b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
index 41aa598c4f3b..414e46e2f072 100644
--- a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
@@ -114,12 +114,26 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
list_for_each_entry(obj, list, batch_pool_link) {
/* The batches are strictly LRU ordered */
if (i915_gem_object_is_active(obj)) {
-   if (!reservation_object_test_signaled_rcu(obj->resv,
- true))
+   struct reservation_object *resv = obj->resv;
+
+   if (!reservation_object_test_signaled_rcu(resv, true))
break;
 
i915_gem_retire_requests(pool->engine->i915);
GEM_BUG_ON(i915_gem_object_is_active(obj));
+
+   /* The object is now idle, clear the array of shared
+* fences before we add a new request. Although, we
+* remain on the same engine, we may be on a different
+* timeline and so may continually grow the array,
+* trapping a reference to all the old fences, rather
+* than replace the existing fence.
+*/
+   if (rcu_access_pointer(resv->fence)) {
+   reservation_object_lock(resv, NULL);
+   reservation_object_add_excl_fence(resv, NULL);
+   reservation_object_unlock(resv);
+   }
}
 
GEM_BUG_ON(!reservation_object_test_signaled_rcu(obj->resv,
-- 
2.11.0

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


Re: [Intel-gfx] [PATCH] drm/i915: Add i810/i815 pci-ids for completeness

2017-03-17 Thread Chris Wilson
On Mon, Mar 13, 2017 at 03:04:21PM +0200, Jani Nikula wrote:
> On Mon, 13 Mar 2017, Chris Wilson  wrote:
> > To improve our historical record and to simplify userspace that wants to
> > include i915_pciids.h as its canonical breakdown of PCI IDs and their
> > respective generations, include the gen1 ids for i810 and i815.
> 
> Is this how you start sneaking in support for them in i915? ;)
> 
> Acked-by: Jani Nikula 

Ok, pulled the trigger on this so I can use the single set of i915
pciids from userspace.
-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] [GIT PULL] GVT-g fixes for 4.11-rc4

2017-03-17 Thread Daniel Vetter
On Fri, Mar 17, 2017 at 05:02:24PM +0800, Zhenyu Wang wrote:
> On 2017.03.17 10:58:26 +0200, Jani Nikula wrote:
> > On Fri, 17 Mar 2017, Zhenyu Wang  wrote:
> > > Hi,
> > >
> > > This is gvt fixes for 4.11-rc4. Last minute rebase was to move
> > > from 70647f9163aa ("Merge tag 'gvt-fixes-2017-03-08' of 
> > > https://github.com/01org/gvt-linux into drm-intel-fixes") onto 
> > > 'drm-intel-fixes-2017-03-14'.
> > >
> > 
> > Why would you do that? Did you have conflicts? You know you don't have
> > to rebase unless there are issues.
> > 
> 
> I did a backmerge of drm-intel-fixes to the gvt-fixes after last pull,
> then now can't generate a sane request pull against previous
> gvt-fixes-2017-03-08...Sorry for that.

You don't generate the pull request against your last pull request, but
against latest upstream (drm-intel-fixes for you). Then it should filter
this all out if you have a backmerge that's merged already.
-Daniel

> 
> > 
> > > p.s, once this pull would hit linus tree, requires a backmerge
> > > with those gvt changes for dinq, as new 4.12 stuff would base on that.
> > >
> > > Thanks.
> > >
> > > --
> > > The following changes since commit 
> > > 6aef660370a9c246956ba6d01eebd8063c4214cb:
> > >
> > >   drm/i915: Fix forcewake active domain tracking (2017-03-13 17:30:54 
> > > +0200)
> > >
> > > are available in the git repository at:
> > >
> > >   https://github.com/01org/gvt-linux.git tags/gvt-fixes-2017-03-17
> > >
> > > for you to fetch changes up to 2958b9013fcbabeeba221161d0712f5259f1e15d:
> > >
> > >   drm/i915/gvt: Fix gvt scheduler interval time (2017-03-17 16:46:45 
> > > +0800)
> > >
> > > 
> > > gvt-fixes-2017-03-17
> > >
> > > - force_nonpriv reg handling in cmd parser (Yan)
> > > - gvt error message cleanup (Tina)
> > > - i915_wait_request fix from Chris
> > > - KVM srcu warning fix (Changbin)
> > > - ensure shadow ctx pinned (Chuanxiao)
> > > - critical gvt scheduler interval time fix (Zhenyu)
> > > - etc.
> > >
> > > 
> > > Changbin Du (1):
> > >   drm/i915/kvmgt: fix suspicious rcu dereference usage
> > >
> > > Chris Wilson (1):
> > >   drm/i915/gvt: Remove bogus retry around i915_wait_request
> > >
> > > Chuanxiao Dong (2):
> > >   drm/i915/gvt: add enable_execlists check before enable gvt
> > >   drm/i915/gvt: GVT pin/unpin shadow context
> > >
> > > Tina Zhang (2):
> > >   drm/i915/gvt: replace the gvt_err with gvt_vgpu_err
> > >   drm/i915/gvt: scan shadow indirect context image when valid
> > >
> > > Yulei Zhang (1):
> > >   drm/i915/gvt: correct the ggtt valid bit check in pipe control 
> > > command
> > >
> > > Zhao Yan (1):
> > >   drm/i915/gvt: handle force-nonpriv registers, cmd parser part
> > >
> > > Zhenyu Wang (1):
> > >   drm/i915/gvt: Fix gvt scheduler interval time
> > >
> > >  drivers/gpu/drm/i915/gvt/aperture_gm.c  |   8 +--
> > >  drivers/gpu/drm/i915/gvt/cmd_parser.c   | 109 
> > > +---
> > >  drivers/gpu/drm/i915/gvt/debug.h|   8 +++
> > >  drivers/gpu/drm/i915/gvt/edid.c |  13 ++--
> > >  drivers/gpu/drm/i915/gvt/execlist.c |  29 -
> > >  drivers/gpu/drm/i915/gvt/gtt.c  |  74 +++---
> > >  drivers/gpu/drm/i915/gvt/handlers.c |  45 -
> > >  drivers/gpu/drm/i915/gvt/kvmgt.c|  37 +++
> > >  drivers/gpu/drm/i915/gvt/mmio.c |  38 +--
> > >  drivers/gpu/drm/i915/gvt/mmio.h |   3 +
> > >  drivers/gpu/drm/i915/gvt/opregion.c |  10 +--
> > >  drivers/gpu/drm/i915/gvt/render.c   |   2 +-
> > >  drivers/gpu/drm/i915/gvt/sched_policy.c |   4 +-
> > >  drivers/gpu/drm/i915/gvt/scheduler.c|  61 --
> > >  drivers/gpu/drm/i915/intel_gvt.c|   5 ++
> > >  15 files changed, 268 insertions(+), 178 deletions(-)
> > 
> > -- 
> > Jani Nikula, Intel Open Source Technology Center
> 
> -- 
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827



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


Re: [Intel-gfx] [dim PATCH 00/10] dim: shellcheck fixes

2017-03-17 Thread Daniel Vetter
On Fri, Mar 17, 2017 at 12:42:51PM +0200, Jani Nikula wrote:
> Noticing that 64a54c5e1a5d ("dim: Add add-link command") added a
> condition that is always true (if [ -n $foo ]), despite my review of the
> patch, I refreshed some of my old patches to fix issues that can be
> caught by shellcheck.
> 
> Starting from patch 1, the minimal merge criteria for any new dim
> patches is that 'make shellcheck' passes.
> 
> I add shellcheck exceptions for starters, so there are no errors
> reported, and then remove the exceptions by fixing them one by one. I'm
> not sure if we'll ever fix them all, but let's at least make sure we're
> not adding any new silly mistakes.

Ack on the entire series. checkpatch for dim!
-Daniel

> 
> BR,
> Jani.
> 
> 
> 
> Jani Nikula (10):
>   dim: add make target to shellcheck dim
>   dim: quote check for non-zero string
>   dim: replace expr with $((..))
>   dim: use $* instead of $@ within string
>   dim: double quote array expansions
>   dim: quote expressions using { }
>   dim: add double quotes to prevent glob interpretation
>   dim: prevent * from becoming options
>   dim: avoid useless cat in apply-branch
>   dim: Replace `..` with $(..)
> 
>  Makefile |  16 +++
>  dim  | 143 
> ---
>  2 files changed, 88 insertions(+), 71 deletions(-)
> 
> -- 
> 2.1.4
> 

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


Re: [Intel-gfx] [PATCH] drm/atomic: protect crtc|connector->state with rcu

2017-03-17 Thread Maarten Lankhorst
Op 16-03-17 om 21:15 schreef Daniel Vetter:
> On Thu, Mar 16, 2017 at 5:09 PM, Maarten Lankhorst
>  wrote:
>> Op 16-03-17 om 16:52 schreef Daniel Vetter:
>>> The vblank code really wants to look at crtc->state without having to
>>> take a ww_mutex. One option might be to take one of the vblank locks
>>> right when assigning crtc->state, which would ensure that the vblank
>>> code doesn't race and access freed memory.
>> I'm not sure this is the right approach for vblank.
> It's not, it's just that I've had to resurrect this patch quickly
> before leaving and accidentally left the vblank stuff in.
>
>> crtc->state might not be the same as the current state in case of a 
>> nonblocking
>> modeset that hasn't even disabled the old crtc yet.
>>> But userspace tends to poke the vblank_ioctl to query the current
>>> vblank timestamp rather often, and going all in with rcu would help a
>>> bit. We're not there yet, but also doesn't really hurt.
>>>
>>> v2: Maarten needs this to make connector properties atomic, so he can
>>> peek at state from the various ->mode_valid hooks.
>>>
>>> Cc: Maarten Lankhorst 
>>> Signed-off-by: Daniel Vetter 
>>> ---
>>>  drivers/gpu/drm/drm_atomic.c| 26 +-
>>>  drivers/gpu/drm/drm_atomic_helper.c |  2 +-
>>>  include/drm/drm_atomic.h|  5 +
>>>  include/drm/drm_connector.h | 13 -
>>>  include/drm/drm_crtc.h  |  9 -
>>>  5 files changed, 43 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>>> index 9b892af7811a..ba11e31ff9ba 100644
>>> --- a/drivers/gpu/drm/drm_atomic.c
>>> +++ b/drivers/gpu/drm/drm_atomic.c
>>> @@ -213,16 +213,10 @@ void drm_atomic_state_clear(struct drm_atomic_state 
>>> *state)
>>>  }
>>>  EXPORT_SYMBOL(drm_atomic_state_clear);
>>>
>>> -/**
>>> - * __drm_atomic_state_free - free all memory for an atomic state
>>> - * @ref: This atomic state to deallocate
>>> - *
>>> - * This frees all memory associated with an atomic state, including all the
>>> - * per-object state for planes, crtcs and connectors.
>>> - */
>>> -void __drm_atomic_state_free(struct kref *ref)
>>> +void ___drm_atomic_state_free(struct rcu_head *rhead)
>>>  {
>>> - struct drm_atomic_state *state = container_of(ref, typeof(*state), 
>>> ref);
>>> + struct drm_atomic_state *state =
>>> + container_of(rhead, typeof(*state), rhead);
>>>   struct drm_mode_config *config = >dev->mode_config;
>>>
>>>   drm_atomic_state_clear(state);
>>> @@ -236,6 +230,20 @@ void __drm_atomic_state_free(struct kref *ref)
>>>   kfree(state);
>>>   }
>>>  }
>> whatisRCU.txt:
>> "This function invokes func(head) after a grace period has elapsed.
>> This invocation might happen from either softirq or process context,
>> so the function is not permitted to block."
>>
>> Looking at
>> commit 6f0f02dc56f18760b46dc1bf5b3f7386869d4162
>> Author: Chris Wilson 
>> Date:   Mon Jan 23 21:29:39 2017 +
>>
>> drm/i915: Move atomic state free from out of fence release
>>
>> I would say that drm_atomic_state_free would definitely block..
>>
>> The only thing that makes sense IMO is doing kfree_rcu on the object_states.
>> But I don't think RCU is the answer here, it won't protect you against using
>> the wrong crtc state.
>>
>> I think I would try to use the crtc ww_mutex in the vblank code and 
>> serialize it to pending commits, if at all possible.
> Oops. I guess it should have come with "totally untested". In that
> case we need a workter which does a synchronize_rcu() before
> releasing. I don't just want to do a simple kfree_rcu() because by
> that point we've (partially) destroyed the state alreayd (so it's
> already unsafe to access, and special ruels are ugly). And doing it
> here before we release anything in the core would avoid the need for
> drivers to bother with kfree_rcu().
>
> I'll try to respin something less obviously buggy tomorrow :-)
It will still be buggy tomorrow, since you have no way to know if the current 
hardware crtc_state is anything like crtc->state.

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


[Intel-gfx] [Announcement] 2016-Q4 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

2017-03-17 Thread Wang, Hongbo
Hi all,

We are pleased to announce another update of Intel GVT-g for Xen.

Intel GVT-g is a full GPU virtualization solution with mediated pass-through, 
starting from 4th generation Intel Core(TM) processors with Intel Graphics 
processors. A virtual GPU instance is maintained for each VM, with part of 
performance critical resources directly assigned. The capability of running 
native graphics driver inside a VM, without hypervisor intervention in 
performance critical paths, achieves a good balance among performance, feature, 
and sharing capability. Xen is currently supported on Intel Processor Graphics 
(a.k.a. XenGT).

Repositories
-Xen: https://github.com/01org/igvtg-xen (2016q4-4.6 branch)
-Kernel: https://github.com/01org/igvtg-kernel (2016q4-4.3.0 branch)
-Qemu: https://github.com/01org/igvtg-qemu (2016q4-2.3.0 branch)

This update consists of:
-Support new platform: Intel Core 7th Generation, and Intel Xen E3 v6.  
Code name is Kabylake.
-Improve stability when QoS feature is enabled
-Windows10 RedStone2 64bit support


Known issues:< QA need provide>
-   At least 2GB memory is suggested for Guest Virtual Machine (win7-32/64, 
win8.1-64, win10-64) to run most 3D workloads
-   Windows8 and later Windows fast boot is not supported, the workaround is to 
disable power S3/S4 in HVM file by adding “acpi_S3=0, acpi_S4=0”
-   Sometimes when dom0 and guest has heavy workload, i915 in dom0 will trigger 
a false-alarmed TDR. The workaround is to disable dom0 hangcheck in dom0 grub 
file by adding “i915.enable_hangcheck=0”

This is the last GVT-g community release based on old architecture design. 
After that, our next community release will switch to new code repository and 
new upstream architecture which has been upstreamed in kernel 4.10. 
Refer to the following blog for more details. 
https://01.org/igvt-g/blogs/wangbo85/2017/gvt-g-upstream-status-update-were-transition-phase
 

GVT-g project portal: https://01.org/igvt-g please subscribe mailing list: 
https://lists.01.org/mailman/listinfo/igvt-g

More information about background, architecture and others about Intel GVT-g, 
can be found at:
https://01.org/igvt-g
https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian

http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-v7_0.pdf

http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-REWRITE%203RD%20v4.pdf
https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt


Note: The XenGT project should be considered a work in progress. As such it is 
not a complete product nor should it be considered one. Extra care should be 
taken when testing and configuring a system to use the XenGT project.



Best regards.
Hongbo
Tel: +86-21-6116 7445
MP: +86-1364 1793 689
Mail: hongbo.w...@intel.com

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


[Intel-gfx] [ANNOUNCE] 2016-Q4 release of KVMGT (Intel GVT-g for KVM)

2017-03-17 Thread Wang, Hongbo
Hi all,

Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with 
mediated pass-through, starting from 5th generation Intel Core(TM) processors 
with Intel Graphics processors.  A virtual GPU instance is maintained for each 
VM, with part of performance critical resources directly assigned. The 
capability of running native graphics driver inside a VM, without hypervisor 
intervention in performance critical paths, achieves a good balance among 
performance, feature, and sharing capability.

Repositories:

Kernel: https://github.com/01org/igvtg-kernel (2016q4-4.3.0 branch)
Qemu: https://github.com/01org/igvtg-qemu (2016q4-2.3.0 branch)

This update consists of:
-Support new platform: Intel Core 7th Generation, and Intel Xen E3 v6.  
Code name is Kabylake.
-Improve stability when QoS feature is enabled
-Windows10 RedStone2 64bit support


Known issues:
-   At least 2GB memory is suggested for Guest Virtual Machine (win7-32/64, 
win8.1-64, win10-64) to run most 3D workloads
-   Windows8 and later Windows fast boot is not supported, the workaround is to 
disable power S3/S4 in HVM file by adding “acpi_S3=0, acpi_S4=0”
-   Sometimes when dom0 and guest has heavy workload, i915 in dom0 will trigger 
a false-alarmed TDR. The workaround is to disable dom0 hangcheck in dom0 grub 
file by adding “i915.enable_hangcheck=0”
-   Win7 32bit guest may meet tdr while multi guests are concurrently running 
heavy workload for a long time

Note: This is the last GVT-g community release based on old architecture 
design. After that, our next community release will switch to new code 
repository and new upstream architecture which has been upstreamed in kernel 
4.10. 
Refer to the following blog for more details. 
https://01.org/igvt-g/blogs/wangbo85/2017/gvt-g-upstream-status-update-were-transition-phase
 

Please subscribe to join the mailing list: 
https://lists.01.org/mailman/listinfo/igvt-g

Official iGVT-g portal: https://01.org/igvt-g

More information about background, architecture and others about Intel GVT-g, 
can be found at:

http://www.linux-kvm.org/images/f/f3/01x08b-KVMGT-a.pdf
https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian


Note:
The KVMGT project should be considered a work in progress. As such it is not a 
complete product nor should it be considered one. Extra care should be taken 
when testing and configuring a system to use the KVMGT project.


Best regards.
Hongbo
Tel: +86-21-6116 7445
MP: +86-1364 1793 689
Mail: hongbo.w...@intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2] drm/i915/glk: Enable pooled EUs for Geminilake

2017-03-17 Thread Mika Kuoppala
Ander Conselvan de Oliveira 
writes:

> Geminilake also supports pooled EUs. Enable it.
>
> It is unclear if the recommendation to disable it for 2x6 configurations
> from commit e015dd69b2cf ("drm/i915/bxt: Add WaEnablePooledEuFor2x6")
> should also apply to GLK, but it is applied anyway to be on the safe
> side. That restriction can be lifted later if determined not to impact
> performance.
>
> The extra restriction should not impact user space either. The only user
> space that uses this feature is Beignet, and it only does so for 3x6
> devices. See See Beignet's commit 6901899ec90a ("Runtime: set the sub
> slice according to kernel pooled EU configure.").
>
> v2: Improve commit message. (Mika, Roy)
>
> Cc: Arun Siluvery 
> Cc: Mika Kuoppala 
> Cc: Tvrtko Ursulin 
> Cc: Yang Rong 
> Signed-off-by: Ander Conselvan de Oliveira 
> 

Pushed, thanks for patch and review.
-Mika

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


Re: [Intel-gfx] [PATCH v2] drm/i915/glk: Enable pooled EUs for Geminilake

2017-03-17 Thread Mika Kuoppala
Ander Conselvan de Oliveira 
writes:

> Geminilake also supports pooled EUs. Enable it.
>
> It is unclear if the recommendation to disable it for 2x6 configurations
> from commit e015dd69b2cf ("drm/i915/bxt: Add WaEnablePooledEuFor2x6")
> should also apply to GLK, but it is applied anyway to be on the safe
> side. That restriction can be lifted later if determined not to impact
> performance.
>
> The extra restriction should not impact user space either. The only user
> space that uses this feature is Beignet, and it only does so for 3x6
> devices. See See Beignet's commit 6901899ec90a ("Runtime: set the sub
> slice according to kernel pooled EU configure.").
>
> v2: Improve commit message. (Mika, Roy)
>
> Cc: Arun Siluvery 
> Cc: Mika Kuoppala 
> Cc: Tvrtko Ursulin 
> Cc: Yang Rong 
> Signed-off-by: Ander Conselvan de Oliveira 
> 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/intel_device_info.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
> b/drivers/gpu/drm/i915/intel_device_info.c
> index 9fc6ab7..7d01dfe 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -197,8 +197,10 @@ static void gen9_sseu_info_init(struct drm_i915_private 
> *dev_priv)
>   IS_GEN9_LP(dev_priv) && sseu_subslice_total(sseu) > 1;
>   sseu->has_eu_pg = sseu->eu_per_subslice > 2;
>  
> - if (IS_BROXTON(dev_priv)) {
> + if (IS_GEN9_LP(dev_priv)) {
>  #define IS_SS_DISABLED(ss)   (!(sseu->subslice_mask & BIT(ss)))
> + info->has_pooled_eu = hweight8(sseu->subslice_mask) == 3;
> +
>   /*
>* There is a HW issue in 2x6 fused down parts that requires
>* Pooled EU to be enabled as a WA. The pool configuration
> @@ -206,9 +208,8 @@ static void gen9_sseu_info_init(struct drm_i915_private 
> *dev_priv)
>* doesn't affect if the device has all 3 subslices enabled.
>*/
>   /* WaEnablePooledEuFor2x6:bxt */
> - info->has_pooled_eu = ((hweight8(sseu->subslice_mask) == 3) ||
> -(hweight8(sseu->subslice_mask) == 2 &&
> - INTEL_REVID(dev_priv) < BXT_REVID_C0));
> + info->has_pooled_eu |= (hweight8(sseu->subslice_mask) == 2 &&
> + IS_BXT_REVID(dev_priv, 0, 
> BXT_REVID_B_LAST));
>  
>   sseu->min_eu_in_pool = 0;
>   if (info->has_pooled_eu) {
> -- 
> 2.9.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/915/glk: Enable pooled EUs for Geminilake (rev2)

2017-03-17 Thread Patchwork
== Series Details ==

Series: drm/915/glk: Enable pooled EUs for Geminilake (rev2)
URL   : https://patchwork.freedesktop.org/series/20212/
State : success

== Summary ==

Series 20212v2 drm/915/glk: Enable pooled EUs for Geminilake
https://patchwork.freedesktop.org/api/1.0/series/20212/revisions/2/mbox/

Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a:
dmesg-warn -> PASS   (fi-byt-n2820) fdo#100094

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 460s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 573s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 532s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 562s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 502s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 497s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 437s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 428s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 439s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 510s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 488s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 487s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 480s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 599s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 478s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 515s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 542s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 423s

a201103b5beed97d7ee2f86624d83b1fd7f1c117 drm-tip: 2017y-03m-17d-13h-05m-28s UTC 
integration manifest
b54f395 drm/i915/glk: Enable pooled EUs for Geminilake

== Logs ==

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


[Intel-gfx] [PATCH v2] drm/i915/glk: Enable pooled EUs for Geminilake

2017-03-17 Thread Ander Conselvan de Oliveira
Geminilake also supports pooled EUs. Enable it.

It is unclear if the recommendation to disable it for 2x6 configurations
from commit e015dd69b2cf ("drm/i915/bxt: Add WaEnablePooledEuFor2x6")
should also apply to GLK, but it is applied anyway to be on the safe
side. That restriction can be lifted later if determined not to impact
performance.

The extra restriction should not impact user space either. The only user
space that uses this feature is Beignet, and it only does so for 3x6
devices. See See Beignet's commit 6901899ec90a ("Runtime: set the sub
slice according to kernel pooled EU configure.").

v2: Improve commit message. (Mika, Roy)

Cc: Arun Siluvery 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Cc: Yang Rong 
Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_device_info.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 9fc6ab7..7d01dfe 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -197,8 +197,10 @@ static void gen9_sseu_info_init(struct drm_i915_private 
*dev_priv)
IS_GEN9_LP(dev_priv) && sseu_subslice_total(sseu) > 1;
sseu->has_eu_pg = sseu->eu_per_subslice > 2;
 
-   if (IS_BROXTON(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv)) {
 #define IS_SS_DISABLED(ss) (!(sseu->subslice_mask & BIT(ss)))
+   info->has_pooled_eu = hweight8(sseu->subslice_mask) == 3;
+
/*
 * There is a HW issue in 2x6 fused down parts that requires
 * Pooled EU to be enabled as a WA. The pool configuration
@@ -206,9 +208,8 @@ static void gen9_sseu_info_init(struct drm_i915_private 
*dev_priv)
 * doesn't affect if the device has all 3 subslices enabled.
 */
/* WaEnablePooledEuFor2x6:bxt */
-   info->has_pooled_eu = ((hweight8(sseu->subslice_mask) == 3) ||
-  (hweight8(sseu->subslice_mask) == 2 &&
-   INTEL_REVID(dev_priv) < BXT_REVID_C0));
+   info->has_pooled_eu |= (hweight8(sseu->subslice_mask) == 2 &&
+   IS_BXT_REVID(dev_priv, 0, 
BXT_REVID_B_LAST));
 
sseu->min_eu_in_pool = 0;
if (info->has_pooled_eu) {
-- 
2.9.3

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


Re: [Intel-gfx] [PATCH] drm/i915/glk: CDCLK calculation changes for glk

2017-03-17 Thread Chauhan, Madhav
> -Original Message-
> From: Nikula, Jani
> Sent: Thursday, March 16, 2017 7:00 PM
> To: Ander Conselvan De Oliveira ; Chauhan,
> Madhav ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/glk: CDCLK calculation changes for
> glk
> 
> On Thu, 16 Mar 2017, Ander Conselvan De Oliveira
>  wrote:
> > On Thu, 2017-03-16 at 15:10 +0200, Jani Nikula wrote:
> >> On Thu, 16 Mar 2017, "Chauhan, Madhav"
>  wrote:
> >> > > -Original Message-
> >> > > From: Nikula, Jani
> >> > > Sent: Thursday, February 16, 2017 9:03 PM
> >> > > To: Chauhan, Madhav ; intel-
> >> > > g...@lists.freedesktop.org
> >> > > Cc: Conselvan De Oliveira, Ander
> >> > > ;
> >> > > Shankar, Uma ; Mukherjee, Indranil
> >> > > ; Sharma, Shashank
> >> > > ; Chauhan, Madhav
> >> > > ; ville.syrj...@linux.intel.com
> >> > > Subject: Re: [PATCH] drm/i915/glk: CDCLK calculation changes for
> >> > > glk
> >> > >
> >> > > On Thu, 16 Feb 2017, Madhav Chauhan
> 
> >> > > wrote:
> >> > > > As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 Mhz.
> >> > > > Practically we can achive only 99% of these cdclk values(HW
> >> > > > team checking on this). So cdclk should be calculated for the
> >> > > > given pixclk as per that otherwise it may lead to screen corruption
> for some scenarios.
> >> > > >
> >> > > > v2: Rebased to new CDLCK code framework
> >> > > >
> >> > > > Signed-off-by: Madhav Chauhan 
> >> > > > ---
> >> > > >  drivers/gpu/drm/i915/intel_cdclk.c | 4 ++--
> >> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> >> > > >
> >> > > > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
> >> > > > b/drivers/gpu/drm/i915/intel_cdclk.c
> >> > > > index d643c0c..834df68 100644
> >> > > > --- a/drivers/gpu/drm/i915/intel_cdclk.c
> >> > > > +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> >> > > > @@ -1071,9 +1071,9 @@ static int bxt_calc_cdclk(int max_pixclk)
> >> > > >
> >> > > >  static int glk_calc_cdclk(int max_pixclk)  {
> >> > > > -if (max_pixclk > 2 * 158400)
> >> > > > +if (max_pixclk > DIV_ROUND_UP(2 * 158400 * 99, 100))
> >> > >
> >> > > Where do we ensure we don't use pixel clock 312841..316800?
> >> > > Clearly we shouldn't use that because we can't guarantee it works,
> right?
> >> >
> >> > Why do we need to ensure that ?? Can you please elaborate more on
> this?
> >> > Here we are finding one of  the defined CDCLK value for a pixel
> >> > clock
> >>
> >> I probably had some great idea a month ago when I wrote that, but I
> >> can no longer remember what it was. :(
> >
> > I'm not sure if that is what you meant, but if the hardware can't
> > handle it,
> > intel_compute_max_dotclk() needs to take the 99% limitation into account
> too.
> > I.e., max dot clock would be .99 * 2 *  316800 = 627264.
> 
> Yes, thank you!

Ok. Will include this change as well along with additional comments
for explaining 99% usage of cdclk inside glk_calc_cdclk.
Thanks for review.

> 
> Jani.
> 
> >
> > Ander
> >
> >>
> >> BR,
> >> Jani.
> >>
> >>
> >> > >
> >> > > Before we get the spec update to confirm what to do, I think we
> >> > > need a comment here explaining what's going on.
> >> >
> >> > Will add the following comment, if that's fine, will send the rebased
> patch:
> >> > "For GLK platform, only 99% of the defined CDCLK value can be achieved
> >> >   So calculate pixel clock on that basis"
> >> >
> >> > Regards,
> >> > Madhav
> >> > >
> >> > > BR,
> >> > > Jani.
> >> > >
> >> > > >  return 316800;
> >> > > > -else if (max_pixclk > 2 * 79200)
> >> > > > +else if (max_pixclk > DIV_ROUND_UP(2 * 79200 * 99, 100))
> >> > > >  return 158400;
> >> > > >  else
> >> > > >  return 79200;
> >> > >
> >> > > --
> >> > > Jani Nikula, Intel Open Source Technology Center
> >>
> >>
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH i-g-t 4/4] intel-ci: Add extended.testlist for wider testing

2017-03-17 Thread Petri Latvala
Test list with wider coverage and longer full runtime.

Signed-off-by: Petri Latvala 
CC: Tomi Sarvela 
---

This is a preliminary testlist for extended testing. Tomi has been
running it semi-manually in CI already.

I think I have incorporated all the changes Tomi has been making for
his runs. Tomi can double-check that the list matches.

 tests/intel-ci/README|6 +
 tests/intel-ci/checked_lists.txt |1 +
 tests/intel-ci/extended.testlist | 1919 ++
 3 files changed, 1926 insertions(+)
 create mode 100644 tests/intel-ci/extended.testlist

diff --git a/tests/intel-ci/README b/tests/intel-ci/README
index dc7e5c8..1bc940d 100644
--- a/tests/intel-ci/README
+++ b/tests/intel-ci/README
@@ -32,3 +32,9 @@ test per feature.
 
 The string "basic" in a test name means the test probably belongs in
 this list.
+
+=
+extended.testlist
+=
+
+Test list for wider coverage testing.
diff --git a/tests/intel-ci/checked_lists.txt b/tests/intel-ci/checked_lists.txt
index 2f8a386..34ac85c 100644
--- a/tests/intel-ci/checked_lists.txt
+++ b/tests/intel-ci/checked_lists.txt
@@ -1 +1,2 @@
 fast-feedback.testlist
+extended.testlist
diff --git a/tests/intel-ci/extended.testlist b/tests/intel-ci/extended.testlist
new file mode 100644
index 000..67bd314
--- /dev/null
+++ b/tests/intel-ci/extended.testlist
@@ -0,0 +1,1919 @@
+igt@core_auth@many-magics
+igt@core_get_client_auth@master-drop
+igt@core_get_client_auth@simple
+igt@core_getclient
+igt@core_getstats
+igt@core_getversion
+igt@core_prop_blob@blob-multiple
+igt@core_prop_blob@blob-prop-core
+igt@core_prop_blob@blob-prop-lifetime
+igt@core_prop_blob@blob-prop-validate
+igt@core_prop_blob@invalid-get-prop
+igt@core_prop_blob@invalid-get-prop-any
+igt@core_prop_blob@invalid-set-prop
+igt@core_prop_blob@invalid-set-prop-any
+igt@core_setmaster_vs_auth
+igt@debugfs_emon_crash
+igt@drm_import_export@flink
+igt@drm_import_export@import-close-race-flink
+igt@drm_import_export@import-close-race-prime
+igt@drm_import_export@prime
+igt@drm_read@empty-block
+igt@drm_read@empty-nonblock
+igt@drm_read@fault-buffer
+igt@drm_read@invalid-buffer
+igt@drm_read@short-buffer-block
+igt@drm_read@short-buffer-nonblock
+igt@drm_vma_limiter
+igt@drm_vma_limiter_cached
+igt@drm_vma_limiter_cpu
+igt@drm_vma_limiter_gtt
+igt@drv_debugfs_reader
+igt@drv_missed_irq
+igt@drv_suspend@debugfs-reader
+igt@drv_suspend@fence-restore-tiled2untiled
+igt@drv_suspend@fence-restore-untiled
+igt@gem_bad_length
+igt@gem_bad_reloc@negative-reloc-blt
+igt@gem_bad_reloc@negative-reloc-bltcopy
+igt@gem_bad_reloc@negative-reloc-bsd
+igt@gem_bad_reloc@negative-reloc-bsd1
+igt@gem_bad_reloc@negative-reloc-bsd2
+igt@gem_bad_reloc@negative-reloc-default
+igt@gem_bad_reloc@negative-reloc-lut-blt
+igt@gem_bad_reloc@negative-reloc-lut-bsd
+igt@gem_bad_reloc@negative-reloc-lut-bsd1
+igt@gem_bad_reloc@negative-reloc-lut-bsd2
+igt@gem_bad_reloc@negative-reloc-lut-default
+igt@gem_bad_reloc@negative-reloc-lut-render
+igt@gem_bad_reloc@negative-reloc-lut-vebox
+igt@gem_bad_reloc@negative-reloc-render
+igt@gem_bad_reloc@negative-reloc-vebox
+igt@gem_busy@busy-blt
+igt@gem_busy@busy-bsd
+igt@gem_busy@busy-bsd1
+igt@gem_busy@busy-bsd2
+igt@gem_busy@busy-render
+igt@gem_busy@busy-vebox
+igt@gem_busy@close-race
+igt@gem_busy@extended-blt
+igt@gem_busy@extended-bsd
+igt@gem_busy@extended-bsd1
+igt@gem_busy@extended-bsd2
+igt@gem_busy@extended-parallel-blt
+igt@gem_busy@extended-parallel-bsd
+igt@gem_busy@extended-parallel-bsd1
+igt@gem_busy@extended-parallel-bsd2
+igt@gem_busy@extended-parallel-render
+igt@gem_busy@extended-parallel-vebox
+igt@gem_busy@extended-render
+igt@gem_busy@extended-semaphore-blt
+igt@gem_busy@extended-semaphore-bsd
+igt@gem_busy@extended-semaphore-bsd1
+igt@gem_busy@extended-semaphore-bsd2
+igt@gem_busy@extended-semaphore-render
+igt@gem_busy@extended-semaphore-vebox
+igt@gem_busy@extended-vebox
+igt@gem_caching@read-writes
+igt@gem_caching@reads
+igt@gem_caching@writes
+igt@gem_close_race@gem-close-race
+igt@gem_close_race@process-exit
+igt@gem_cpu_reloc@full
+igt@gem_create@create-invalid-nonaligned
+igt@gem_create@create-invalid-size
+igt@gem_create@create-valid-nonaligned
+igt@gem_create@stolen-invalid-flag
+igt@gem_cs_prefetch@blt
+igt@gem_cs_prefetch@bsd
+igt@gem_cs_prefetch@bsd1
+igt@gem_cs_prefetch@bsd2
+igt@gem_cs_prefetch@default
+igt@gem_cs_prefetch@render
+igt@gem_cs_prefetch@vebox
+igt@gem_cs_tlb@blt
+igt@gem_cs_tlb@bsd
+igt@gem_cs_tlb@bsd1
+igt@gem_cs_tlb@bsd2
+igt@gem_cs_tlb@render
+igt@gem_cs_tlb@vebox
+igt@gem_ctx_bad_destroy@double-destroy
+igt@gem_ctx_bad_destroy@invalid-ctx
+igt@gem_ctx_bad_destroy@invalid-default-ctx
+igt@gem_ctx_bad_destroy@invalid-pad
+igt@gem_ctx_bad_exec@blt
+igt@gem_ctx_bad_exec@bsd
+igt@gem_ctx_bad_exec@bsd1
+igt@gem_ctx_bad_exec@bsd2
+igt@gem_ctx_bad_exec@default
+igt@gem_ctx_bad_exec@render
+igt@gem_ctx_bad_exec@vebox

[Intel-gfx] [PATCH i-g-t 3/4] intel-ci: Build-time check for testlists

2017-03-17 Thread Petri Latvala
Test at check and distcheck that testlist files only contain tests
that are still present.

Signed-off-by: Petri Latvala 
---
 configure.ac  |  1 +
 tests/Makefile.am |  2 ++
 tests/intel-ci/.gitignore |  1 +
 tests/intel-ci/Makefile.am| 42 +
 tests/intel-ci/check_testlists.sh | 65 +++
 tests/intel-ci/checked_lists.txt  |  1 +
 6 files changed, 112 insertions(+)
 create mode 100644 tests/intel-ci/.gitignore
 create mode 100644 tests/intel-ci/Makefile.am
 create mode 100755 tests/intel-ci/check_testlists.sh
 create mode 100644 tests/intel-ci/checked_lists.txt

diff --git a/configure.ac b/configure.ac
index 12b0ab0..9aa6068 100644
--- a/configure.ac
+++ b/configure.ac
@@ -341,6 +341,7 @@ AC_CONFIG_FILES([
 man/Makefile
 scripts/Makefile
 tests/Makefile
+tests/intel-ci/Makefile
 tools/Makefile
 tools/null_state_gen/Makefile
 tools/registers/Makefile
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 2080b3f..001106f 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -1,5 +1,7 @@
 include Makefile.sources
 
+SUBDIRS = . intel-ci
+
 if HAVE_LIBDRM_NOUVEAU
 TESTS_progs_M += $(NOUVEAU_TESTS_M)
 endif
diff --git a/tests/intel-ci/.gitignore b/tests/intel-ci/.gitignore
new file mode 100644
index 000..1a8f133
--- /dev/null
+++ b/tests/intel-ci/.gitignore
@@ -0,0 +1 @@
+all-tests.testlist
diff --git a/tests/intel-ci/Makefile.am b/tests/intel-ci/Makefile.am
new file mode 100644
index 000..de92b24
--- /dev/null
+++ b/tests/intel-ci/Makefile.am
@@ -0,0 +1,42 @@
+if BUILD_TESTS
+
+TESTLIST = $(top_builddir)/tests/test-list.txt
+
+ALL_TESTS = all-tests.testlist
+CHECKED_TESTLISTS = checked_lists.txt
+
+check_DATA = $(ALL_TESTS)
+$(ALL_TESTS): $(TESTLIST)
+   echo "# This file is automatically generated at build-time." > $@
+   echo "# It contains a list of all available (sub)tests, " >> $@
+   echo "# for checking other lists against it." >> $@
+   echo >> $@
+   for test in `cat $(TESTLIST)`; do \
+   if [ "$$test" = "TESTLIST" -o "$$test" = "END" ]; then \
+   continue; \
+   fi; \
+   if [ -x $(top_builddir)/tests/$$test ]; then \
+   testprog=$(top_builddir)/tests/$$test; \
+   else \
+   testprog=$(top_srcdir)/tests/$$test; \
+   fi; \
+   progbase=`basename $$testprog | tr '[:upper:]' '[:lower:]'`; \
+   if ./$$testprog --list-subtests > /dev/null ; then \
+   for subtest in `./$$testprog --list-subtests`; do \
+   subname=`echo $$subtest | tr '[:upper:]' 
'[:lower:]'`; \
+   echo "igt@$$progbase@$$subname" >> $@; \
+   done; \
+   else \
+   echo "igt@$$progbase" >> $@; \
+   fi; \
+   done
+
+CLEANFILES = $(ALL_TESTS)
+
+check_SCRIPTS = check_testlists.sh
+
+EXTRA_DIST = $(CHECKED_TESTLISTS) $(shell cat $(CHECKED_TESTLISTS)) 
$(check_SCRIPTS)
+
+TESTS = $(check_SCRIPTS)
+
+endif
diff --git a/tests/intel-ci/check_testlists.sh 
b/tests/intel-ci/check_testlists.sh
new file mode 100755
index 000..648364d
--- /dev/null
+++ b/tests/intel-ci/check_testlists.sh
@@ -0,0 +1,65 @@
+#!/bin/sh
+#
+# Copyright © 2017 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+# IN THE SOFTWARE.
+
+#
+# Check that testlist files don't have tests that are not available
+#
+
+if [ -z "$top_builddir" ]; then
+   top_builddir="$(dirname $0)"
+fi
+
+# allow to run this script from top directory
+TESTLISTS=`cat $top_builddir/checked_lists.txt`
+if [ $? -ne 0 ]; then
+   # distcheck requires this hack
+   TESTLISTS=$(cat 

[Intel-gfx] [PATCH i-g-t 2/4] tests/Makefile.am: Only ignore generated gitignore in gitignore

2017-03-17 Thread Petri Latvala
When generating the .gitignore file, use /.gitignore instead of
.gitignore to not have it apply to subdirectories.

Signed-off-by: Petri Latvala 
---
 tests/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index 8930c24..2080b3f 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -44,7 +44,7 @@ dist_pkgdata_DATA = \
 
 all-local: .gitignore
 .gitignore: Makefile.sources
-   @echo "$(pkglibexec_PROGRAMS) $(HANG) test-list.txt test-list-full.txt 
.gitignore" | sed 's/\s\+/\n/g' | sort > $@
+   @echo "$(pkglibexec_PROGRAMS) $(HANG) test-list.txt test-list-full.txt 
/.gitignore" | sed 's/\s\+/\n/g' | sort > $@
 
 pkgdata_DATA = test-list.txt test-list-full.txt
 
-- 
2.9.3

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


[Intel-gfx] [PATCH i-g-t 0/4] Testlist changes

2017-03-17 Thread Petri Latvala
This series introduces a build-time checker for testlists, the test
list for extended testing, and as an added bonus, introduces the
ability to comment test lists.

Petri Latvala (4):
  intel-ci: Add comments on test order to fast-feedback.testlist
  tests/Makefile.am: Only ignore generated gitignore in gitignore
  intel-ci: Build-time check for testlists
  intel-ci: Add extended.testlist for wider testing

 configure.ac  |1 +
 tests/Makefile.am |4 +-
 tests/intel-ci/.gitignore |1 +
 tests/intel-ci/Makefile.am|   42 +
 tests/intel-ci/README |6 +
 tests/intel-ci/check_testlists.sh |   65 ++
 tests/intel-ci/checked_lists.txt  |2 +
 tests/intel-ci/extended.testlist  | 1919 +
 tests/intel-ci/fast-feedback.testlist |7 +
 9 files changed, 2046 insertions(+), 1 deletion(-)
 create mode 100644 tests/intel-ci/.gitignore
 create mode 100644 tests/intel-ci/Makefile.am
 create mode 100755 tests/intel-ci/check_testlists.sh
 create mode 100644 tests/intel-ci/checked_lists.txt
 create mode 100644 tests/intel-ci/extended.testlist

-- 
2.9.3

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


[Intel-gfx] [PATCH i-g-t 1/4] intel-ci: Add comments on test order to fast-feedback.testlist

2017-03-17 Thread Petri Latvala
Document the test ordering choices in fast-feedback.testlist.

For comments in testlists, piglit commit

 commit 0c535186d624071098c10003fdafe8f475ed9ae7
 Author: Petri Latvala 
 Date:   Wed Feb 1 12:57:45 2017 +0200

framework/programs/run.py: Allow comments in test-list files.

is required.

Signed-off-by: Petri Latvala 
---
 tests/intel-ci/fast-feedback.testlist | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tests/intel-ci/fast-feedback.testlist 
b/tests/intel-ci/fast-feedback.testlist
index 5ffa2ce..ce7a41f 100644
--- a/tests/intel-ci/fast-feedback.testlist
+++ b/tests/intel-ci/fast-feedback.testlist
@@ -1,3 +1,5 @@
+# Keep alphabetically sorted by default
+
 igt@core_auth@basic-auth
 igt@core_prop_blob@basic
 igt@drv_getparams_basic@basic-eu-total
@@ -270,6 +272,11 @@ igt@vgem_basic@dmabuf-mmap
 igt@vgem_basic@mmap
 igt@vgem_basic@second-client
 igt@vgem_basic@sysfs
+
+# All tests that do module unloading and reloading are executed last.
+# They will sometimes reveal issues of earlier tests leaving the
+# driver in a broken state that is not otherwise noticed in that test.
+
 igt@vgem_basic@unload
 igt@drv_module_reload@basic-reload
 igt@drv_module_reload@basic-no-display
-- 
2.9.3

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


Re: [Intel-gfx] [PATCH 12/15] drm/i915: Remove superfluous i915_add_request_no_flush() helper

2017-03-17 Thread Chris Wilson
On Fri, Mar 17, 2017 at 01:17:17PM +0200, Joonas Lahtinen wrote:
> On to, 2017-03-16 at 13:20 +, Chris Wilson wrote:
> > The only time we need to emit a flush inside request emission is after
> > an execbuffer, for which we can use the full __i915_add_request(). All
> > other instances want the simpler i915_add_request() without flushing, so
> > remove the useless helper.
> > 
> > Signed-off-by: Chris Wilson 
> 
> Reviewed-by: Joonas Lahtinen 

Extracted and pushed to reduce the noise, thanks.
-Chris

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


Re: [Intel-gfx] [PATCH] drm/i915: Squelch WARN for VLV_COUNTER_CONTROL

2017-03-17 Thread Mika Kuoppala
Chris Wilson  writes:

> Before rc6 is initialised (after driver load or resume), the value inside
> VLV_COUNTER_CONTROL is undefined so we cannot make an assertion that is
> in HIGH_RANGE mode.
>
> Fixes: 6b7f6aa75e38 ("drm/i915: Use coarse grained residency counter with 
> byt")
> Testcase: igt/drv_suspend/debugfs-reader
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> Cc: Mika Kuoppala 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 19 +--
>  1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index d55bf882d1aa..aece0ff88a5d 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -8354,22 +8354,24 @@ void intel_pm_setup(struct drm_i915_private *dev_priv)
>  static u64 vlv_residency_raw(struct drm_i915_private *dev_priv,
>const i915_reg_t reg)
>  {
> - u32 lower, upper, tmp, saved_ctl;
> + u32 lower, upper, tmp;
>  
>   /* The register accessed do not need forcewake. We borrow
>* uncore lock to prevent concurrent access to range reg.
>*/
>   spin_lock_irq(_priv->uncore.lock);
> - saved_ctl = I915_READ_FW(VLV_COUNTER_CONTROL);
> -
> - if (WARN_ON(!(saved_ctl & VLV_COUNT_RANGE_HIGH)))
> - I915_WRITE_FW(VLV_COUNTER_CONTROL,
> -   _MASKED_BIT_ENABLE(VLV_COUNT_RANGE_HIGH));
>  
>   /* vlv and chv residency counters are 40 bits in width.
>* With a control bit, we can choose between upper or lower
>* 32bit window into this counter.
> +  *
> +  * Although we always use the counter in high-range mode elsewhere,
> +  * userspace may attempt to read the value before rc6 is initialised,
> +  * before we have set the default VLV_COUNTER_CONTROL value. So always
> +  * set the high bit to be safe.
>*/
> + I915_WRITE_FW(VLV_COUNTER_CONTROL,
> +   _MASKED_BIT_ENABLE(VLV_COUNT_RANGE_HIGH));
>   upper = I915_READ_FW(reg);
>   do {
>   tmp = upper;
> @@ -8383,6 +8385,11 @@ static u64 vlv_residency_raw(struct drm_i915_private 
> *dev_priv,
>   upper = I915_READ_FW(reg);
>   } while (upper != tmp);
>  
> + /* Everywhere else we always use VLV_COUNTER_CONTROL with the
> +  * VLV_COUNT_RANGE_HIGH bit set - so it is safe to leave it set
> +  * now.
> +  */
> +
>   spin_unlock_irq(_priv->uncore.lock);
>  
>   return lower | (u64)upper << 8;
> -- 
> 2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: Squelch WARN for VLV_COUNTER_CONTROL

2017-03-17 Thread Chris Wilson
Before rc6 is initialised (after driver load or resume), the value inside
VLV_COUNTER_CONTROL is undefined so we cannot make an assertion that is
in HIGH_RANGE mode.

Fixes: 6b7f6aa75e38 ("drm/i915: Use coarse grained residency counter with byt")
Testcase: igt/drv_suspend/debugfs-reader
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_pm.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d55bf882d1aa..aece0ff88a5d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -8354,22 +8354,24 @@ void intel_pm_setup(struct drm_i915_private *dev_priv)
 static u64 vlv_residency_raw(struct drm_i915_private *dev_priv,
 const i915_reg_t reg)
 {
-   u32 lower, upper, tmp, saved_ctl;
+   u32 lower, upper, tmp;
 
/* The register accessed do not need forcewake. We borrow
 * uncore lock to prevent concurrent access to range reg.
 */
spin_lock_irq(_priv->uncore.lock);
-   saved_ctl = I915_READ_FW(VLV_COUNTER_CONTROL);
-
-   if (WARN_ON(!(saved_ctl & VLV_COUNT_RANGE_HIGH)))
-   I915_WRITE_FW(VLV_COUNTER_CONTROL,
- _MASKED_BIT_ENABLE(VLV_COUNT_RANGE_HIGH));
 
/* vlv and chv residency counters are 40 bits in width.
 * With a control bit, we can choose between upper or lower
 * 32bit window into this counter.
+*
+* Although we always use the counter in high-range mode elsewhere,
+* userspace may attempt to read the value before rc6 is initialised,
+* before we have set the default VLV_COUNTER_CONTROL value. So always
+* set the high bit to be safe.
 */
+   I915_WRITE_FW(VLV_COUNTER_CONTROL,
+ _MASKED_BIT_ENABLE(VLV_COUNT_RANGE_HIGH));
upper = I915_READ_FW(reg);
do {
tmp = upper;
@@ -8383,6 +8385,11 @@ static u64 vlv_residency_raw(struct drm_i915_private 
*dev_priv,
upper = I915_READ_FW(reg);
} while (upper != tmp);
 
+   /* Everywhere else we always use VLV_COUNTER_CONTROL with the
+* VLV_COUNT_RANGE_HIGH bit set - so it is safe to leave it set
+* now.
+*/
+
spin_unlock_irq(_priv->uncore.lock);
 
return lower | (u64)upper << 8;
-- 
2.11.0

___
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: Remove superfluous i915_add_request_no_flush() helper

2017-03-17 Thread Patchwork
== Series Details ==

Series: drm/i915: Remove superfluous i915_add_request_no_flush() helper
URL   : https://patchwork.freedesktop.org/series/21442/
State : success

== Summary ==

Series 21442v1 drm/i915: Remove superfluous i915_add_request_no_flush() helper
https://patchwork.freedesktop.org/api/1.0/series/21442/revisions/1/mbox/

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

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 463s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 578s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 537s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 560s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 502s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 498s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 438s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 436s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 439s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 518s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 494s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 484s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 475s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 605s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 487s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 528s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 552s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time: 412s

5fef332e008b4531d1d3dfd6ff16308a56fc26ce drm-tip: 2017y-03m-17d-11h-21m-37s UTC 
integration manifest
0e96779 drm/i915: Remove superfluous i915_add_request_no_flush() helper

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4215/
___
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: Skip execlists_dequeue() early if the list is empty (rev2)

2017-03-17 Thread Patchwork
== Series Details ==

Series: drm/i915: Skip execlists_dequeue() early if the list is empty (rev2)
URL   : https://patchwork.freedesktop.org/series/21382/
State : success

== Summary ==

Series 21382v2 drm/i915: Skip execlists_dequeue() early if the list is empty
https://patchwork.freedesktop.org/api/1.0/series/21382/revisions/2/mbox/

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

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 456s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 572s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 540s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 537s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 506s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 506s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 439s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 433s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 435s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 516s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 486s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 487s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 481s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 599s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 478s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 526s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 554s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time: 410s

5fef332e008b4531d1d3dfd6ff16308a56fc26ce drm-tip: 2017y-03m-17d-11h-21m-37s UTC 
integration manifest
42708cc drm/i915: Skip execlists_dequeue() early if the list is empty

== Logs ==

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


[Intel-gfx] [PATCH v3] drm/i915: Skip execlists_dequeue() early if the list is empty

2017-03-17 Thread Chris Wilson
Do an early read of the execlists' queue before we take the spinlock and
start checking. This is safe as the first writer to the execlists queue
will cause the tasklet to be run again after a memory barrier.

v2: Keep guc in sync with execlists queue changes
v3: Explain the mb between the tasklet running on one cpu and the
execlist_first update and schedule from a second cpu.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Cc: Michał Winiarski 
Reviewed-by: Tvrtko Ursulin 
Reviewed-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 12 
 drivers/gpu/drm/i915/intel_lrc.c   | 12 
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index a3636b31ebc3..832ac9e45801 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -577,6 +577,18 @@ static bool i915_guc_dequeue(struct intel_engine_cs 
*engine)
struct rb_node *rb;
bool submit = false;
 
+   /* After execlist_first is updated, the tasklet will be rescheduled.
+*
+* If we are currently running (inside the tasklet) and a third
+* party queues a request and so updates engine->execlist_first under
+* the spinlock (which we have elided), it will atomically set the
+* TASKLET_SCHED flag causing the us to be re-executed and pick up
+* the change in state (the update to TASKLET_SCHED incurs a memory
+* barrier making this cross-cpu checking safe).
+*/
+   if (!READ_ONCE(engine->execlist_first))
+   return false;
+
spin_lock_irqsave(>timeline->lock, flags);
rb = engine->execlist_first;
while (rb) {
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index becde55b02a3..77168e673e0a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -403,6 +403,18 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
struct rb_node *rb;
bool submit = false;
 
+   /* After execlist_first is updated, the tasklet will be rescheduled.
+*
+* If we are currently running (inside the tasklet) and a third
+* party queues a request and so updates engine->execlist_first under
+* the spinlock (which we have elided), it will atomically set the
+* TASKLET_SCHED flag causing the us to be re-executed and pick up
+* the change in state (the update to TASKLET_SCHED incurs a memory
+* barrier making this cross-cpu checking safe).
+*/
+   if (!READ_ONCE(engine->execlist_first))
+   return;
+
last = port->request;
if (last)
/* WaIdleLiteRestore:bdw,skl
-- 
2.11.0

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


Re: [Intel-gfx] [CI] drm/i915: Skip execlists_dequeue() early if the list is empty

2017-03-17 Thread Michal Wajdeczko
On Fri, Mar 17, 2017 at 11:27:22AM +, Chris Wilson wrote:
> Do an early read of the execlists' queue before we take the spinlock and
> start checking. This is safe as the first writer to the execlists queue
> will cause the tasklet to be run again after a memory barrier.
> 
> v2: Keep guc in sync with execlists queue changes
> 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Joonas Lahtinen 
> Cc: Michał Winiarski 
> Reviewed-by: Tvrtko Ursulin 
> Reviewed-by: Michał Winiarski 
> ---
>  drivers/gpu/drm/i915/i915_guc_submission.c | 4 
>  drivers/gpu/drm/i915/intel_lrc.c   | 4 
>  2 files changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index a3636b31ebc3..78718a8e70c3 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -577,6 +577,10 @@ static bool i915_guc_dequeue(struct intel_engine_cs 
> *engine)
>   struct rb_node *rb;
>   bool submit = false;
>  
> + /* After execlist_first is updated, a new tasklet must be scheduled */

Hmm, I think this comment is litlle misleading when placed right to the "if" 
that do early return.
Either extend it with the info from the commit message, or move down.

-Michal

> + if (!READ_ONCE(engine->execlist_first))
> + return false;
> +
>   spin_lock_irqsave(>timeline->lock, flags);
>   rb = engine->execlist_first;
>   while (rb) {
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index becde55b02a3..7adc588d1a19 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -403,6 +403,10 @@ static void execlists_dequeue(struct intel_engine_cs 
> *engine)
>   struct rb_node *rb;
>   bool submit = false;
>  
> + /* After execlist_first is updated, a new tasklet must be scheduled */
> + if (!READ_ONCE(engine->execlist_first))
> + return;
> +
>   last = port->request;
>   if (last)
>   /* WaIdleLiteRestore:bdw,skl
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [CI] drm/i915: Remove superfluous i915_add_request_no_flush() helper

2017-03-17 Thread Chris Wilson
The only time we need to emit a flush inside request emission is after
an execbuffer, for which we can use the full __i915_add_request(). All
other instances want the simpler i915_add_request() without flushing, so
remove the useless helper.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/gvt/scheduler.c| 2 +-
 drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
 drivers/gpu/drm/i915/i915_gem_request.h | 2 --
 drivers/gpu/drm/i915/intel_display.c| 4 ++--
 drivers/gpu/drm/i915/intel_overlay.c| 8 
 drivers/gpu/drm/i915/intel_pm.c | 2 +-
 6 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 48e508865ff5..811a84bdbafb 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -224,7 +224,7 @@ static int dispatch_workload(struct intel_vgpu_workload 
*workload)
workload->status = ret;
 
if (!IS_ERR_OR_NULL(rq))
-   i915_add_request_no_flush(rq);
+   i915_add_request(rq);
mutex_unlock(_priv->drm.struct_mutex);
return ret;
 }
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 000508502cf9..486051ed681d 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -933,7 +933,7 @@ int i915_gem_switch_to_kernel_context(struct 
drm_i915_private *dev_priv)
}
 
ret = i915_switch_context(req);
-   i915_add_request_no_flush(req);
+   i915_add_request(req);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index 0cef887b0de4..a211c53c813f 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -267,8 +267,6 @@ int i915_gem_request_await_dma_fence(struct 
drm_i915_gem_request *req,
 
 void __i915_add_request(struct drm_i915_gem_request *req, bool flush_caches);
 #define i915_add_request(req) \
-   __i915_add_request(req, true)
-#define i915_add_request_no_flush(req) \
__i915_add_request(req, false)
 
 void __i915_gem_request_submit(struct drm_i915_gem_request *request);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5959c9b6dc97..010e5ddb198a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10668,7 +10668,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
intel_mark_page_flip_active(intel_crtc, work);
 
work->flip_queued_req = i915_gem_request_get(request);
-   i915_add_request_no_flush(request);
+   i915_add_request(request);
}
 
i915_gem_object_wait_priority(obj, 0, I915_PRIORITY_DISPLAY);
@@ -10684,7 +10684,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
return 0;
 
 cleanup_request:
-   i915_add_request_no_flush(request);
+   i915_add_request(request);
 cleanup_unpin:
to_intel_plane_state(primary->state)->vma = work->old_vma;
intel_unpin_fb_vma(vma);
diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index 5ef9f5bfb92c..2e0c56ed22bb 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -278,7 +278,7 @@ static int intel_overlay_on(struct intel_overlay *overlay)
 
cs = intel_ring_begin(req, 4);
if (IS_ERR(cs)) {
-   i915_add_request_no_flush(req);
+   i915_add_request(req);
return PTR_ERR(cs);
}
 
@@ -343,7 +343,7 @@ static int intel_overlay_continue(struct intel_overlay 
*overlay,
 
cs = intel_ring_begin(req, 2);
if (IS_ERR(cs)) {
-   i915_add_request_no_flush(req);
+   i915_add_request(req);
return PTR_ERR(cs);
}
 
@@ -419,7 +419,7 @@ static int intel_overlay_off(struct intel_overlay *overlay)
 
cs = intel_ring_begin(req, 6);
if (IS_ERR(cs)) {
-   i915_add_request_no_flush(req);
+   i915_add_request(req);
return PTR_ERR(cs);
}
 
@@ -477,7 +477,7 @@ static int intel_overlay_release_old_vid(struct 
intel_overlay *overlay)
 
cs = intel_ring_begin(req, 2);
if (IS_ERR(cs)) {
-   i915_add_request_no_flush(req);
+   i915_add_request(req);
return PTR_ERR(cs);
}
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 934a8c00073a..d55bf882d1aa 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7086,7 +7086,7 @@ static void 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/15] drm/i915: Copy user requested buffers into the error state (rev2)

2017-03-17 Thread Patchwork
== Series Details ==

Series: series starting with [01/15] drm/i915: Copy user requested buffers into 
the error state (rev2)
URL   : https://patchwork.freedesktop.org/series/21377/
State : success

== Summary ==

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

Test gem_exec_fence:
Subgroup await-hang-default:
pass   -> INCOMPLETE (fi-ilk-650) fdo#100144
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 486s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 580s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 546s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 568s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 501s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 496s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 435s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 436s
fi-ilk-650   total:48   pass:27   dwarn:0   dfail:0   fail:0   skip:20  
time: 0s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 506s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 490s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 498s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 492s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 617s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 506s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 536s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 548s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time: 420s

03d01320f28dfbae10d844cfedef8e72f58b55f5 drm-tip: 2017y-03m-17d-09h-54m-24s UTC 
integration manifest
1a47c4b drm/i915/scheduler: Support user-defined priorities
c6d9bf0 drm/i915: Async GPU relocation processing
ffbde09 drm/i915: Allow execbuffer to use the first object as the batch
7bbe353 drm/i915: Remove superfluous i915_add_request_no_flush() helper
5f274c0 drm/i915: Wait upon userptr get-user-pages within execbuffer
325e1c9 drm/i915: First try the previous execbuffer location
87c839b drm/i915: Eliminate lots of iterations over the execobjects array
280004c drm/i915: Pass vma to relocate entry
0a98fab drm/i915: Store a direct lookup from object handle to vma
6d59ab9 drm/i915: Stop using obj->obj_exec_link outside of execbuf
2cadbd9 drm/i915: Split vma exec_link/evict_link
c079fc3 drm/i915: Use vma->exec_entry as our double-entry placeholder
75d739f drm/i915: Amalgamate execbuffer parameter structures
4284f1b drm/i915: Retire an active batch pool object rather than allocate new
a67a616 drm/i915: Copy user requested buffers into the error state

== Logs ==

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


[Intel-gfx] [CI] drm/i915: Skip execlists_dequeue() early if the list is empty

2017-03-17 Thread Chris Wilson
Do an early read of the execlists' queue before we take the spinlock and
start checking. This is safe as the first writer to the execlists queue
will cause the tasklet to be run again after a memory barrier.

v2: Keep guc in sync with execlists queue changes

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Cc: Michał Winiarski 
Reviewed-by: Tvrtko Ursulin 
Reviewed-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 4 
 drivers/gpu/drm/i915/intel_lrc.c   | 4 
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index a3636b31ebc3..78718a8e70c3 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -577,6 +577,10 @@ static bool i915_guc_dequeue(struct intel_engine_cs 
*engine)
struct rb_node *rb;
bool submit = false;
 
+   /* After execlist_first is updated, a new tasklet must be scheduled */
+   if (!READ_ONCE(engine->execlist_first))
+   return false;
+
spin_lock_irqsave(>timeline->lock, flags);
rb = engine->execlist_first;
while (rb) {
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index becde55b02a3..7adc588d1a19 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -403,6 +403,10 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
struct rb_node *rb;
bool submit = false;
 
+   /* After execlist_first is updated, a new tasklet must be scheduled */
+   if (!READ_ONCE(engine->execlist_first))
+   return;
+
last = port->request;
if (last)
/* WaIdleLiteRestore:bdw,skl
-- 
2.11.0

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


Re: [Intel-gfx] [PATCH 1/2] drm: Mark up accesses of vblank->enabled outside of its spinlock

2017-03-17 Thread Ville Syrjälä
On Fri, Mar 17, 2017 at 10:19:51AM +, Chris Wilson wrote:
> On Fri, Mar 17, 2017 at 11:47:51AM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 16, 2017 at 11:47:48PM +, Chris Wilson wrote:
> > > @@ -360,7 +358,7 @@ static void vblank_disable_fn(unsigned long arg)
> > >   unsigned long irqflags;
> > >  
> > >   spin_lock_irqsave(>vbl_lock, irqflags);
> > > - if (atomic_read(>refcount) == 0 && vblank->enabled) {
> > > + if (atomic_read(>refcount) == 0 && READ_ONCE(vblank->enabled)) {
> > 
> > Hmm. Aren't most of these accesses inside the lock? Looks like you're
> > marking everything READ/WRITE_ONCE()?
> 
> There's like 3 different locks here. Afaict, the correct one for
> serialising vblank->enabled was dev->vblank_time_lock. Every access
> outside of that lock, I marked up as READ_ONCE.
> 
> Oh, you are using vbl_lock as the barrier? That's not as clear for
> disable:
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 53a526c7b24d..f447ed07ef95 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -325,6 +325,8 @@ static void vblank_disable_and_save(struct drm_device 
> *dev, unsigned int pipe)
> struct drm_vblank_crtc *vblank = >vblank[pipe];
> unsigned long irqflags;
>  
> +   assert_spin_locked(>vbl_lock);
> +
> /* Prevent vblank irq processing while disabling vblank irqs,
>  * so no updates of timestamps or count can happen after we've
>  * disabled. Needed to prevent races in case of delayed irq's.
> 
> 
> > > @@ -1714,6 +1717,9 @@ bool drm_handle_vblank(struct drm_device *dev, 
> > > unsigned int pipe)
> > >   if (WARN_ON(pipe >= dev->num_crtcs))
> > >   return false;
> > >  
> > > + if (!READ_ONCE(vblank->enabled))
> > > + return false;
> > 
> > This to me looks like it could theoretically cause us to
> > miss an interrupt.
> > 
> > 1. enable_irq()
> > 2. drm_update_vblank_count()
> > 3. irq fires
> > 4. drm_handle_vblank() doesn't do anything
> > 5. enabled=true
> 
> Sure. There's a danger you miss the irq anyway, and so the last action
> after enabling the interrupt should be to process any completed events -
> that's implicitly handled by enabling the interrupt in advance of adding
> the first event. In the scenario above, there should be nothing to do.

That's a slightly different scenario since you're only thinking about 
actually enabling the interrupt vs. calling drm_update_vblank_count().
That is fine as is. But with the extra 'enabled' check in the interrupt
handler you're effectively reversing that order to enable the interrupt
after drm_update_vblank_count(). Hence we can lose an interrupt now.

Of course we would eventually get another interrupt, and thanks to the
hw frame counter and whatnot we wouldn't actually lose our place entirely,
but we would see the counter jump by two frames when we actually handle
the interrupt.

-- 
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 12/15] drm/i915: Remove superfluous i915_add_request_no_flush() helper

2017-03-17 Thread Joonas Lahtinen
On to, 2017-03-16 at 13:20 +, Chris Wilson wrote:
> The only time we need to emit a flush inside request emission is after
> an execbuffer, for which we can use the full __i915_add_request(). All
> other instances want the simpler i915_add_request() without flushing, so
> remove the useless helper.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

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


Re: [Intel-gfx] [PATCH 13/15] drm/i915: Allow execbuffer to use the first object as the batch

2017-03-17 Thread Joonas Lahtinen
On to, 2017-03-16 at 13:20 +, Chris Wilson wrote:
> Currently, the last object in the execlist is the always the batch.
> However, when building the batch buffer we often know the batch object
> first and if we can use the first slot in the execlist we can emit
> relocation instructions relative to it immediately and avoid a separate
> pass to adjust the relocations to point to the last execlist slot.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

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


Re: [Intel-gfx] [PATCH 14/15] drm/i915: Async GPU relocation processing

2017-03-17 Thread Joonas Lahtinen
On to, 2017-03-16 at 13:20 +, Chris Wilson wrote:
> If the user requires patching of their batch or auxiliary buffers, we
> currently make the alterations on the cpu. If they are active on the GPU
> at the time, we wait under the struct_mutex for them to finish executing
> before we rewrite the contents. This happens if shared relocation trees
> are used between different contexts with separate address space (and the
> buffers then have different addresses in each), the 3D state will need
> to be adjusted between execution on each context. However, we don't need
> to use the CPU to do the relocation patching, as we could queue commands
> to the GPU to perform it and use fences to serialise the operation with
> the current activity and future - so the operation on the GPU appears
> just as atomic as performing it immediately. Performing the relocation
> rewrites on the GPU is not free, in terms of pure throughput, the number
> of relocations/s is about halved - but more importantly so is the time
> under the struct_mutex.
> 
> Signed-off-by: Chris Wilson 



>   /* Must be a variable in the struct to allow GCC to unroll. */
> + cache->gen = INTEL_GEN(i915);
>   cache->has_llc = HAS_LLC(i915);
> - cache->has_fence = INTEL_GEN(i915) < 4;
> - cache->use_64bit_reloc = HAS_64BIT_RELOC(i915);
> + cache->has_fence = cache->gen < 4;
> + cache->use_64bit_reloc = cache->gen >= 8;

Keep using HAS_64BIT_RELOC(i915)...

> +static u32 *reloc_gpu(struct i915_execbuffer *eb,
> +   struct i915_vma *vma,
> +   unsigned int len)
> +{
> + struct reloc_cache *cache = >reloc_cache;
> + u32 *cmd;
> +
> + if (cache->rq_size > PAGE_SIZE/sizeof(u32) - (len + 1))

There's no overflow chance here, so I'd rq_size + len + 1. 

> + reloc_gpu_flush(cache);
> +
> + if (!cache->rq) {
> + struct drm_i915_gem_object *obj;
> + struct drm_i915_gem_request *rq;
> + struct i915_vma *batch;
> + int err;
> +
> + GEM_BUG_ON(vma->obj->base.write_domain & I915_GEM_DOMAIN_CPU);

Use ==.

I just close my eyes for the reminder of this function and expect v2 to
have a proper teardown :P

Also vma / obj pair naming varies from what they usually are, so I'd
consider renaming one of them to lessen confusion.

> @@ -1012,6 +1148,67 @@ relocate_entry(struct i915_vma *vma,
>   bool wide = eb->reloc_cache.use_64bit_reloc;
>   void *vaddr;
>  
> + if (!eb->reloc_cache.vaddr &&
> + (DBG_FORCE_RELOC == FORCE_GPU_RELOC ||
> +  !reservation_object_test_signaled_rcu(obj->resv, true))) {
> + const unsigned int gen = eb->reloc_cache.gen;
> + unsigned int len;
> + u32 *batch;
> + u64 addr;
> +
> + if (wide)
> + len = offset & 7 ? 8 : 5;
> + else if (gen >= 4)
> + len = 4;
> + else if (gen >= 3)
> + len = 3;
> + else /* On gen2 MI_STORE_DWORD_IMM uses a physical address */
> + goto repeat;
> +
> + batch = reloc_gpu(eb, vma, len);
> + if (IS_ERR(batch))
> + goto repeat;
> +
> + addr = gen8_canonical_addr(vma->node.start + offset);
> + if (wide) {
> + if (offset & 7) {
> + *batch++ = MI_STORE_DWORD_IMM_GEN4;

This indent level calls for a new function. __relocate_entry_gpu

Couldn't we share some of this STORE IMM code we have around? I don't
want to crawl the specs every time :(

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: Async GPU relocation processing

2017-03-17 Thread Chris Wilson
If the user requires patching of their batch or auxiliary buffers, we
currently make the alterations on the cpu. If they are active on the GPU
at the time, we wait under the struct_mutex for them to finish executing
before we rewrite the contents. This happens if shared relocation trees
are used between different contexts with separate address space (and the
buffers then have different addresses in each), the 3D state will need
to be adjusted between execution on each context. However, we don't need
to use the CPU to do the relocation patching, as we could queue commands
to the GPU to perform it and use fences to serialise the operation with
the current activity and future - so the operation on the GPU appears
just as atomic as performing it immediately. Performing the relocation
rewrites on the GPU is not free, in terms of pure throughput, the number
of relocations/s is about halved - but more importantly so is the time
under the struct_mutex.

v2: Break out the request/batch allocation for clearer error flow.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c|   1 -
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 233 +++--
 2 files changed, 224 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 90b7c34ef550..ff4029bb6ad4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4248,7 +4248,6 @@ static void __i915_gem_free_objects(struct 
drm_i915_private *i915,
GEM_BUG_ON(i915_gem_object_is_active(obj));
list_for_each_entry_safe(vma, vn,
 >vma_list, obj_link) {
-   GEM_BUG_ON(!i915_vma_is_ggtt(vma));
GEM_BUG_ON(i915_vma_is_active(vma));
vma->flags &= ~I915_VMA_PIN_MASK;
i915_vma_close(vma);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index d39ea2ba20ff..a28d08f5b8b4 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -40,7 +40,12 @@
 #include "intel_drv.h"
 #include "intel_frontbuffer.h"
 
-#define DBG_USE_CPU_RELOC 0 /* -1 force GTT relocs; 1 force CPU relocs */
+enum {
+   FORCE_CPU_RELOC = 1,
+   FORCE_GTT_RELOC,
+   FORCE_GPU_RELOC,
+#define DBG_FORCE_RELOC 0 /* choose one of the above! */
+};
 
 #define  __EXEC_OBJECT_HAS_PIN BIT(31)
 #define  __EXEC_OBJECT_HAS_FENCE   BIT(30)
@@ -187,9 +192,14 @@ struct i915_execbuffer {
struct drm_mm_node node;
unsigned long vaddr;
unsigned int page;
-   bool use_64bit_reloc;
-   bool has_llc;
-   bool has_fence;
+   unsigned int gen;
+   bool use_64bit_reloc : 1;
+   bool has_llc : 1;
+   bool has_fence : 1;
+
+   struct drm_i915_gem_request *rq;
+   u32 *rq_cmd;
+   unsigned int rq_size;
} reloc_cache;
u64 invalid_flags;
u32 context_flags;
@@ -434,8 +444,11 @@ static inline int use_cpu_reloc(const struct reloc_cache 
*cache,
if (!i915_gem_object_has_struct_page(obj))
return false;
 
-   if (DBG_USE_CPU_RELOC)
-   return DBG_USE_CPU_RELOC > 0;
+   if (DBG_FORCE_RELOC == FORCE_CPU_RELOC)
+   return true;
+
+   if (DBG_FORCE_RELOC == FORCE_GTT_RELOC)
+   return false;
 
return (cache->has_llc ||
obj->base.write_domain == I915_GEM_DOMAIN_CPU ||
@@ -807,10 +820,13 @@ static void reloc_cache_init(struct reloc_cache *cache,
cache->page = -1;
cache->vaddr = 0;
/* Must be a variable in the struct to allow GCC to unroll. */
+   cache->gen = INTEL_GEN(i915);
cache->has_llc = HAS_LLC(i915);
-   cache->has_fence = INTEL_GEN(i915) < 4;
-   cache->use_64bit_reloc = HAS_64BIT_RELOC(i915);
+   cache->has_fence = cache->gen < 4;
+   cache->use_64bit_reloc = cache->gen >= 8;
cache->node.allocated = false;
+   cache->rq = NULL;
+   cache->rq_size = 0;
 }
 
 static inline void *unmask_page(unsigned long p)
@@ -832,10 +848,24 @@ static inline struct i915_ggtt *cache_to_ggtt(struct 
reloc_cache *cache)
return >ggtt;
 }
 
+static void reloc_gpu_flush(struct reloc_cache *cache)
+{
+   GEM_BUG_ON(cache->rq_size >= cache->rq->batch->obj->base.size / 
sizeof(u32));
+   cache->rq_cmd[cache->rq_size] = MI_BATCH_BUFFER_END;
+   i915_gem_object_unpin_map(cache->rq->batch->obj);
+   i915_gem_chipset_flush(cache->rq->i915);
+
+   __i915_add_request(cache->rq, true);
+   cache->rq = NULL;
+}
+
 static void reloc_cache_reset(struct reloc_cache *cache)
 {
void *vaddr;
 
+   if (cache->rq)
+   reloc_gpu_flush(cache);
+
if 

[Intel-gfx] ✓ Fi.CI.BAT: success for fs/pstore: Perform erase from a worker

2017-03-17 Thread Patchwork
== Series Details ==

Series: fs/pstore: Perform erase from a worker
URL   : https://patchwork.freedesktop.org/series/21438/
State : success

== Summary ==

Series 21438v1 fs/pstore: Perform erase from a worker
https://patchwork.freedesktop.org/api/1.0/series/21438/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 456s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 579s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 537s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 554s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 501s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 500s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 437s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 435s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 437s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 526s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 492s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 487s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 481s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 589s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 477s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 518s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 547s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 417s

03d01320f28dfbae10d844cfedef8e72f58b55f5 drm-tip: 2017y-03m-17d-09h-54m-24s UTC 
integration manifest
e940f6d fs/pstore: Perform erase from a worker

== Logs ==

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


  1   2   >