[Intel-gfx] ✗ Ro.CI.BAT: warning for series starting with [1/2] drm/i915/guc: prefer 'dev_priv' to 'dev' for static functions

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

Series: series starting with [1/2] drm/i915/guc: prefer 'dev_priv' to 'dev' for 
static functions
URL   : https://patchwork.freedesktop.org/series/8556/
State : warning

== Summary ==

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

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
fail   -> PASS   (ro-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
dmesg-warn -> PASS   (ro-hsw-i3-4010u)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-skl-i5-6260u)
Subgroup suspend-read-crc-pipe-a:
skip   -> DMESG-WARN (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-b:
skip   -> DMESG-WARN (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-c:
skip   -> PASS   (fi-skl-i5-6260u)

fi-bdw-i7-5557u  total:213  pass:201  dwarn:0   dfail:0   fail:0   skip:12 
fi-skl-i5-6260u  total:213  pass:202  dwarn:0   dfail:0   fail:0   skip:11 
fi-skl-i7-6700k  total:213  pass:188  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:213  pass:174  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:213  pass:197  dwarn:4   dfail:0   fail:0   skip:12 
ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:213  pass:174  dwarn:0   dfail:0   fail:2   skip:37 
ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:177  pass:120  dwarn:2   dfail:2   fail:1   skip:51 
ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl3-i5-6260u total:213  pass:201  dwarn:1   dfail:0   fail:0   skip:11 
ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38 
fi-hsw-i7-4770k failed to connect after reboot
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1162/

94fd582 drm-intel-nightly: 2016y-06m-10d-16h-42m-36s UTC integration manifest
4c20b95 drm/i915/guc: prefer 'dev_priv' to 'dev' for intra-module functions
b0b12a6 drm/i915/guc: prefer 'dev_priv' to 'dev' for static functions

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


[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915/guc: updates to GuC doorbell handling

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

Series: drm/i915/guc: updates to GuC doorbell handling
URL   : https://patchwork.freedesktop.org/series/8553/
State : success

== Summary ==

Series 8553v1 drm/i915/guc: updates to GuC doorbell handling
http://patchwork.freedesktop.org/api/1.0/series/8553/revisions/1/mbox

Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
dmesg-warn -> PASS   (ro-hsw-i3-4010u)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-skl-i5-6260u)
Subgroup suspend-read-crc-pipe-c:
skip   -> PASS   (fi-skl-i5-6260u)

fi-bdw-i7-5557u  total:213  pass:201  dwarn:0   dfail:0   fail:0   skip:12 
fi-skl-i5-6260u  total:213  pass:202  dwarn:0   dfail:0   fail:0   skip:11 
fi-skl-i7-6700k  total:213  pass:188  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:213  pass:174  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:213  pass:173  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:213  pass:150  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl3-i5-6260u total:213  pass:201  dwarn:1   dfail:0   fail:0   skip:11 
ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38 
fi-hsw-i7-4770k failed to connect after reboot
ro-bdw-i5-5250u failed to connect after reboot
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1161/

94fd582 drm-intel-nightly: 2016y-06m-10d-16h-42m-36s UTC integration manifest
fd29e26 drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission
3c41a24 drm/i915/guc: refactor doorbell management code
a691e53 drm/i915/guc: remove writes to GEN8_DRBREG registers
bcb2128 drm/i915/guc: prefer __set/clear_bit() to bitmap_set/clear()
893dfd7 drm/i915/guc: move guc_ring_doorbell() nearer to callsite
11b028f drm/i915/guc: add doorbell map to debugfs/i915_guc_info

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


[Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

2016-06-10 Thread Paulo Zanoni
Ever since I started working on FBC I was already aware that FBC can
really amplify the FIFO underrun symptoms. On systems where FIFO
underruns were harmless error messages, enabling FBC would cause the
underruns to give black screens.

We recently tried to enable FBC on Haswell and got reports of a system
that would hang after some hours of uptime, and the first bad commit
was the one that enabled FBC. We also observed that this system had
FIFO underrun error messages on its dmesg. Although we don't have any
evidence that fixing the underruns would solve the bug and make FBC
work properly on this machine, IMHO it's better if we minimize the
amount of possible problems by just giving up FBC whenever we detect
an underrun.

v2: new version, different implementation and commit message.

Cc: Stefan Richter 
Cc: Lyude 
Cc: Steven Honeyman 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h|  3 ++
 drivers/gpu/drm/i915/intel_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_fbc.c   | 53 ++
 drivers/gpu/drm/i915/intel_fifo_underrun.c |  2 ++
 4 files changed, 59 insertions(+)


Since my test machines don't produce FIFO underrun errors, I tested this by
creating a debugfs file that just calls intel_fbc_handle_fifo_underrun(). I'd
appreciate some Tested-by tags, if possible.


diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 20a676d..18b4257 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -908,6 +908,9 @@ struct intel_fbc {
bool enabled;
bool active;
 
+   bool underrun_detected;
+   struct work_struct underrun_work;
+
struct intel_fbc_state_cache {
struct {
unsigned int mode_flags;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ebe7b34..7bf97b1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1436,6 +1436,7 @@ void intel_fbc_invalidate(struct drm_i915_private 
*dev_priv,
 void intel_fbc_flush(struct drm_i915_private *dev_priv,
 unsigned int frontbuffer_bits, enum fb_op_origin origin);
 void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
+void intel_fbc_handle_fifo_underrun(struct drm_i915_private *dev_priv);
 
 /* intel_hdmi.c */
 void intel_hdmi_init(struct drm_device *dev, i915_reg_t hdmi_reg, enum port 
port);
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index d268f76..2363bff 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -755,6 +755,13 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
struct intel_fbc *fbc = _priv->fbc;
struct intel_fbc_state_cache *cache = >state_cache;
 
+   /* We don't need to use a state cache here since this information is
+* global for every CRTC. */
+   if (fbc->underrun_detected) {
+   fbc->no_fbc_reason = "underrun detected";
+   return false;
+   }
+
if (!cache->plane.visible) {
fbc->no_fbc_reason = "primary plane not visible";
return false;
@@ -1195,6 +1202,51 @@ void intel_fbc_global_disable(struct drm_i915_private 
*dev_priv)
cancel_work_sync(>work.work);
 }
 
+static void intel_fbc_underrun_work_fn(struct work_struct *work)
+{
+   struct drm_i915_private *dev_priv =
+   container_of(work, struct drm_i915_private, fbc.underrun_work);
+   struct intel_fbc *fbc = _priv->fbc;
+
+   mutex_lock(>lock);
+
+   /* Maybe we were scheduled twice. */
+   if (fbc->underrun_detected)
+   goto out;
+
+   DRM_DEBUG_KMS("Disabling FBC due to FIFO underrun.\n");
+   fbc->underrun_detected = true;
+
+   intel_fbc_deactivate(dev_priv);
+out:
+   mutex_unlock(>lock);
+}
+
+/**
+ * intel_fbc_handle_fifo_underrun - disable FBC when we get a FIFO underrun
+ * @dev_priv: i915 device instance
+ *
+ * Without FBC, most underruns are harmless and don't really cause too many
+ * problems, except for an annoying message on dmesg. With FBC, underruns can
+ * become black screens or even worse, especially when paired with bad
+ * watermarks. So in order for us to be on the safe side, completely disable 
FBC
+ * in case we ever detect a FIFO underrun on any pipe. An underrun on any pipe
+ * already suggests that watermarks may be bad, so try to be as safe as
+ * possible.
+ */
+void intel_fbc_handle_fifo_underrun(struct drm_i915_private *dev_priv)
+{
+   struct intel_fbc *fbc = _priv->fbc;
+
+   if (!fbc_supported(dev_priv))
+   return;
+
+   if (fbc->underrun_detected)
+   return;
+
+   schedule_work(>underrun_work);
+}
+
 /**
  * intel_fbc_init_pipe_state - initialize FBC's CRTC visibility tracking
  * 

[Intel-gfx] REBASED: [PATCH 1/3] drm: Add vblank prepare and unprepare hooks.

2016-06-10 Thread Dhinakaran Pandiyan
From: Rodrigo Vivi 

This will allow drivers to control specific power saving
feature and power domains when dealing with vblanks.

Vblanks code are protected by spin_locks where we can't
have anything that can sleep. While power saving features
and power domain code have mutexes to control the states.

Mutex can sleep so they cannot be used inside spin lock areas.
So the easiest way to deal with them currently is to add these
prepare hook for pre enabling vblanks
and unprepare one for post disabling them.

Let's introduce this optional prepare and unprepare
hooks so drivers can deal with cases like this and any other
case that should require sleeping codes interacting with vblanks.

Signed-off-by: Rodrigo Vivi 
---
 Rebased.

 drivers/gpu/drm/drm_irq.c | 28 +++-
 include/drm/drmP.h| 30 ++
 2 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 5a773e4..bdf01cd 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -347,6 +347,8 @@ void drm_vblank_cleanup(struct drm_device *dev)
drm_core_check_feature(dev, DRIVER_MODESET));
 
del_timer_sync(>disable_timer);
+
+   flush_work(>unprepare.work);
}
 
kfree(dev->vblank);
@@ -355,6 +357,20 @@ void drm_vblank_cleanup(struct drm_device *dev)
 }
 EXPORT_SYMBOL(drm_vblank_cleanup);
 
+static void drm_vblank_unprepare_work_fn(struct work_struct *work)
+{
+   struct drm_vblank_crtc *vblank;
+   struct drm_device *dev;
+
+   vblank = container_of(work, typeof(*vblank), unprepare.work);
+   dev = vblank->dev;
+
+   do {
+   if (dev->driver->unprepare_vblank)
+   dev->driver->unprepare_vblank(dev, vblank->pipe);
+   } while (!atomic_dec_and_test(>unprepare.counter));
+}
+
 /**
  * drm_vblank_init - initialize vblank support
  * @dev: DRM device
@@ -388,6 +404,8 @@ int drm_vblank_init(struct drm_device *dev, unsigned int 
num_crtcs)
setup_timer(>disable_timer, vblank_disable_fn,
(unsigned long)vblank);
seqlock_init(>seqlock);
+   INIT_WORK(>unprepare.work,
+ drm_vblank_unprepare_work_fn);
}
 
DRM_INFO("Supports vblank timestamp caching Rev 2 (21.10.2013).\n");
@@ -1170,6 +1188,9 @@ int drm_vblank_get(struct drm_device *dev, unsigned int 
pipe)
if (WARN_ON(pipe >= dev->num_crtcs))
return -EINVAL;
 
+   if (dev->driver->prepare_vblank)
+   dev->driver->prepare_vblank(dev, pipe);
+
spin_lock_irqsave(>vbl_lock, irqflags);
/* Going from 0->1 means we have to enable interrupts again */
if (atomic_add_return(1, >refcount) == 1) {
@@ -1182,6 +1203,9 @@ int drm_vblank_get(struct drm_device *dev, unsigned int 
pipe)
}
spin_unlock_irqrestore(>vbl_lock, irqflags);
 
+   if (ret != 0 && dev->driver->unprepare_vblank)
+   dev->driver->unprepare_vblank(dev, pipe);
+
return ret;
 }
 EXPORT_SYMBOL(drm_vblank_get);
@@ -1234,6 +1258,9 @@ void drm_vblank_put(struct drm_device *dev, unsigned int 
pipe)
mod_timer(>disable_timer,
  jiffies + ((drm_vblank_offdelay * HZ)/1000));
}
+
+   atomic_inc(>unprepare.counter);
+   schedule_work(>unprepare.work);
 }
 EXPORT_SYMBOL(drm_vblank_put);
 
@@ -1668,7 +1695,6 @@ static int drm_queue_vblank_event(struct drm_device *dev, 
unsigned int pipe,
}
 
spin_unlock_irqrestore(>event_lock, flags);
-
return 0;
 
 err_unlock:
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c5d2950..7495f56 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -443,6 +443,30 @@ struct drm_driver {
u32 (*get_vblank_counter) (struct drm_device *dev, unsigned int pipe);
 
/**
+* prepare_vblank - Optional prepare vblank hook.
+* @dev: DRM device
+* @pipe: counter to fetch
+*
+* Drivers that need to handle any kind of mutex or any other sleeping
+* code in combination with vblanks need to implement this hook
+* that will be called before drm_vblank_get spin_lock gets.
+*/
+   void (*prepare_vblank) (struct drm_device *dev, unsigned int pipe);
+
+   /**
+* unprepare_vblank - Optional unprepare vblank hook.
+* @dev: DRM device
+* @pipe: counter to fetch
+*
+* Drivers that need to handle any kind of mutex or any other sleeping
+* code in combination with vblanks need to implement this hook
+* that will be called in a work queue to be executed after spin lock
+* areas of drm_vblank_put.
+*/
+   void (*unprepare_vblank) (struct drm_device *dev, unsigned int pipe);
+
+
+   /**
 * 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: prefer 'dev_priv' to 'dev' for static functions

2016-06-10 Thread Chris Wilson
On Fri, Jun 10, 2016 at 06:29:25PM +0100, Dave Gordon wrote:
> -static struct drm_i915_gem_object *gem_allocate_guc_obj(struct drm_device 
> *dev,
> - u32 size)
> +static struct drm_i915_gem_object *
> +gem_allocate_guc_obj(struct drm_i915_private *dev_priv, u32 size)

Whilst you are looking at these, this is not GEM allocating an object
for the guc, but guc allocating a GEM object for itself.
-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] ✗ Ro.CI.BAT: failure for series starting with drm/i915/guc: suppress GuC-related message on non-GuC platforms (rev2)

2016-06-10 Thread Dave Gordon

On 10/06/16 17:59, Patchwork wrote:

== Series Details ==

Series: series starting with drm/i915/guc: suppress GuC-related message on 
non-GuC platforms (rev2)
URL   : https://patchwork.freedesktop.org/series/8380/
State : failure

== Summary ==

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

Test gem_exec_flush:
 Subgroup basic-batch-kernel-default-cmd:
 pass   -> FAIL   (ro-byt-n2820)


Bug 95372 - [BAT BYT] Sporadic failure from 
igt/gem_exec_flush@basic-batch-kernel-default-cmd



Test kms_pipe_crc_basic:
 Subgroup nonblocking-crc-pipe-c-frame-sequence:
 fail   -> PASS   (ro-ivb-i7-3770)
 Subgroup suspend-read-crc-pipe-a:
 dmesg-warn -> SKIP   (ro-bdw-i7-5557U)
 Subgroup suspend-read-crc-pipe-b:
 dmesg-warn -> SKIP   (ro-bdw-i7-5557U)
 Subgroup suspend-read-crc-pipe-c:
 skip   -> DMESG-WARN (ro-bdw-i5-5250u)


Looks like https://bugs.freedesktop.org/show_bug.cgi?id=94605#c17
as do the two that have gone from WARN to SKIP. Connector problem?


ro-bdw-i5-5250u  total:213  pass:197  dwarn:4   dfail:0   fail:0   skip:12
ro-bdw-i7-5557U  total:213  pass:197  dwarn:1   dfail:0   fail:0   skip:15
ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28
ro-bsw-n3050 total:213  pass:171  dwarn:1   dfail:0   fail:2   skip:39
ro-byt-n2820 total:213  pass:173  dwarn:0   dfail:0   fail:3   skip:37
ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23
ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23
ro-ilk-i7-620lm  total:213  pass:150  dwarn:0   dfail:0   fail:1   skip:62
ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57
ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32
ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28
ro-skl3-i5-6260u total:213  pass:201  dwarn:1   dfail:0   fail:0   skip:11
ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38

Results at /archive/results/CI_IGT_test/RO_Patchwork_1160/

5de1a00 drm-intel-nightly: 2016y-06m-10d-15h-26m-55s UTC integration manifest
8f7efa4 drm/i915/guc: suppress GuC-related message on non-GuC platforms



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


[Intel-gfx] [PATCH] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen

2016-06-10 Thread Dave Gordon
More Coccinellery ...

Wherever we find "INTEL_INFO(dev)->gen", and have a suitable
"dev_priv" in scope, replace it with "INTEL_GEN(dev_priv)".
At this time, we've found 189 instances, and each replacement
saves one memory cycle at runtime and two bytes of codespace
(~360 bytes total text size reduction).

@dev_priv_param@
function FUNC;
idexpression struct drm_device *DEV;
identifier DEV_PRIV;
@@
FUNC(..., struct drm_i915_private *DEV_PRIV, ...)
{
<...
-   INTEL_INFO(DEV)->gen
+   INTEL_GEN(DEV_PRIV)
...>
}

@dev_priv_local@
idexpression struct drm_device *DEV;
identifier DEV_PRIV;
expression E;
@@
{
...
(
struct drm_i915_private *DEV_PRIV;
|
struct drm_i915_private *DEV_PRIV = E;
)
<...
-   INTEL_INFO(DEV)->gen
+   INTEL_GEN(DEV_PRIV)
...>
}

Plus manual deletion of one now-unused local "dev".

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  52 +++---
 drivers/gpu/drm/i915/i915_dma.c|  16 ++---
 drivers/gpu/drm/i915/i915_drv.c|   2 +-
 drivers/gpu/drm/i915/i915_gem.c|   4 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   8 +--
 drivers/gpu/drm/i915/i915_gem_fence.c  |   8 +--
 drivers/gpu/drm/i915/i915_gem_gtt.c|  12 ++--
 drivers/gpu/drm/i915/i915_gem_stolen.c |   6 +-
 drivers/gpu/drm/i915/i915_gpu_error.c  |  14 ++--
 drivers/gpu/drm/i915/i915_irq.c|  12 ++--
 drivers/gpu/drm/i915/i915_suspend.c|  20 +++---
 drivers/gpu/drm/i915/intel_color.c |   2 +-
 drivers/gpu/drm/i915/intel_crt.c   |   6 +-
 drivers/gpu/drm/i915/intel_ddi.c   |   4 +-
 drivers/gpu/drm/i915/intel_display.c   | 111 ++---
 drivers/gpu/drm/i915/intel_dp.c|  20 +++---
 drivers/gpu/drm/i915/intel_dpll_mgr.c  |   2 +-
 drivers/gpu/drm/i915/intel_lvds.c  |   4 +-
 drivers/gpu/drm/i915/intel_pm.c|  18 ++---
 drivers/gpu/drm/i915/intel_psr.c   |   4 +-
 drivers/gpu/drm/i915/intel_sdvo.c  |   8 +--
 drivers/gpu/drm/i915/intel_tv.c|   2 +-
 22 files changed, 167 insertions(+), 168 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e4f2c55..6a106d5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -672,7 +672,7 @@ static int i915_gem_pageflip_info(struct seq_file *m, void 
*data)
   intel_crtc_get_vblank_counter(crtc));
seq_printf(m, "%d prepares\n", 
atomic_read(>pending));
 
-   if (INTEL_INFO(dev)->gen >= 4)
+   if (INTEL_GEN(dev_priv) >= 4)
addr = 
I915_HI_DISPBASE(I915_READ(DSPSURF(crtc->plane)));
else
addr = I915_READ(DSPADDR(crtc->plane));
@@ -869,7 +869,7 @@ static int i915_interrupt_info(struct seq_file *m, void 
*data)
   I915_READ(GEN8_PCU_IIR));
seq_printf(m, "PCU interrupt enable:\t%08x\n",
   I915_READ(GEN8_PCU_IER));
-   } else if (INTEL_INFO(dev)->gen >= 8) {
+   } else if (INTEL_GEN(dev_priv) >= 8) {
seq_printf(m, "Master Interrupt Control:\t%08x\n",
   I915_READ(GEN8_MASTER_IRQ));
 
@@ -995,7 +995,7 @@ static int i915_interrupt_info(struct seq_file *m, void 
*data)
   I915_READ(GTIMR));
}
for_each_engine(engine, dev_priv) {
-   if (INTEL_INFO(dev)->gen >= 6) {
+   if (INTEL_GEN(dev_priv) >= 6) {
seq_printf(m,
   "Graphics Interrupt mask (%s):   %08x\n",
   engine->name, I915_READ_IMR(engine));
@@ -1232,7 +1232,7 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
   "efficient (RPe) frequency: %d MHz\n",
   intel_gpu_freq(dev_priv, 
dev_priv->rps.efficient_freq));
mutex_unlock(_priv->rps.hw_lock);
-   } else if (INTEL_INFO(dev)->gen >= 6) {
+   } else if (INTEL_GEN(dev_priv) >= 6) {
u32 rp_state_limits;
u32 gt_perf_status;
u32 rp_state_cap;
@@ -1745,7 +1745,7 @@ static int i915_fbc_fc_get(void *data, u64 *val)
struct drm_device *dev = data;
struct drm_i915_private *dev_priv = dev->dev_private;
 
-   if (INTEL_INFO(dev)->gen < 7 || !HAS_FBC(dev))
+   if (INTEL_GEN(dev_priv) < 7 || !HAS_FBC(dev))
return -ENODEV;
 
*val = dev_priv->fbc.false_color;
@@ -1759,7 +1759,7 @@ static int i915_fbc_fc_set(void *data, u64 val)
struct drm_i915_private *dev_priv = dev->dev_private;
u32 reg;
 
-   if (INTEL_INFO(dev)->gen < 7 || !HAS_FBC(dev))
+   if (INTEL_GEN(dev_priv) < 7 || !HAS_FBC(dev))

[Intel-gfx] [PATCH 2/2] drm/i915/guc: prefer 'dev_priv' to 'dev' for intra-module functions

2016-06-10 Thread Dave Gordon
There are four non-static functions in i915_guc_submission.c that take a
'dev' parameter. All are called only from GuC loader code, and can be
easily converted to accept 'dev_priv' instead.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 14 +-
 drivers/gpu/drm/i915/intel_guc.h   |  8 
 drivers/gpu/drm/i915/intel_guc_loader.c| 12 ++--
 3 files changed, 15 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 1bd0fac..65e67f0 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -906,9 +906,8 @@ static void guc_create_ads(struct intel_guc *guc)
  * Set up the memory resources to be shared with the GuC.  At this point,
  * we require just one object that can be mapped through the GGTT.
  */
-int i915_guc_submission_init(struct drm_device *dev)
+int i915_guc_submission_init(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = dev->dev_private;
const size_t ctxsize = sizeof(struct guc_context_desc);
const size_t poolsize = GUC_MAX_GPU_CONTEXTS * ctxsize;
const size_t gemsize = round_up(poolsize, PAGE_SIZE);
@@ -916,7 +915,7 @@ int i915_guc_submission_init(struct drm_device *dev)
 
/* Wipe bitmap & delete client in case of reinitialisation */
bitmap_clear(guc->doorbell_bitmap, 0, GUC_MAX_DOORBELLS);
-   i915_guc_submission_disable(dev);
+   i915_guc_submission_disable(dev_priv);
 
if (!i915.enable_guc_submission)
return 0; /* not enabled  */
@@ -935,9 +934,8 @@ int i915_guc_submission_init(struct drm_device *dev)
return 0;
 }
 
-int i915_guc_submission_enable(struct drm_device *dev)
+int i915_guc_submission_enable(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc *guc = _priv->guc;
struct i915_guc_client *client;
 
@@ -957,18 +955,16 @@ int i915_guc_submission_enable(struct drm_device *dev)
return 0;
 }
 
-void i915_guc_submission_disable(struct drm_device *dev)
+void i915_guc_submission_disable(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc *guc = _priv->guc;
 
guc_client_free(dev_priv, guc->execbuf_client);
guc->execbuf_client = NULL;
 }
 
-void i915_guc_submission_fini(struct drm_device *dev)
+void i915_guc_submission_fini(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc *guc = _priv->guc;
 
gem_release_guc_obj(dev_priv->guc.ads_obj);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 41601c7..4df80cc 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -156,11 +156,11 @@ extern int intel_guc_suspend(struct drm_device *dev);
 extern int intel_guc_resume(struct drm_device *dev);
 
 /* i915_guc_submission.c */
-int i915_guc_submission_init(struct drm_device *dev);
-int i915_guc_submission_enable(struct drm_device *dev);
+int i915_guc_submission_init(struct drm_i915_private *dev_priv);
+int i915_guc_submission_enable(struct drm_i915_private *dev_priv);
 int i915_guc_wq_check_space(struct drm_i915_gem_request *rq);
 int i915_guc_submit(struct drm_i915_gem_request *rq);
-void i915_guc_submission_disable(struct drm_device *dev);
-void i915_guc_submission_fini(struct drm_device *dev);
+void i915_guc_submission_disable(struct drm_i915_private *dev_priv);
+void i915_guc_submission_fini(struct drm_i915_private *dev_priv);
 
 #endif
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 41f7c7d..d29137f 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -453,7 +453,7 @@ int intel_guc_setup(struct drm_device *dev)
intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status),
intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
 
-   err = i915_guc_submission_init(dev);
+   err = i915_guc_submission_init(dev_priv);
if (err)
goto fail;
 
@@ -492,7 +492,7 @@ int intel_guc_setup(struct drm_device *dev)
intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
 
if (i915.enable_guc_submission) {
-   err = i915_guc_submission_enable(dev);
+   err = i915_guc_submission_enable(dev_priv);
if (err)
goto fail;
direct_interrupts_to_guc(dev_priv);
@@ -505,8 +505,8 @@ int intel_guc_setup(struct drm_device *dev)
guc_fw->guc_fw_load_status = GUC_FIRMWARE_FAIL;
 
direct_interrupts_to_host(dev_priv);
-   i915_guc_submission_disable(dev);
-   i915_guc_submission_fini(dev);
+   

[Intel-gfx] [PATCH 1/2] drm/i915/guc: prefer 'dev_priv' to 'dev' for static functions

2016-06-10 Thread Dave Gordon
Convert all static functions in i915_guc_submission.c that currently
take a 'dev' pointer to take 'dev_priv' instead (there are three,
guc_client_alloc(), guc_client_free(), and gem_allocate_guc_obj().

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 39 +++---
 1 file changed, 19 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 2db1182..1bd0fac 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -591,7 +591,7 @@ int i915_guc_submit(struct drm_i915_gem_request *rq)
 
 /**
  * gem_allocate_guc_obj() - Allocate gem object for GuC usage
- * @dev:   drm device
+ * @dev_priv:  driver private data structure
  * @size:  size of object
  *
  * This is a wrapper to create a gem obj. In order to use it inside GuC, the
@@ -600,13 +600,12 @@ int i915_guc_submit(struct drm_i915_gem_request *rq)
  *
  * Return: A drm_i915_gem_object if successful, otherwise NULL.
  */
-static struct drm_i915_gem_object *gem_allocate_guc_obj(struct drm_device *dev,
-   u32 size)
+static struct drm_i915_gem_object *
+gem_allocate_guc_obj(struct drm_i915_private *dev_priv, u32 size)
 {
-   struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_object *obj;
 
-   obj = i915_gem_object_create(dev, size);
+   obj = i915_gem_object_create(dev_priv->dev, size);
if (IS_ERR(obj))
return NULL;
 
@@ -642,10 +641,10 @@ static void gem_release_guc_obj(struct 
drm_i915_gem_object *obj)
drm_gem_object_unreference(>base);
 }
 
-static void guc_client_free(struct drm_device *dev,
-   struct i915_guc_client *client)
+static void
+guc_client_free(struct drm_i915_private *dev_priv,
+   struct i915_guc_client *client)
 {
-   struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc *guc = _priv->guc;
 
if (!client)
@@ -688,7 +687,7 @@ static void guc_client_free(struct drm_device *dev,
 
 /**
  * guc_client_alloc() - Allocate an i915_guc_client
- * @dev:   drm device
+ * @dev_priv:  driver private data structure
  * @priority:  four levels priority _CRITICAL, _HIGH, _NORMAL and _LOW
  * The kernel client to replace ExecList submission is created with
  * NORMAL priority. Priority of a client for scheduler can be HIGH,
@@ -698,12 +697,12 @@ static void guc_client_free(struct drm_device *dev,
  *
  * Return: An i915_guc_client object if success, else NULL.
  */
-static struct i915_guc_client *guc_client_alloc(struct drm_device *dev,
-   uint32_t priority,
-   struct i915_gem_context *ctx)
+static struct i915_guc_client *
+guc_client_alloc(struct drm_i915_private *dev_priv,
+uint32_t priority,
+struct i915_gem_context *ctx)
 {
struct i915_guc_client *client;
-   struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc *guc = _priv->guc;
struct drm_i915_gem_object *obj;
 
@@ -724,7 +723,7 @@ static struct i915_guc_client *guc_client_alloc(struct 
drm_device *dev,
}
 
/* The first page is doorbell/proc_desc. Two followed pages are wq. */
-   obj = gem_allocate_guc_obj(dev, GUC_DB_SIZE + GUC_WQ_SIZE);
+   obj = gem_allocate_guc_obj(dev_priv, GUC_DB_SIZE + GUC_WQ_SIZE);
if (!obj)
goto err;
 
@@ -768,7 +767,7 @@ static struct i915_guc_client *guc_client_alloc(struct 
drm_device *dev,
 err:
DRM_ERROR("FAILED to create priority %u GuC client!\n", priority);
 
-   guc_client_free(dev, client);
+   guc_client_free(dev_priv, client);
return NULL;
 }
 
@@ -793,7 +792,7 @@ static void guc_create_log(struct intel_guc *guc)
 
obj = guc->log_obj;
if (!obj) {
-   obj = gem_allocate_guc_obj(dev_priv->dev, size);
+   obj = gem_allocate_guc_obj(dev_priv, size);
if (!obj) {
/* logging will be off */
i915.guc_log_level = -1;
@@ -853,7 +852,7 @@ static void guc_create_ads(struct intel_guc *guc)
 
obj = guc->ads_obj;
if (!obj) {
-   obj = gem_allocate_guc_obj(dev_priv->dev, PAGE_ALIGN(size));
+   obj = gem_allocate_guc_obj(dev_priv, PAGE_ALIGN(size));
if (!obj)
return;
 
@@ -925,7 +924,7 @@ int i915_guc_submission_init(struct drm_device *dev)
if (guc->ctx_pool_obj)
return 0; /* already allocated */
 
-   guc->ctx_pool_obj = gem_allocate_guc_obj(dev_priv->dev, gemsize);
+   guc->ctx_pool_obj = gem_allocate_guc_obj(dev_priv, gemsize);
if (!guc->ctx_pool_obj)
return 

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with drm/i915/guc: suppress GuC-related message on non-GuC platforms (rev2)

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

Series: series starting with drm/i915/guc: suppress GuC-related message on 
non-GuC platforms (rev2)
URL   : https://patchwork.freedesktop.org/series/8380/
State : failure

== Summary ==

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

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
pass   -> FAIL   (ro-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-c-frame-sequence:
fail   -> PASS   (ro-ivb-i7-3770)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> SKIP   (ro-bdw-i7-5557U)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> SKIP   (ro-bdw-i7-5557U)
Subgroup suspend-read-crc-pipe-c:
skip   -> DMESG-WARN (ro-bdw-i5-5250u)

ro-bdw-i5-5250u  total:213  pass:197  dwarn:4   dfail:0   fail:0   skip:12 
ro-bdw-i7-5557U  total:213  pass:197  dwarn:1   dfail:0   fail:0   skip:15 
ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-bsw-n3050 total:213  pass:171  dwarn:1   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:213  pass:173  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:213  pass:150  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl3-i5-6260u total:213  pass:201  dwarn:1   dfail:0   fail:0   skip:11 
ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38 

Results at /archive/results/CI_IGT_test/RO_Patchwork_1160/

5de1a00 drm-intel-nightly: 2016y-06m-10d-15h-26m-55s UTC integration manifest
8f7efa4 drm/i915/guc: suppress GuC-related message on non-GuC platforms

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


[Intel-gfx] [PATCH v2 6/6] drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission

2016-06-10 Thread Dave Gordon
During a hibernate/resume cycle, the whole system is reset, including
the GuC and the doorbell hardware. Then the system is booted up, drivers
are loaded, etc -- the GuC firmware may be loaded and set running at
this point. But then, the booted kernel is replaced by the hibernated
image, and this resumed kernel will also try to reload the GuC firmware
(which will fail). To recover, we reset the GuC and try again (which
should work). But this GuC reset doesn't also reset the doorbell
hardware, so it can be left in a state inconsistent with that assumed
by the driver and/or the newly-loaded GuC firmware.

It would be better if the GuC reset also cleared all doorbell state,
but that's not how the hardware currently works; also, the driver cannot
directly reprogram the doorbell hardware (only the GuC can do that).

So this patch cycles through all doorbells, assigning and releasing each
in turn, so that all the doorbell hardware is left in a consistent
state, no matter how it was programmed by the previously-running kernel
and/or GuC firmware.

v2: don't use kmap_atomic() now that client page 0 is kept mapped.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 44 +-
 1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 1833bfd..120d2e8 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -694,6 +694,48 @@ static void guc_client_free(struct drm_device *dev,
kfree(client);
 }
 
+/*
+ * Borrow the first client to set up & tear down every doorbell
+ * in turn, to ensure that all doorbell h/w is (re)initialised.
+ */
+static void guc_init_doorbell_hw(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   struct i915_guc_client *client = guc->execbuf_client;
+   uint16_t db_id, i;
+   int err;
+
+   db_id = client->doorbell_id;
+
+   for (i = 0; i < GUC_MAX_DOORBELLS; ++i) {
+   i915_reg_t drbreg = GEN8_DRBREGL(i);
+   u32 value = I915_READ(drbreg);
+
+   err = guc_update_doorbell_id(guc, client, i);
+
+   /* Report update failure or unexpectedly active doorbell */
+   if (err || (i != db_id && (value & GUC_DOORBELL_ENABLED)))
+   DRM_DEBUG_DRIVER("Doorbell %d (reg 0x%x) was 0x%x, err 
%d\n",
+ i, drbreg.reg, value, err);
+   }
+
+   /* Restore to original value */
+   err = guc_update_doorbell_id(guc, client, db_id);
+   if (err)
+   DRM_ERROR("Failed to restore doorbell to %d, err %d\n",
+   db_id, err);
+
+   for (i = 0; i < GUC_MAX_DOORBELLS; ++i) {
+   i915_reg_t drbreg = GEN8_DRBREGL(i);
+   u32 value = I915_READ(drbreg);
+
+   if (i != db_id && (value & GUC_DOORBELL_ENABLED))
+   DRM_DEBUG_DRIVER("Doorbell %d (reg 0x%x) finally 
0x%x\n",
+ i, drbreg.reg, value);
+
+   }
+}
+
 /**
  * guc_client_alloc() - Allocate an i915_guc_client
  * @dev:   drm device
@@ -959,8 +1001,8 @@ int i915_guc_submission_enable(struct drm_device *dev)
}
 
guc->execbuf_client = client;
-
host2guc_sample_forcewake(guc, client);
+   guc_init_doorbell_hw(guc);
 
return 0;
 }
-- 
1.9.1

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


[Intel-gfx] [PATCH v2 5/6] drm/i915/guc: refactor doorbell management code

2016-06-10 Thread Dave Gordon
This patch refactors the driver's handling and tracking of doorbells, in
preparation for a later one which will resolve a suspend-resume issue.

There are three resources to be managed:
1. Cachelines: a single line within the client-object's page 0
   is snooped by doorbell hardware for writes from the host.
2. Doorbell registers: each defines one cacheline to be snooped.
3. Bitmap: tracks which doorbell registers are in use.

The doorbell setup/teardown protocol starts with:
1. Pick a cacheline: select_doorbell_cacheline()
2. Find an available doorbell register: assign_doorbell()
(These values are passed to the GuC via the shared context
descriptor; this part of the sequence remains unchanged).

3. Update the bitmap to reflect registers-in-use
4. Prepare the cacheline for use by setting its status to ENABLED
5. Ask the GuC to program the doorbell to snoop the cacheline

and of course teardown is very similar:
6. Set the cacheline to DISABLED
7. Ask the GuC to reprogram the doorbell to stop snooping
8. Record that the doorbell is not in use.

Operations 6-8 (guc_disable_doorbell(), host2guc_release_doorbell(), and
release_doorbell()) were called in sequence from guc_client_free(), but
are now moved into the teardown phase of the common function.

Steps 4-5 (guc_init_doorbell() and host2guc_allocate_doorbell()) were
similarly done as sequential steps in guc_client_alloc(), but since it
turns out that we don't need to be able to do them separately they're
now collected into the setup phase of the common function.

The only new code (and new capability) is the block tagged
/* Update the GuC's idea of the doorbell ID */
i.e. we can now *change* the doorbell register used by an existing
client, whereas previously it was set once for the entire lifetime
of the client. We will use this new feature in the next patch.

v2: Trivial independent fixes pushed ahead as separate patches.
MUCH longer commit message :) [Tvrtko Ursulin]

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 94 +-
 1 file changed, 53 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 45b33f8..1833bfd 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -174,31 +174,59 @@ static int host2guc_sample_forcewake(struct intel_guc 
*guc,
  * client object which contains the page being used for the doorbell
  */
 
-static void guc_init_doorbell(struct intel_guc *guc,
- struct i915_guc_client *client)
+static int guc_update_doorbell_id(struct intel_guc *guc,
+ struct i915_guc_client *client,
+ u16 new_id)
 {
+   struct sg_table *sg = guc->ctx_pool_obj->pages;
+   void *doorbell_bitmap = guc->doorbell_bitmap;
struct guc_doorbell_info *doorbell;
+   struct guc_context_desc desc;
+   size_t len;
 
doorbell = client->client_base + client->doorbell_offset;
 
-   doorbell->db_status = GUC_DOORBELL_ENABLED;
+   if (client->doorbell_id != GUC_INVALID_DOORBELL_ID &&
+   test_bit(client->doorbell_id, doorbell_bitmap)) {
+   /* Deactivate the old doorbell */
+   doorbell->db_status = GUC_DOORBELL_DISABLED;
+   (void)host2guc_release_doorbell(guc, client);
+   __clear_bit(client->doorbell_id, doorbell_bitmap);
+   }
+
+   /* Update the GuC's idea of the doorbell ID */
+   len = sg_pcopy_to_buffer(sg->sgl, sg->nents, , sizeof(desc),
+sizeof(desc) * client->ctx_index);
+   if (len != sizeof(desc))
+   return -EFAULT;
+   desc.db_id = new_id;
+   len = sg_pcopy_from_buffer(sg->sgl, sg->nents, , sizeof(desc),
+sizeof(desc) * client->ctx_index);
+   if (len != sizeof(desc))
+   return -EFAULT;
+
+   client->doorbell_id = new_id;
+   if (new_id == GUC_INVALID_DOORBELL_ID)
+   return 0;
+
+   /* Activate the new doorbell */
+   __set_bit(new_id, doorbell_bitmap);
doorbell->cookie = 0;
+   doorbell->db_status = GUC_DOORBELL_ENABLED;
+   return host2guc_allocate_doorbell(guc, client);
+}
+
+static int guc_init_doorbell(struct intel_guc *guc,
+ struct i915_guc_client *client,
+ uint16_t db_id)
+{
+   return guc_update_doorbell_id(guc, client, db_id);
 }
 
 static void guc_disable_doorbell(struct intel_guc *guc,
 struct i915_guc_client *client)
 {
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
-   struct guc_doorbell_info *doorbell;
-   i915_reg_t drbreg = GEN8_DRBREGL(client->doorbell_id);
-   int value;
-
-   doorbell = client->client_base + client->doorbell_offset;
-
-   

[Intel-gfx] [PATCH v2 4/6] drm/i915/guc: remove writes to GEN8_DRBREG registers

2016-06-10 Thread Dave Gordon
These registers are not actually writable by the CPU; only the GuC can
actually program them. So let's not do writes that have no effect.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index e198599..45b33f8 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -197,14 +197,9 @@ static void guc_disable_doorbell(struct intel_guc *guc,
 
doorbell->db_status = GUC_DOORBELL_DISABLED;
 
-   I915_WRITE(drbreg, I915_READ(drbreg) & ~GEN8_DRB_VALID);
-
value = I915_READ(drbreg);
WARN_ON((value & GEN8_DRB_VALID) != 0);
 
-   I915_WRITE(GEN8_DRBREGU(client->doorbell_id), 0);
-   I915_WRITE(drbreg, 0);
-
/* XXX: wait for any interrupts */
/* XXX: wait for workqueue to drain */
 }
-- 
1.9.1

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


[Intel-gfx] [PATCH v2 3/6] drm/i915/guc: prefer __set/clear_bit() to bitmap_set/clear()

2016-06-10 Thread Dave Gordon
Bitmap operators are overkill when touching only one bit.

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

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 7510841..e198599 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -251,7 +251,7 @@ static uint16_t assign_doorbell(struct intel_guc *guc, 
uint32_t priority)
if (id == end)
id = GUC_INVALID_DOORBELL_ID;
else
-   bitmap_set(guc->doorbell_bitmap, id, 1);
+   __set_bit(id, guc->doorbell_bitmap);
 
DRM_DEBUG_DRIVER("assigned %s priority doorbell id 0x%x\n",
hi_pri ? "high" : "normal", id);
@@ -261,7 +261,7 @@ static uint16_t assign_doorbell(struct intel_guc *guc, 
uint32_t priority)
 
 static void release_doorbell(struct intel_guc *guc, uint16_t id)
 {
-   bitmap_clear(guc->doorbell_bitmap, id, 1);
+   __clear_bit(id, guc->doorbell_bitmap);
 }
 
 /*
-- 
1.9.1

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


[Intel-gfx] [PATCH v2 2/6] drm/i915/guc: move guc_ring_doorbell() nearer to callsite

2016-06-10 Thread Dave Gordon
Just code movement, no actual change to the function. This is in
preparation for the next patch, which will reorganise all the other
doorbell code, but doesn't change this function. So let's shuffle it
down near its caller rather than leaving it mixed in with the setup
code. Unlike the doorbell management code, this function is somewhat
time-critical, so putting it near its caller may even yield a tiny
performance improvement.

Signed-off-by: Dave Gordon 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 110 ++---
 1 file changed, 55 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 2db1182..7510841 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -185,61 +185,6 @@ static void guc_init_doorbell(struct intel_guc *guc,
doorbell->cookie = 0;
 }
 
-static int guc_ring_doorbell(struct i915_guc_client *gc)
-{
-   struct guc_process_desc *desc;
-   union guc_doorbell_qw db_cmp, db_exc, db_ret;
-   union guc_doorbell_qw *db;
-   int attempt = 2, ret = -EAGAIN;
-
-   desc = gc->client_base + gc->proc_desc_offset;
-
-   /* Update the tail so it is visible to GuC */
-   desc->tail = gc->wq_tail;
-
-   /* current cookie */
-   db_cmp.db_status = GUC_DOORBELL_ENABLED;
-   db_cmp.cookie = gc->cookie;
-
-   /* cookie to be updated */
-   db_exc.db_status = GUC_DOORBELL_ENABLED;
-   db_exc.cookie = gc->cookie + 1;
-   if (db_exc.cookie == 0)
-   db_exc.cookie = 1;
-
-   /* pointer of current doorbell cacheline */
-   db = gc->client_base + gc->doorbell_offset;
-
-   while (attempt--) {
-   /* lets ring the doorbell */
-   db_ret.value_qw = atomic64_cmpxchg((atomic64_t *)db,
-   db_cmp.value_qw, db_exc.value_qw);
-
-   /* if the exchange was successfully executed */
-   if (db_ret.value_qw == db_cmp.value_qw) {
-   /* db was successfully rung */
-   gc->cookie = db_exc.cookie;
-   ret = 0;
-   break;
-   }
-
-   /* XXX: doorbell was lost and need to acquire it again */
-   if (db_ret.db_status == GUC_DOORBELL_DISABLED)
-   break;
-
-   DRM_ERROR("Cookie mismatch. Expected %d, returned %d\n",
- db_cmp.cookie, db_ret.cookie);
-
-   /* update the cookie to newly read cookie from GuC */
-   db_cmp.cookie = db_ret.cookie;
-   db_exc.cookie = db_ret.cookie + 1;
-   if (db_exc.cookie == 0)
-   db_exc.cookie = 1;
-   }
-
-   return ret;
-}
-
 static void guc_disable_doorbell(struct intel_guc *guc,
 struct i915_guc_client *client)
 {
@@ -543,6 +488,61 @@ static void guc_add_workqueue_item(struct i915_guc_client 
*gc,
kunmap_atomic(base);
 }
 
+static int guc_ring_doorbell(struct i915_guc_client *gc)
+{
+   struct guc_process_desc *desc;
+   union guc_doorbell_qw db_cmp, db_exc, db_ret;
+   union guc_doorbell_qw *db;
+   int attempt = 2, ret = -EAGAIN;
+
+   desc = gc->client_base + gc->proc_desc_offset;
+
+   /* Update the tail so it is visible to GuC */
+   desc->tail = gc->wq_tail;
+
+   /* current cookie */
+   db_cmp.db_status = GUC_DOORBELL_ENABLED;
+   db_cmp.cookie = gc->cookie;
+
+   /* cookie to be updated */
+   db_exc.db_status = GUC_DOORBELL_ENABLED;
+   db_exc.cookie = gc->cookie + 1;
+   if (db_exc.cookie == 0)
+   db_exc.cookie = 1;
+
+   /* pointer of current doorbell cacheline */
+   db = gc->client_base + gc->doorbell_offset;
+
+   while (attempt--) {
+   /* lets ring the doorbell */
+   db_ret.value_qw = atomic64_cmpxchg((atomic64_t *)db,
+   db_cmp.value_qw, db_exc.value_qw);
+
+   /* if the exchange was successfully executed */
+   if (db_ret.value_qw == db_cmp.value_qw) {
+   /* db was successfully rung */
+   gc->cookie = db_exc.cookie;
+   ret = 0;
+   break;
+   }
+
+   /* XXX: doorbell was lost and need to acquire it again */
+   if (db_ret.db_status == GUC_DOORBELL_DISABLED)
+   break;
+
+   DRM_ERROR("Cookie mismatch. Expected %d, returned %d\n",
+ db_cmp.cookie, db_ret.cookie);
+
+   /* update the cookie to newly read cookie from GuC */
+   db_cmp.cookie = db_ret.cookie;
+   db_exc.cookie = db_ret.cookie + 1;
+   if (db_exc.cookie == 0)
+

[Intel-gfx] [PATCH v2 0/6] drm/i915/guc: updates to GuC doorbell handling

2016-06-10 Thread Dave Gordon
Various GuC (doorbell) related patches, some trivial. The bulk of the
changes are in [patch 5/6], but it's mostly just reorganisation of
existing code. The new functionality is implemented in a single new
function in [patch 6/6].

Background, from v1 of this patchset:

The Linux hibernate/resume sequence involves booting one kernel, and
then replacing(!) its in-memory image with that of the previously
hibernated system.  This can lead to inconsistencies in the state of
the hardware, in particular where a driver does not or cannot reset
it to a well-defined initial state during resume.

For i915, the issue is that the doorbell hardware is not reset when
the GuC is reset; also, the driver *cannot* directly reprogram it:
only the GuC can do that. So this set of patches first reorganises
the doorbell handling, and then (in the last patch of the set)
ensures that the doorbell hardware is fully (re-)initialised when
the GuC is (re-)loaded.

Dave Gordon (6):
  drm/i915/guc: add doorbell map to debugfs/i915_guc_info
  drm/i915/guc: move guc_ring_doorbell() nearer to callsite
  drm/i915/guc: prefer __set/clear_bit() to bitmap_set/clear()
  drm/i915/guc: remove writes to GEN8_DRBREG registers
  drm/i915/guc: refactor doorbell management code
  drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission

 drivers/gpu/drm/i915/i915_debugfs.c|   4 +
 drivers/gpu/drm/i915/i915_guc_submission.c | 249 +
 2 files changed, 153 insertions(+), 100 deletions(-)

-- 
1.9.1

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


[Intel-gfx] [PATCH v2 1/6] drm/i915/guc: add doorbell map to debugfs/i915_guc_info

2016-06-10 Thread Dave Gordon
To properly verify the driver->doorbell->GuC functionality, validation
needs to know how the driver has assigned the doorbell cache lines and
registers, so make them visible through debugfs.

v2: use kernel bitmap-printing format (%pb) rather than %x.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e4f2c55..6efc8b1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2574,6 +2574,10 @@ static int i915_guc_info(struct seq_file *m, void *data)
 
mutex_unlock(>struct_mutex);
 
+   seq_printf(m, "Doorbell map:\n");
+   seq_printf(m, "\t%*pb\n", GUC_MAX_DOORBELLS, guc.doorbell_bitmap);
+   seq_printf(m, "Doorbell next cacheline: 0x%x\n\n", guc.db_cacheline);
+
seq_printf(m, "GuC total action count: %llu\n", guc.action_count);
seq_printf(m, "GuC action failure count: %u\n", guc.action_fail);
seq_printf(m, "GuC last action command: 0x%x\n", guc.action_cmd);
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH v2 06/20] drm: i915: Rely on the default ->best_encoder() behavior where appropriate

2016-06-10 Thread Daniel Vetter
On Fri, Jun 10, 2016 at 05:24:12PM +0200, Daniel Vetter wrote:
> On Tue, Jun 07, 2016 at 01:48:01PM +0200, Boris Brezillon wrote:
> > For all outputs except dp_mst, we have a 1:1 relationship between
> > connectors and encoders and the driver is relying on the atomic helpers:
> > we can drop the custom ->best_encoder() implementation and let the core
> > call drm_atomic_helper_best_encoder() for us.
> > 
> > Signed-off-by: Boris Brezillon 
> 
> You can also drop the best_encoder from intel_dp_mst, we only need the
> atomic_best_encoder. The best_encoder there was needed to help out the
> fbdev emulation. Care to respin?

Boris pointed out on irc that this won't work for the fbdev stuff since
that has a WARN_ON if theres more than 1 possible encoder. Applied this
one here instead.

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


Re: [Intel-gfx] [PATCH v5 10/10] drm/i915: Add DP branch device info on debugfs

2016-06-10 Thread kbuild test robot
Hi,

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.7-rc2 next-20160609]
[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/Mika-Kahola/drm-i915-DP-branch-devices/20160610-203119
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-randconfig-s1-06102203 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/i915_debugfs.c: In function 'intel_dp_info':
>> drivers/gpu/drm/i915/i915_debugfs.c:2954:10: error: unused variable 'cap' 
>> [-Werror=unused-variable]
 uint8_t cap[4];
 ^~~
>> drivers/gpu/drm/i915/i915_debugfs.c:2953:6: error: unused variable 
>> 'cap_size' [-Werror=unused-variable]
 int cap_size;
 ^~~~
   cc1: all warnings being treated as errors

vim +/cap +2954 drivers/gpu/drm/i915/i915_debugfs.c

  2947  bool is_branch_device;
  2948  bool detailed_cap_info = 
intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
  2949  DP_DETAILED_CAP_INFO_AVAILABLE;
  2950  int type;
  2951  int clk;
  2952  int bpc;
> 2953  int cap_size;
> 2954  uint8_t cap[4];
  2955  char id[6];
  2956  
  2957  seq_printf(m, "\tDPCD rev: %x\n", intel_dp->dpcd[DP_DPCD_REV]);

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


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


Re: [Intel-gfx] [PATCH v6 11/34] drm/i915: Added deferred work handler for scheduler

2016-06-10 Thread Tvrtko Ursulin


Hi,

More random comments.

On 20/04/16 18:13, john.c.harri...@intel.com wrote:

From: John Harrison 

The scheduler needs to do interrupt triggered work that is too complex
to do in the interrupt handler. Thus it requires a deferred work
handler to process such tasks asynchronously.

v2: Updated to reduce mutex lock usage. The lock is now only held for
the minimum time within the remove function rather than for the whole
of the worker thread's operation.

v5: Removed objectionable white space and added some documentation.
[Joonas Lahtinen]

v6: Updated to newer nightly (lots of ring -> engine renaming).

Added an i915_scheduler_destroy() function instead of doing explicit
clean up of scheduler internals from i915_driver_unload().
[review feedback from Joonas Lahtinen]

For: VIZ-1587
Signed-off-by: John Harrison 
Cc: Joonas Lahtinen 
Reviewed-by: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_drv.h   | 10 ++
  drivers/gpu/drm/i915/i915_gem.c   |  2 ++
  drivers/gpu/drm/i915/i915_scheduler.c | 28 ++--
  drivers/gpu/drm/i915/i915_scheduler.h |  1 +
  4 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7b62e2c..ed9d829 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1296,6 +1296,16 @@ struct i915_gem_mm {
struct delayed_work retire_work;

/**
+* New scheme is to get an interrupt after every work packet
+* in order to allow the low latency scheduling of pending
+* packets. The idea behind adding new packets to a pending
+* queue rather than directly into the hardware ring buffer
+* is to allow high priority packets to over take low priority
+* ones.
+*/
+   struct work_struct scheduler_work;
+
+   /**
 * When we detect an idle GPU, we want to turn on
 * powersaving features. So once we see that there
 * are no more requests outstanding and no more
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 14dc641..50c45f3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5546,6 +5546,8 @@ i915_gem_load_init(struct drm_device *dev)
  i915_gem_retire_work_handler);
INIT_DELAYED_WORK(_priv->mm.idle_work,
  i915_gem_idle_work_handler);
+   INIT_WORK(_priv->mm.scheduler_work,
+   i915_scheduler_work_handler);
init_waitqueue_head(_priv->gpu_error.reset_queue);

dev_priv->relative_constants_mode = I915_EXEC_CONSTANTS_REL_GENERAL;
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c 
b/drivers/gpu/drm/i915/i915_scheduler.c
index 6dd9838..2dc5597 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -95,6 +95,8 @@ void i915_scheduler_destroy(struct drm_i915_private *dev_priv)
if (!scheduler)
return;

+   cancel_work_sync(_priv->mm.scheduler_work);
+
for (e = 0; e < I915_NUM_ENGINES; e++)
WARN(!list_empty(>node_queue[e]), "Destroying with list 
entries on engine %d!", e);

@@ -738,7 +740,9 @@ static int i915_scheduler_remove_dependent(struct 
i915_scheduler *scheduler,
   */
  void i915_scheduler_wakeup(struct drm_device *dev)
  {
-   /* XXX: Need to call i915_scheduler_remove() via work handler. */
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   queue_work(dev_priv->wq, _priv->mm.scheduler_work);


As I commented in person, sharing this wq with the rest of the driver 
could introduce scheduling latency since it is an ordered (one work item 
at a time) queue.


It would probably be good to create a dedicated wq for the scheduler, 
maybe even WQ_HIGHPRI one.



  }

  /**
@@ -820,7 +824,7 @@ static bool i915_scheduler_remove(struct i915_scheduler 
*scheduler,
return do_submit;
  }

-void i915_scheduler_process_work(struct intel_engine_cs *engine)
+static void i915_scheduler_process_work(struct intel_engine_cs *engine)
  {
struct drm_i915_private *dev_priv = to_i915(engine->dev);
struct i915_scheduler *scheduler = dev_priv->scheduler;
@@ -867,6 +871,26 @@ void i915_scheduler_process_work(struct intel_engine_cs 
*engine)
  }

  /**
+ * i915_scheduler_work_handler - scheduler's work handler callback.
+ * @work: Work structure
+ * A lot of the scheduler's work must be done asynchronously in response to
+ * an interrupt or other event. However, that work cannot be done at
+ * interrupt time or in the context of the event signaller (which might in
+ * fact be an interrupt). Thus a worker thread is required. This function
+ * will cause the thread to wake up and do its processing.
+ */
+void i915_scheduler_work_handler(struct work_struct 

Re: [Intel-gfx] [PATCH v6 06/34] drm/i915: Start of GPU scheduler

2016-06-10 Thread Tvrtko Ursulin


Hi,

Just a few random comments/questions. (not a full review!)

On 20/04/16 18:13, john.c.harri...@intel.com wrote:

From: John Harrison 

Initial creation of scheduler source files. Note that this patch
implements most of the scheduler functionality but does not hook it in
to the driver yet. It also leaves the scheduler code in 'pass through'
mode so that even when it is hooked in, it will not actually do very
much. This allows the hooks to be added one at a time in bite size
chunks and only when the scheduler is finally enabled at the end does
anything start happening.

The general theory of operation is that when batch buffers are
submitted to the driver, the execbuffer() code packages up all the
information required to execute the batch buffer at a later time. This
package is given over to the scheduler which adds it to an internal
node list. The scheduler also scans the list of objects associated
with the batch buffer and compares them against the objects already in
use by other buffers in the node list. If matches are found then the
new batch buffer node is marked as being dependent upon the matching
node. The same is done for the context object. The scheduler also
bumps up the priority of such matching nodes on the grounds that the
more dependencies a given batch buffer has the more important it is
likely to be.

The scheduler aims to have a given (tuneable) number of batch buffers
in flight on the hardware at any given time. If fewer than this are
currently executing when a new node is queued, then the node is passed
straight through to the submit function. Otherwise it is simply added
to the queue and the driver returns back to user land.

The scheduler is notified when each batch buffer completes and updates
its internal tracking accordingly. At the end of the completion
interrupt processing, if any scheduler tracked batches were processed,
the scheduler's deferred worker thread is woken up. This can do more
involved processing such as actually removing completed nodes from the
queue and freeing up the resources associated with them (internal
memory allocations, DRM object references, context reference, etc.).
The work handler also checks the in flight count and calls the
submission code if a new slot has appeared.

When the scheduler's submit code is called, it scans the queued node
list for the highest priority node that has no unmet dependencies.
Note that the dependency calculation is complex as it must take
inter-ring dependencies and potential preemptions into account. Note
also that in the future this will be extended to include external
dependencies such as the Android Native Sync file descriptors and/or
the linux dma-buff synchronisation scheme.

If a suitable node is found then it is sent to execbuff_final() for
submission to the hardware. The in flight count is then re-checked and
a new node popped from the list if appropriate. All nodes that are not
submitted have their priority bumped. This ensures that low priority
tasks do not get starved out by busy higher priority ones - everything
will eventually get its turn to run.

Note that this patch does not implement pre-emptive scheduling. Only
basic scheduling by re-ordering batch buffer submission is currently
implemented. Pre-emption of actively executing batch buffers comes in
the next patch series.

v2: Changed priority levels to +/-1023 due to feedback from Chris
Wilson.

Removed redundant index from scheduler node.

Changed time stamps to use jiffies instead of raw monotonic. This
provides lower resolution but improved compatibility with other i915
code.

Major re-write of completion tracking code due to struct fence
conversion. The scheduler no longer has it's own private IRQ handler
but just lets the existing request code handle completion events.
Instead, the scheduler now hooks into the request notify code to be
told when a request has completed.

Reduced driver mutex locking scope. Removal of scheduler nodes no
longer grabs the mutex lock.

v3: Refactor of dependency generation to make the code more readable.
Also added in read-read optimisation support - i.e., don't treat a
shared read-only buffer as being a dependency.

Allowed the killing of queued nodes rather than only flying ones.

v4: Updated the commit message to better reflect the current state of
the code. Downgraded some BUG_ONs to WARN_ONs. Used the correct array
memory allocator function (kmalloc_array instead of kmalloc).
Corrected the format of some comments. Wrapped some lines differently
to keep the style checker happy.

Fixed a WARN_ON when killing nodes. The dependency removal code checks
that nodes being destroyed do not have any oustanding dependencies
(which would imply they should not have been executed yet). In the
case of nodes being destroyed, e.g. due to context banning, then this
might well be the case - they have not been executed and do indeed
have outstanding dependencies.

Re-instated the code to disble interrupts 

[Intel-gfx] [PATCH] drm/i915/guc: suppress GuC-related message on non-GuC platforms

2016-06-10 Thread Dave Gordon
If the user doesn't override the default values of the GuC-related
kernel parameters, then on a non-GuC-based platform we shouldn't
mention that we haven't loaded the GuC firmware.

The various messages have been reordered into a least->most severe
cascade (none/INFO/INFO/ERROR) for ease of comprehension.

Signed-off-by: Dave Gordon 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_guc_loader.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 41f7c7d..05732e3 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -525,12 +525,14 @@ int intel_guc_setup(struct drm_device *dev)
ret = 0;
}
 
-   if (err == 0)
+   if (err == 0 && !HAS_GUC_UCODE(dev))
+   ;   /* Don't mention the GuC! */
+   else if (err == 0)
DRM_INFO("GuC firmware load skipped\n");
-   else if (ret == -EIO)
-   DRM_ERROR("GuC firmware load failed: %d\n", err);
-   else
+   else if (ret != -EIO)
DRM_INFO("GuC firmware load failed: %d\n", err);
+   else
+   DRM_ERROR("GuC firmware load failed: %d\n", err);
 
if (i915.enable_guc_submission) {
if (fw_path == NULL)
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: fix GuC loading/submission check

2016-06-10 Thread Dave Gordon

On 09/06/16 12:04, Tvrtko Ursulin wrote:


On 07/06/16 09:41, Tvrtko Ursulin wrote:


On 07/06/16 09:14, Dave Gordon wrote:

The last stage of the GuC loader also sanitises the GuC submission
settings, so should be called unconditionally (even on platforms
without a GuC) to ensure consistent settings; in particular, this
prevents any attempt to use GuC submission on GuCless platforms!

Also fix error path handling and clarify DRM_INFO fallback message.

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_gem.c |  8 +++-
  drivers/gpu/drm/i915/intel_guc_loader.c | 12 
  2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index 1bfc260..eae8d7a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4930,11 +4930,9 @@ int i915_gem_init_engines(struct drm_device *dev)
  intel_mocs_init_l3cc_table(dev);

  /* We can't enable contexts until all firmware is loaded */
-if (HAS_GUC(dev)) {
-ret = intel_guc_setup(dev);
-if (ret)
-goto out;
-}
+ret = intel_guc_setup(dev);
+if (ret)
+goto out;

  /*
   * Increment the next seqno by 0x100 so we have a visible break
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index f2b88c7..4e34c2e 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -425,9 +425,13 @@ int intel_guc_setup(struct drm_device *dev)
  if (!i915.enable_guc_loading) {
  err = 0;
  goto fail;
-} else if (fw_path == NULL || *fw_path == '\0') {
-if (*fw_path == '\0')


Ops. I can only assume I meant !fw_path.


-DRM_INFO("No GuC firmware known for this platform\n");
+} else if (fw_path == NULL) {
+/* Device is known to have no uCode (e.g. no GuC) */
+err = -ENXIO;
+goto fail;
+} else if (*fw_path == '\0') {
+/* Device has a GuC but we don't know what f/w to load? */
+DRM_INFO("No GuC firmware known for this platform\n");
  err = -ENODEV;
  goto fail;
  }
@@ -535,7 +539,7 @@ int intel_guc_setup(struct drm_device *dev)
  if (fw_path == NULL)
  DRM_INFO("GuC submission without firmware not
supported\n");
  if (ret == 0)
-DRM_INFO("Falling back to execlist mode\n");
+DRM_INFO("Falling back from GuC submission to execlist
mode\n");
  else
  DRM_ERROR("GuC init failed: %d\n", ret);
  }



Reviewed-by: Tvrtko Ursulin 


Bah now on BDW we get on boot:

[drm:gen8_init_common_ring] Execlists enabled for render ring
[drm:gen8_init_common_ring] Execlists enabled for blitter ring
[drm:gen8_init_common_ring] Execlists enabled for bsd ring
[drm:gen8_init_common_ring] Execlists enabled for video enhancement ring
[drm:intel_guc_setup] GuC fw status: path (null), fetch NONE, load NONE
[drm] GuC firmware load skipped
[drm] GuC submission without firmware not supported
[drm] Falling back from GuC submission to execlist mode

Which is a bit untidy. :(

Regards,
Tvrtko


You shouldn't get the second or third [drm] message, if you haven't 
overridden the default values. The default for enable_guc_submission
is (-1) which gets mapped to HAS_GUC_SCHED() which is 0 on BDW; you only 
get the extra messages if you've set it to a non-default value.


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


Re: [Intel-gfx] [PATCH v2 00/20] drm/atomic: Provide default ->best_encoder() behavior

2016-06-10 Thread Daniel Vetter
On Tue, Jun 07, 2016 at 01:47:55PM +0200, Boris Brezillon wrote:
> Hello,
> 
> This patch series aims at replacing all dummy ->best_encoder()
> implementations where we have a 1:1 relationship between encoders
> and connectors.
> The core already provides the drm_atomic_helper_best_encoder()
> function which is taking the first encoder attached to the
> connector (after making sure only one encoder was attached to the
> connector), but it's not automatically used, and drivers wanting
> to rely on this default behavior have to explicitly assign their
> ->best_encoder() hook to drm_atomic_helper_best_encoder().
> 
> The first patch fixes remaining places where
> drm_atomic_helper_best_encoder() should be called when ->best_encoder()
> is NULL, so that drivers using the atomic helpers can get rid of the
> explicit ->best_encoder assignment if they need to rely on the default
> drm_atomic_helper_best_encoder() implementation.
> 
> The following patches are killing all open coded ->best_encoder()
> implementations that could be replaced by
> drm_atomic_helper_best_encoder().
> 
> All modifications have been compile tested except for the changed on
> the intel driver.
> I've also tested on an atmel board, but I recommend waiting for DRM
> driver maintainers feedback before applying the associated changes.
> 
> Note that once patch 1 is applied, the other patches can be applied
> independently.

One comment on the i915 patch, all others should now be in drm-misc.
Thanks a lot for doing this.
-Daniel

> 
> Best Regards,
> 
> Boris
> 
> Changes since v1:
> - remove useless ->encoder backpointers in some implementations
> - documented the default behavior in the vtable doc
> - added R-b/A-b tags
> 
> Boris Brezillon (20):
>   drm/atomic: Fix remaining places where !funcs->best_encoder is valid
>   drm: arc: Rely on the default ->best_encoder() behavior
>   drm: atmel-hlcdc: Rely on the default ->best_encoder() behavior
>   drm: exynos: Rely on the default ->best_encoder() behavior
>   drm: fsl-dcu: Rely on the default ->best_encoder() behavior
>   drm: i915: Rely on the default ->best_encoder() behavior where
> appropriate
>   drm: mediatek: Rely on the default ->best_encoder() behavior
>   drm: msm: Rely on the default ->best_encoder() behavior where
> appropriate
>   drm: rcar-du: Rely on the default ->best_encoder() behavior
>   drm: rockchip: Rely on the default ->best_encoder() behavior
>   drm: sti: Rely on the default ->best_encoder() behavior
>   drm: sun4i: Rely on the default ->best_encoder() behavior
>   drm: tegra: Rely on the default ->best_encoder() behavior
>   drm: vc4: Rely on the default ->best_encoder() behavior
>   drm: virtgpu: Rely on the default ->best_encoder() behavior
>   drm: omap: Rely on the default ->best_encoder() behavior
>   drm/bridge: anx78xx: Rely on the default ->best_encoder() behavior
>   drm/bridge: ptn3460: Rely on the default ->best_encoder() behavior
>   drm/bridge: ps8622: Rely on the default ->best_encoder() behavior
>   drm/bridge: dw-hdmi: Use drm_atomic_helper_best_encoder()
> 
>  drivers/gpu/drm/arc/arcpgu_hdmi.c  | 18 --
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c   | 12 
>  drivers/gpu/drm/bridge/analogix-anx78xx.c  |  8 
>  drivers/gpu/drm/bridge/dw-hdmi.c   | 11 +--
>  drivers/gpu/drm/bridge/nxp-ptn3460.c   |  8 
>  drivers/gpu/drm/bridge/parade-ps8622.c | 10 --
>  drivers/gpu/drm/drm_atomic_helper.c|  4 +++-
>  drivers/gpu/drm/drm_fb_helper.c| 13 -
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c|  9 -
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c|  9 -
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c   |  8 
>  drivers/gpu/drm/exynos/exynos_hdmi.c   |  8 
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c  |  9 -
>  drivers/gpu/drm/i915/intel_crt.c   |  1 -
>  drivers/gpu/drm/i915/intel_display.c   |  8 
>  drivers/gpu/drm/i915/intel_dp.c|  1 -
>  drivers/gpu/drm/i915/intel_drv.h   |  1 -
>  drivers/gpu/drm/i915/intel_dsi.c   |  1 -
>  drivers/gpu/drm/i915/intel_dvo.c   |  1 -
>  drivers/gpu/drm/i915/intel_hdmi.c  |  1 -
>  drivers/gpu/drm/i915/intel_lvds.c  |  1 -
>  drivers/gpu/drm/i915/intel_sdvo.c  |  1 -
>  drivers/gpu/drm/i915/intel_tv.c|  1 -
>  drivers/gpu/drm/mediatek/mtk_dsi.c |  9 -
>  drivers/gpu/drm/msm/edp/edp_connector.c| 10 --
>  drivers/gpu/drm/msm/hdmi/hdmi_connector.c  |  8 
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_lvds_connector.c |  9 -
>  drivers/gpu/drm/omapdrm/omap_connector.c   | 10 --
>  drivers/gpu/drm/rcar-du/rcar_du_encoder.c  

Re: [Intel-gfx] [PATCH v2 06/20] drm: i915: Rely on the default ->best_encoder() behavior where appropriate

2016-06-10 Thread Daniel Vetter
On Tue, Jun 07, 2016 at 01:48:01PM +0200, Boris Brezillon wrote:
> For all outputs except dp_mst, we have a 1:1 relationship between
> connectors and encoders and the driver is relying on the atomic helpers:
> we can drop the custom ->best_encoder() implementation and let the core
> call drm_atomic_helper_best_encoder() for us.
> 
> Signed-off-by: Boris Brezillon 

You can also drop the best_encoder from intel_dp_mst, we only need the
atomic_best_encoder. The best_encoder there was needed to help out the
fbdev emulation. Care to respin?
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_crt.c | 1 -
>  drivers/gpu/drm/i915/intel_display.c | 8 
>  drivers/gpu/drm/i915/intel_dp.c  | 1 -
>  drivers/gpu/drm/i915/intel_drv.h | 1 -
>  drivers/gpu/drm/i915/intel_dsi.c | 1 -
>  drivers/gpu/drm/i915/intel_dvo.c | 1 -
>  drivers/gpu/drm/i915/intel_hdmi.c| 1 -
>  drivers/gpu/drm/i915/intel_lvds.c| 1 -
>  drivers/gpu/drm/i915/intel_sdvo.c| 1 -
>  drivers/gpu/drm/i915/intel_tv.c  | 1 -
>  10 files changed, 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_crt.c 
> b/drivers/gpu/drm/i915/intel_crt.c
> index 3fbb6fc..bd0cd68 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -753,7 +753,6 @@ static const struct drm_connector_funcs 
> intel_crt_connector_funcs = {
>  static const struct drm_connector_helper_funcs 
> intel_crt_connector_helper_funcs = {
>   .mode_valid = intel_crt_mode_valid,
>   .get_modes = intel_crt_get_modes,
> - .best_encoder = intel_best_encoder,
>  };
>  
>  static const struct drm_encoder_funcs intel_crt_enc_funcs = {
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 2113f40..77026ce 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -16113,14 +16113,6 @@ void intel_modeset_cleanup(struct drm_device *dev)
>   intel_teardown_gmbus(dev);
>  }
>  
> -/*
> - * Return which encoder is currently attached for connector.
> - */
> -struct drm_encoder *intel_best_encoder(struct drm_connector *connector)
> -{
> - return _attached_encoder(connector)->base;
> -}
> -
>  void intel_connector_attach_encoder(struct intel_connector *connector,
>   struct intel_encoder *encoder)
>  {
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f192f58..21b2833 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4935,7 +4935,6 @@ static const struct drm_connector_funcs 
> intel_dp_connector_funcs = {
>  static const struct drm_connector_helper_funcs 
> intel_dp_connector_helper_funcs = {
>   .get_modes = intel_dp_get_modes,
>   .mode_valid = intel_dp_mode_valid,
> - .best_encoder = intel_best_encoder,
>  };
>  
>  static const struct drm_encoder_funcs intel_dp_enc_funcs = {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index a28b4aa..79a4d6b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1128,7 +1128,6 @@ struct intel_connector *intel_connector_alloc(void);
>  bool intel_connector_get_hw_state(struct intel_connector *connector);
>  void intel_connector_attach_encoder(struct intel_connector *connector,
>   struct intel_encoder *encoder);
> -struct drm_encoder *intel_best_encoder(struct drm_connector *connector);
>  struct drm_display_mode *intel_crtc_mode_get(struct drm_device *dev,
>struct drm_crtc *crtc);
>  enum pipe intel_get_pipe_from_connector(struct intel_connector *connector);
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 366ad6c..ec51952 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -1378,7 +1378,6 @@ static const struct drm_encoder_funcs intel_dsi_funcs = 
> {
>  static const struct drm_connector_helper_funcs 
> intel_dsi_connector_helper_funcs = {
>   .get_modes = intel_dsi_get_modes,
>   .mode_valid = intel_dsi_mode_valid,
> - .best_encoder = intel_best_encoder,
>  };
>  
>  static const struct drm_connector_funcs intel_dsi_connector_funcs = {
> diff --git a/drivers/gpu/drm/i915/intel_dvo.c 
> b/drivers/gpu/drm/i915/intel_dvo.c
> index 286baec..34b7e3f 100644
> --- a/drivers/gpu/drm/i915/intel_dvo.c
> +++ b/drivers/gpu/drm/i915/intel_dvo.c
> @@ -351,7 +351,6 @@ static const struct drm_connector_funcs 
> intel_dvo_connector_funcs = {
>  static const struct drm_connector_helper_funcs 
> intel_dvo_connector_helper_funcs = {
>   .mode_valid = intel_dvo_mode_valid,
>   .get_modes = intel_dvo_get_modes,
> - .best_encoder = intel_best_encoder,
>  };
>  
>  static void intel_dvo_enc_destroy(struct drm_encoder *encoder)
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> 

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: Remaining PSR fixes

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

Series: drm/i915: Remaining PSR fixes
URL   : https://patchwork.freedesktop.org/series/8046/
State : warning

== Summary ==

Series 8046v1 drm/i915: Remaining PSR fixes
http://patchwork.freedesktop.org/api/1.0/series/8046/revisions/1/mbox

Test drv_module_reload_basic:
skip   -> PASS   (ro-ivb-i7-3770)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b:
pass   -> SKIP   (fi-skl-i5-6260u)
Subgroup read-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-skl-i5-6260u)
Test kms_sink_crc_basic:
pass   -> SKIP   (ro-bdw-i7-5600u)

fi-bdw-i7-5557u  total:213  pass:201  dwarn:0   dfail:0   fail:0   skip:12 
fi-skl-i5-6260u  total:213  pass:201  dwarn:0   dfail:0   fail:0   skip:12 
fi-skl-i7-6700k  total:213  pass:188  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:213  pass:174  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:213  pass:197  dwarn:1   dfail:0   fail:0   skip:15 
ro-bdw-i7-5557U  total:213  pass:197  dwarn:1   dfail:0   fail:0   skip:15 
ro-bdw-i7-5600u  total:213  pass:184  dwarn:0   dfail:0   fail:0   skip:29 
ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2   skip:39 
ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:213  pass:150  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl3-i5-6260u total:213  pass:201  dwarn:1   dfail:0   fail:0   skip:11 
ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38 
fi-hsw-i7-4770k failed to connect after reboot
ro-byt-n2820 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1159/

1723c64 drm-intel-nightly: 2016y-06m-10d-14h-36m-05s UTC integration manifest
77cd5c6 drm/i915: Move psr.link_standby setup to intel_psr_match_conditions()
c16c581 drm/i915: Ask the sink whether training is required when exiting PSR 
main-link off mode
1bb3ecf drm/i915/psr: Skip aux handeshake if the vbt tells us to
6e94f00 drm/i915: Check PSR setup time vs. vblank length
1b495b8 drm/dp: Add drm_dp_psr_need_train_on_exit()
4ab36fd drm/dp: Add drm_dp_psr_setup_time()

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


Re: [Intel-gfx] [PATCH 0/3] SKL watermark fixes for !fbcon

2016-06-10 Thread Matt Roper
On Fri, Jun 10, 2016 at 10:28:13AM +0300, Jani Nikula wrote:
> On Fri, 10 Jun 2016, Matt Roper  wrote:
> > There are a handful of watermark bugs that are only triggered (or more 
> > easily
> > triggered) when running without fbcon.  Thanks Tvrtko for pointing these 
> > out.
> >
> > I do still see some WARN()'s from other parts of the display code when
> > launching X in a non-fbcon setup, so there may be other bugfixes needed in
> > other parts of the code as well.
> 
> Should some or all of these be cc: stable?

I don't think so; these are all followups to the SKL atomic wm work that
isn't going to land until 4.8.


Matt

> 
> BR,
> Jani.
> 
> >
> > Cc: Tvrtko Ursulin 
> >
> > Matt Roper (3):
> >   drm/i915/gen9: Initialize intel_state->active_crtcs during WM
> > sanitization
> >   drm/i915/gen9: Compute data rates for all planes on first commit
> >   drm/i915/gen9: Drop invalid WARN() during data rate calculation
> >
> >  drivers/gpu/drm/i915/intel_pm.c | 25 ++---
> >  1 file changed, 22 insertions(+), 3 deletions(-)
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

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


Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for SKL watermark fixes for !fbcon

2016-06-10 Thread Matt Roper
On Fri, Jun 10, 2016 at 06:24:43AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: SKL watermark fixes for !fbcon
> URL   : https://patchwork.freedesktop.org/series/8513/
> State : failure
> 
> == Summary ==
> 
> Series 8513v1 SKL watermark fixes for !fbcon
> http://patchwork.freedesktop.org/api/1.0/series/8513/revisions/1/mbox
> 
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-cmd:
> pass   -> FAIL   (ro-byt-n2820)

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

> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> fail   -> PASS   (ro-bdw-i7-5600u)
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-c:
> skip   -> DMESG-WARN (ro-bdw-i5-5250u)

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

> 
> ro-bdw-i5-5250u  total:213  pass:197  dwarn:3   dfail:0   fail:0   skip:13 
> ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
> ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2   skip:39 
> ro-byt-n2820 total:213  pass:173  dwarn:0   dfail:0   fail:3   skip:37 
> ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
> ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
> ro-ilk-i7-620lm  total:177  pass:120  dwarn:2   dfail:2   fail:1   skip:51 
> ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57 
> ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32 
> ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
> ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38 
> fi-hsw-i7-4770k failed to connect after reboot
> ro-bdw-i7-5557U failed to connect after reboot
> 
> Results at /archive/results/CI_IGT_test/RO_Patchwork_1154/
> 
> b373842 drm-intel-nightly: 2016y-06m-09d-16h-49m-09s UTC integration manifest
> 7db1532 drm/i915/gen9: Drop invalid WARN() during data rate calculation
> 46946f4 drm/i915/gen9: Compute data rates for all planes on first commit
> c90f98f drm/i915/gen9: Initialize intel_state->active_crtcs during WM 
> sanitization
> 

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


Re: [Intel-gfx] [PATCH v5 10/10] drm/i915: Add DP branch device info on debugfs

2016-06-10 Thread kbuild test robot
Hi,

[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.7-rc2 next-20160609]
[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/Mika-Kahola/drm-i915-DP-branch-devices/20160610-203119
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: i386-defconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/i915_debugfs.c: In function 'intel_dp_info':
>> drivers/gpu/drm/i915/i915_debugfs.c:2954:10: warning: unused variable 'cap' 
>> [-Wunused-variable]
 uint8_t cap[4];
 ^~~
>> drivers/gpu/drm/i915/i915_debugfs.c:2953:6: warning: unused variable 
>> 'cap_size' [-Wunused-variable]
 int cap_size;
 ^~~~

vim +/cap +2954 drivers/gpu/drm/i915/i915_debugfs.c

  2947  bool is_branch_device;
  2948  bool detailed_cap_info = 
intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
  2949  DP_DETAILED_CAP_INFO_AVAILABLE;
  2950  int type;
  2951  int clk;
  2952  int bpc;
> 2953  int cap_size;
> 2954  uint8_t cap[4];
  2955  char id[6];
  2956  
  2957  seq_printf(m, "\tDPCD rev: %x\n", intel_dp->dpcd[DP_DPCD_REV]);

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


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


[Intel-gfx] ✗ Ro.CI.BAT: failure for Support for sustained capturing of GuC firmware logs (rev2)

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

Series: Support for sustained capturing of GuC firmware logs (rev2)
URL   : https://patchwork.freedesktop.org/series/7910/
State : failure

== Summary ==

Applying: drm/i915: Decouple GuC log setup from verbosity parameter
Applying: drm/i915: Add GuC ukernel logging related fields to fw interface file
Applying: drm/i915: Add low level set of routines for programming PM 
IER/IIR/IMR register set
Applying: drm/i915: Support for GuC interrupts
fatal: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_drv.h).
error: could not build fake ancestor
Patch failed at 0004 drm/i915: Support for GuC interrupts
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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


[Intel-gfx] [PATCH 00/11] Support for sustained capturing of GuC firmware logs

2016-06-10 Thread akash . goel
From: Akash Goel 

GuC firmware log its debug messages into a Host-GuC shared memory buffer
and when the buffer is half full it sends a Flush interrupt to Host.
GuC firmware expects that while it is writing to 2nd half of the buffer,
first half would get consumed by Host and then get a flush completed
acknowledgement from Host, so that it does not end up doing any overwrite
causing loss of logs.
So far Flush interrupt wasn't enabled on Host side & User could capture the
contents/snapshot of log buffer through 'i915_guc_log_dump' debugfs iface.
But this couldn't meet couple of key requirements, especially of Validation,
first is to ensure capturing of all boot time logs even with high verbosity
level and second is to enable capturing of logs in a sustained manner like
for the entire duration of a workload.
Now Driver will enable Flush interrupt and on receving it, would copy the
contents of log buffer into its local buffer. The size of local buffer would
be big enough to contain multiple snapshots of the log buffer giving ample
time to User to pull boot time messages.
Have added a debugfs interface '/sys/kernel/debug/dri/guc_log' for User to
collect the logs. Availed relay framework to implement this interface, where
Driver will have to just use a relay API to store snapshots of GuC log buffer
in a buffer managed by relay. The relay buffer will be operated in a mode
where the old data, not yet collected by User, will be overwritten if buffer
becomes full. So the behavior exhibited will be equivalent to 'dmesg -c'.
Besides mmap method, through which User can directly access the relay
buffer contents, relay also supports the 'poll' method. Through the 'poll'
call on log file, User can come to know whenever a new snapshot of the log
buffer is taken by Driver, so can run in lockstep with the Driver and thus
capture logs in a sustained/streaming manner, without any loss of data.

Akash Goel (4):
  drm/i915: Add low level set of routines for programming PM IER/IIR/IMR
register set
  drm/i915: Add a relay backed debugfs interface for capturing GuC logs
  drm/i915: New module param to control the size of buffer used for
storing GuC firmware logs
  drm/i915: Use uncached(WC) mapping for acessing the GuC log buffer

Chris Wilson (1):
  drm/i915: Support to create write combined type vmaps

Sagar Arun Kamble (6):
  drm/i915: Decouple GuC log setup from verbosity parameter
  drm/i915: Add GuC ukernel logging related fields to fw interface file
  drm/i915: Support for GuC interrupts
  drm/i915: Handle log buffer flush interrupt event from GuC
  drm/i915: Forcefully flush GuC log buffer on reset
  drm/i915: Debugfs support for GuC logging control

 drivers/gpu/drm/i915/i915_debugfs.c|  35 +++-
 drivers/gpu/drm/i915/i915_drv.h|   6 +-
 drivers/gpu/drm/i915/i915_gem.c|  57 --
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |   2 +-
 drivers/gpu/drm/i915/i915_guc_submission.c | 292 -
 drivers/gpu/drm/i915/i915_irq.c| 169 +++--
 drivers/gpu/drm/i915/i915_params.c |   5 +
 drivers/gpu/drm/i915/i915_params.h |   1 +
 drivers/gpu/drm/i915/i915_reg.h|  11 ++
 drivers/gpu/drm/i915/intel_drv.h   |   9 +
 drivers/gpu/drm/i915/intel_guc.h   |  10 +
 drivers/gpu/drm/i915/intel_guc_fwif.h  |  53 ++
 drivers/gpu/drm/i915/intel_guc_loader.c|  12 +-
 drivers/gpu/drm/i915/intel_lrc.c   |   8 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c|   2 +-
 15 files changed, 631 insertions(+), 41 deletions(-)

-- 
1.9.2

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


[Intel-gfx] [PATCH 07/11] drm/i915: Forcefully flush GuC log buffer on reset

2016-06-10 Thread akash . goel
From: Sagar Arun Kamble 

If GuC logs are being captured, there should be a force log buffer flush
action sent to GuC before proceeding with GPU reset and re-initializing
GUC. Those logs would be useful to understand why the GPU reset was
initiated.

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 25 +
 drivers/gpu/drm/i915/i915_irq.c|  2 ++
 drivers/gpu/drm/i915/intel_guc.h   |  1 +
 3 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 14f53de..4590cb4 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -169,6 +169,16 @@ static int host2guc_sample_forcewake(struct intel_guc *guc,
return host2guc_action(guc, data, ARRAY_SIZE(data));
 }
 
+static int host2guc_force_logbuffer_flush(struct intel_guc *guc)
+{
+   u32 data[2];
+
+   data[0] = HOST2GUC_ACTION_FORCE_LOGBUFFERFLUSH;
+   data[1] = 0;
+
+   return host2guc_action(guc, data, 2);
+}
+
 /*
  * Initialise, update, or clear doorbell data shared with the GuC
  *
@@ -1233,3 +1243,18 @@ void i915_guc_capture_logs(struct drm_device *dev)
if (host2guc_action(guc, data, 1))
DRM_ERROR("Failed\n");
 }
+
+void i915_guc_capture_logs_on_reset(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_guc *guc = _priv->guc;
+
+   /* First disable the interrupts, will be renabled after reset */
+   gen9_disable_guc_interrupts(dev_priv);
+
+   /* Ask GuC to update the log buffer state */
+   host2guc_force_logbuffer_flush(guc);
+
+   /* GuC would have updated the log buffer by now, so capture it */
+   i915_guc_capture_logs(dev);
+}
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5da2b0b..0234c7f 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2701,6 +2701,8 @@ static void i915_reset_and_wakeup(struct drm_i915_private 
*dev_priv)
 */
intel_runtime_pm_get(dev_priv);
 
+   i915_guc_capture_logs_on_reset(dev_priv->dev);
+
intel_prepare_reset(dev_priv);
 
/*
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index bf61925..3999f7b 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -169,5 +169,6 @@ int i915_guc_submit(struct drm_i915_gem_request *rq);
 void i915_guc_submission_disable(struct drm_device *dev);
 void i915_guc_submission_fini(struct drm_device *dev);
 void i915_guc_capture_logs(struct drm_device *dev);
+void i915_guc_capture_logs_on_reset(struct drm_device *dev);
 
 #endif
-- 
1.9.2

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


[Intel-gfx] [PATCH 11/11] drm/i915: Use uncached(WC) mapping for acessing the GuC log buffer

2016-06-10 Thread akash . goel
From: Akash Goel 

Host needs to sample the GuC log buffer on every flush interrupt from GuC.
To ensure that we always get the up-to-date data from log buffer, its
better to access the buffer through an uncached CPU mapping.
Since the data to be read is less than 50 KB, there would not be any
performance implications.

Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 27 +--
 drivers/gpu/drm/i915/intel_guc.h   |  1 +
 2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index cf72482..3408c4f 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -816,8 +816,7 @@ static void guc_read_update_log_buffer(struct drm_device 
*dev)
if (!guc->log_obj)
return;
 
-   log_buffer_state = src_ptr =
-   kmap_atomic(i915_gem_object_get_page(guc->log_obj, 0));
+   log_buffer_state = src_ptr = guc->log_buf_addr;
 
/* Get the pointer to local buffer to store the logs */
dst_ptr = log_buffer_copy_state = guc_get_write_buffer(guc);
@@ -847,14 +846,11 @@ static void guc_read_update_log_buffer(struct drm_device 
*dev)
log_buffer_copy_state++;
}
 
-   kunmap_atomic(src_ptr);
-
/* Now copy the actual logs */
for (i=1; (i < guc->log_obj->base.size / PAGE_SIZE) && dst_ptr; i++) {
dst_ptr += PAGE_SIZE;
-   src_ptr = kmap_atomic(i915_gem_object_get_page(guc->log_obj, 
i));
+   src_ptr += PAGE_SIZE;
memcpy(dst_ptr, src_ptr, PAGE_SIZE);
-   kunmap_atomic(src_ptr);
}
 }
 
@@ -983,6 +979,7 @@ static void guc_create_log(struct intel_guc *guc)
struct drm_i915_gem_object *obj;
unsigned long offset;
uint32_t size, flags;
+   void *vaddr;
 
if (i915.guc_log_level > GUC_LOG_VERBOSITY_MAX)
i915.guc_log_level = GUC_LOG_VERBOSITY_MAX;
@@ -1003,6 +1000,21 @@ static void guc_create_log(struct intel_guc *guc)
}
 
guc->log_obj = obj;
+
+   /* Create a WC (Uncached for read) mapping so that we can
+* directly get the data (up-to-date) from system memory.
+*/
+   vaddr = i915_gem_object_pin_map(obj, true);
+   if (IS_ERR(vaddr)) {
+   DRM_DEBUG_DRIVER("Couldn't map log buffer pages(%ld)\n",
+   PTR_ERR(vaddr));
+   i915.guc_log_level = -1;
+   gem_release_guc_obj(dev_priv->guc.log_obj);
+   guc->log_obj = NULL;
+   return;
+   }
+
+   guc->log_buf_addr = vaddr;
}
 
/* each allocated unit is a page */
@@ -1176,6 +1188,9 @@ void i915_guc_submission_fini(struct drm_device *dev)
gem_release_guc_obj(dev_priv->guc.ads_obj);
guc->ads_obj = NULL;
 
+   if (guc->log_obj)
+   i915_gem_object_unpin_map(guc->log_obj);
+   guc->log_buf_addr = NULL;
gem_release_guc_obj(dev_priv->guc.log_obj);
guc->log_obj = NULL;
guc_logging_fini(guc);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 6f4828b..d6146e4 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -125,6 +125,7 @@ struct intel_guc {
struct intel_guc_fw guc_fw;
uint32_t log_flags;
struct drm_i915_gem_object *log_obj;
+   void *log_buf_addr;
struct rchan *log_relay_chan;
/*
 * work, interrupts_enabled are protected by dev_priv->irq_lock
-- 
1.9.2

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


[Intel-gfx] [PATCH 05/11] drm/i915: Handle log buffer flush interrupt event from GuC

2016-06-10 Thread akash . goel
From: Sagar Arun Kamble 

GuC ukernel sends an interrupt to Host to flush the log buffer
and expects Host to correspondingly update the read pointer
information in the state structure, once it has consumed the
log buffer contents by copying them to a file or buffer.
Even if Host couldn't copy the contents, it can still update the
read pointer so that logging state is not disturbed on GuC side.

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 72 ++
 drivers/gpu/drm/i915/i915_irq.c| 19 +++-
 drivers/gpu/drm/i915/intel_guc.h   |  1 +
 3 files changed, 91 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index ad7b409..d887031 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -769,6 +769,65 @@ err:
return NULL;
 }
 
+static void* guc_get_write_buffer(struct intel_guc *guc)
+{
+   return NULL;
+}
+
+static void guc_read_update_log_buffer(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_guc *guc = _priv->guc;
+   struct guc_log_buffer_state *log_buffer_state;
+   struct guc_log_buffer_state *log_buffer_copy_state;
+   void *src_ptr, *dst_ptr;
+   int i;
+
+   if (!guc->log_obj)
+   return;
+
+   log_buffer_state = src_ptr =
+   kmap_atomic(i915_gem_object_get_page(guc->log_obj, 0));
+
+   /* Get the pointer to local buffer to store the logs */
+   dst_ptr = log_buffer_copy_state = guc_get_write_buffer(guc);
+   if (log_buffer_copy_state)
+   memcpy(log_buffer_copy_state, log_buffer_state, PAGE_SIZE);
+
+   for (i = 0; i < GUC_MAX_LOG_BUFFER; i++) {
+   /* Update the read pointer in the shared log buffer */
+   log_buffer_state->read_ptr =
+   log_buffer_state->sampled_write_ptr;
+
+   /* Clear the 'flush to file' flag */
+   log_buffer_state->flush_to_file = 0;
+   log_buffer_state++;
+
+   if (!log_buffer_copy_state)
+   continue;
+
+   /* The write pointer could have been updated by the GuC 
firmware,
+* after sending the flush interrupt to Host, for consistency
+* set the write pointer value to same value of 
sampled_write_ptr
+* in the snapshot buffer.
+*/
+   log_buffer_copy_state->write_ptr =
+   log_buffer_copy_state->sampled_write_ptr;
+
+   log_buffer_copy_state++;
+   }
+
+   kunmap_atomic(src_ptr);
+
+   /* Now copy the actual logs */
+   for (i=1; (i < guc->log_obj->base.size / PAGE_SIZE) && dst_ptr; i++) {
+   dst_ptr += PAGE_SIZE;
+   src_ptr = kmap_atomic(i915_gem_object_get_page(guc->log_obj, 
i));
+   memcpy(dst_ptr, src_ptr, PAGE_SIZE);
+   kunmap_atomic(src_ptr);
+   }
+}
+
 static void guc_create_log(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
@@ -1030,3 +1089,16 @@ int intel_guc_resume(struct drm_device *dev)
 
return host2guc_action(guc, data, ARRAY_SIZE(data));
 }
+
+void i915_guc_capture_logs(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_guc *guc = _priv->guc;
+   u32 data[1];
+
+   guc_read_update_log_buffer(dev);
+
+   data[0] = HOST2GUC_ACTION_LOG_BUFFER_FILE_FLUSH_COMPLETE;
+   if (host2guc_action(guc, data, 1))
+   DRM_ERROR("Failed\n");
+}
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4797bb3..5da2b0b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1249,6 +1249,7 @@ static void gen9_guc2host_events_work(struct work_struct 
*work)
 {
struct drm_i915_private *dev_priv =
container_of(work, struct drm_i915_private, guc.events_work);
+   u32 msg;
 
spin_lock_irq(_priv->irq_lock);
/* Speed up work cancelation during disabling guc interrupts. */
@@ -1268,7 +1269,23 @@ static void gen9_guc2host_events_work(struct work_struct 
*work)
gen6_enable_pm_irq(dev_priv, GEN9_GUC_TO_HOST_INT_EVENT);
spin_unlock_irq(_priv->irq_lock);
 
-   /* TODO: Handle the events for which GuC interrupted host */
+   /* Determine why GuC interrupted host and process */
+   msg = I915_READ(SOFT_SCRATCH(15));
+   if (msg & (GUC2HOST_MSG_CRASH_DUMP_POSTED |
+  GUC2HOST_MSG_FLUSH_LOG_BUFFER)) {
+   i915_guc_capture_logs(dev_priv->dev);
+
+   /* Clear GuC to Host msg bits that are handled */
+   if (msg & 

[Intel-gfx] [PATCH 04/11] drm/i915: Support for GuC interrupts

2016-06-10 Thread akash . goel
From: Sagar Arun Kamble 

There are certain types of interrupts which Host can recieve from GuC.
GuC ukernel sends an interrupt to Host for certain events, like for
example retrieve/consume the logs generated by ukernel.
This patch adds support to receive interrupts from GuC but currently
enables & partially handles only the interrupt sent by GuC ukernel.
Future patches will add support for handling other interrupt types.

v2: Use common low level routines for PM IER/IIR programming (Chris)
Rename interrupt functions to gen9_xxx from gen8_xxx (Chris)
Replace disabling of wake ref asserts with rpm get/put (Chris)

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/i915_drv.h|  1 +
 drivers/gpu/drm/i915/i915_guc_submission.c |  5 ++
 drivers/gpu/drm/i915/i915_irq.c| 95 --
 drivers/gpu/drm/i915/i915_reg.h| 11 
 drivers/gpu/drm/i915/intel_drv.h   |  3 +
 drivers/gpu/drm/i915/intel_guc.h   |  5 ++
 drivers/gpu/drm/i915/intel_guc_loader.c|  4 ++
 7 files changed, 120 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 021dbe5..18947ba 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1791,6 +1791,7 @@ struct drm_i915_private {
u32 pm_irq_mask;
u32 pm_ier_mask;
u32 pm_rps_events;
+   u32 guc_events;
u32 pipestat_irq_mask[I915_MAX_PIPES];
 
struct i915_hotplug hotplug;
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index da7c242..ad7b409 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -990,6 +990,8 @@ int intel_guc_suspend(struct drm_device *dev)
if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;
 
+   gen9_disable_guc_interrupts(dev_priv);
+
ctx = dev_priv->kernel_context;
 
data[0] = HOST2GUC_ACTION_ENTER_S_STATE;
@@ -1016,6 +1018,9 @@ int intel_guc_resume(struct drm_device *dev)
if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;
 
+   if (i915.guc_log_level >= 0)
+   gen9_enable_guc_interrupts(dev_priv);
+
ctx = dev_priv->kernel_context;
 
data[0] = HOST2GUC_ACTION_EXIT_S_STATE;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 330d87b..4797bb3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -170,6 +170,7 @@ static void gen5_assert_iir_is_zero(struct drm_i915_private 
*dev_priv,
 } while (0)
 
 static void gen6_rps_irq_handler(struct drm_i915_private *dev_priv, u32 
pm_iir);
+static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv, u32 
pm_iir);
 
 /* For display hotplug interrupt */
 static inline void
@@ -434,6 +435,42 @@ void gen6_disable_rps_interrupts(struct drm_i915_private 
*dev_priv)
synchronize_irq(dev_priv->dev->irq);
 }
 
+void gen9_reset_guc_interrupts(struct drm_i915_private *dev_priv)
+{
+   spin_lock_irq(_priv->irq_lock);
+   gen6_reset_pm_interrupts(dev_priv, dev_priv->guc_events);
+   spin_unlock_irq(_priv->irq_lock);
+}
+
+void gen9_enable_guc_interrupts(struct drm_i915_private *dev_priv)
+{
+   spin_lock_irq(_priv->irq_lock);
+   if (!dev_priv->guc.interrupts_enabled) {
+   WARN_ON(I915_READ(gen6_pm_iir(dev_priv)) &
+   dev_priv->guc_events);
+   dev_priv->guc.interrupts_enabled = true;
+   gen6_enable_pm_interrupts(dev_priv, dev_priv->guc_events);
+   }
+   spin_unlock_irq(_priv->irq_lock);
+}
+
+void gen9_disable_guc_interrupts(struct drm_i915_private *dev_priv)
+{
+   spin_lock_irq(_priv->irq_lock);
+   dev_priv->guc.interrupts_enabled = false;
+   spin_unlock_irq(_priv->irq_lock);
+
+   cancel_work_sync(_priv->guc.events_work);
+
+   spin_lock_irq(_priv->irq_lock);
+
+   gen6_disable_pm_interrupts(dev_priv, dev_priv->guc_events);
+
+   spin_unlock_irq(_priv->irq_lock);
+
+   synchronize_irq(dev_priv->dev->irq);
+}
+
 /**
  * bdw_update_port_irq - update DE port interrupt
  * @dev_priv: driver private
@@ -1208,6 +1245,33 @@ out:
ENABLE_RPM_WAKEREF_ASSERTS(dev_priv);
 }
 
+static void gen9_guc2host_events_work(struct work_struct *work)
+{
+   struct drm_i915_private *dev_priv =
+   container_of(work, struct drm_i915_private, guc.events_work);
+
+   spin_lock_irq(_priv->irq_lock);
+   /* Speed up work cancelation during disabling guc interrupts. */
+   if (!dev_priv->guc.interrupts_enabled) {
+   spin_unlock_irq(_priv->irq_lock);
+   return;
+   }
+
+   /* Though this work item gets synced during rpm suspend, 

[Intel-gfx] [PATCH 02/11] drm/i915: Add GuC ukernel logging related fields to fw interface file

2016-06-10 Thread akash . goel
From: Sagar Arun Kamble 

The first page of the GuC log buffer contains state info or meta data
which is required to parse the logs contained in the subsequent pages.
The structure representing the state info is added to interface file
as Driver would need to handle log buffer flush interrupts from GuC.
Added an enum for the different message/event types that can be send
by the GuC ukernel to Host.
Also added 2 new Host to GuC action types to inform GuC when Host has
flushed the log buffer and forcefuly cause the GuC to send a new
log buffer flush interrupt.

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/intel_guc_fwif.h | 53 +++
 1 file changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 944786d..eb10324 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -418,15 +418,62 @@ struct guc_ads {
u32 reserved2[4];
 } __packed;
 
+/* GuC logging structures */
+
+enum guc_log_buffer_type {
+   GUC_ISR_LOG_BUFFER,
+   GUC_DPC_LOG_BUFFER,
+   GUC_CRASH_DUMP_LOG_BUFFER,
+   GUC_MAX_LOG_BUFFER
+};
+
+/*
+ * Below state is used for coordination of retrival of GuC logs
+ * by i915. read_ptr is where i915 read last. GuC keeps incrementing
+ * write_ptr on each log entry. When buffer gets half filled and i915
+ * has requested interrupt, GuC will set flush_to_file field and raise the
+ * interrupt. i915 should read the buffer and clear flush_to_file field.
+ * i915 should also update the read_ptr.
+*/
+struct guc_log_buffer_state {
+   u32 marker[2];
+   u32 read_ptr;
+   u32 write_ptr;
+   u32 size;
+   u32 sampled_write_ptr;
+   union {
+   struct {
+   u32 flush_to_file:1;
+   u32 buffer_full_cnt:4;
+   u32 reserved:27;
+   };
+   u32 flags;
+   };
+   u32 version;
+} __packed;
+
+union guc_log_control {
+   struct {
+   u32 logging_enabled:1;
+   u32 reserved1:3;
+   u32 verbosity:4;
+   u32 reserved2:24;
+   };
+   u32 value;
+} __packed;
+
 /* This Action will be programmed in C180 - SOFT_SCRATCH_O_REG */
 enum host2guc_action {
HOST2GUC_ACTION_DEFAULT = 0x0,
HOST2GUC_ACTION_SAMPLE_FORCEWAKE = 0x6,
HOST2GUC_ACTION_ALLOCATE_DOORBELL = 0x10,
HOST2GUC_ACTION_DEALLOCATE_DOORBELL = 0x20,
+   HOST2GUC_ACTION_LOG_BUFFER_FILE_FLUSH_COMPLETE = 0x30,
+   HOST2GUC_ACTION_FORCE_LOGBUFFERFLUSH = 0x302,
HOST2GUC_ACTION_ENTER_S_STATE = 0x501,
HOST2GUC_ACTION_EXIT_S_STATE = 0x502,
HOST2GUC_ACTION_SLPC_REQUEST = 0x3003,
+   HOST2GUC_ACTION_UK_LOG_ENABLE_LOGGING = 0x0E000,
HOST2GUC_ACTION_LIMIT
 };
 
@@ -448,4 +495,10 @@ enum guc2host_status {
GUC2HOST_STATUS_GENERIC_FAIL = GUC2HOST_STATUS(0xF000)
 };
 
+/* This action will be programmed in C1BC - SOFT_SCRATCH_15_REG */
+enum guc2host_message {
+   GUC2HOST_MSG_CRASH_DUMP_POSTED = (1 << 1),
+   GUC2HOST_MSG_FLUSH_LOG_BUFFER = (1 << 3)
+};
+
 #endif
-- 
1.9.2

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


[Intel-gfx] [PATCH 06/11] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

2016-06-10 Thread akash . goel
From: Akash Goel 

Added a new debugfs interface '/sys/kernel/debug/dri/guc_log' for the
User to capture GuC firmware logs. Availed relay framework to implement
the interface, where Driver will have to just use a relay API to store
snapshots of the GuC log buffer in the buffer managed by relay.
The snapshot will be taken when GuC firmware sends a log buffer flush
interrupt and up to four snaphots could be stored in the relay buffer.
The relay buffer will be operated in a mode where it will overwrite the
data not yet collected by User.
Besides mmap method, through which User can directly access the relay
buffer contents, relay also supports the 'poll' method. Through the 'poll'
call on log file, User can come to know whenever a new snapshot of the
log buffer is taken by Driver, so can run in lockstep with the Driver and
capture the logs in a sustained/streaming manner, without any loss of data.

Suggested-by: Chris Wilson 
Signed-off-by: Sourab Gupta 
Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 133 -
 drivers/gpu/drm/i915/intel_guc.h   |   1 +
 2 files changed, 133 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index d887031..14f53de 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -23,6 +23,8 @@
  */
 #include 
 #include 
+#include 
+#include 
 #include "i915_drv.h"
 #include "intel_guc.h"
 
@@ -771,7 +773,15 @@ err:
 
 static void* guc_get_write_buffer(struct intel_guc *guc)
 {
-   return NULL;
+   if (!guc->log_relay_chan)
+   return NULL;
+
+   /* Get the pointer to relay sub buffer and copy data into it ourselves.
+* Could have used the relay_write() to indirectly copy the data, but
+* that would have been bit convoluted, as we also need to update the
+* first page containing state data.
+*/
+   return relay_reserve(guc->log_relay_chan, guc->log_obj->base.size);
 }
 
 static void guc_read_update_log_buffer(struct drm_device *dev)
@@ -828,6 +838,125 @@ static void guc_read_update_log_buffer(struct drm_device 
*dev)
}
 }
 
+/*
+ * Sub buffer switch callback. If this callback is not implemented
+ * relay will operate in non-overwrite mode so will stop accepting
+ * new data if there are no empty sub buffers left.
+ */
+static int subbuf_start_callback(struct rchan_buf *buf,
+void *subbuf,
+void *prev_subbuf,
+size_t prev_padding)
+{
+   /* Always switch to next sub buffer as we don't mind overwriting of
+* old data/logs.
+*/
+   return 1;
+}
+
+/*
+ * file_create() callback. Creates relay file in debugfs.
+ */
+static struct dentry *create_buf_file_callback(const char *filename,
+  struct dentry *parent,
+  umode_t mode,
+  struct rchan_buf *buf,
+  int *is_global)
+{
+   /*
+* Not using the channel filename passed as an argument, since for each
+* channel relay appends the corresponding CPU number to the filename
+* passed in relay_open(). This should be fine as relay just needs a
+* dentry of the file associated with the channel buffer and that file's
+* name need not be same as the filename passed as an argument.
+*/
+   struct dentry *buf_file = debugfs_create_file("guc_log", mode,
+   parent, buf, _file_operations);
+
+   /* This to enable the use of a single buffer for the relay channel and
+* correspondingly have a single file exposed to User, through which
+* it can pull the logs in order without any post-processing.
+*/
+   *is_global = 1;
+
+   return buf_file;
+}
+
+/*
+ * file_remove() default callback. Removes relay file in debugfs.
+ */
+static int remove_buf_file_callback(struct dentry *dentry)
+{
+   debugfs_remove(dentry);
+   return 0;
+}
+
+/* relay channel callbacks */
+static struct rchan_callbacks relay_callbacks = {
+   .subbuf_start = subbuf_start_callback,
+   .create_buf_file = create_buf_file_callback,
+   .remove_buf_file = remove_buf_file_callback,
+};
+
+static void guc_remove_log_relay_file(struct intel_guc *guc)
+{
+   relay_close(guc->log_relay_chan);
+}
+
+static void guc_create_log_relay_file(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   struct drm_device *dev = dev_priv->dev;
+   struct dentry *log_dir;
+   struct rchan *guc_log_relay_chan;
+   size_t n_subbufs, subbuf_size;
+
+   if (guc->log_relay_chan)
+   

[Intel-gfx] [PATCH 08/11] drm/i915: Debugfs support for GuC logging control

2016-06-10 Thread akash . goel
From: Sagar Arun Kamble 

This patch provides debugfs interface i915_guc_output_control for
on the fly enabling/disabling of logging in GuC firmware and controlling
the verbosity level of logs.

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/i915_debugfs.c| 35 -
 drivers/gpu/drm/i915/i915_guc_submission.c | 41 ++
 drivers/gpu/drm/i915/intel_guc.h   |  1 +
 3 files changed, 76 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index ac7e569..193073c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2624,6 +2624,38 @@ static int i915_guc_log_dump(struct seq_file *m, void 
*data)
return 0;
 }
 
+static int
+i915_guc_log_control_set(void *data, u64 val)
+{
+   struct drm_device *dev = data;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
+   struct intel_guc *guc = _priv->guc;
+   int ret;
+
+   if (!HAS_GUC_UCODE(dev))
+   return -EINVAL;
+
+   if (!i915.enable_guc_submission)
+   return -EINVAL;
+
+   if (guc_fw->guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+   return -EINVAL;
+
+   if (!guc->log_obj || !guc->log_relay_chan)
+   return -EINVAL;
+
+   intel_runtime_pm_get(dev_priv);
+   ret = i915_guc_log_control(dev, val);
+   intel_runtime_pm_put(dev_priv);
+
+   return ret;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_control_fops,
+   NULL, i915_guc_log_control_set,
+   "0x%08llx\n");
+
 static int i915_edp_psr_status(struct seq_file *m, void *data)
 {
struct drm_info_node *node = m->private;
@@ -5481,7 +5513,8 @@ static const struct i915_debugfs_files {
{"i915_fbc_false_color", _fbc_fc_fops},
{"i915_dp_test_data", _displayport_test_data_fops},
{"i915_dp_test_type", _displayport_test_type_fops},
-   {"i915_dp_test_active", _displayport_test_active_fops}
+   {"i915_dp_test_active", _displayport_test_active_fops},
+   {"i915_guc_log_control", _guc_log_control_fops}
 };
 
 void intel_display_crc_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 4590cb4..53a9ff99 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -169,6 +169,16 @@ static int host2guc_sample_forcewake(struct intel_guc *guc,
return host2guc_action(guc, data, ARRAY_SIZE(data));
 }
 
+static int host2guc_logging_control(struct intel_guc *guc, u32 control_val)
+{
+   u32 data[2];
+
+   data[0] = HOST2GUC_ACTION_UK_LOG_ENABLE_LOGGING;
+   data[1] = control_val;
+
+   return host2guc_action(guc, data, 2);
+}
+
 static int host2guc_force_logbuffer_flush(struct intel_guc *guc)
 {
u32 data[2];
@@ -1258,3 +1268,34 @@ void i915_guc_capture_logs_on_reset(struct drm_device 
*dev)
/* GuC would have updated the log buffer by now, so capture it */
i915_guc_capture_logs(dev);
 }
+
+int i915_guc_log_control(struct drm_device *dev, uint64_t control_val)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_guc *guc = _priv->guc;
+   union guc_log_control log_param;
+
+   log_param.logging_enabled = control_val & 0x1;
+   log_param.verbosity = (control_val >> 4) & 0xF;
+
+   if (log_param.verbosity < GUC_LOG_VERBOSITY_MIN ||
+   log_param.verbosity > GUC_LOG_VERBOSITY_MAX)
+   return -EINVAL;
+
+   if (!host2guc_logging_control(guc, log_param.value)) {
+   /* If log_level was set as -1 at boot time, then interrupt would
+* not have been enabled. Can keep the interrupt on even when
+* logging is being disabled at runtime, as GuC itself won't
+* generate an interrupt in that case.
+*/
+   if (i915.guc_log_level < 0)
+   gen9_enable_guc_interrupts(dev_priv);
+
+   i915.guc_log_level = log_param.verbosity;
+   } else {
+   DRM_ERROR("Failed\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 3999f7b..6f4828b 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -170,5 +170,6 @@ void i915_guc_submission_disable(struct drm_device *dev);
 void i915_guc_submission_fini(struct drm_device *dev);
 void i915_guc_capture_logs(struct drm_device *dev);
 void i915_guc_capture_logs_on_reset(struct drm_device *dev);
+int i915_guc_log_control(struct drm_device *dev, uint64_t control_val);
 
 #endif
-- 
1.9.2


[Intel-gfx] [PATCH 03/11] drm/i915: Add low level set of routines for programming PM IER/IIR/IMR register set

2016-06-10 Thread akash . goel
From: Akash Goel 

So far PM IER/IIR/IMR registers were being used only for Turbo related
interrupts. But interrupts coming from GuC also use the same set.
As a precursor to supporting GuC interrupts, added new low level routines
so as to allow sharing the programming of PM IER/IIR/IMR registers between
Turbo & GuC.
Also similar to PM IMR, maintaining a bitmask for PM IER register, to allow
easy sharing of it between Turbo & GuC without involving a rmw operation.

Suggested-by: Chris Wilson 
Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_irq.c  | 55 
 drivers/gpu/drm/i915/intel_drv.h |  6 +
 3 files changed, 52 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2a88a46..021dbe5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1789,6 +1789,7 @@ struct drm_i915_private {
};
u32 gt_irq_mask;
u32 pm_irq_mask;
+   u32 pm_ier_mask;
u32 pm_rps_events;
u32 pipestat_irq_mask[I915_MAX_PIPES];
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index caaf1e2..330d87b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -336,14 +336,52 @@ void gen6_disable_pm_irq(struct drm_i915_private 
*dev_priv, uint32_t mask)
__gen6_disable_pm_irq(dev_priv, mask);
 }
 
-void gen6_reset_rps_interrupts(struct drm_i915_private *dev_priv)
+void gen6_reset_pm_interrupts(struct drm_i915_private *dev_priv,
+  uint32_t reset_mask)
 {
i915_reg_t reg = gen6_pm_iir(dev_priv);
 
-   spin_lock_irq(_priv->irq_lock);
-   I915_WRITE(reg, dev_priv->pm_rps_events);
-   I915_WRITE(reg, dev_priv->pm_rps_events);
+   assert_spin_locked(_priv->irq_lock);
+
+   I915_WRITE(reg, reset_mask);
+   I915_WRITE(reg, reset_mask);
POSTING_READ(reg);
+}
+
+void gen6_enable_pm_interrupts(struct drm_i915_private *dev_priv,
+  uint32_t enable_mask)
+{
+   uint32_t new_val;
+
+   assert_spin_locked(_priv->irq_lock);
+
+   new_val = dev_priv->pm_ier_mask;
+   new_val |= enable_mask;
+
+   dev_priv->pm_ier_mask = new_val;
+   I915_WRITE(gen6_pm_ier(dev_priv), dev_priv->pm_ier_mask);
+   gen6_enable_pm_irq(dev_priv, enable_mask);
+}
+
+void gen6_disable_pm_interrupts(struct drm_i915_private *dev_priv,
+   uint32_t disable_mask)
+{
+   uint32_t new_val;
+
+   assert_spin_locked(_priv->irq_lock);
+
+   new_val = dev_priv->pm_ier_mask;
+   new_val &= ~disable_mask;
+
+   dev_priv->pm_ier_mask = new_val;
+   __gen6_disable_pm_irq(dev_priv, disable_mask);
+   I915_WRITE(gen6_pm_ier(dev_priv), dev_priv->pm_ier_mask);
+}
+
+void gen6_reset_rps_interrupts(struct drm_i915_private *dev_priv)
+{
+   spin_lock_irq(_priv->irq_lock);
+   gen6_reset_pm_interrupts(dev_priv, dev_priv->pm_rps_events);
dev_priv->rps.pm_iir = 0;
spin_unlock_irq(_priv->irq_lock);
 }
@@ -355,9 +393,7 @@ void gen6_enable_rps_interrupts(struct drm_i915_private 
*dev_priv)
WARN_ON(dev_priv->rps.pm_iir);
WARN_ON(I915_READ(gen6_pm_iir(dev_priv)) & dev_priv->pm_rps_events);
dev_priv->rps.interrupts_enabled = true;
-   I915_WRITE(gen6_pm_ier(dev_priv), I915_READ(gen6_pm_ier(dev_priv)) |
-   dev_priv->pm_rps_events);
-   gen6_enable_pm_irq(dev_priv, dev_priv->pm_rps_events);
+   gen6_enable_pm_interrupts(dev_priv, dev_priv->pm_rps_events);
 
spin_unlock_irq(_priv->irq_lock);
 }
@@ -391,9 +427,7 @@ void gen6_disable_rps_interrupts(struct drm_i915_private 
*dev_priv)
 
I915_WRITE(GEN6_PMINTRMSK, gen6_sanitize_rps_pm_mask(dev_priv, ~0));
 
-   __gen6_disable_pm_irq(dev_priv, dev_priv->pm_rps_events);
-   I915_WRITE(gen6_pm_ier(dev_priv), I915_READ(gen6_pm_ier(dev_priv)) &
-   ~dev_priv->pm_rps_events);
+   gen6_disable_pm_interrupts(dev_priv, dev_priv->pm_rps_events);
 
spin_unlock_irq(_priv->irq_lock);
 
@@ -3781,6 +3815,7 @@ static void gen8_gt_irq_postinstall(struct 
drm_i915_private *dev_priv)
gt_interrupts[0] |= GT_RENDER_L3_PARITY_ERROR_INTERRUPT;
 
dev_priv->pm_irq_mask = 0x;
+   dev_priv->pm_ier_mask = 0x0;
GEN8_IRQ_INIT_NDX(GT, 0, ~gt_interrupts[0], gt_interrupts[0]);
GEN8_IRQ_INIT_NDX(GT, 1, ~gt_interrupts[1], gt_interrupts[1]);
/*
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9b5f663..2dae2e5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1058,6 +1058,12 @@ void gen6_disable_pm_irq(struct drm_i915_private 
*dev_priv, uint32_t mask);
 void 

[Intel-gfx] [PATCH 09/11] drm/i915: New module param to control the size of buffer used for storing GuC firmware logs

2016-06-10 Thread akash . goel
From: Akash Goel 

On recieving the log buffer flush interrupt from GuC firmware, Driver
stores the snapshot of the log buffer in a local buffer, from which
Userspace can pull the logs. By default Driver store, up to, 4 snapshots
of the log buffer in a local buffer (managed by relay).
Added a new module (read only) param, 'guc_log_size', through which User
can specify the number of snapshots of log buffer to be stored in local
buffer. This can be used to ensure capturing of all boot time logs even
with high verbosity level.

Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
 drivers/gpu/drm/i915/i915_params.c | 5 +
 drivers/gpu/drm/i915/i915_params.h | 1 +
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 53a9ff99..cf72482 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -950,7 +950,7 @@ static void guc_create_log_relay_file(struct intel_guc *guc)
/* Keep the size of sub buffers same as shared log buffer */
subbuf_size = guc->log_obj->base.size;
/* TODO: Decide based on the User's input */
-   n_subbufs = 4;
+   n_subbufs = i915.guc_log_size;
 
guc_log_relay_chan = relay_open("guc_log", log_dir,
subbuf_size, n_subbufs, _callbacks, dev);
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 5e18cf9..f8ddec8 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -57,6 +57,7 @@ struct i915_params i915 __read_mostly = {
.enable_guc_loading = 0,
.enable_guc_submission = 0,
.guc_log_level = -1,
+   .guc_log_size = 4,
.enable_dp_mst = true,
.inject_load_failure = 0,
.enable_dpcd_backlight = false,
@@ -213,6 +214,10 @@ module_param_named(guc_log_level, i915.guc_log_level, int, 
0400);
 MODULE_PARM_DESC(guc_log_level,
"GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
 
+module_param_named(guc_log_size, i915.guc_log_size, int, 0400);
+MODULE_PARM_DESC(guc_log_size,
+   "Number of sub buffers to store GuC firmware logs (default: 4)");
+
 module_param_named_unsafe(enable_dp_mst, i915.enable_dp_mst, bool, 0600);
 MODULE_PARM_DESC(enable_dp_mst,
"Enable multi-stream transport (MST) for new DisplayPort sinks. 
(default: true)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 1323261..cbd649e 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -48,6 +48,7 @@ struct i915_params {
int enable_guc_loading;
int enable_guc_submission;
int guc_log_level;
+   int guc_log_size;
int use_mmio_flip;
int mmio_debug;
int edp_vswing;
-- 
1.9.2

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


[Intel-gfx] [PATCH 10/11] drm/i915: Support to create write combined type vmaps

2016-06-10 Thread akash . goel
From: Chris Wilson 

vmaps has a provision for controlling the page protection bits, with which
we can use to control the mapping type, e.g. WB, WC, UC or even WT.
To allow the caller to choose their mapping type, we add a parameter to
i915_gem_object_pin_map - but we still only allow one vmap to be cached
per object. If the object is currently not pinned, then we recreate the
previous vmap with the new access type, but if it was pinned we report an
error. This effectively limits the access via i915_gem_object_pin_map to a
single mapping type for the lifetime of the object. Not usually a problem,
but something to be aware of when setting up the object's vmap.

We will want to vary the access type to enable WC mappings of ringbuffer
and context objects on !llc platforms, as well as other objects where we
need coherent access to the GPU's pages without going through the GTT

Signed-off-by: Chris Wilson 
Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/i915_drv.h |  4 ++-
 drivers/gpu/drm/i915/i915_gem.c | 57 +
 drivers/gpu/drm/i915/i915_gem_dmabuf.c  |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c|  8 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.c |  2 +-
 5 files changed, 53 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 18947ba..2a0eb01 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3144,6 +3144,7 @@ static inline void i915_gem_object_unpin_pages(struct 
drm_i915_gem_object *obj)
 /**
  * i915_gem_object_pin_map - return a contiguous mapping of the entire object
  * @obj - the object to map into kernel address space
+ * _wc - whether the mapping should be using WC or WB pgprot_t
  *
  * Calls i915_gem_object_pin_pages() to prevent reaping of the object's
  * pages and then returns a contiguous mapping of the backing storage into
@@ -3155,7 +3156,8 @@ static inline void i915_gem_object_unpin_pages(struct 
drm_i915_gem_object *obj)
  * Returns the pointer through which to access the mapped object, or an
  * ERR_PTR() on error.
  */
-void *__must_check i915_gem_object_pin_map(struct drm_i915_gem_object *obj);
+void *__must_check i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
+bool use_wc);
 
 /**
  * i915_gem_object_unpin_map - releases an earlier mapping
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 343d881..cafbbdc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2225,10 +2225,11 @@ i915_gem_object_put_pages(struct drm_i915_gem_object 
*obj)
list_del(>global_list);
 
if (obj->mapping) {
-   if (is_vmalloc_addr(obj->mapping))
-   vunmap(obj->mapping);
+   void *ptr = (void *)((uintptr_t)obj->mapping & ~1);
+   if (is_vmalloc_addr(ptr))
+   vunmap(ptr);
else
-   kunmap(kmap_to_page(obj->mapping));
+   kunmap(kmap_to_page(ptr));
obj->mapping = NULL;
}
 
@@ -2401,7 +2402,8 @@ i915_gem_object_get_pages(struct drm_i915_gem_object *obj)
 }
 
 /* The 'mapping' part of i915_gem_object_pin_map() below */
-static void *i915_gem_object_map(const struct drm_i915_gem_object *obj)
+static void *i915_gem_object_map(const struct drm_i915_gem_object *obj,
+   bool use_wc)
 {
unsigned long n_pages = obj->base.size >> PAGE_SHIFT;
struct sg_table *sgt = obj->pages;
@@ -2413,7 +2415,7 @@ static void *i915_gem_object_map(const struct 
drm_i915_gem_object *obj)
void *addr;
 
/* A single page can always be kmapped */
-   if (n_pages == 1)
+   if (n_pages == 1 && !use_wc)
return kmap(sg_page(sgt->sgl));
 
if (n_pages > ARRAY_SIZE(stack_pages)) {
@@ -2429,7 +2431,8 @@ static void *i915_gem_object_map(const struct 
drm_i915_gem_object *obj)
/* Check that we have the expected number of pages */
GEM_BUG_ON(i != n_pages);
 
-   addr = vmap(pages, n_pages, 0, PAGE_KERNEL);
+   addr = vmap(pages, n_pages, VM_NO_GUARD,
+   use_wc ? pgprot_writecombine(PAGE_KERNEL_IO) : PAGE_KERNEL);
 
if (pages != stack_pages)
drm_free_large(pages);
@@ -2438,27 +2441,55 @@ static void *i915_gem_object_map(const struct 
drm_i915_gem_object *obj)
 }
 
 /* get, pin, and map the pages of the object into kernel space */
-void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj)
+void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj, bool use_wc)
 {
+   void *ptr;
+   bool has_wc;
+   bool pinned;
int ret;
 
lockdep_assert_held(>base.dev->struct_mutex);
+   GEM_BUG_ON((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0);
 

[Intel-gfx] [PATCH 01/11] drm/i915: Decouple GuC log setup from verbosity parameter

2016-06-10 Thread akash . goel
From: Sagar Arun Kamble 

GuC Log buffer allocation was tied up with verbosity level kernel parameter
i915.guc_log_level. User could be given a provision to enable logging at
runtime and not necessarily during load time only. This patch will perform
allocation of shared log buffer always but will initially enable logging on
GuC side through init params based on i915.guc_log_level.

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 3 ---
 drivers/gpu/drm/i915/intel_guc_loader.c| 8 +---
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index ac72451..da7c242 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -776,9 +776,6 @@ static void guc_create_log(struct intel_guc *guc)
unsigned long offset;
uint32_t size, flags;
 
-   if (i915.guc_log_level < GUC_LOG_VERBOSITY_MIN)
-   return;
-
if (i915.guc_log_level > GUC_LOG_VERBOSITY_MAX)
i915.guc_log_level = GUC_LOG_VERBOSITY_MAX;
 
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 29273e5..fdaeed8 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -162,11 +162,13 @@ static void set_guc_init_params(struct drm_i915_private 
*dev_priv)
params[GUC_CTL_FEATURE] |= GUC_CTL_DISABLE_SCHEDULER |
GUC_CTL_VCS2_ENABLED;
 
-   if (i915.guc_log_level >= 0) {
-   params[GUC_CTL_LOG_PARAMS] = guc->log_flags;
+   params[GUC_CTL_LOG_PARAMS] = guc->log_flags;
+
+   if (i915.guc_log_level >= 0)
params[GUC_CTL_DEBUG] =
i915.guc_log_level << GUC_LOG_VERBOSITY_SHIFT;
-   }
+   else
+   params[GUC_CTL_DEBUG] = GUC_LOG_DISABLED;
 
if (guc->ads_obj) {
u32 ads = (u32)i915_gem_obj_ggtt_offset(guc->ads_obj)
-- 
1.9.2

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


Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/5] drm/i915: Add support for mapping an object page by page

2016-06-10 Thread Chris Wilson
On Fri, Jun 10, 2016 at 01:49:18PM +0100, Tvrtko Ursulin wrote:
> 
> On 10/06/16 10:40, Patchwork wrote:
> >== Series Details ==
> >
> >Series: series starting with [1/5] drm/i915: Add support for mapping an 
> >object page by page
> >URL   : https://patchwork.freedesktop.org/series/8528/
> >State : failure
> >
> >== Summary ==
> >
> >Series 8528v1 Series without cover letter
> >http://patchwork.freedesktop.org/api/1.0/series/8528/revisions/1/mbox
> >
> >Test gem_exec_flush:
> > Subgroup basic-batch-kernel-default-cmd:
> > pass   -> FAIL   (ro-byt-n2820)
> >Test kms_flip:
> > Subgroup basic-flip-vs-wf_vblank:
> > fail   -> PASS   (ro-bdw-i7-5600u)
> >Test kms_pipe_crc_basic:
> > Subgroup suspend-read-crc-pipe-a:
> > skip   -> DMESG-WARN (ro-bdw-i5-5250u)
> >
> >ro-bdw-i5-5250u  total:213  pass:197  dwarn:3   dfail:0   fail:0   skip:13
> >ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28
> >ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2   skip:39
> >ro-byt-n2820 total:213  pass:173  dwarn:0   dfail:0   fail:3   skip:37
> >ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23
> >ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23
> >ro-ilk-i7-620lm  total:213  pass:150  dwarn:0   dfail:0   fail:1   skip:62
> >ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57
> >ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32
> >ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28
> >ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38
> >fi-hsw-i7-4770k failed to connect after reboot
> >ro-bdw-i7-5557U failed to connect after reboot
> >
> >Results at /archive/results/CI_IGT_test/RO_Patchwork_1156/
> >
> >b373842 drm-intel-nightly: 2016y-06m-09d-16h-49m-09s UTC integration manifest
> >165ff1a drm/i915: Support for pread/pwrite from/to non shmem backed objects
> >7c4d2d9 drm/i915: Clearing buffer objects via CPU/GTT
> >2c60c194 drm/i915: Use insert_page for pwrite_fast
> >3f97215 drm/i915: Introduce i915_gem_object_get_dma_address()
> >fbba107 drm/i915: Add support for mapping an object page by page
> 
> Copy of Ankit's result analysis from another thread:
> 
> """
> Hi,
> 
> The failures seen are not introduced by the patches.
> Following are the bug numbers related to the failures
> https://bugs.freedesktop.org/show_bug.cgi?id=95372 -
> igt/gem_exec_flush@basic-batch-kernel-default-cmd
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=86365 -
> igt/kms_pipe_crc_basic
> """
> 
> Chris, are you happy with merging this reduced series?

Patch 4 (clear via CPU) is unused.

Other than that the pread/pwrite fix a hole in the API for imported
dma-buf objects, so yes they are useful.
-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] ✗ Ro.CI.BAT: failure for series starting with [1/5] drm/i915: Add support for mapping an object page by page

2016-06-10 Thread Tvrtko Ursulin


On 10/06/16 10:40, Patchwork wrote:

== Series Details ==

Series: series starting with [1/5] drm/i915: Add support for mapping an object 
page by page
URL   : https://patchwork.freedesktop.org/series/8528/
State : failure

== Summary ==

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

Test gem_exec_flush:
 Subgroup basic-batch-kernel-default-cmd:
 pass   -> FAIL   (ro-byt-n2820)
Test kms_flip:
 Subgroup basic-flip-vs-wf_vblank:
 fail   -> PASS   (ro-bdw-i7-5600u)
Test kms_pipe_crc_basic:
 Subgroup suspend-read-crc-pipe-a:
 skip   -> DMESG-WARN (ro-bdw-i5-5250u)

ro-bdw-i5-5250u  total:213  pass:197  dwarn:3   dfail:0   fail:0   skip:13
ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28
ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2   skip:39
ro-byt-n2820 total:213  pass:173  dwarn:0   dfail:0   fail:3   skip:37
ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23
ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23
ro-ilk-i7-620lm  total:213  pass:150  dwarn:0   dfail:0   fail:1   skip:62
ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57
ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32
ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28
ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38
fi-hsw-i7-4770k failed to connect after reboot
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1156/

b373842 drm-intel-nightly: 2016y-06m-09d-16h-49m-09s UTC integration manifest
165ff1a drm/i915: Support for pread/pwrite from/to non shmem backed objects
7c4d2d9 drm/i915: Clearing buffer objects via CPU/GTT
2c60c194 drm/i915: Use insert_page for pwrite_fast
3f97215 drm/i915: Introduce i915_gem_object_get_dma_address()
fbba107 drm/i915: Add support for mapping an object page by page


Copy of Ankit's result analysis from another thread:

"""
Hi,

The failures seen are not introduced by the patches.
Following are the bug numbers related to the failures
https://bugs.freedesktop.org/show_bug.cgi?id=95372 -
igt/gem_exec_flush@basic-batch-kernel-default-cmd

https://bugs.freedesktop.org/show_bug.cgi?id=86365 -
igt/kms_pipe_crc_basic
"""

Chris, are you happy with merging this reduced series?

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


[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: DP branch devices (rev5)

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

Series: drm/i915: DP branch devices (rev5)
URL   : https://patchwork.freedesktop.org/series/6658/
State : warning

== Summary ==

Series 6658v5 drm/i915: DP branch devices
http://patchwork.freedesktop.org/api/1.0/series/6658/revisions/5/mbox

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (ro-bdw-i7-5600u)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
skip   -> DMESG-WARN (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)

ro-bdw-i5-5250u  total:213  pass:197  dwarn:2   dfail:0   fail:0   skip:14 
ro-bdw-i7-5557U  total:213  pass:197  dwarn:1   dfail:0   fail:0   skip:15 
ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:213  pass:174  dwarn:0   dfail:0   fail:2   skip:37 
ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:213  pass:150  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38 
fi-hsw-i7-4770k failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1157/

b373842 drm-intel-nightly: 2016y-06m-09d-16h-49m-09s UTC integration manifest
8395b91 drm/i915: Add DP branch device info on debugfs
7826a6e drm/i915: Update bits per component for display info
655e8d7 drm/i915: Check pixel rate for DP to VGA dongle
45e1784 drm: Read DP branch device SW revision
e97d307 drm: Read DP branch device HW revision
7d881c0 drm: Read DP branch device id
2267452 drm: Helper to read max bits per component
8c4d678 drm: Helper to read max clock rate
67038d0 drm: Drop VGA from bpc definitions
3d67f7a drm: Add missing DP downstream port types

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


[Intel-gfx] [PATCH v5 07/10] drm: Read DP branch device SW revision

2016-06-10 Thread Mika Kahola
SW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register field 0x50A.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/drm_dp_helper.c | 21 +
 include/drm/drm_dp_helper.h |  2 ++
 2 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index b5ae189..80147cd 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -535,6 +535,27 @@ struct drm_dp_revision drm_dp_downstream_hw_rev(struct 
drm_dp_aux *aux)
 EXPORT_SYMBOL(drm_dp_downstream_hw_rev);
 
 /**
+ * drm_dp_downstream_sw_rev() - read DP branch device SW revision
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns SW revision on success or negative error code on failure
+ */
+struct drm_dp_revision drm_dp_downstream_sw_rev(struct drm_dp_aux *aux)
+{
+   uint8_t tmp[2];
+   struct drm_dp_revision rev = { .major = -EINVAL, .minor = -EINVAL };
+
+   if (drm_dp_dpcd_read(aux, DP_BRANCH_SW_REV, tmp, 2) != 2)
+   return rev;
+
+   rev.major = tmp[0];
+   rev.minor = tmp[1];
+
+   return rev;
+}
+EXPORT_SYMBOL(drm_dp_downstream_sw_rev);
+
+/**
  * drm_dp_downstream_id() - identify branch device
  * @aux: DisplayPort AUX channel
  *
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 641bf3d..c3e4759 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -447,6 +447,7 @@
 #define DP_BRANCH_OUI  0x500
 #define DP_BRANCH_ID0x503
 #define DP_BRANCH_HW_REV0x509
+#define DP_BRANCH_SW_REV0x50A
 
 #define DP_SET_POWER0x600
 # define DP_SET_POWER_D00x1
@@ -819,6 +820,7 @@ int drm_dp_downstream_max_bpc(const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
  const u8 port_cap[4]);
 int drm_dp_downstream_id(struct drm_dp_aux *aux, char id[6]);
 struct drm_dp_revision drm_dp_downstream_hw_rev(struct drm_dp_aux *aux);
+struct drm_dp_revision drm_dp_downstream_sw_rev(struct drm_dp_aux *aux);
 
 int drm_dp_aux_register(struct drm_dp_aux *aux);
 void drm_dp_aux_unregister(struct drm_dp_aux *aux);
-- 
1.9.1

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


[Intel-gfx] [PATCH v5 03/10] drm: Helper to read max clock rate

2016-06-10 Thread Mika Kahola
Helper routine to read out maximum supported pixel rate
for DisplayPort legay VGA converter or TMDS clock rate
for other digital legacy converters. The helper returns
clock rate in kHz.

v2: Return early if detailed port cap info is not available.
Replace if-else ladder with switch-case (Ville)

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/drm_dp_helper.c | 33 +
 include/drm/drm_dp_helper.h |  2 ++
 2 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index eeaf5a7..1199a02 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -438,6 +438,39 @@ int drm_dp_link_configure(struct drm_dp_aux *aux, struct 
drm_dp_link *link)
 }
 EXPORT_SYMBOL(drm_dp_link_configure);
 
+/**
+ * drm_dp_downstream_max_clock() - extract branch device max
+ * pixel rate for legacy VGA
+ * converter or max TMDS clock
+ * rate for others
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: port capabilities
+ *
+ * Returns max clock in kHz on success or 0 if max clock not defined
+ */
+int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+   const u8 port_cap[4])
+{
+   int type = port_cap[0] & DP_DS_PORT_TYPE_MASK;
+   bool detailed_cap_info = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
+   DP_DETAILED_CAP_INFO_AVAILABLE;
+
+   if (!detailed_cap_info)
+   return 0;
+
+   switch (type) {
+   case DP_DS_PORT_TYPE_VGA:
+   return port_cap[1] * 8 * 1000;
+   case DP_DS_PORT_TYPE_DVI:
+   case DP_DS_PORT_TYPE_HDMI:
+   case DP_DS_PORT_TYPE_DP_DUALMODE:
+   return port_cap[1] * 2500;
+   default:
+   return 0;
+   }
+}
+EXPORT_SYMBOL(drm_dp_downstream_max_clock);
+
 /*
  * I2C-over-AUX implementation
  */
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index a7badba..0cf6d3a 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -806,6 +806,8 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct 
drm_dp_link *link);
 int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link);
 int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link);
 int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link);
+int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+   const u8 port_cap[4]);
 
 int drm_dp_aux_register(struct drm_dp_aux *aux);
 void drm_dp_aux_unregister(struct drm_dp_aux *aux);
-- 
1.9.1

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


[Intel-gfx] [PATCH v5 01/10] drm: Add missing DP downstream port types

2016-06-10 Thread Mika Kahola
Add missing DisplayPort downstream port types. The introduced
new port types are DP++ and Wireless.

Signed-off-by: Mika Kahola 
---
 include/drm/drm_dp_helper.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 5a848e7..e384c7f 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -211,6 +211,8 @@
 # define DP_DS_PORT_TYPE_DVI   2
 # define DP_DS_PORT_TYPE_HDMI  3
 # define DP_DS_PORT_TYPE_NON_EDID  4
+# define DP_DS_PORT_TYPE_DP_DUALMODE5
+# define DP_DS_PORT_TYPE_WIRELESS   6
 # define DP_DS_PORT_HPD(1 << 3)
 /* offset 1 for VGA is maximum megapixels per second / 8 */
 /* offset 2 */
-- 
1.9.1

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


[Intel-gfx] [PATCH v5 10/10] drm/i915: Add DP branch device info on debugfs

2016-06-10 Thread Mika Kahola
Read DisplayPort branch device info from through debugfs
interface.

v2: use drm_dp_helper routines to collect data
v3: cleanup to match the drm_dp_helper.c patches introduced
earlier in this series

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 72 +
 1 file changed, 72 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e4f2c55..442df3a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2943,9 +2943,81 @@ static void intel_dp_info(struct seq_file *m,
 {
struct intel_encoder *intel_encoder = intel_connector->encoder;
struct intel_dp *intel_dp = enc_to_intel_dp(_encoder->base);
+   struct drm_dp_revision rev;
+   bool is_branch_device;
+   bool detailed_cap_info = intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
+   DP_DETAILED_CAP_INFO_AVAILABLE;
+   int type;
+   int clk;
+   int bpc;
+   int cap_size;
+   uint8_t cap[4];
+   char id[6];
 
seq_printf(m, "\tDPCD rev: %x\n", intel_dp->dpcd[DP_DPCD_REV]);
seq_printf(m, "\taudio support: %s\n", yesno(intel_dp->has_audio));
+
+   is_branch_device = intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
+   DP_DWN_STRM_PORT_PRESENT;
+   seq_printf(m, "\tbranch device: %s\n", yesno(is_branch_device));
+
+   if (is_branch_device) {
+   type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
+
+   switch (type) {
+   case DP_DS_PORT_TYPE_DP:
+   seq_printf(m, "\ttype: DisplayPort\n");
+   break;
+   case DP_DS_PORT_TYPE_VGA:
+   seq_printf(m, "\ttype: VGA\n");
+   break;
+   case DP_DS_PORT_TYPE_DVI:
+   seq_printf(m, "\ttype: DVI\n");
+   break;
+   case DP_DS_PORT_TYPE_HDMI:
+   seq_printf(m, "\ttype: HDMI\n");
+   break;
+   case DP_DS_PORT_TYPE_NON_EDID:
+   seq_printf(m, "\ttype: others without EDID support\n");
+   break;
+   case DP_DS_PORT_TYPE_DP_DUALMODE:
+   seq_printf(m, "\ttype: DP++\n");
+   break;
+   case DP_DS_PORT_TYPE_WIRELESS:
+   seq_printf(m, "\ttype: Wireless\n");
+   break;
+   default:
+   seq_printf(m, "\ttype: N/A\n");
+   }
+
+   drm_dp_downstream_id(_dp->aux, id);
+   seq_printf(m, "\tDevice id: %s\n", id);
+
+   rev = drm_dp_downstream_hw_rev(_dp->aux);
+   seq_printf(m, "\tHW revision: %.2d.%.2d\n", rev.major, 
rev.minor);
+
+   rev = drm_dp_downstream_sw_rev(_dp->aux);
+   seq_printf(m, "\tSW revision: %.2d.%.2d\n", rev.major, 
rev.minor);
+
+   if (detailed_cap_info) {
+   clk = drm_dp_downstream_max_clock(intel_dp->dpcd,
+ 
intel_dp->downstream_ports);
+
+   if (clk > 0) {
+   if (type == DP_DS_PORT_TYPE_VGA)
+   seq_printf(m, "\tMax dot clock: %d 
kHz\n", clk);
+   else
+   seq_printf(m, "\tMax TMDS clock: %d 
kHz\n", clk);
+   }
+
+   bpc = drm_dp_downstream_max_bpc(intel_dp->dpcd,
+   
intel_dp->downstream_ports);
+
+   if (bpc > 0)
+   seq_printf(m, "\tMax bpc: %d\n", bpc);
+   }
+   }
+
if (intel_encoder->type == INTEL_OUTPUT_EDP)
intel_panel_info(m, _connector->panel);
 }
-- 
1.9.1

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


[Intel-gfx] [PATCH v5 08/10] drm/i915: Check pixel rate for DP to VGA dongle

2016-06-10 Thread Mika Kahola
Filter out a mode that exceeds the max pixel rate setting
for DP to VGA dongle. This is defined in DPCD register 0x81
if detailed cap info i.e. info field is 4 bytes long and
it is available for DP downstream port.

The register defines the pixel rate divided by 8 in MP/s.

v2: DPCD read outs and computation moved to drm (Ville, Daniel)
v3: Sink pixel rate computation moved to drm_dp_max_sink_dotclock()
function (Daniel)
v4: Use of drm_dp_helper.c routines to compute max pixel clock (Ville)
v5: Use of intel_dp->downstream_ports to read out port capabilities.
Code restructuring (Ville)

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dp.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f97cd53..3b09230 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -190,6 +190,20 @@ intel_dp_max_data_rate(int max_link_clock, int max_lanes)
return (max_link_clock * max_lanes * 8) / 10;
 }
 
+static int
+intel_dp_downstream_max_clock(struct intel_dp *intel_dp, int clock)
+{
+   int dp_ds_clk;
+
+   dp_ds_clk = drm_dp_downstream_max_clock(intel_dp->dpcd,
+   intel_dp->downstream_ports);
+
+   if (dp_ds_clk == 0)
+   return clock;
+
+   return min(clock, dp_ds_clk);
+}
+
 static enum drm_mode_status
 intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
@@ -201,6 +215,18 @@ intel_dp_mode_valid(struct drm_connector *connector,
int max_rate, mode_rate, max_lanes, max_link_clock;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
 
+   bool is_branch_device = intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
+   DP_DWN_STRM_PORT_PRESENT;
+   int type;
+
+   if (is_branch_device) {
+   type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
+
+   if (type == DP_DS_PORT_TYPE_VGA)
+   max_dotclk = intel_dp_downstream_max_clock(intel_dp,
+  max_dotclk);
+   }
+
if (is_edp(intel_dp) && fixed_mode) {
if (mode->hdisplay > fixed_mode->hdisplay)
return MODE_PANEL;
-- 
1.9.1

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


[Intel-gfx] [PATCH v5 05/10] drm: Read DP branch device id

2016-06-10 Thread Mika Kahola
Read DisplayPort branch device id string.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/drm_dp_helper.c | 12 
 include/drm/drm_dp_helper.h |  2 ++
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3dab8a4..0c83685 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -513,6 +513,18 @@ int drm_dp_downstream_max_bpc(const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
 }
 EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
 
+/**
+ * drm_dp_downstream_id() - identify branch device
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns branch device id on success or NULL on failure
+ */
+int drm_dp_downstream_id(struct drm_dp_aux *aux, char id[6])
+{
+   return drm_dp_dpcd_read(aux, DP_BRANCH_ID, id, 6);
+}
+EXPORT_SYMBOL(drm_dp_downstream_id);
+
 /*
  * I2C-over-AUX implementation
  */
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index b18d17c..88bf3bf 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -445,6 +445,7 @@
 #define DP_SOURCE_OUI  0x300
 #define DP_SINK_OUI0x400
 #define DP_BRANCH_OUI  0x500
+#define DP_BRANCH_ID0x503
 
 #define DP_SET_POWER0x600
 # define DP_SET_POWER_D00x1
@@ -810,6 +811,7 @@ int drm_dp_downstream_max_clock(const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
const u8 port_cap[4]);
 int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
  const u8 port_cap[4]);
+int drm_dp_downstream_id(struct drm_dp_aux *aux, char id[6]);
 
 int drm_dp_aux_register(struct drm_dp_aux *aux);
 void drm_dp_aux_unregister(struct drm_dp_aux *aux);
-- 
1.9.1

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


[Intel-gfx] [PATCH v5 09/10] drm/i915: Update bits per component for display info

2016-06-10 Thread Mika Kahola
DisplayPort branch device may define max supported bits per
component. Update display info based on this value if bpc
is defined.

v2: cleanup to match the drm_dp_helper.c patches introduced
earlier in this series

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dp.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3b09230..8a293bee 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3942,6 +3942,14 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
uint8_t *dpcd = intel_dp->dpcd;
uint8_t type;
 
+   if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT) {
+   int bpc = drm_dp_downstream_max_bpc(dpcd,
+   intel_dp->downstream_ports);
+
+   if (bpc > 0)
+   intel_dp->attached_connector->base.display_info.bpc = 
bpc;
+   }
+
if (!intel_dp_get_dpcd(intel_dp))
return connector_status_disconnected;
 
@@ -3978,6 +3986,7 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
return connector_status_unknown;
}
 
+
/* Anything else is out of spec, warn and ignore */
DRM_DEBUG_KMS("Broken DP branch device, ignoring\n");
return connector_status_disconnected;
-- 
1.9.1

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


[Intel-gfx] [PATCH v5 02/10] drm: Drop VGA from bpc definitions

2016-06-10 Thread Mika Kahola
Drop "VGA" from bits per component definitions as these
are also used by other standards such as DVI, HDMI,
DP++.

Signed-off-by: Mika Kahola 
---
 include/drm/drm_dp_helper.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index e384c7f..a7badba 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -216,11 +216,11 @@
 # define DP_DS_PORT_HPD(1 << 3)
 /* offset 1 for VGA is maximum megapixels per second / 8 */
 /* offset 2 */
-# define DP_DS_VGA_MAX_BPC_MASK(3 << 0)
-# define DP_DS_VGA_8BPC0
-# define DP_DS_VGA_10BPC   1
-# define DP_DS_VGA_12BPC   2
-# define DP_DS_VGA_16BPC   3
+# define DP_DS_MAX_BPC_MASK(3 << 0)
+# define DP_DS_8BPC0
+# define DP_DS_10BPC   1
+# define DP_DS_12BPC   2
+# define DP_DS_16BPC   3
 
 /* link configuration */
 #defineDP_LINK_BW_SET  0x100
-- 
1.9.1

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


[Intel-gfx] [PATCH v5 06/10] drm: Read DP branch device HW revision

2016-06-10 Thread Mika Kahola
HW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register field 0x509.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/drm_dp_helper.c | 21 +
 include/drm/drm_dp_helper.h |  7 +++
 2 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 0c83685..b5ae189 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -514,6 +514,27 @@ int drm_dp_downstream_max_bpc(const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
 EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
 
 /**
+ * drm_dp_downstream_hw_rev() - read DP branch device HW revision
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns HW revision on succes or negative error code on failure
+ */
+struct drm_dp_revision drm_dp_downstream_hw_rev(struct drm_dp_aux *aux)
+{
+   uint8_t tmp;
+   struct drm_dp_revision rev = { .major = -EINVAL, .minor = -EINVAL };
+
+   if (drm_dp_dpcd_read(aux, DP_BRANCH_HW_REV, , 1) != 1)
+   return rev;
+
+   rev.major = (tmp & 0xf0) >> 4;
+   rev.minor = tmp & 0xf;
+
+   return rev;
+}
+EXPORT_SYMBOL(drm_dp_downstream_hw_rev);
+
+/**
  * drm_dp_downstream_id() - identify branch device
  * @aux: DisplayPort AUX channel
  *
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 88bf3bf..641bf3d 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -446,6 +446,7 @@
 #define DP_SINK_OUI0x400
 #define DP_BRANCH_OUI  0x500
 #define DP_BRANCH_ID0x503
+#define DP_BRANCH_HW_REV0x509
 
 #define DP_SET_POWER0x600
 # define DP_SET_POWER_D00x1
@@ -803,6 +804,11 @@ struct drm_dp_link {
unsigned long capabilities;
 };
 
+struct drm_dp_revision {
+   int major;
+   int minor;
+};
+
 int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link);
 int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link);
 int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link);
@@ -812,6 +818,7 @@ int drm_dp_downstream_max_clock(const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
 int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
  const u8 port_cap[4]);
 int drm_dp_downstream_id(struct drm_dp_aux *aux, char id[6]);
+struct drm_dp_revision drm_dp_downstream_hw_rev(struct drm_dp_aux *aux);
 
 int drm_dp_aux_register(struct drm_dp_aux *aux);
 void drm_dp_aux_unregister(struct drm_dp_aux *aux);
-- 
1.9.1

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


[Intel-gfx] [PATCH v5 04/10] drm: Helper to read max bits per component

2016-06-10 Thread Mika Kahola
Helper routine to read out maximum supported bits per
component for DisplayPort legay converters.

v2: Return early if detailed port cap info is not available.
Replace if-else ladder with switch-case (Ville)

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/drm_dp_helper.c | 42 +
 include/drm/drm_dp_helper.h |  2 ++
 2 files changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 1199a02..3dab8a4 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -471,6 +471,48 @@ int drm_dp_downstream_max_clock(const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
 }
 EXPORT_SYMBOL(drm_dp_downstream_max_clock);
 
+/**
+ * drm_dp_downstream_max_bpc() - extract branch device max
+ *   bits per component
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: port capabilities
+ *
+ * Returns max bpc on success or 0 if max bpc not defined
+ */
+int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+ const u8 port_cap[4])
+{
+   int type = port_cap[0] & DP_DS_PORT_TYPE_MASK;
+   bool detailed_cap_info = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
+   DP_DETAILED_CAP_INFO_AVAILABLE;
+   int bpc;
+
+   if (!detailed_cap_info)
+   return 0;
+
+   switch (type) {
+   case DP_DS_PORT_TYPE_VGA:
+   case DP_DS_PORT_TYPE_DVI:
+   case DP_DS_PORT_TYPE_HDMI:
+   case DP_DS_PORT_TYPE_DP_DUALMODE:
+   bpc = port_cap[2] & DP_DS_MAX_BPC_MASK;
+
+   switch (bpc) {
+   case DP_DS_8BPC:
+   return 8;
+   case DP_DS_10BPC:
+   return 10;
+   case DP_DS_12BPC:
+   return 12;
+   case DP_DS_16BPC:
+   return 16;
+   }
+   default:
+   return 0;
+   }
+}
+EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
+
 /*
  * I2C-over-AUX implementation
  */
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 0cf6d3a..b18d17c 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -808,6 +808,8 @@ int drm_dp_link_power_down(struct drm_dp_aux *aux, struct 
drm_dp_link *link);
 int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link);
 int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
const u8 port_cap[4]);
+int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+ const u8 port_cap[4]);
 
 int drm_dp_aux_register(struct drm_dp_aux *aux);
 void drm_dp_aux_unregister(struct drm_dp_aux *aux);
-- 
1.9.1

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


[Intel-gfx] [PATCH v5 00/10] drm/i915: DP branch devices

2016-06-10 Thread Mika Kahola
Prep work for DP branch device handling

This series of patches reads DPCD register 0x80h for receiver
capabilities for DP branch devices. The branch device types are
converters for the following standards

 - DP to VGA
 - DP to DVI
 - DP to HDMI
 - DP++ dual mode
 - Wireless WiGig
 
DPCD register defines max pixel rate for VGA dongles. This
check is carried out during mode validation. 

What's new in the series:
 - Readout of branch device ID, HW, and SW revisions from DPCD register 

v2: DPCD register read outs moved to drm (Ville, Daniel)
v3: Max pixel rate computation moved to drm (Daniel)
v4: Use of drm_dp_helper routines to collect data (Ville)
v5: Remove duplicate code and unnecessary functions from drm_dp_helper (Ville)

Mika Kahola (10):
  drm: Add missing DP downstream port types
  drm: Drop VGA from bpc definitions
  drm: Helper to read max clock rate
  drm: Helper to read max bits per component
  drm: Read DP branch device id
  drm: Read DP branch device HW revision
  drm: Read DP branch device SW revision
  drm/i915: Check pixel rate for DP to VGA dongle
  drm/i915: Update bits per component for display info
  drm/i915: Add DP branch device info on debugfs

 drivers/gpu/drm/drm_dp_helper.c | 129 
 drivers/gpu/drm/i915/i915_debugfs.c |  72 
 drivers/gpu/drm/i915/intel_dp.c |  35 ++
 include/drm/drm_dp_helper.h |  27 ++--
 4 files changed, 258 insertions(+), 5 deletions(-)

-- 
1.9.1

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


Re: [Intel-gfx] [PATCH 0/6] drm/i915/bxt: Fix DDI PHY setup for low resolutions

2016-06-10 Thread Ville Syrjälä
On Tue, Jun 07, 2016 at 09:24:27PM +0300, Imre Deak wrote:
> There are two problems with the current way of enabling the DDI PHYs
> during driver loading/resuming:
> Relying on the HWs dynamic power gating may waste some power and part of
> the PHY configuration is dependent on the mode specific DDI lane count.
> To solve both of these issues split the PHY initialization, moving one
> half of it to the power well code the other half to the modeset code,
> similarly to the CHV code.
> 
> Kudos to Ville for explaining about the PHY power gating and other
> quirks on CHV, it helped a lot to better understand the BXT PHY which is
> quite similar.
> 
> This fixes modeset problems for modes with less than 4 lanes.
> 
> Imre Deak (6):
>   drm/i915/bxt: Wait for PHY1 GRC calibration synchronously
>   drm/i915: Factor out intel_power_well_get/put
>   drm/i915/bxt: Move DDI PHY enabling/disabling to the power well code
>   drm/i915/bxt: Set DDI PHY lane latency optimization during modeset
>   drm/i915/bxt: Rename broxton to bxt in PHY/CDCLK function prefixes
>   drm/i915/bxt: Sanitiy check the PHY lane power down status

Series lgtm

Reviewed-by: Ville Syrjälä 

> 
>  drivers/gpu/drm/i915/i915_reg.h |  12 ++
>  drivers/gpu/drm/i915/intel_ddi.c| 222 
> ++--
>  drivers/gpu/drm/i915/intel_display.c|  33 +++--
>  drivers/gpu/drm/i915/intel_drv.h|  19 ++-
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 133 ---
>  5 files changed, 291 insertions(+), 128 deletions(-)
> 
> -- 
> 2.5.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH 3/4] drm/i915/guc: refactor doorbell management code

2016-06-10 Thread Dave Gordon

On 08/06/16 14:11, Tvrtko Ursulin wrote:


On 08/06/16 11:55, Dave Gordon wrote:

During a hibernate/resume cycle, the driver, the GuC, and the doorbell
hardware can end up in inconsistent states. This patch refactors the
driver's handling and tracking of doorbells, in preparation for a later
one which will resolve the issue.


Perhaps a few word on the goal, method and result of refactoring. Would
be good for documentation and easier review.


The refactoring is exactly that; there's very little new code.
All we're doing is centralising all doorbell management into
just one function and turning the (outermost) old functions
into wrappers for the single function.

There are three resources to be managed:
1. Cachelines: a single line within the client-object's page 0
   is snooped for writes by the host.
2. Doorbell registers: each defines a cacheline to be snooped.
3. Bitmap: tracks which registers are in use.

The doorbell setup/teardown protocol starts with:
1. Pick a cacheline: select_doorbell_cacheline()
2. Find an available doorbell (register): assign_doorbell()
(These values are passed to the GuC via the shared context
descriptor; this part of the sequence remains unchanged).

3. Update the bitmap to reflect registers-in-use
4. Prepare the cacheline for use by setting its status to ENABLED
5. Ask the GuC to program the doorbell to snoop the cacheline

and of course teardown is very similar:
6. Set the cacheline to DISABLED
7. Ask the GuC to reprogram the doorbell to stop snooping
8. Record that the doorbell is not in use.

Operations 6-8 (guc_disable_doorbell(), host2guc_release_doorbell(), and 
release_doorbell()) were called in sequence from guc_client_free(), but 
are now moved into the teardown part of the common function.


Steps 4-5 (guc_init_doorbell() and host2guc_allocate_doorbell()) were 
similarly done as sequential steps in guc_client_alloc(), but since it 
turns out we don't need to do them separately they're now collected into 
the setup part of the common function.



Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 87
++
  1 file changed, 53 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 7510841..eef67c8 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -174,36 +174,63 @@ static int host2guc_sample_forcewake(struct
intel_guc *guc,
   * client object which contains the page being used for the doorbell
   */

-static void guc_init_doorbell(struct intel_guc *guc,
-  struct i915_guc_client *client)
+static int guc_update_doorbell_id(struct i915_guc_client *client,
+  struct guc_doorbell_info *doorbell,
+  u16 new_id)
  {
-struct guc_doorbell_info *doorbell;
+struct sg_table *sg = client->guc->ctx_pool_obj->pages;
+void *doorbell_bitmap = client->guc->doorbell_bitmap;
+struct guc_context_desc desc;
+size_t len;
+
+if (client->doorbell_id != GUC_INVALID_DOORBELL_ID &&
+test_bit(client->doorbell_id, doorbell_bitmap)) {
+/* Deactivate the old doorbell */
+doorbell->db_status = GUC_DOORBELL_DISABLED;
+(void)host2guc_release_doorbell(client->guc, client);
+clear_bit(client->doorbell_id, doorbell_bitmap);
+}

-doorbell = client->client_base + client->doorbell_offset;
+/* Update the GuC's idea of the doorbell ID */
+len = sg_pcopy_to_buffer(sg->sgl, sg->nents, , sizeof(desc),
+ sizeof(desc) * client->ctx_index);
+if (len != sizeof(desc))
+return -EFAULT;
+desc.db_id = new_id;
+len = sg_pcopy_from_buffer(sg->sgl, sg->nents, , sizeof(desc),
+ sizeof(desc) * client->ctx_index);
+if (len != sizeof(desc))
+return -EFAULT;
+
+client->doorbell_id = new_id;
+if (new_id == GUC_INVALID_DOORBELL_ID)
+return 0;

+/* Activate the new doorbell */
+set_bit(client->doorbell_id, doorbell_bitmap);
  doorbell->db_status = GUC_DOORBELL_ENABLED;
  doorbell->cookie = 0;
+return host2guc_allocate_doorbell(client->guc, client);


A bunch of new code here which wasn't done on doorbell init before.
Populating the ctx_pool_obj and hust2guc call. I think the commit needs
to explain what is happening here.


The only new code (and new capability) is the block
/* Update the GuC's idea of the doorbell ID */
i.e. we can now *change* the doorbell (register) used by an
existing client, whereas previously it was set once for the
entire lifetime of the client. We will use this new feature
in the next patch.

The host2guc call is not new, but it was previously called
separately after the return from guc_init_doorbell().


Maybe it is mostly a matter of copying over some text from the cover
letter, but ideally it should explain what it is doing more precisely.


I'll put 

Re: [Intel-gfx] [PATCH v9 2/6] drm/i915: Convert requests to use struct fence

2016-06-10 Thread John Harrison

On 07/06/2016 12:42, Maarten Lankhorst wrote:

Op 02-06-16 om 13:07 schreef Tvrtko Ursulin:

On 01/06/16 18:07, john.c.harri...@intel.com wrote:

From: John Harrison 

There is a construct in the linux kernel called 'struct fence' that is
intended to keep track of work that is executed on hardware. I.e. it
solves the basic problem that the drivers 'struct
drm_i915_gem_request' is trying to address. The request structure does
quite a lot more than simply track the execution progress so is very
definitely still required. However, the basic completion status side
could be updated to use the ready made fence implementation and gain
all the advantages that provides.

This patch makes the first step of integrating a struct fence into the
request. It replaces the explicit reference count with that of the
fence. It also replaces the 'is completed' test with the fence's
equivalent. Currently, that simply chains on to the original request
implementation. A future patch will improve this.

v3: Updated after review comments by Tvrtko Ursulin. Added fence
context/seqno pair to the debugfs request info. Renamed fence 'driver
name' to just 'i915'. Removed BUG_ONs.

v5: Changed seqno format in debugfs to %x rather than %u as that is
apparently the preferred appearance. Line wrapped some long lines to
keep the style checker happy.

v6: Updated to newer nigthly and resolved conflicts. The biggest issue
was with the re-worked busy spin precursor to waiting on a request. In
particular, the addition of a 'request_started' helper function. This
has no corresponding concept within the fence framework. However, it
is only ever used in one place and the whole point of that place is to
always directly read the seqno for absolutely lowest latency possible.
So the simple solution is to just make the seqno test explicit at that
point now rather than later in the series (it was previously being
done anyway when fences become interrupt driven).

v7: Rebased to newer nightly - lots of ring -> engine renaming and
interface change to get_seqno().

v8: Rebased to newer nightly - no longer needs to worry about mutex
locking in the request free code path. Moved to after fence timeline
patch so no longer needs to add a horrid hack timeline.

Removed commented out code block. Added support for possible RCU usage
of fence object (Review comments by Maarten Lankhorst).

For: VIZ-5190
Signed-off-by: John Harrison 
Cc: Tvrtko Ursulin 
Cc: Maarten Lankhorst 
Reviewed-by: Jesse Barnes 

Was it an r-b or an ack from Jesse? If the former does it need a "(v?)" suffix, 
depending on the amount of code changes after his r-b?
Going back through the old emails it looks like you are right, it was 
actually an ack on v3. What is the official tag for that?





---
   drivers/gpu/drm/i915/i915_debugfs.c |   5 +-
   drivers/gpu/drm/i915/i915_drv.h |  43 +-
   drivers/gpu/drm/i915/i915_gem.c | 101 
+---
   drivers/gpu/drm/i915/intel_lrc.c|   1 +
   drivers/gpu/drm/i915/intel_ringbuffer.c |   1 +
   drivers/gpu/drm/i915/intel_ringbuffer.h |   2 +
   6 files changed, 115 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index ac7e569..844cc4b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -767,11 +767,12 @@ static int i915_gem_request_info(struct seq_file *m, void 
*data)
   task = NULL;
   if (req->pid)
   task = pid_task(req->pid, PIDTYPE_PID);
-seq_printf(m, "%x @ %d: %s [%d]\n",
+seq_printf(m, "%x @ %d: %s [%d], fence = %x:%x\n",

In the previous patch fence context and seqno were %d in the timeline->name so 
it would probably be more consistent.
It is trying to be consistent with the surroundings. Requests used to be 
printed as %d but for some reason got changed to be %x recently. Whereas 
the fence debug output is all %d still. Currently, the request::seqno 
and fence::seqno are different so maybe it doesn't really matter that 
they are printed differently but the ultimate aim is to merge the two 
into a single value. At which point all i915 code would be showing the 
value in one format but all fence code in another.





  req->seqno,
  (int) (jiffies - req->emitted_jiffies),
  task ? task->comm : "",
-   task ? task->pid : -1);
+   task ? task->pid : -1,
+   req->fence.context, req->fence.seqno);

req->fence.context is 64-bits, will probably cause a compiler warning.
Not at the point the above was written. Have rebased to the newer tree 
and updated to u64 / %llx.



   rcu_read_unlock();
   }

diff --git 

Re: [Intel-gfx] Intel-gfx Digest, Vol 101, Issue 215

2016-06-10 Thread Ankitprasad Sharma
On Fri, 2016-06-10 at 14:57 +0530, Ankitprasad Sharma wrote:
> On Fri, 2016-06-10 at 09:40 +,
> intel-gfx-requ...@lists.freedesktop.org wrote:
> Hi,
> > == Series Details ==
> > 
> > Series: series starting with [1/5] drm/i915: Add support for mapping
> > an object page by page
> > URL   : https://patchwork.freedesktop.org/series/8528/
> > State : failure
> > 
> > == Summary ==
> > 
> > Series 8528v1 Series without cover letter
> > http://patchwork.freedesktop.org/api/1.0/series/8528/revisions/1/mbox
> > 
> > Test gem_exec_flush:
> > Subgroup basic-batch-kernel-default-cmd:
> > pass   -> FAIL   (ro-byt-n2820)
> > Test kms_flip:
> > Subgroup basic-flip-vs-wf_vblank:
> > fail   -> PASS   (ro-bdw-i7-5600u)
> > Test kms_pipe_crc_basic:
> > Subgroup suspend-read-crc-pipe-a:
> > skip   -> DMESG-WARN (ro-bdw-i5-5250u)
> > 
> > ro-bdw-i5-5250u  total:213  pass:197  dwarn:3   dfail:0   fail:0
> >  skip:13
> > ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0
> >  skip:28
> > ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2
> >  skip:39
> > ro-byt-n2820 total:213  pass:173  dwarn:0   dfail:0   fail:3
> >  skip:37
> > ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0
> >  skip:23
> > ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0
> >  skip:23
> > ro-ilk-i7-620lm  total:213  pass:150  dwarn:0   dfail:0   fail:1
> >  skip:62
> > ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1
> >  skip:57
> > ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0
> >  skip:32
> > ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0
> >  skip:28
> > ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1
> >  skip:38
> > fi-hsw-i7-4770k failed to connect after reboot
> > ro-bdw-i7-5557U failed to connect after reboot
> > 
> > Results at /archive/results/CI_IGT_test/RO_Patchwork_1156/
> > 
> > b373842 drm-intel-nightly: 2016y-06m-09d-16h-49m-09s UTC integration
> > manifest
> > 165ff1a drm/i915: Support for pread/pwrite from/to non shmem backed
> > objects
> > 7c4d2d9 drm/i915: Clearing buffer objects via CPU/GTT
> > 2c60c194 drm/i915: Use insert_page for pwrite_fast
> > 3f97215 drm/i915: Introduce i915_gem_object_get_dma_address()
> > fbba107 drm/i915: Add support for mapping an object page by page
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
Hi,

The failures seen are not introduced by the patches.
Following are the bug numbers related to the failures
https://bugs.freedesktop.org/show_bug.cgi?id=95372 -
igt/gem_exec_flush@basic-batch-kernel-default-cmd

https://bugs.freedesktop.org/show_bug.cgi?id=86365 -
igt/kms_pipe_crc_basic

Thanks,
Ankit
> > 
> > 
> > 
> 


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


Re: [Intel-gfx] [PATCH v3 06/33] drm: Minimally initialise drm_dp_aux

2016-06-10 Thread Chris Wilson
On Fri, Jun 10, 2016 at 01:26:24PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 09, 2016 at 09:57:24PM +0100, Chris Wilson wrote:
> > On Fri, Jun 03, 2016 at 05:59:11PM +0300, Ville Syrjälä wrote:
> > > On Fri, Jun 03, 2016 at 03:36:49PM +0100, Chris Wilson wrote:
> > > > When trying to split up the initialisation phase and the registration
> > > > phase, one immediate problem encountered is trying to use our own i2c
> > > > devices before registration with userspace (to read EDID during device
> > > > discovery). drm_dp_aux in particular only offers an interface for 
> > > > setting
> > > > up the device *after* we have exposed the connector via sysfs. In order
> > > > to break the chicken-and-egg problem, export drm_dp_aux_init() to
> > > > minimally prepare the i2c device for internal use before
> > > > drm_connector_register().
> > > > 
> > > > Signed-off-by: Chris Wilson 
> > > > Cc: Dave Airlie 
> > > > Cc: Rafael Antognolli 
> > > > Cc: Ville Syrjälä 
> > > > Cc: dri-de...@lists.freedesktop.org
> > > > ---
> > > >  drivers/gpu/drm/drm_dp_helper.c | 26 +-
> > > >  include/drm/drm_dp_helper.h |  1 +
> > > >  2 files changed, 22 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > > > b/drivers/gpu/drm/drm_dp_helper.c
> > > > index 4b088afa21b2..9b4ec65e1de6 100644
> > > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > > @@ -791,15 +791,16 @@ static void unlock_bus(struct i2c_adapter *i2c, 
> > > > unsigned int flags)
> > > >  }
> > > >  
> > > >  /**
> > > > - * drm_dp_aux_register() - initialise and register aux channel
> > > > + * drm_dp_aux_init() - minimally initialise an aux channel
> > > >   * @aux: DisplayPort AUX channel
> > > >   *
> > > > - * Returns 0 on success or a negative error code on failure.
> > > > + * If you need to use the drm_dp_aux's i2c adapter prior to 
> > > > registering it
> > > > + * with the outside world, call drm_dp_aux_init() first. You must still
> > > > + * call drm_dp_aux_register() once the connector has been registered to
> > > > + * allow userspace access to the auxiliary DP channel.
> > > >   */
> > > > -int drm_dp_aux_register(struct drm_dp_aux *aux)
> > > > +void drm_dp_aux_init(struct drm_dp_aux *aux)
> > > >  {
> > > > -   int ret;
> > > > -
> > > > mutex_init(>hw_mutex);
> > > >  
> > > > aux->ddc.algo = _dp_i2c_algo;
> > > > @@ -809,6 +810,21 @@ int drm_dp_aux_register(struct drm_dp_aux *aux)
> > > > aux->ddc.lock_bus = lock_bus;
> > > > aux->ddc.trylock_bus = trylock_bus;
> > > > aux->ddc.unlock_bus = unlock_bus;
> > > > +}
> > > > +EXPORT_SYMBOL(drm_dp_aux_init);
> > > 
> > > This doesn't feel very safe to me. To me it looks like the i2c core
> > > wasn't designed to have the adapter be used before i2c_add_adapter()
> > > is called. I guess it might work in this case since you provide your
> > > own lock vfuncs.
> > > 
> > > I think someone should fix the i2c core to split i2c_add_adapter()
> > > & co. into init and register phases. Cc:ing i2c folks...
> > 
> > As you've seen, I sent the patches to split i2c_add_adapter() to allow for
> > us to call i2c_init_adapter() here instead. It still requires the same
> > basic review that this init (the same as above) is sufficient for using
> > i2c_transfer().
> > 
> > I would like to get the regression fix completed without much futher
> > ado - in particular, not depending upon landing an external patch.
> 
> What regression is this?

It all started from the unclaimed mmio access across suspend, which
stems from never having touched a context before suspend. That in turn
meant touching the delayed rps initialisation which ended up with Daniel
saying that the entire init chain needs to be unravelled. Snowball.
-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 v3 06/33] drm: Minimally initialise drm_dp_aux

2016-06-10 Thread Ville Syrjälä
On Thu, Jun 09, 2016 at 09:57:24PM +0100, Chris Wilson wrote:
> On Fri, Jun 03, 2016 at 05:59:11PM +0300, Ville Syrjälä wrote:
> > On Fri, Jun 03, 2016 at 03:36:49PM +0100, Chris Wilson wrote:
> > > When trying to split up the initialisation phase and the registration
> > > phase, one immediate problem encountered is trying to use our own i2c
> > > devices before registration with userspace (to read EDID during device
> > > discovery). drm_dp_aux in particular only offers an interface for setting
> > > up the device *after* we have exposed the connector via sysfs. In order
> > > to break the chicken-and-egg problem, export drm_dp_aux_init() to
> > > minimally prepare the i2c device for internal use before
> > > drm_connector_register().
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Dave Airlie 
> > > Cc: Rafael Antognolli 
> > > Cc: Ville Syrjälä 
> > > Cc: dri-de...@lists.freedesktop.org
> > > ---
> > >  drivers/gpu/drm/drm_dp_helper.c | 26 +-
> > >  include/drm/drm_dp_helper.h |  1 +
> > >  2 files changed, 22 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index 4b088afa21b2..9b4ec65e1de6 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -791,15 +791,16 @@ static void unlock_bus(struct i2c_adapter *i2c, 
> > > unsigned int flags)
> > >  }
> > >  
> > >  /**
> > > - * drm_dp_aux_register() - initialise and register aux channel
> > > + * drm_dp_aux_init() - minimally initialise an aux channel
> > >   * @aux: DisplayPort AUX channel
> > >   *
> > > - * Returns 0 on success or a negative error code on failure.
> > > + * If you need to use the drm_dp_aux's i2c adapter prior to registering 
> > > it
> > > + * with the outside world, call drm_dp_aux_init() first. You must still
> > > + * call drm_dp_aux_register() once the connector has been registered to
> > > + * allow userspace access to the auxiliary DP channel.
> > >   */
> > > -int drm_dp_aux_register(struct drm_dp_aux *aux)
> > > +void drm_dp_aux_init(struct drm_dp_aux *aux)
> > >  {
> > > - int ret;
> > > -
> > >   mutex_init(>hw_mutex);
> > >  
> > >   aux->ddc.algo = _dp_i2c_algo;
> > > @@ -809,6 +810,21 @@ int drm_dp_aux_register(struct drm_dp_aux *aux)
> > >   aux->ddc.lock_bus = lock_bus;
> > >   aux->ddc.trylock_bus = trylock_bus;
> > >   aux->ddc.unlock_bus = unlock_bus;
> > > +}
> > > +EXPORT_SYMBOL(drm_dp_aux_init);
> > 
> > This doesn't feel very safe to me. To me it looks like the i2c core
> > wasn't designed to have the adapter be used before i2c_add_adapter()
> > is called. I guess it might work in this case since you provide your
> > own lock vfuncs.
> > 
> > I think someone should fix the i2c core to split i2c_add_adapter()
> > & co. into init and register phases. Cc:ing i2c folks...
> 
> As you've seen, I sent the patches to split i2c_add_adapter() to allow for
> us to call i2c_init_adapter() here instead. It still requires the same
> basic review that this init (the same as above) is sufficient for using
> i2c_transfer().
> 
> I would like to get the regression fix completed without much futher
> ado - in particular, not depending upon landing an external patch.

What regression is this?

-- 
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] Intel-gfx Digest, Vol 101, Issue 215

2016-06-10 Thread Ankitprasad Sharma
On Fri, 2016-06-10 at 09:40 +,
intel-gfx-requ...@lists.freedesktop.org wrote:
Hi,
> == Series Details ==
> 
> Series: series starting with [1/5] drm/i915: Add support for mapping
> an object page by page
> URL   : https://patchwork.freedesktop.org/series/8528/
> State : failure
> 
> == Summary ==
> 
> Series 8528v1 Series without cover letter
> http://patchwork.freedesktop.org/api/1.0/series/8528/revisions/1/mbox
> 
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-cmd:
> pass   -> FAIL   (ro-byt-n2820)
> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> fail   -> PASS   (ro-bdw-i7-5600u)
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-a:
> skip   -> DMESG-WARN (ro-bdw-i5-5250u)
> 
> ro-bdw-i5-5250u  total:213  pass:197  dwarn:3   dfail:0   fail:0
>  skip:13
> ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0
>  skip:28
> ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2
>  skip:39
> ro-byt-n2820 total:213  pass:173  dwarn:0   dfail:0   fail:3
>  skip:37
> ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0
>  skip:23
> ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0
>  skip:23
> ro-ilk-i7-620lm  total:213  pass:150  dwarn:0   dfail:0   fail:1
>  skip:62
> ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1
>  skip:57
> ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0
>  skip:32
> ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0
>  skip:28
> ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1
>  skip:38
> fi-hsw-i7-4770k failed to connect after reboot
> ro-bdw-i7-5557U failed to connect after reboot
> 
> Results at /archive/results/CI_IGT_test/RO_Patchwork_1156/
> 
> b373842 drm-intel-nightly: 2016y-06m-09d-16h-49m-09s UTC integration
> manifest
> 165ff1a drm/i915: Support for pread/pwrite from/to non shmem backed
> objects
> 7c4d2d9 drm/i915: Clearing buffer objects via CPU/GTT
> 2c60c194 drm/i915: Use insert_page for pwrite_fast
> 3f97215 drm/i915: Introduce i915_gem_object_get_dma_address()
> fbba107 drm/i915: Add support for mapping an object page by page
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
Hi Tvrtko,

These issues does not seem to be related to the patches

Thanks,
Ankit
> 
> 
> 


___
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: Crop cursor image for CHV pipe C cursor issue

2016-06-10 Thread Agrawal, Akshu

On 6/8/2016 2:10 PM, Daniel Vetter wrote:

On Wed, Jun 08, 2016 at 01:57:44PM +0530, Akshu Agrawal wrote:

CHV pipe C hits underrun when we get -ve X values of cursor. To avoid
this we crop the cursor image for by -ve X value and thus use '0' as
least X value.


You're talking about "-ve" here and there's absolutely no "-ve" anywhere
in your patch. That makes your commit message non-understandable.


Will change -ve to "negative" for better readability.



But I think I get what you're doing here, and nope, you can't override the
cursor image like that. If we go with this w/a then you need to allocate a
new cursor gem bo instead. This is userspace-visible.


Can't we use the same gem bo? As we are calling 
"i915_gem_object_set_to_gtt_domain" to get write access for CPU after 
unbinding from GTT.


Regards,
Akshu


For similar reasons you're also not allowed to change crtc->state.
-Daniel


Signed-off-by: Akshu Agrawal 
---
 drivers/gpu/drm/i915/intel_display.c | 113 +++
 drivers/gpu/drm/i915/intel_drv.h |   3 +
 2 files changed, 116 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bca9245..e6e6568 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14279,6 +14279,81 @@ void intel_create_rotation_property(struct drm_device 
*dev, struct intel_plane *
plane->base.state->rotation);
 }

+static void vlv_unpin_buffer_obj(struct drm_i915_gem_object *obj,
+ char __iomem *buffer_start)
+{
+   iounmap(buffer_start);
+   i915_gem_object_ggtt_unpin(obj);
+}
+
+static char __iomem *vlv_pin_and_map_buffer_obj
+   (struct drm_i915_gem_object *obj)
+{
+   struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
+   char __iomem *buffer_start;
+   int ret;
+
+   ret = i915_gem_obj_ggtt_pin(obj, PAGE_SIZE, PIN_MAPPABLE);
+   if (ret)
+   return NULL;
+
+   ret = i915_gem_object_set_to_gtt_domain(obj, true);
+   if (ret) {
+   i915_gem_object_ggtt_unpin(obj);
+   return NULL;
+   }
+
+   buffer_start = ioremap_wc(dev_priv->gtt.mappable_base +
+   i915_gem_obj_ggtt_offset(obj), obj->base.size);
+   if (buffer_start == NULL) {
+   i915_gem_object_ggtt_unpin(obj);
+   return NULL;
+   }
+
+   return buffer_start;
+}
+
+static int vlv_cursor_crop(struct intel_plane_state *state,
+ int prev_x)
+{
+   struct drm_i915_gem_object *obj = intel_fb_obj(state->base.fb);
+   struct drm_framebuffer *fb = state->base.fb;
+   char __iomem *buffer = state->vlv_cursor_image;
+   char __iomem *base, *cursor_base;
+   int size = obj->base.size;
+   int i, x = state->base.crtc_x;
+   int bytes_per_pixel = fb->bits_per_pixel / 8;
+
+   base = vlv_pin_and_map_buffer_obj(obj);
+   if (base == NULL)
+   return -ENOMEM;
+
+   if (prev_x >= 0) {
+   if (buffer != NULL)
+   kfree(buffer);
+   buffer = kzalloc(size, GFP_KERNEL);
+   state->vlv_cursor_image = buffer;
+   if (buffer == NULL)
+   return -ENOMEM;
+   memcpy(buffer, base, size);
+   }
+   cursor_base = buffer;
+   x = -x;
+   for (i = 0; i < state->base.crtc_h; i++) {
+   cursor_base += x * bytes_per_pixel;
+   memcpy(base, cursor_base,
+   (state->base.crtc_w - x) * bytes_per_pixel);
+   base += (state->base.crtc_w - x) * bytes_per_pixel;
+   memset(base, 0, x * bytes_per_pixel);
+   base += x * bytes_per_pixel;
+   cursor_base += (state->base.crtc_w - x) * bytes_per_pixel;
+   }
+
+   vlv_unpin_buffer_obj(obj, base);
+
+   return 0;
+}
+
 static int
 intel_check_cursor_plane(struct drm_plane *plane,
 struct intel_crtc_state *crtc_state,
@@ -14287,8 +14362,10 @@ intel_check_cursor_plane(struct drm_plane *plane,
struct drm_crtc *crtc = crtc_state->base.crtc;
struct drm_framebuffer *fb = state->base.fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+   enum pipe pipe = to_intel_plane(plane)->pipe;
unsigned stride;
int ret;
+   int crtc_prev_x = state->vlv_cursor_prev_x;

ret = drm_plane_helper_check_update(plane, crtc, fb, >src,
>dst, >clip,
@@ -14309,6 +14386,32 @@ intel_check_cursor_plane(struct drm_plane *plane,
return -EINVAL;
}

+   /*
+* There is an issue in CHV PIPE C where we hit underrun on
+* -ve value of cursor. To avoid this we are cropping the
+*  image for all PIPE C -ve values.
+*/
+   if 

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/5] drm/i915: Add support for mapping an object page by page

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

Series: series starting with [1/5] drm/i915: Add support for mapping an object 
page by page
URL   : https://patchwork.freedesktop.org/series/8528/
State : failure

== Summary ==

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

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
pass   -> FAIL   (ro-byt-n2820)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (ro-bdw-i7-5600u)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
skip   -> DMESG-WARN (ro-bdw-i5-5250u)

ro-bdw-i5-5250u  total:213  pass:197  dwarn:3   dfail:0   fail:0   skip:13 
ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:213  pass:173  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:213  pass:150  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38 
fi-hsw-i7-4770k failed to connect after reboot
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1156/

b373842 drm-intel-nightly: 2016y-06m-09d-16h-49m-09s UTC integration manifest
165ff1a drm/i915: Support for pread/pwrite from/to non shmem backed objects
7c4d2d9 drm/i915: Clearing buffer objects via CPU/GTT
2c60c194 drm/i915: Use insert_page for pwrite_fast
3f97215 drm/i915: Introduce i915_gem_object_get_dma_address()
fbba107 drm/i915: Add support for mapping an object page by page

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


[Intel-gfx] [PATCH 5/5] drm/i915: Support for pread/pwrite from/to non shmem backed objects

2016-06-10 Thread ankitprasad . r . sharma
From: Ankitprasad Sharma 

This patch adds support for extending the pread/pwrite functionality
for objects not backed by shmem. The access will be made through
gtt interface. This will cover objects backed by stolen memory as well
as other non-shmem backed objects.

v2: Drop locks around slow_user_access, prefault the pages before
access (Chris)

v3: Rebased to the latest drm-intel-nightly (Ankit)

v4: Moved page base & offset calculations outside the copy loop,
corrected data types for size and offset variables, corrected if-else
braces format (Tvrtko/kerneldocs)

v5: Enabled pread/pwrite for all non-shmem backed objects including
without tiling restrictions (Ankit)

v6: Using pwrite_fast for non-shmem backed objects as well (Chris)

v7: Updated commit message, Renamed i915_gem_gtt_read to i915_gem_gtt_copy,
added pwrite slow path for non-shmem backed objects (Chris/Tvrtko)

v8: Updated v7 commit message, mutex unlock around pwrite slow path for
non-shmem backed objects (Tvrtko)

v9: Corrected check during pread_ioctl, to avoid shmem_pread being
called for non-shmem backed objects (Tvrtko)

v10: Moved the write_domain check to needs_clflush and tiling mode check
to pwrite_fast (Chris)

v11: Use pwrite_fast fallback for all objects (shmem and non-shmem backed),
call fast_user_write regardless of pagefault in previous iteration

v12: Use page-by-page copy for slow user access too (Chris)

v13: Handled EFAULT, Avoid use of WARN_ON, put_fence only if whole obj
pinned (Chris)

v14: Corrected datatypes/initializations (Tvrtko)

Testcase: igt/gem_stolen, igt/gem_pread, igt/gem_pwrite

Signed-off-by: Ankitprasad Sharma 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 218 ++--
 1 file changed, 188 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d658d46..1777202 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -54,6 +54,9 @@ static bool cpu_cache_is_coherent(struct drm_device *dev,
 
 static bool cpu_write_needs_clflush(struct drm_i915_gem_object *obj)
 {
+   if (obj->base.write_domain == I915_GEM_DOMAIN_CPU)
+   return false;
+
if (!cpu_cache_is_coherent(obj->base.dev, obj->cache_level))
return true;
 
@@ -606,6 +609,142 @@ shmem_pread_slow(struct page *page, int 
shmem_page_offset, int page_length,
return ret ? - EFAULT : 0;
 }
 
+static inline unsigned long
+slow_user_access(struct io_mapping *mapping,
+uint64_t page_base, int page_offset,
+char __user *user_data,
+unsigned long length, bool pwrite)
+{
+   void __iomem *ioaddr;
+   void *vaddr;
+   uint64_t unwritten;
+
+   ioaddr = io_mapping_map_wc(mapping, page_base, PAGE_SIZE);
+   /* We can use the cpu mem copy function because this is X86. */
+   vaddr = (void __force *)ioaddr + page_offset;
+   if (pwrite)
+   unwritten = __copy_from_user(vaddr, user_data, length);
+   else
+   unwritten = __copy_to_user(user_data, vaddr, length);
+
+   io_mapping_unmap(ioaddr);
+   return unwritten;
+}
+
+static int
+i915_gem_gtt_pread(struct drm_device *dev,
+  struct drm_i915_gem_object *obj, uint64_t size,
+  uint64_t data_offset, uint64_t data_ptr)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct i915_ggtt *ggtt = _priv->ggtt;
+   struct drm_mm_node node;
+   char __user *user_data;
+   uint64_t remain;
+   uint64_t offset;
+   int ret;
+
+   ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE);
+   if (ret) {
+   ret = insert_mappable_node(dev_priv, , PAGE_SIZE);
+   if (ret)
+   goto out;
+
+   ret = i915_gem_object_get_pages(obj);
+   if (ret) {
+   remove_mappable_node();
+   goto out;
+   }
+
+   i915_gem_object_pin_pages(obj);
+   } else {
+   node.start = i915_gem_obj_ggtt_offset(obj);
+   node.allocated = false;
+   ret = i915_gem_object_put_fence(obj);
+   if (ret)
+   goto out_unpin;
+   }
+
+   ret = i915_gem_object_set_to_gtt_domain(obj, false);
+   if (ret)
+   goto out_unpin;
+
+   user_data = u64_to_user_ptr(data_ptr);
+   remain = size;
+   offset = data_offset;
+
+   mutex_unlock(>struct_mutex);
+   if (likely(!i915.prefault_disable)) {
+   ret = fault_in_multipages_writeable(user_data, remain);
+   if (ret) {
+   mutex_lock(>struct_mutex);
+   goto out_unpin;
+   }
+   }
+
+   while (remain > 0) {
+   /* Operation in 

[Intel-gfx] [PATCH 4/5] drm/i915: Clearing buffer objects via CPU/GTT

2016-06-10 Thread ankitprasad . r . sharma
From: Ankitprasad Sharma 

This patch adds support for clearing buffer objects via CPU/GTT. This
is particularly useful for clearing out the non shmem backed objects.
Currently intend to use this only for buffers allocated from stolen
region.

v2: Added kernel doc for i915_gem_clear_object(), corrected/removed
variable assignments (Tvrtko)

v3: Map object page by page to the gtt if the pinning of the whole object
to the ggtt fails, Corrected function name (Chris)

v4: Clear the buffer page by page, and not map the whole object in the gtt
aperture. Use i915 wrapper function in place of drm_mm_insert_node_in_range.

v5: Use renamed wrapper function for drm_mm_insert_node_in_range,
updated barrier positioning (Chris)

v6: Use PAGE_SIZE instead of 4096, use get_pages call before pinning pages
(Tvrtko)

v7: Fixed the onion (undo operation in reverse order) (Chris)

v8: Rebase (Ankit)

Testcase: igt/gem_stolen

Signed-off-by: Ankitprasad Sharma 
Reviewed-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 45 +
 2 files changed, 46 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0349c5f..e72e6af 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3109,6 +3109,7 @@ int i915_gem_obj_prepare_shmem_read(struct 
drm_i915_gem_object *obj,
int *needs_clflush);
 
 int __must_check i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
+int i915_gem_object_clear(struct drm_i915_gem_object *obj);
 
 static inline int __sg_page_count(struct scatterlist *sg)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 452178c..d658d46 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5418,3 +5418,48 @@ fail:
drm_gem_object_unreference(>base);
return ERR_PTR(ret);
 }
+
+/**
+ * i915_gem_object_clear() - Clear buffer object via CPU/GTT
+ * @obj: Buffer object to be cleared
+ *
+ * Return: 0 - success, non-zero - failure
+ */
+int i915_gem_object_clear(struct drm_i915_gem_object *obj)
+{
+   struct drm_i915_private *i915 = to_i915(obj->base.dev);
+   struct i915_ggtt *ggtt = >ggtt;
+   struct drm_mm_node node;
+   char __iomem *base;
+   uint64_t size = obj->base.size;
+   int ret, i;
+
+   lockdep_assert_held(>base.dev->struct_mutex);
+   ret = insert_mappable_node(i915, , PAGE_SIZE);
+   if (ret)
+   return ret;
+
+   ret = i915_gem_object_get_pages(obj);
+   if (ret)
+   goto err_remove_node;
+
+   i915_gem_object_pin_pages(obj);
+   base = io_mapping_map_wc(ggtt->mappable, node.start, PAGE_SIZE);
+
+   for (i = 0; i < size/PAGE_SIZE; i++) {
+   ggtt->base.insert_page(>base,
+  i915_gem_object_get_dma_address(obj, i),
+  node.start, I915_CACHE_NONE, 0);
+   wmb(); /* flush modifications to the GGTT (insert_page) */
+   memset_io(base, 0, PAGE_SIZE);
+   wmb(); /* flush the write before we modify the GGTT */
+   }
+
+   io_mapping_unmap(base);
+   ggtt->base.clear_range(>base, node.start, node.size, true);
+   i915_gem_object_unpin_pages(obj);
+
+err_remove_node:
+   remove_mappable_node();
+   return ret;
+}
-- 
1.9.1

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


[Intel-gfx] [PATCH 2/5] drm/i915: Introduce i915_gem_object_get_dma_address()

2016-06-10 Thread ankitprasad . r . sharma
From: Chris Wilson 

This utility function is a companion to i915_gem_object_get_page() that
uses the same cached iterator for the scatterlist to perform fast
sequential lookup of the dma address associated with any page within the
object.

Signed-off-by: Chris Wilson 
Signed-off-by: Ankitprasad Sharma 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 53d9e3f..0349c5f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3118,6 +3118,23 @@ static inline int __sg_page_count(struct scatterlist *sg)
 struct page *
 i915_gem_object_get_dirty_page(struct drm_i915_gem_object *obj, int n);
 
+static inline dma_addr_t
+i915_gem_object_get_dma_address(struct drm_i915_gem_object *obj, int n)
+{
+   if (n < obj->get_page.last) {
+   obj->get_page.sg = obj->pages->sgl;
+   obj->get_page.last = 0;
+   }
+
+   while (obj->get_page.last + __sg_page_count(obj->get_page.sg) <= n) {
+   obj->get_page.last += __sg_page_count(obj->get_page.sg++);
+   if (unlikely(sg_is_chain(obj->get_page.sg)))
+   obj->get_page.sg = sg_chain_ptr(obj->get_page.sg);
+   }
+
+   return sg_dma_address(obj->get_page.sg) + ((n - obj->get_page.last) << 
PAGE_SHIFT);
+}
+
 static inline struct page *
 i915_gem_object_get_page(struct drm_i915_gem_object *obj, int n)
 {
-- 
1.9.1

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


[Intel-gfx] [PATCH 1/5] drm/i915: Add support for mapping an object page by page

2016-06-10 Thread ankitprasad . r . sharma
From: Chris Wilson 

Introduced a new vm specfic callback insert_page() to program a single pte in
ggtt or ppgtt. This allows us to map a single page in to the mappable aperture
space. This can be iterated over to access the whole object by using space as
meagre as page size.

v2: Added low level rpm assertions to insert_page routines (Chris)

v3: Added POSTING_READ post register write (Tvrtko)

v4: Rebase (Ankit)

v5: Removed wmb() and FLUSH_CTL from insert_page, caller to take care
of it (Chris)

v6: insert_page not working correctly without FLSH_CNTL write, added the
write again.

Signed-off-by: Chris Wilson 
Signed-off-by: Ankitprasad Sharma 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/char/agp/intel-gtt.c|  8 +
 drivers/gpu/drm/i915/i915_gem_gtt.c | 66 -
 drivers/gpu/drm/i915/i915_gem_gtt.h |  5 +++
 include/drm/intel-gtt.h |  3 ++
 4 files changed, 81 insertions(+), 1 deletion(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index aef87fd..4431129 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -840,6 +840,14 @@ static bool i830_check_flags(unsigned int flags)
return false;
 }
 
+void intel_gtt_insert_page(dma_addr_t addr,
+  unsigned int pg,
+  unsigned int flags)
+{
+   intel_private.driver->write_entry(addr, pg, flags);
+}
+EXPORT_SYMBOL(intel_gtt_insert_page);
+
 void intel_gtt_insert_sg_entries(struct sg_table *st,
 unsigned int pg_start,
 unsigned int flags)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4668477..7a139a6 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2355,6 +2355,28 @@ static void gen8_set_pte(void __iomem *addr, gen8_pte_t 
pte)
 #endif
 }
 
+static void gen8_ggtt_insert_page(struct i915_address_space *vm,
+ dma_addr_t addr,
+ uint64_t offset,
+ enum i915_cache_level level,
+ u32 unused)
+{
+   struct drm_i915_private *dev_priv = to_i915(vm->dev);
+   gen8_pte_t __iomem *pte =
+   (gen8_pte_t __iomem *)dev_priv->ggtt.gsm +
+   (offset >> PAGE_SHIFT);
+   int rpm_atomic_seq;
+
+   rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
+
+   gen8_set_pte(pte, gen8_pte_encode(addr, level, true));
+
+   I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+   POSTING_READ(GFX_FLSH_CNTL_GEN6);
+
+   assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
+}
+
 static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
 struct sg_table *st,
 uint64_t start,
@@ -2424,6 +2446,28 @@ static void gen8_ggtt_insert_entries__BKL(struct 
i915_address_space *vm,
stop_machine(gen8_ggtt_insert_entries__cb, , NULL);
 }
 
+static void gen6_ggtt_insert_page(struct i915_address_space *vm,
+ dma_addr_t addr,
+ uint64_t offset,
+ enum i915_cache_level level,
+ u32 flags)
+{
+   struct drm_i915_private *dev_priv = to_i915(vm->dev);
+   gen6_pte_t __iomem *pte =
+   (gen6_pte_t __iomem *)dev_priv->ggtt.gsm +
+   (offset >> PAGE_SHIFT);
+   int rpm_atomic_seq;
+
+   rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
+
+   iowrite32(vm->pte_encode(addr, level, true, flags), pte);
+
+   I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+   POSTING_READ(GFX_FLSH_CNTL_GEN6);
+
+   assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
+}
+
 /*
  * Binds an object into the global gtt with the specified cache level. The 
object
  * will be accessible to the GPU via commands whose operands reference offsets
@@ -2543,6 +2587,24 @@ static void gen6_ggtt_clear_range(struct 
i915_address_space *vm,
assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
 }
 
+static void i915_ggtt_insert_page(struct i915_address_space *vm,
+ dma_addr_t addr,
+ uint64_t offset,
+ enum i915_cache_level cache_level,
+ u32 unused)
+{
+   struct drm_i915_private *dev_priv = to_i915(vm->dev);
+   unsigned int flags = (cache_level == I915_CACHE_NONE) ?
+   AGP_USER_MEMORY : AGP_USER_CACHED_MEMORY;
+   int rpm_atomic_seq;
+
+   rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
+
+   intel_gtt_insert_page(addr, offset >> PAGE_SHIFT, flags);
+
+   assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
+}
+
 

[Intel-gfx] [PATCH 3/5] drm/i915: Use insert_page for pwrite_fast

2016-06-10 Thread ankitprasad . r . sharma
From: Ankitprasad Sharma 

In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First,
we try a nonblocking pin for the whole object (since that is fastest if
reused), then failing that we try to grab one page in the mappable
aperture. It also allows us to handle objects larger than the mappable
aperture (e.g. if we need to pwrite with vGPU restricting the aperture
to a measely 8MiB or something like that).

v2: Pin pages before starting pwrite, Combined duplicate loops (Chris)

v3: Combined loops based on local patch by Chris (Chris)

v4: Added i915 wrapper function for drm_mm_insert_node_in_range (Chris)

v5: Renamed wrapper function for drm_mm_insert_node_in_range (Chris)

v5: Added wrapper for drm_mm_remove_node() (Chris)

v6: Added get_pages call before pinning the pages (Tvrtko)
Added remove_mappable_node() wrapper for drm_mm_remove_node() (Chris)

v7: Added size argument for insert_mappable_node (Tvrtko)

v8: Do not put_pages after pwrite, do memset of node in the wrapper
function (insert_mappable_node) (Chris)

v9: Rebase (Ankit)

Signed-off-by: Ankitprasad Sharma 
Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 90 +++--
 1 file changed, 68 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index eae8d7a..452178c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -60,6 +60,24 @@ static bool cpu_write_needs_clflush(struct 
drm_i915_gem_object *obj)
return obj->pin_display;
 }
 
+static int
+insert_mappable_node(struct drm_i915_private *i915,
+ struct drm_mm_node *node, u32 size)
+{
+   memset(node, 0, sizeof(*node));
+   return drm_mm_insert_node_in_range_generic(>ggtt.base.mm, node,
+  size, 0, 0, 0,
+  i915->ggtt.mappable_end,
+  DRM_MM_SEARCH_DEFAULT,
+  DRM_MM_CREATE_DEFAULT);
+}
+
+static void
+remove_mappable_node(struct drm_mm_node *node)
+{
+   drm_mm_remove_node(node);
+}
+
 /* some bookkeeping */
 static void i915_gem_info_add_obj(struct drm_i915_private *dev_priv,
  size_t size)
@@ -765,21 +783,34 @@ fast_user_write(struct io_mapping *mapping,
  * @file: drm file pointer
  */
 static int
-i915_gem_gtt_pwrite_fast(struct drm_device *dev,
+i915_gem_gtt_pwrite_fast(struct drm_i915_private *i915,
 struct drm_i915_gem_object *obj,
 struct drm_i915_gem_pwrite *args,
 struct drm_file *file)
 {
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct i915_ggtt *ggtt = _priv->ggtt;
-   ssize_t remain;
-   loff_t offset, page_base;
+   struct i915_ggtt *ggtt = >ggtt;
+   struct drm_mm_node node;
+   uint64_t remain, offset;
char __user *user_data;
-   int page_offset, page_length, ret;
+   int ret;
 
ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE | PIN_NONBLOCK);
-   if (ret)
-   goto out;
+   if (ret) {
+   ret = insert_mappable_node(i915, , PAGE_SIZE);
+   if (ret)
+   goto out;
+
+   ret = i915_gem_object_get_pages(obj);
+   if (ret) {
+   remove_mappable_node();
+   goto out;
+   }
+
+   i915_gem_object_pin_pages(obj);
+   } else {
+   node.start = i915_gem_obj_ggtt_offset(obj);
+   node.allocated = false;
+   }
 
ret = i915_gem_object_set_to_gtt_domain(obj, true);
if (ret)
@@ -789,26 +820,32 @@ i915_gem_gtt_pwrite_fast(struct drm_device *dev,
if (ret)
goto out_unpin;
 
-   user_data = u64_to_user_ptr(args->data_ptr);
-   remain = args->size;
-
-   offset = i915_gem_obj_ggtt_offset(obj) + args->offset;
-
intel_fb_obj_invalidate(obj, ORIGIN_GTT);
+   obj->dirty = true;
 
-   while (remain > 0) {
+   user_data = u64_to_user_ptr(args->data_ptr);
+   offset = args->offset;
+   remain = args->size;
+   while (remain) {
/* Operation in this page
 *
 * page_base = page offset within aperture
 * page_offset = offset within page
 * page_length = bytes to copy for this page
 */
-   page_base = offset & PAGE_MASK;
-   page_offset = offset_in_page(offset);
-   page_length = remain;
-   if ((page_offset + remain) > PAGE_SIZE)
-   page_length = PAGE_SIZE - page_offset;
-
+   u32 

Re: [Intel-gfx] [PATCH v2] drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate

2016-06-10 Thread Gore, Tim


Tim Gore 
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ


> -Original Message-
> From: Arun Siluvery [mailto:arun.siluv...@linux.intel.com]
> Sent: Friday, June 10, 2016 9:38 AM
> To: Gore, Tim; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH v2] drm/i915/gen9: implement
> WaConextSwitchWithConcurrentTLBInvalidate
> 
> On 10/06/2016 12:16, Gore, Tim wrote:
> >
> >
> > Tim Gore
> > Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon
> > SN3 1RJ
> >
> >
> >> -Original Message-
> >> From: Arun Siluvery [mailto:arun.siluv...@linux.intel.com]
> >> Sent: Friday, June 10, 2016 7:30 AM
> >> To: Gore, Tim; intel-gfx@lists.freedesktop.org
> >> Subject: Re: [PATCH v2] drm/i915/gen9: implement
> >> WaConextSwitchWithConcurrentTLBInvalidate
> >>
> >> On 09/06/2016 20:19, tim.g...@intel.com wrote:
> >>> From: Tim Gore 
> >>>
> >>> This patch enables a workaround for a mid thread preemption issue
> >>> where a hardware timing problem can prevent the context restore from
> >>> happening, leading to a hang.
> >>>
> >>> v2: move to gen9_init_workarounds (Arun)
> >>>
> >>> Signed-off-by: Tim Gore 
> >>> ---
> >>>drivers/gpu/drm/i915/i915_reg.h | 4 
> >>>drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
> >>>2 files changed, 7 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >>> b/drivers/gpu/drm/i915/i915_reg.h index 81d1896..2a6fc62 100644
> >>> --- a/drivers/gpu/drm/i915/i915_reg.h
> >>> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >>> @@ -1810,6 +1810,10 @@ enum skl_disp_power_wells {
> >>>#define   GEN9_IZ_HASHING_MASK(slice)  (0x3
> <<
> >> ((slice) * 2))
> >>>#define   GEN9_IZ_HASHING(slice, val)  ((val) <<
> >> ((slice) * 2))
> >>>
> >>> +/* chicken reg for WaConextSwitchWithConcurrentTLBInvalidate */
> >>> +#define GEN9_CSFE_CHICKEN1_RCS _MMIO(0x20D4)
> >>> +#define   GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE (1 << 2)
> >>> +
> >>>/* WaClearTdlStateAckDirtyBits */
> >>>#define GEN8_STATE_ACK _MMIO(0x20F0)
> >>>#define GEN9_STATE_ACK_SLICE1  _MMIO(0x20F8)
> >>> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> >>> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >>> index cf8d0bf..7c756ac 100644
> >>> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> >>> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >>> @@ -1022,6 +1022,9 @@ static int gen9_init_workarounds(struct
> >> intel_engine_cs *engine)
> >>>   if (ret)
> >>>   return ret;
> >>>
> >>> + /* WaConextSwitchWithConcurrentTLBInvalidate:skl,bxt,kbl */
> >>> + I915_WRITE(GEN9_CSFE_CHICKEN1_RCS,
> >>>
> >>
> +_MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE)
> >> );
> >>> +
> >> WA_SET_BIT_MASKED(GEN9_CSFE_CHICKEN1_RCS,
> >> GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE);
> >>
> >> Please correct the spelling.
> >> We should try to keep WA regs in some order although it is not true
> >> for some of the existing ones but we should try to follow this rule
> >> for the new ones; HW whitelist registers are normally kept at the end.
> >> I think the correct place for this one is at the beginning of this
> >> function to maintain increasing order.
> >>
> >> regards
> >> Arun
> >>
> >>
> > Which spelling do you want corrected?
> 
> WaConextSwitchWithConcurrentTLBInvalidate - two occurrences.
> 
> regards
> Arun
> 
As per my previous replies to Jani and you, 
WaConextSwitchWithConcurrentTLBInvalidate
is copied directly from the documentation (bug report etc) and also from another
implementation of this workaround. Actually, to be precise the spec has
"WAConextSwitchWithConcurrentTLBInvalidate" (capitalised WA), but the bug report
and other implementation use "WaConextSwitchWithConcurrentTLBInvalidate".
I am not really comfortable with using a different spelling here, even if it is 
"correct".
Seems like it could lead to confusion or at least trip up some script.

  Tim
> >
> >Tim
> >>>   return 0;
> >>>}
> >>>
> >>>
> >
> >

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


Re: [Intel-gfx] [PATCH 0/3] SKL watermark fixes for !fbcon

2016-06-10 Thread Tvrtko Ursulin


Hi,

On 09/06/16 23:14, Matt Roper wrote:

There are a handful of watermark bugs that are only triggered (or more easily
triggered) when running without fbcon.  Thanks Tvrtko for pointing these out.

I do still see some WARN()'s from other parts of the display code when
launching X in a non-fbcon setup, so there may be other bugfixes needed in
other parts of the code as well.

Cc: Tvrtko Ursulin 

Matt Roper (3):
   drm/i915/gen9: Initialize intel_state->active_crtcs during WM
 sanitization
   drm/i915/gen9: Compute data rates for all planes on first commit
   drm/i915/gen9: Drop invalid WARN() during data rate calculation

  drivers/gpu/drm/i915/intel_pm.c | 25 ++---
  1 file changed, 22 insertions(+), 3 deletions(-)


Thanks Matt, this fixes the issue on my SKL!

For the series,

Tested-by: Tvrtko Ursulin 

Regards,

Tvrtko

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


Re: [Intel-gfx] [PATCH v2] drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate

2016-06-10 Thread Arun Siluvery

On 10/06/2016 12:16, Gore, Tim wrote:



Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ



-Original Message-
From: Arun Siluvery [mailto:arun.siluv...@linux.intel.com]
Sent: Friday, June 10, 2016 7:30 AM
To: Gore, Tim; intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/i915/gen9: implement
WaConextSwitchWithConcurrentTLBInvalidate

On 09/06/2016 20:19, tim.g...@intel.com wrote:

From: Tim Gore 

This patch enables a workaround for a mid thread preemption issue
where a hardware timing problem can prevent the context restore from
happening, leading to a hang.

v2: move to gen9_init_workarounds (Arun)

Signed-off-by: Tim Gore 
---
   drivers/gpu/drm/i915/i915_reg.h | 4 
   drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
   2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h index 81d1896..2a6fc62 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1810,6 +1810,10 @@ enum skl_disp_power_wells {
   #define   GEN9_IZ_HASHING_MASK(slice)(0x3 <<

((slice) * 2))

   #define   GEN9_IZ_HASHING(slice, val)((val) <<

((slice) * 2))


+/* chicken reg for WaConextSwitchWithConcurrentTLBInvalidate */
+#define GEN9_CSFE_CHICKEN1_RCS _MMIO(0x20D4)
+#define   GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE (1 << 2)
+
   /* WaClearTdlStateAckDirtyBits */
   #define GEN8_STATE_ACK   _MMIO(0x20F0)
   #define GEN9_STATE_ACK_SLICE1_MMIO(0x20F8)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index cf8d0bf..7c756ac 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1022,6 +1022,9 @@ static int gen9_init_workarounds(struct

intel_engine_cs *engine)

if (ret)
return ret;

+   /* WaConextSwitchWithConcurrentTLBInvalidate:skl,bxt,kbl */
+   I915_WRITE(GEN9_CSFE_CHICKEN1_RCS,


+_MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE)
);

+

WA_SET_BIT_MASKED(GEN9_CSFE_CHICKEN1_RCS,
GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE);

Please correct the spelling.
We should try to keep WA regs in some order although it is not true for some
of the existing ones but we should try to follow this rule for the new ones;
HW whitelist registers are normally kept at the end.
I think the correct place for this one is at the beginning of this function to
maintain increasing order.

regards
Arun



Which spelling do you want corrected?


WaConextSwitchWithConcurrentTLBInvalidate - two occurrences.

regards
Arun



   Tim

return 0;
   }







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


Re: [Intel-gfx] [PATCH 0/3] SKL watermark fixes for !fbcon

2016-06-10 Thread Jani Nikula
On Fri, 10 Jun 2016, Matt Roper  wrote:
> There are a handful of watermark bugs that are only triggered (or more easily
> triggered) when running without fbcon.  Thanks Tvrtko for pointing these out.
>
> I do still see some WARN()'s from other parts of the display code when
> launching X in a non-fbcon setup, so there may be other bugfixes needed in
> other parts of the code as well.

Should some or all of these be cc: stable?

BR,
Jani.

>
> Cc: Tvrtko Ursulin 
>
> Matt Roper (3):
>   drm/i915/gen9: Initialize intel_state->active_crtcs during WM
> sanitization
>   drm/i915/gen9: Compute data rates for all planes on first commit
>   drm/i915/gen9: Drop invalid WARN() during data rate calculation
>
>  drivers/gpu/drm/i915/intel_pm.c | 25 ++---
>  1 file changed, 22 insertions(+), 3 deletions(-)

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


Re: [Intel-gfx] [PATCH v2] drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate

2016-06-10 Thread Gore, Tim


Tim Gore 
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ


> -Original Message-
> From: Arun Siluvery [mailto:arun.siluv...@linux.intel.com]
> Sent: Friday, June 10, 2016 7:30 AM
> To: Gore, Tim; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH v2] drm/i915/gen9: implement
> WaConextSwitchWithConcurrentTLBInvalidate
> 
> On 09/06/2016 20:19, tim.g...@intel.com wrote:
> > From: Tim Gore 
> >
> > This patch enables a workaround for a mid thread preemption issue
> > where a hardware timing problem can prevent the context restore from
> > happening, leading to a hang.
> >
> > v2: move to gen9_init_workarounds (Arun)
> >
> > Signed-off-by: Tim Gore 
> > ---
> >   drivers/gpu/drm/i915/i915_reg.h | 4 
> >   drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
> >   2 files changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index 81d1896..2a6fc62 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1810,6 +1810,10 @@ enum skl_disp_power_wells {
> >   #define   GEN9_IZ_HASHING_MASK(slice) (0x3 <<
> ((slice) * 2))
> >   #define   GEN9_IZ_HASHING(slice, val) ((val) <<
> ((slice) * 2))
> >
> > +/* chicken reg for WaConextSwitchWithConcurrentTLBInvalidate */
> > +#define GEN9_CSFE_CHICKEN1_RCS _MMIO(0x20D4)
> > +#define   GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE (1 << 2)
> > +
> >   /* WaClearTdlStateAckDirtyBits */
> >   #define GEN8_STATE_ACK_MMIO(0x20F0)
> >   #define GEN9_STATE_ACK_SLICE1 _MMIO(0x20F8)
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index cf8d0bf..7c756ac 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -1022,6 +1022,9 @@ static int gen9_init_workarounds(struct
> intel_engine_cs *engine)
> > if (ret)
> > return ret;
> >
> > +   /* WaConextSwitchWithConcurrentTLBInvalidate:skl,bxt,kbl */
> > +   I915_WRITE(GEN9_CSFE_CHICKEN1_RCS,
> >
> +_MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE)
> );
> > +
> WA_SET_BIT_MASKED(GEN9_CSFE_CHICKEN1_RCS,
> GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE);
> 
> Please correct the spelling.
> We should try to keep WA regs in some order although it is not true for some
> of the existing ones but we should try to follow this rule for the new ones;
> HW whitelist registers are normally kept at the end.
> I think the correct place for this one is at the beginning of this function to
> maintain increasing order.
> 
> regards
> Arun
> 
> 
Which spelling do you want corrected?

  Tim
> > return 0;
> >   }
> >
> >

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


Re: [Intel-gfx] [PATCH] i915/fbc: Disable on HSW by default for now

2016-06-10 Thread Stefan Richter
On Jun 09 Zanoni, Paulo R wrote:
> Em Qui, 2016-06-09 às 11:58 -0400, Lyude escreveu:
> > From https://bugs.freedesktop.org/show_bug.cgi?id=96461 :
> > 
> > This was kind of a difficult bug to track down. If you're using a
> > Haswell system running GNOME and you have fbc completely enabled and
> > working, playing videos can result in video artifacts.
[...]
> > For the time being, disable FBC for Haswell by default.  
> 
> In case we want to improve the commit message:
> 
> We also got reports from Steven Honeyman on openbox+roxterm, and from
> Stefan Richter.

Perhaps also worth mentioning in the changelog:
Stefan Richter reported kernel freezes (no video artifacts) when fbc is on.
(E3-1245 v3 with HD P4600; openbox and some KDE and LXDE applications,
thread begins at https://lkml.org/lkml/2016/4/26/813)
-- 
Stefan Richter
-==- -==- -=-=-
http://arcgraph.de/sr/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for Introduce the implementation of GVT context (rev8)

2016-06-10 Thread Wang, Zhi A
The failed test case is related to the following bug:
https://bugs.freedesktop.org/show_bug.cgi?id=95372

> -Original Message-
> From: Patchwork [mailto:patchw...@emeril.freedesktop.org]
> Sent: Friday, June 10, 2016 8:32 AM
> To: Wang, Zhi A 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: ✗ Ro.CI.BAT: failure for Introduce the implementation of GVT context
> (rev8)
> 
> == Series Details ==
> 
> Series: Introduce the implementation of GVT context (rev8)
> URL   : https://patchwork.freedesktop.org/series/7208/
> State : failure
> 
> == Summary ==
> 
> Series 7208v8 Introduce the implementation of GVT context
> http://patchwork.freedesktop.org/api/1.0/series/7208/revisions/8/mbox
> 
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-cmd:
> pass   -> FAIL   (ro-byt-n2820)
> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> fail   -> PASS   (ro-bdw-i7-5600u)
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-b:
> dmesg-warn -> SKIP   (ro-bdw-i5-5250u)
> 
> ro-bdw-i5-5250u  total:213  pass:197  dwarn:1   dfail:0   fail:0
> skip:15
> ro-bdw-i7-5557U  total:213  pass:197  dwarn:1   dfail:0   fail:0
> skip:15
> ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0
> skip:28
> ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2
> skip:39
> ro-byt-n2820 total:213  pass:173  dwarn:0   dfail:0   fail:3
> skip:37
> ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0
> skip:23
> ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23
> ro-ilk-i7-620lm  total:213  pass:150  dwarn:0   dfail:0   fail:1   skip:62
> ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57
> ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32
> ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28
> ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1
> skip:38
> fi-hsw-i7-4770k failed to connect after reboot
> 
> Results at /archive/results/CI_IGT_test/RO_Patchwork_1152/
> 
> b373842 drm-intel-nightly: 2016y-06m-09d-16h-49m-09s UTC integration
> manifest
> 49cc9a2 drm/i915: Introduce GVT context creation API
> 60b7103 drm/i915: Support LRC context single submission 99bf9fe drm/i915:
> Introduce execlist context status change notification 426bd8e drm/i915: Make
> addressing mode bits in context descriptor configurable
> 10f04f2 drm/i915: Make ring buffer size of a LRC context configurable
> 82be702 drm/i915: Introduce host graphics memory partition for GVT-g
> abfadd5 drm/i915: gvt: Introduce the basic architecture of GVT-g
> ae7b792 drm/i915: Fold vGPU active check into inner functions 3fb8c7b
> drm/i915: Use offsetof() to calculate the offset of members in PVINFO page
> 7810fd7 drm/i915: Factor out i915_pvinfo.h

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


Re: [Intel-gfx] [PATCH v2] drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate

2016-06-10 Thread Arun Siluvery

On 09/06/2016 20:19, tim.g...@intel.com wrote:

From: Tim Gore 

This patch enables a workaround for a mid thread preemption
issue where a hardware timing problem can prevent the
context restore from happening, leading to a hang.

v2: move to gen9_init_workarounds (Arun)

Signed-off-by: Tim Gore 
---
  drivers/gpu/drm/i915/i915_reg.h | 4 
  drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
  2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 81d1896..2a6fc62 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1810,6 +1810,10 @@ enum skl_disp_power_wells {
  #define   GEN9_IZ_HASHING_MASK(slice) (0x3 << ((slice) * 2))
  #define   GEN9_IZ_HASHING(slice, val) ((val) << ((slice) * 2))

+/* chicken reg for WaConextSwitchWithConcurrentTLBInvalidate */
+#define GEN9_CSFE_CHICKEN1_RCS _MMIO(0x20D4)
+#define   GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE (1 << 2)
+
  /* WaClearTdlStateAckDirtyBits */
  #define GEN8_STATE_ACK_MMIO(0x20F0)
  #define GEN9_STATE_ACK_SLICE1 _MMIO(0x20F8)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index cf8d0bf..7c756ac 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1022,6 +1022,9 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
if (ret)
return ret;

+   /* WaConextSwitchWithConcurrentTLBInvalidate:skl,bxt,kbl */
+   I915_WRITE(GEN9_CSFE_CHICKEN1_RCS, 
_MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE));
+
WA_SET_BIT_MASKED(GEN9_CSFE_CHICKEN1_RCS, 
GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE);


Please correct the spelling.
We should try to keep WA regs in some order although it is not true for 
some of the existing ones but we should try to follow this rule for the 
new ones; HW whitelist registers are normally kept at the end.
I think the correct place for this one is at the beginning of this 
function to maintain increasing order.


regards
Arun



return 0;
  }




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


[Intel-gfx] ✗ Ro.CI.BAT: failure for SKL watermark fixes for !fbcon

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

Series: SKL watermark fixes for !fbcon
URL   : https://patchwork.freedesktop.org/series/8513/
State : failure

== Summary ==

Series 8513v1 SKL watermark fixes for !fbcon
http://patchwork.freedesktop.org/api/1.0/series/8513/revisions/1/mbox

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
pass   -> FAIL   (ro-byt-n2820)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (ro-bdw-i7-5600u)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
skip   -> DMESG-WARN (ro-bdw-i5-5250u)

ro-bdw-i5-5250u  total:213  pass:197  dwarn:3   dfail:0   fail:0   skip:13 
ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:213  pass:173  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:177  pass:120  dwarn:2   dfail:2   fail:1   skip:51 
ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38 
fi-hsw-i7-4770k failed to connect after reboot
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1154/

b373842 drm-intel-nightly: 2016y-06m-09d-16h-49m-09s UTC integration manifest
7db1532 drm/i915/gen9: Drop invalid WARN() during data rate calculation
46946f4 drm/i915/gen9: Compute data rates for all planes on first commit
c90f98f drm/i915/gen9: Initialize intel_state->active_crtcs during WM 
sanitization

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