[Intel-gfx] [PATCH v2 0/9] drm/i915/dsi: improved gpio element support for vlv/chv/bxt

[Jani Nikula]

Next iteration after [1]. Plenty of changes around VLV macros and
tables. I wish I could get my hands on a CHV gpio table spec. BXT is
included.

BR,
Jani.


[1] http://mid.gmane.org/cover.1458226863.git.jani.nik...@intel.com

Jani Nikula (8):
  drm/i915/dsi: refer to gpio index instead of gpio to avoid confusion
  drm/i915/dsi: add support for DSI sequence block v2 gpio element
  drm/i915/dsi: clean up vlv gpio table and definitions
  drm/i915/dsi: add gpio indexes to the gpio table
  drm/i915/dsi: abstract VLV gpio element execution to a separate
function
  drm/i915/dsi: add support for sequence block v3 gpio for VLV
  drm/i915/chv: add more IOSF port definitions
  drm/i915/bxt: add bxt dsi gpio element support

Yogesh Mohan Marimuthu (1):
  drm/i915/dsi: add support for gpio elements on CHV

 drivers/gpu/drm/i915/i915_reg.h|   4 +
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 893 ++---
 2 files changed, 826 insertions(+), 71 deletions(-)

-- 
2.1.4

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

Re: [Intel-gfx] [PATCH 2/2] igt/gem_stolen: No support for stolen backed objects if Intel RST present

[Chris Wilson]

On Thu, Mar 17, 2016 at 11:52:50AM +0530, ankitprasad.r.sha...@intel.com wrote:
> From: Ankitprasad Sharma 
> 
> Skip gem_stolen and pread/pwrite on stolen backed objects if Intel
> RST device is present.

This has to be checking for kernel support of user stolen nothing else.
-Chris

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

[Intel-gfx] [PATCH 2/3] drm/i915/tdr: Prepare error handler to accept mask of hung engines

[Arun Siluvery]

In preparation for engine reset, the wedged argument of i915_handle_error()
is extended to reflect as a mask of engines that are hung. This is further
passed down to error state capture functions which are also updated.

Engine reset recovery mechanism uses this mask and schedules recovery work
for those particular engines.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Tomas Elf 
Signed-off-by: Arun Siluvery 
---
 drivers/gpu/drm/i915/i915_drv.h   |  4 ++--
 drivers/gpu/drm/i915/i915_gpu_error.c |  8 
 drivers/gpu/drm/i915/i915_irq.c   | 16 
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 549a232..49ac065 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2735,7 +2735,7 @@ bool intel_hpd_pin_to_port(enum hpd_pin pin, enum port 
*port);
 /* i915_irq.c */
 void i915_queue_hangcheck(struct drm_device *dev);
 __printf(3, 4)
-void i915_handle_error(struct drm_device *dev, bool wedged,
+void i915_handle_error(struct drm_device *dev, u32 engine_mask,
   const char *fmt, ...);
 
 extern void intel_irq_init(struct drm_i915_private *dev_priv);
@@ -3321,7 +3321,7 @@ static inline void i915_error_state_buf_release(
 {
kfree(eb->buf);
 }
-void i915_capture_error_state(struct drm_device *dev, bool wedge,
+void i915_capture_error_state(struct drm_device *dev, u32 engine_mask,
  const char *error_msg);
 void i915_error_state_get(struct drm_device *dev,
  struct i915_error_state_file_priv *error_priv);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index db8600a..1f8ff06 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1301,7 +1301,7 @@ static void i915_capture_reg_state(struct 
drm_i915_private *dev_priv,
 
 static void i915_error_capture_msg(struct drm_device *dev,
   struct drm_i915_error_state *error,
-  bool wedged,
+  u32 engine_mask,
   const char *error_msg)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -1324,7 +1324,7 @@ static void i915_error_capture_msg(struct drm_device *dev,
scnprintf(error->error_msg + len, sizeof(error->error_msg) - len,
  ", reason: %s, action: %s",
  error_msg,
- wedged ? "reset" : "continue");
+ engine_mask ? "reset" : "continue");
 }
 
 static void i915_capture_gen_state(struct drm_i915_private *dev_priv,
@@ -1347,7 +1347,7 @@ static void i915_capture_gen_state(struct 
drm_i915_private *dev_priv,
  * out a structure which becomes available in debugfs for user level tools
  * to pick up.
  */
-void i915_capture_error_state(struct drm_device *dev, bool wedged,
+void i915_capture_error_state(struct drm_device *dev, u32 engine_mask,
  const char *error_msg)
 {
static bool warned;
@@ -1375,7 +1375,7 @@ void i915_capture_error_state(struct drm_device *dev, 
bool wedged,
error->overlay = intel_overlay_capture_error_state(dev);
error->display = intel_display_capture_error_state(dev);
 
-   i915_error_capture_msg(dev, error, wedged, error_msg);
+   i915_error_capture_msg(dev, error, engine_mask, error_msg);
DRM_INFO("%s\n", error->error_msg);
 
spin_lock_irqsave(_priv->gpu_error.lock, flags);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8f3e330..a55a7cc 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2653,14 +2653,14 @@ static void i915_report_and_clear_eir(struct drm_device 
*dev)
 /**
  * i915_handle_error - handle a gpu error
  * @dev: drm device
- *
+ * @engine_mask: mask representing engines that are hung
  * Do some basic checking of register state at error time and
  * dump it to the syslog.  Also call i915_capture_error_state() to make
  * sure we get a record and make it available in debugfs.  Fire a uevent
  * so userspace knows something bad happened (should trigger collection
  * of a ring dump etc.).
  */
-void i915_handle_error(struct drm_device *dev, bool wedged,
+void i915_handle_error(struct drm_device *dev, u32 engine_mask,
   const char *fmt, ...)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -2671,10 +2671,10 @@ void i915_handle_error(struct drm_device *dev, bool 
wedged,
vscnprintf(error_msg, sizeof(error_msg), fmt, args);
va_end(args);
 
-   i915_capture_error_state(dev, wedged, error_msg);
+   i915_capture_error_state(dev, engine_mask, error_msg);
i915_report_and_clear_eir(dev);
 
-   if 

[Intel-gfx] [PATCH v3 07/19] drm/i915: Move load time gem_load_init earlier

[Imre Deak]

The only steps requiring device access is the fence and swizzling
initialization, so split these out keeping them in their current place
and move the rest of init steps earlier.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_dma.c | 13 -
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 34 --
 3 files changed, 29 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index da96ccd..9ada500 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1031,6 +1031,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
intel_init_display_hooks(dev_priv);
intel_init_clock_gating_hooks(dev_priv);
intel_init_audio_hooks(dev_priv);
+   i915_gem_load_init(dev);
 
intel_runtime_pm_get(dev_priv);
 
@@ -1114,7 +1115,9 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
 
intel_opregion_setup(dev);
 
-   i915_gem_load_init(dev);
+   i915_gem_load_init_fences(dev_priv);
+   i915_gem_detect_bit_6_swizzle(dev);
+
i915_gem_shrinker_init(dev_priv);
 
/* On the 945G/GM, the chipset reports the MSI capability on the
@@ -1136,7 +1139,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
if (INTEL_INFO(dev)->num_pipes) {
ret = drm_vblank_init(dev, INTEL_INFO(dev)->num_pipes);
if (ret)
-   goto out_gem_unload;
+   goto out_cleanup_shrinker;
}
 
ret = i915_load_modeset_init(dev);
@@ -1174,7 +1177,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
 out_power_well:
intel_power_domains_fini(dev_priv);
drm_vblank_cleanup(dev);
-out_gem_unload:
+out_cleanup_shrinker:
i915_gem_shrinker_cleanup(dev_priv);
 
if (dev->pdev->msi_enabled)
@@ -1190,9 +1193,9 @@ out_uncore_fini:
i915_mmio_cleanup(dev);
 put_bridge:
pci_dev_put(dev_priv->bridge_dev);
-   i915_gem_load_cleanup(dev);
 out_runtime_pm_put:
intel_runtime_pm_put(dev_priv);
+   i915_gem_load_cleanup(dev);
i915_workqueues_cleanup(dev_priv);
 out_free_priv:
kfree(dev_priv);
@@ -1277,8 +1280,8 @@ int i915_driver_unload(struct drm_device *dev)
intel_uncore_fini(dev);
i915_mmio_cleanup(dev);
 
-   i915_gem_load_cleanup(dev);
pci_dev_put(dev_priv->bridge_dev);
+   i915_gem_load_cleanup(dev);
i915_workqueues_cleanup(dev_priv);
kfree(dev_priv);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 80b14f1..25274e1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2836,6 +2836,7 @@ int i915_gem_wait_ioctl(struct drm_device *dev, void 
*data,
struct drm_file *file_priv);
 void i915_gem_load_init(struct drm_device *dev);
 void i915_gem_load_cleanup(struct drm_device *dev);
+void i915_gem_load_init_fences(struct drm_i915_private *dev_priv);
 void *i915_gem_object_alloc(struct drm_device *dev);
 void i915_gem_object_free(struct drm_i915_gem_object *obj);
 void i915_gem_object_init(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b854af2..3dab0d6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5029,6 +5029,26 @@ init_ring_lists(struct intel_engine_cs *ring)
 }
 
 void
+i915_gem_load_init_fences(struct drm_i915_private *dev_priv)
+{
+   if (INTEL_INFO(dev_priv)->gen >= 7 && !IS_VALLEYVIEW(dev_priv) &&
+   !IS_CHERRYVIEW(dev_priv))
+   dev_priv->num_fence_regs = 32;
+   else if (INTEL_INFO(dev_priv)->gen >= 4 || IS_I945G(dev_priv) ||
+IS_I945GM(dev_priv) || IS_G33(dev_priv))
+   dev_priv->num_fence_regs = 16;
+   else
+   dev_priv->num_fence_regs = 8;
+
+   if (intel_vgpu_active(dev_priv->dev))
+   dev_priv->num_fence_regs =
+   I915_READ(vgtif_reg(avail_rs.fence_num));
+
+   /* Initialize fence registers to zero */
+   i915_gem_restore_fences(dev_priv->dev);
+}
+
+void
 i915_gem_load_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -5067,17 +5087,6 @@ i915_gem_load_init(struct drm_device *dev)
 
dev_priv->relative_constants_mode = I915_EXEC_CONSTANTS_REL_GENERAL;
 
-   if (INTEL_INFO(dev)->gen >= 7 && !IS_VALLEYVIEW(dev) && 
!IS_CHERRYVIEW(dev))
-   dev_priv->num_fence_regs = 32;
-   else if (INTEL_INFO(dev)->gen >= 4 || IS_I945G(dev) || IS_I945GM(dev) 
|| IS_G33(dev))
-   dev_priv->num_fence_regs = 16;
-   else
-   dev_priv->num_fence_regs = 8;
-
-   if (intel_vgpu_active(dev))
-   dev_priv->num_fence_regs =
-   

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: add another virtual PCH bridge for passthrough support

[Jesse Barnes]

On 03/17/2016 05:31 AM, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: add another virtual PCH bridge for passthrough support
> URL   : https://patchwork.freedesktop.org/series/4539/
> State : warning
> 
> == Summary ==
> 
> Series 4539v1 drm/i915: add another virtual PCH bridge for passthrough support
> http://patchwork.freedesktop.org/api/1.0/series/4539/revisions/1/mbox/
> 
> Test drv_module_reload_basic:
> dmesg-warn -> PASS   (hsw-gt2)
> Test gem_ringfill:
> Subgroup basic-default-s3:
> dmesg-warn -> PASS   (bsw-nuc-2)
> Test kms_flip:
> Subgroup basic-flip-vs-dpms:
> dmesg-warn -> PASS   (bdw-ultra)
> Subgroup basic-flip-vs-wf_vblank:
> fail   -> PASS   (snb-x220t)
> Subgroup basic-plain-flip:
> pass   -> DMESG-WARN (hsw-gt2)
> dmesg-warn -> PASS   (hsw-brixbox)
> Test kms_pipe_crc_basic:
> Subgroup read-crc-pipe-b-frame-sequence:
> dmesg-warn -> PASS   (snb-x220t)
> Subgroup read-crc-pipe-c-frame-sequence:
> dmesg-warn -> PASS   (hsw-gt2)
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> fail   -> DMESG-FAIL (snb-x220t)
> pass   -> DMESG-WARN (hsw-brixbox)
> Subgroup basic-rte:
> dmesg-warn -> PASS   (hsw-brixbox)
> 
> bdw-nuci7total:194  pass:182  dwarn:0   dfail:0   fail:0   skip:12 
> bdw-ultratotal:194  pass:173  dwarn:0   dfail:0   fail:0   skip:21 
> bsw-nuc-2total:194  pass:157  dwarn:0   dfail:0   fail:0   skip:37 
> byt-nuc  total:194  pass:155  dwarn:4   dfail:0   fail:0   skip:35 
> hsw-brixbox  total:194  pass:171  dwarn:1   dfail:0   fail:0   skip:22 
> hsw-gt2  total:194  pass:176  dwarn:1   dfail:0   fail:0   skip:17 
> ivb-t430stotal:194  pass:169  dwarn:0   dfail:0   fail:0   skip:25 
> skl-i5k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
> skl-i7k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
> skl-nuci5total:194  pass:183  dwarn:0   dfail:0   fail:0   skip:11 
> snb-x220ttotal:194  pass:160  dwarn:0   dfail:1   fail:0   skip:33 

Well some how this trivial patch only affecting passthrough environments
fixed a bunch of issues but broke D3. :)

I think all of these are still intermittent issues, so this patch is
still ok for merge.

Jesse

___
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/gtt: Reference mappable_end variable from pointer

[Chris Wilson]

On Fri, Mar 18, 2016 at 09:53:08AM +0200, Joonas Lahtinen wrote:
> Reference variable value from pointer, not assumed pointer destination.
> 
> Since:
> 
> commit c44ef60e437019b8ca1dab8b4d2e8761fd4ce1e9
> Author: Mika Kuoppala 
> Date:   Thu Jun 25 18:35:05 2015 +0300
> 
> drm/i915/gtt: Allow >= 4GB sizes for vm.
> 
> Cc: Mika Kuoppala 
> Signed-off-by: Joonas Lahtinen 

Reviewed-by: Chris Wilson 

That reminds, could you pull

https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=breadcrumbs=8ecc77b5864d4911e9fb9b92be8b2e98c3f2261f
[drm/i915: Codify our assumption that the Global GTT is <= 4GiB]

into this series?
-Chris

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

[Intel-gfx] [PATCH 2/6] drm/i915: Allow passing any known pointer to for_each_engine()

[Chris Wilson]

Rather than require the user to grab a drm_i915_private, allow them to
pass anything that we know how to derive such a pointer user to_i915()

Note this fixes a macro bug in for_each_engine_masked() which was not
using its dev_priv__ parameter.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.h | 8 
 drivers/gpu/drm/i915/i915_gem_context.c | 4 ++--
 drivers/gpu/drm/i915/intel_mocs.c   | 3 +--
 3 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8606e2c7db04..0c9fe00d3e83 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1988,12 +1988,12 @@ static inline struct drm_i915_private 
*guc_to_i915(struct intel_guc *guc)
 }
 
 /* Iterate over initialised rings */
-#define for_each_engine(ring__, dev_priv__, i__) \
+#define for_each_engine(ring__, ptr__, i__) \
for ((i__) = 0; (i__) < I915_NUM_ENGINES; (i__)++) \
-   for_each_if ring__) = &(dev_priv__)->engine[(i__)]), 
intel_engine_initialized((ring__
+   for_each_if ring__) = _i915(ptr__)->engine[(i__)]), 
intel_engine_initialized((ring__
 
-#define for_each_engine_masked(engine__, dev_priv__, mask__) \
-   for ((engine__) = _priv->engine[0]; (engine__) < 
_priv->engine[I915_NUM_ENGINES]; (engine__)++) \
+#define for_each_engine_masked(engine__, ptr__, mask__) \
+   for ((engine__) = _i915(ptr__)->engine[0]; (engine__) < 
_i915(ptr__)->engine[I915_NUM_ENGINES]; (engine__)++) \
for_each_if (intel_engine_flag((engine__)) & (mask__) && 
intel_engine_initialized((engine__)))
 
 enum hdmi_force_audio {
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 394e525e55f1..a8afd0cee7f7 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -553,7 +553,7 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
hw_flags)
 
intel_ring_emit(engine,
MI_LOAD_REGISTER_IMM(num_rings));
-   for_each_engine(signaller, to_i915(engine->dev), i) {
+   for_each_engine(signaller, engine->dev, i) {
if (signaller == engine)
continue;
 
@@ -582,7 +582,7 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
hw_flags)
 
intel_ring_emit(engine,
MI_LOAD_REGISTER_IMM(num_rings));
-   for_each_engine(signaller, to_i915(engine->dev), i) {
+   for_each_engine(signaller, engine->dev, i) {
if (signaller == engine)
continue;
 
diff --git a/drivers/gpu/drm/i915/intel_mocs.c 
b/drivers/gpu/drm/i915/intel_mocs.c
index 3c725dde16ed..45200b93e9bb 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -323,12 +323,11 @@ int intel_rcs_context_init_mocs(struct 
drm_i915_gem_request *req)
int ret;
 
if (get_mocs_settings(req->engine->dev, )) {
-   struct drm_i915_private *dev_priv = req->i915;
struct intel_engine_cs *engine;
enum intel_engine_id ring_id;
 
/* Program the control registers */
-   for_each_engine(engine, dev_priv, ring_id) {
+   for_each_engine(engine, req->i915, ring_id) {
ret = emit_mocs_control_table(req, , ring_id);
if (ret)
return ret;
-- 
2.8.0.rc3

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

[Intel-gfx] [PATCH 3/4] drm/i915: Rename local struct intel_ringbuffer variables

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Majority of the code calls these ringbuf so fix up a few
places which use something else to be consistent.

Coccinelle script of:

@@
expression E;
identifier r;
@@
- struct intel_ringbuffer *r = E;
+ struct intel_ringbuffer *ringbuf = E;
<+...
- r
+ ringbuf
...+>
@@
identifier r;
@@
- struct intel_ringbuffer *r;
+ struct intel_ringbuffer *ringbuf;
<+...
- r
+ ringbuf
...+>

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c |  8 
 drivers/gpu/drm/i915/intel_lrc.c|  3 ++-
 drivers/gpu/drm/i915/intel_mocs.c   | 11 +++
 drivers/gpu/drm/i915/intel_ringbuffer.c | 28 ++--
 4 files changed, 27 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 042cb412e652..4a0f9bd87c34 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2821,7 +2821,7 @@ static void i915_gem_reset_engine_status(struct 
drm_i915_private *dev_priv,
 static void i915_gem_reset_engine_cleanup(struct drm_i915_private *dev_priv,
struct intel_engine_cs *engine)
 {
-   struct intel_ringbuffer *buffer;
+   struct intel_ringbuffer *ringbuf;
 
while (!list_empty(>active_list)) {
struct drm_i915_gem_object *obj;
@@ -2874,9 +2874,9 @@ static void i915_gem_reset_engine_cleanup(struct 
drm_i915_private *dev_priv,
 * upon reset is less than when we start. Do one more pass over
 * all the ringbuffers to reset last_retired_head.
 */
-   list_for_each_entry(buffer, >buffers, link) {
-   buffer->last_retired_head = buffer->tail;
-   intel_ring_update_space(buffer);
+   list_for_each_entry(ringbuf, >buffers, link) {
+   ringbuf->last_retired_head = ringbuf->tail;
+   intel_ring_update_space(ringbuf);
}
 }
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 7c636b3db156..bc3183e1c0af 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1001,7 +1001,8 @@ int intel_execlists_submission(struct 
i915_execbuffer_params *params,
intel_logical_ring_emit(ringbuf, MI_NOOP);
intel_logical_ring_emit(ringbuf, MI_LOAD_REGISTER_IMM(1));
intel_logical_ring_emit_reg(ringbuf, INSTPM);
-   intel_logical_ring_emit(ringbuf, instp_mask << 16 | instp_mode);
+   intel_logical_ring_emit(ringbuf,
+   instp_mask << 16 | instp_mode);
intel_logical_ring_advance(ringbuf);
 
dev_priv->relative_constants_mode = instp_mode;
diff --git a/drivers/gpu/drm/i915/intel_mocs.c 
b/drivers/gpu/drm/i915/intel_mocs.c
index 3c725dde16ed..8ef7e2b29d71 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -210,7 +210,8 @@ static int emit_mocs_control_table(struct 
drm_i915_gem_request *req,
MI_LOAD_REGISTER_IMM(GEN9_NUM_MOCS_ENTRIES));
 
for (index = 0; index < table->size; index++) {
-   intel_logical_ring_emit_reg(ringbuf, mocs_register(ring, 
index));
+   intel_logical_ring_emit_reg(ringbuf,
+   mocs_register(ring, index));
intel_logical_ring_emit(ringbuf,
table->table[index].control_value);
}
@@ -224,8 +225,10 @@ static int emit_mocs_control_table(struct 
drm_i915_gem_request *req,
 * that value to all the used entries.
 */
for (; index < GEN9_NUM_MOCS_ENTRIES; index++) {
-   intel_logical_ring_emit_reg(ringbuf, mocs_register(ring, 
index));
-   intel_logical_ring_emit(ringbuf, table->table[0].control_value);
+   intel_logical_ring_emit_reg(ringbuf,
+   mocs_register(ring, index));
+   intel_logical_ring_emit(ringbuf,
+   table->table[0].control_value);
}
 
intel_logical_ring_emit(ringbuf, MI_NOOP);
@@ -266,7 +269,7 @@ static int emit_mocs_l3cc_table(struct drm_i915_gem_request 
*req,
}
 
intel_logical_ring_emit(ringbuf,
-   MI_LOAD_REGISTER_IMM(GEN9_NUM_MOCS_ENTRIES / 2));
+   MI_LOAD_REGISTER_IMM(GEN9_NUM_MOCS_ENTRIES / 
2));
 
for (i = 0, count = 0; i < table->size / 2; i++, count += 2) {
value = (table->table[count].l3cc_value & 0x) |
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index b7c8fc1a73a3..a78a8fae4780 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2177,41 +2177,41 @@ static int intel_alloc_ringbuffer_obj(struct drm_device 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs (rev3)

[Tomi Sarvela]

On Thursday 17 March 2016 18:00:52 Takashi Iwai wrote:
...

> > CI_DRM_1147 git://anongit.freedesktop.org/drm-intel
> > dbbc6d276864d7b7a3a1edb04f0511153f9c3852
> > 
> > Note that drm-intel-nightly history changes, so the exact commits might
> > not be there any more.
> 
> Well, I have no internal access, so I have no idea which one succeeded
> and which one failed.
> 
> Unfortunately I can't reproduce it in my side.  A simpler unit test
> that can reliably reproduce the issue would be really appreciated...

Sorry, I was being unclear. They all fail on selected machines (ILK, SNB), 
since CI_DRM_1140.

The unit tests that hang quite reliably on first run are
igt@gem_ringfill_basic-default-s3
igt@drv_module_reload_basic
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-[abc]

Tomi


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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs (rev3)

[Daniel Vetter]

On Wed, Mar 16, 2016 at 4:50 PM, Jani Nikula
 wrote:
> On Wed, 16 Mar 2016, Daniel Vetter  wrote:
>> [ text/plain ]
>> On Wed, Mar 16, 2016 at 02:37:24PM +0200, Tomi Sarvela wrote:
>>> On Wednesday 16 March 2016 10:48:43 Imre Deak wrote:
>>> > Tomi, noticed two things that maybe infrastructure related, see below:
>>> >
>>> > > Test drv_module_reload_basic:
>>> > > skip   -> PASS   (bdw-nuci7)
>>> > > Test gem_ringfill:
>>> > > Subgroup basic-default-s3:
>>> > > pass   -> DMESG-WARN (skl-nuci5)
>>> > > Test gem_storedw_loop:
>>> > > Subgroup basic-bsd:
>>> > > pass   -> DMESG-WARN (skl-nuci5)
>>> > > Subgroup basic-bsd1:
>>> > > pass   -> DMESG-WARN (skl-nuci5)
>>> >
>>> > Unrelated platform. All of the above are SND resume failures. Ville
>>> > said he contacted Takashi about them.
>>>
>>> SND is recurring problem. I'd like to see drm-intel-nightly not breaking 
>>> when
>>> pulling sound updates.
>>
>> We need to escalate this again, snd team seriously sucks at quality
>> control :( Adding Libin If this doesn't improve I need to throw
>> sound trees out of -nightly for real.
>
> With that, we'd get more stable CI, but we'd also only see the failures
> once the sound trees get merged upstream. We don't want that either.
>
> One idea would be to have separate CI runs for updating trees not in our
> control. But we're pretty far from making that happen.

Yes agreed, it would probably not help a lot at all to drop sound
trees, we'd simply notice a bit later. I'm not sure what would be the
best option here, just expressing maintainer grumpiness ;-) Good ideas
very much welcome ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit

[dw kim]

This error doesn't seem to be related to this specific patch.
Similar issue was already filed in Bugzilla a week ago at

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

On Wed, Mar 16, 2016 at 11:58:28AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit
> URL   : https://patchwork.freedesktop.org/series/4491/
> State : failure
> 
> == Summary ==
> 
> Series 4491v1 drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit
> http://patchwork.freedesktop.org/api/1.0/series/4491/revisions/1/mbox/
> 
> Test gem_mmap_gtt:
> Subgroup basic-small-copy:
> dmesg-warn -> PASS   (bsw-nuc-2)
> pass   -> DMESG-WARN (skl-nuci5)
> Test gem_ringfill:
> Subgroup basic-default-s3:
> dmesg-warn -> PASS   (skl-i5k-2)
> pass   -> DMESG-WARN (skl-nuci5)
> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> pass   -> FAIL   (snb-x220t)
> dmesg-warn -> PASS   (hsw-brixbox)
> Test kms_pipe_crc_basic:
> Subgroup read-crc-pipe-a:
> dmesg-warn -> PASS   (bdw-nuci7)
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> dmesg-warn -> PASS   (bsw-nuc-2)
> pass   -> DMESG-WARN (hsw-brixbox)
> 
> bdw-nuci7total:194  pass:182  dwarn:0   dfail:0   fail:0   skip:12 
> bdw-ultratotal:194  pass:173  dwarn:0   dfail:0   fail:0   skip:21 
> bsw-nuc-2total:194  pass:157  dwarn:0   dfail:0   fail:0   skip:37 
> byt-nuc  total:194  pass:155  dwarn:4   dfail:0   fail:0   skip:35 
> hsw-brixbox  total:194  pass:171  dwarn:1   dfail:0   fail:0   skip:22 
> hsw-gt2  total:194  pass:177  dwarn:0   dfail:0   fail:0   skip:17 
> ivb-t430stotal:194  pass:169  dwarn:0   dfail:0   fail:0   skip:25 
> skl-i5k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
> skl-i7k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
> skl-nuci5total:194  pass:181  dwarn:2   dfail:0   fail:0   skip:11 
> snb-x220ttotal:194  pass:158  dwarn:1   dfail:0   fail:2   skip:33 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_1611/
> 
> 9f8709ffd099e85e5e116ed7d09f1b8009f40847 drm-intel-nightly: 
> 2016y-03m-16d-10h-30m-26s UTC integration manifest
> a5aa41667c7524d0df92320530f11dc283c6c95e drm/i915/bxt: Reversed polarity of 
> PORT_PLL_REF_SEL bit
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] mm/vmap: Add a notifier for when we run out of vmap address space

[Chris Wilson]

On Thu, Mar 17, 2016 at 02:21:40PM +0100, Roman Peniaev wrote:
> On Thu, Mar 17, 2016 at 1:57 PM, Chris Wilson  
> wrote:
> > On Thu, Mar 17, 2016 at 01:37:06PM +0100, Roman Peniaev wrote:
> >> > +   freed = 0;
> >> > +   blocking_notifier_call_chain(_notify_list, 0, );
> >>
> >> It seems to me that alloc_vmap_area() was designed not to sleep,
> >> at least on GFP_NOWAIT path (__GFP_DIRECT_RECLAIM is not set).
> >>
> >> But blocking_notifier_call_chain() might sleep.
> >
> > Indeed, I had not anticipated anybody using GFP_ATOMIC or equivalently
> > restrictive gfp_t for vmap and yes there are such callers.
> >
> > Would guarding the notifier with gfp & __GFP_DIRECT_RECLAIM and
> > !(gfp & __GFP_NORETRY) == be sufficient? Is that enough for GFP_NOFS?
> 
> I would use gfpflags_allow_blocking() for that purpose.

Thanks,
-Chris

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

[Intel-gfx] [PATCH 5/8] drm/i915/dsi: clean up the VLV gpio table and definitions

[Jani Nikula]

Add some VLV prefixes, remove redundant initialization, etc. No
functional changes.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 60 +++---
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 82047eefd3e1..3c6275f85ae2 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -58,39 +58,39 @@ static inline struct vbt_panel *to_vbt_panel(struct 
drm_panel *panel)
 
 #define NS_KHZ_RATIO 100
 
-#define GPI0_NC_0_HV_DDI0_HPD   0x4130
-#define GPIO_NC_1_HV_DDI0_DDC_SDA   0x4120
-#define GPIO_NC_2_HV_DDI0_DDC_SCL   0x4110
-#define GPIO_NC_3_PANEL0_VDDEN  0x4140
-#define GPIO_NC_4_PANEL0_BLKEN  0x4150
-#define GPIO_NC_5_PANEL0_BLKCTL 0x4160
-#define GPIO_NC_6_PCONF00x4180
-#define GPIO_NC_7_PCONF00x4190
-#define GPIO_NC_8_PCONF00x4170
-#define GPIO_NC_9_PCONF00x4100
-#define GPIO_NC_10_PCONF0   0x40E0
-#define GPIO_NC_11_PCONF0   0x40F0
+#define VLV_GPIO_NC_0_HV_DDI0_HPD  0x4130
+#define VLV_GPIO_NC_1_HV_DDI0_DDC_SDA  0x4120
+#define VLV_GPIO_NC_2_HV_DDI0_DDC_SCL  0x4110
+#define VLV_GPIO_NC_3_PANEL0_VDDEN 0x4140
+#define VLV_GPIO_NC_4_PANEL0_BLKEN 0x4150
+#define VLV_GPIO_NC_5_PANEL0_BLKCTL0x4160
+#define VLV_GPIO_NC_6_PCONF0   0x4180
+#define VLV_GPIO_NC_7_PCONF0   0x4190
+#define VLV_GPIO_NC_8_PCONF0   0x4170
+#define VLV_GPIO_NC_9_PCONF0   0x4100
+#define VLV_GPIO_NC_10_PCONF0  0x40E0
+#define VLV_GPIO_NC_11_PCONF0  0x40F0
 
 #define VLV_FUNCTION_TO_PAD_REG(reg) ((reg) + 8)
 
 struct gpio_table {
u16 function_reg;
-   u8 init;
+   bool init;
 };
 
-static struct gpio_table gtable[] = {
-   { GPI0_NC_0_HV_DDI0_HPD, 0 },
-   { GPIO_NC_1_HV_DDI0_DDC_SDA, 0 },
-   { GPIO_NC_2_HV_DDI0_DDC_SCL, 0 },
-   { GPIO_NC_3_PANEL0_VDDEN, 0 },
-   { GPIO_NC_4_PANEL0_BLKEN, 0 },
-   { GPIO_NC_5_PANEL0_BLKCTL, 0 },
-   { GPIO_NC_6_PCONF0, 0 },
-   { GPIO_NC_7_PCONF0, 0 },
-   { GPIO_NC_8_PCONF0, 0 },
-   { GPIO_NC_9_PCONF0, 0 },
-   { GPIO_NC_10_PCONF0, 0},
-   { GPIO_NC_11_PCONF0, 0}
+static struct gpio_table vlv_gpio_table[] = {
+   { VLV_GPIO_NC_0_HV_DDI0_HPD },
+   { VLV_GPIO_NC_1_HV_DDI0_DDC_SDA },
+   { VLV_GPIO_NC_2_HV_DDI0_DDC_SCL },
+   { VLV_GPIO_NC_3_PANEL0_VDDEN },
+   { VLV_GPIO_NC_4_PANEL0_BLKEN },
+   { VLV_GPIO_NC_5_PANEL0_BLKCTL },
+   { VLV_GPIO_NC_6_PCONF0 },
+   { VLV_GPIO_NC_7_PCONF0 },
+   { VLV_GPIO_NC_8_PCONF0 },
+   { VLV_GPIO_NC_9_PCONF0 },
+   { VLV_GPIO_NC_10_PCONF0 },
+   { VLV_GPIO_NC_11_PCONF0 },
 };
 
 static inline enum port intel_dsi_seq_port_to_port(u8 port)
@@ -192,7 +192,7 @@ static void vlv_exec_gpio(struct drm_i915_private *dev_priv,
u16 function, pad;
u8 port;
 
-   if (gpio_index >= ARRAY_SIZE(gtable)) {
+   if (gpio_index >= ARRAY_SIZE(vlv_gpio_table)) {
DRM_DEBUG_KMS("unknown gpio %u\n", gpio_index);
return;
}
@@ -213,15 +213,15 @@ static void vlv_exec_gpio(struct drm_i915_private 
*dev_priv,
port = IOSF_PORT_GPIO_NC;
}
 
-   function = gtable[gpio_index].function_reg;
+   function = vlv_gpio_table[gpio_index].function_reg;
pad = VLV_FUNCTION_TO_PAD_REG(function);
 
mutex_lock(_priv->sb_lock);
-   if (!gtable[gpio_index].init) {
+   if (!vlv_gpio_table[gpio_index].init) {
/* program the function */
/* FIXME: remove constant below */
vlv_iosf_sb_write(dev_priv, port, function, 0x2000CC00);
-   gtable[gpio_index].init = 1;
+   vlv_gpio_table[gpio_index].init = true;
}
 
val = 0x4 | action;
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH 14/21] drm/i915: Use fb modifiers for display tiling decisions

[Matthew Auld]

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Drop locking/rpm resume/flush_delayed_work for cur/min/max freq sysfs read

[Imre Deak]

On Fri, 2016-03-04 at 21:43 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> cur_freq, min/max_freq_softlimit, efficient_freq are just single
> values
> stored under dev_priv.rps, so there's no real point in locking,
> resuming
> the devices and flushing the delayed resume work just to print them
> out.
> 
> Signed-off-by: Ville Syrjälä 

This makes things clearer, so would it make sense to still keep the
flush wq and leave out patch 4 until somebody benchmarks things? That
would address Tom's concern as well.

> ---
>  drivers/gpu/drm/i915/i915_sysfs.c | 84 ++---
> --
>  1 file changed, 13 insertions(+), 71 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
> b/drivers/gpu/drm/i915/i915_sysfs.c
> index 2d576b7ff299..9e39d7a18fdb 100644
> --- a/drivers/gpu/drm/i915/i915_sysfs.c
> +++ b/drivers/gpu/drm/i915/i915_sysfs.c
> @@ -305,55 +305,6 @@ static ssize_t gt_act_freq_mhz_show(struct
> device *kdev,
>   return snprintf(buf, PAGE_SIZE, "%d\n", ret);
>  }
>  
> -static ssize_t gt_cur_freq_mhz_show(struct device *kdev,
> - struct device_attribute *attr,
> char *buf)
> -{
> - struct drm_minor *minor = dev_to_drm_minor(kdev);
> - struct drm_device *dev = minor->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - int ret;
> -
> - flush_delayed_work(_priv->rps.delayed_resume_work);
> -
> - intel_runtime_pm_get(dev_priv);
> -
> - mutex_lock(_priv->rps.hw_lock);
> - ret = intel_gpu_freq(dev_priv, dev_priv->rps.cur_freq);
> - mutex_unlock(_priv->rps.hw_lock);
> -
> - intel_runtime_pm_put(dev_priv);
> -
> - return snprintf(buf, PAGE_SIZE, "%d\n", ret);
> -}
> -
> -static ssize_t vlv_rpe_freq_mhz_show(struct device *kdev,
> -  struct device_attribute *attr,
> char *buf)
> -{
> - struct drm_minor *minor = dev_to_drm_minor(kdev);
> - struct drm_device *dev = minor->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> -
> - return snprintf(buf, PAGE_SIZE,
> - "%d\n",
> - intel_gpu_freq(dev_priv, dev_priv-
> >rps.efficient_freq));
> -}
> -
> -static ssize_t gt_max_freq_mhz_show(struct device *kdev, struct
> device_attribute *attr, char *buf)
> -{
> - struct drm_minor *minor = dev_to_drm_minor(kdev);
> - struct drm_device *dev = minor->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - int ret;
> -
> - flush_delayed_work(_priv->rps.delayed_resume_work);
> -
> - mutex_lock(_priv->rps.hw_lock);
> - ret = intel_gpu_freq(dev_priv, dev_priv-
> >rps.max_freq_softlimit);
> - mutex_unlock(_priv->rps.hw_lock);
> -
> - return snprintf(buf, PAGE_SIZE, "%d\n", ret);
> -}
> -
>  static ssize_t gt_max_freq_mhz_store(struct device *kdev,
>    struct device_attribute *attr,
>    const char *buf, size_t count)
> @@ -406,22 +357,6 @@ static ssize_t gt_max_freq_mhz_store(struct
> device *kdev,
>   return count;
>  }
>  
> -static ssize_t gt_min_freq_mhz_show(struct device *kdev, struct
> device_attribute *attr, char *buf)
> -{
> - struct drm_minor *minor = dev_to_drm_minor(kdev);
> - struct drm_device *dev = minor->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - int ret;
> -
> - flush_delayed_work(_priv->rps.delayed_resume_work);
> -
> - mutex_lock(_priv->rps.hw_lock);
> - ret = intel_gpu_freq(dev_priv, dev_priv-
> >rps.min_freq_softlimit);
> - mutex_unlock(_priv->rps.hw_lock);
> -
> - return snprintf(buf, PAGE_SIZE, "%d\n", ret);
> -}
> -
>  static ssize_t gt_min_freq_mhz_store(struct device *kdev,
>    struct device_attribute *attr,
>    const char *buf, size_t count)
> @@ -472,16 +407,15 @@ static ssize_t gt_min_freq_mhz_store(struct
> device *kdev,
>  }
>  
>  static DEVICE_ATTR(gt_act_freq_mhz, S_IRUGO, gt_act_freq_mhz_show,
> NULL);
> -static DEVICE_ATTR(gt_cur_freq_mhz, S_IRUGO, gt_cur_freq_mhz_show,
> NULL);
> -static DEVICE_ATTR(gt_max_freq_mhz, S_IRUGO | S_IWUSR,
> gt_max_freq_mhz_show, gt_max_freq_mhz_store);
> -static DEVICE_ATTR(gt_min_freq_mhz, S_IRUGO | S_IWUSR,
> gt_min_freq_mhz_show, gt_min_freq_mhz_store);
> -
> -static DEVICE_ATTR(vlv_rpe_freq_mhz, S_IRUGO, vlv_rpe_freq_mhz_show,
> NULL);
>  
>  static ssize_t gt_rp_mhz_show(struct device *kdev, struct
> device_attribute *attr, char *buf);
> +static DEVICE_ATTR(gt_cur_freq_mhz, S_IRUGO, gt_rp_mhz_show, NULL);
> +static DEVICE_ATTR(gt_max_freq_mhz, S_IRUGO | S_IWUSR,
> gt_rp_mhz_show, gt_max_freq_mhz_store);
> +static DEVICE_ATTR(gt_min_freq_mhz, S_IRUGO | S_IWUSR,
> gt_rp_mhz_show, gt_min_freq_mhz_store);
>  static DEVICE_ATTR(gt_RP0_freq_mhz, S_IRUGO, gt_rp_mhz_show, NULL);
>  static DEVICE_ATTR(gt_RP1_freq_mhz, 

Re: [Intel-gfx] [PATCH] drm/i915: fix sparse warning for using false as NULL

[Jani Nikula]

On Wed, 16 Mar 2016, Ville Syrjälä  wrote:
> On Wed, Mar 16, 2016 at 06:06:58PM +0200, Jani Nikula wrote:
>> drivers/gpu/drm/i915/intel_dpll_mgr.c:1200:32: warning: Using plain integer 
>> as NULL pointer
>> 
>> Fixes: 304b65cbdc8d ("drm/i915: Move SKL/KLB pll selection logic to 
>> intel_dpll_mgr.c")
>> Signed-off-by: Jani Nikula 
>
> Reviewed-by: Ville Syrjälä 

Pushed to drm-intel-next-queued, thanks for the review. The CI fails are
unrelated.

BR,
Jani.


>
>> ---
>>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
>> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
>> index 74d5aecc0be5..e53d57c39056 100644
>> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
>> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
>> @@ -1197,7 +1197,7 @@ skl_get_dpll(struct intel_crtc *crtc, struct 
>> intel_crtc_state *crtc_state,
>>  ctrl1 |= DPLL_CTRL1_HDMI_MODE(0);
>>  
>>  if (!skl_ddi_calculate_wrpll(clock * 1000, _params))
>> -return false;
>> +return NULL;
>>  
>>  cfgcr1 = DPLL_CFGCR1_FREQ_ENABLE |
>>   DPLL_CFGCR1_DCO_FRACTION(wrpll_params.dco_fraction) |
>> -- 
>> 2.1.4
>> 
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 1/3] pinctrl: Intel: add RX invertion config

[Linus Walleij]

On Wed, Mar 16, 2016 at 2:34 PM, Daniel Vetter  wrote:
> On Wed, Mar 16, 2016 at 01:27:49PM +0100, Linus Walleij wrote:

>> - What is a HPD interrupt?
>
> hotplug interrupt, fires when you plug in a cable.
>
>> - What is a Type-C DP HPD?
>
> usb type C connector can multiplex both DisplayPort and USB, you need to
> renegotiate the lane splitting every time the sink changes, i.e. on each
> hotplug.

OK I understand, thanks a lot!

>> - Again why can't you just use a notifier or function call?
>
> Because windows sucks, hence all that coordination happens through hw
> forwarded interrupts and magic registers. Same horror story on the sound
> side, where the sound driver needs to know what kind of PCM stream the
> monitor can take. It's hilarious. Except when they screw up the design and
> then need to fake parts of it in software.

So the story is something like that these IRQs have been put into
hardware in order to compensate for flaws in Windows device driver
model, I see.

If there are such special registers in some hardware I guess I'm all for
implementing some generic quirk in gpiolib for people who need to
software-trigger GPIO IRQs. Could be good for testing too, as there
are such registers in ARMs PL061 GPIO controller for test, just so as
to simulate a GPIO IRQ.

gpiod_trig_irq() would work with me, I'm happy to support whatever
the GPIO hardware can do usually.

> In sound we've switched over to a proper sw interface, and we tie the
> different parts (drm graphics driver and alsa snd driver) using the
> component.c framework.

Hm is that solution or something similar proper for USB connector
as well I wonder... I was thinking about just adding $random_notifier
but maybe that is a bit ugly :/

>> What is VPG? Now it seems Intel's internal organization is being used as
>> part of the argument to get this change in and that makes me a bit
>> annoyed.
(...)
> There was chat of usb type C support for forever, but I was always
> promised that we don't need any interactions on the sw side and it's all
> magic in hw. There hasn't been any real design discussions in the open
> source group. VPG is the hw/windows group and generally comes up with
> "interesting" designs not suitable for upstream.
>
> Feel free to just nack this stuff, and please cc intel-gfx/dri-devel in
> the future (since I tend to ignore everything that's not cc'ed to mailing
> lists I don't care about, even when I'm on cc personally). I've added them
> all to cc.

Thanks a lot Daniel, I understand better now. I'm not really against
adding this "interesting" workaround if that is how Windows works,
we usually have to go by their standards. From the GPIO point
of view it is OK, just something the GPIO can do. I would be more
worried about what the USB PHY maintainer (Felipe) is going to say
about this.

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

Re: [Intel-gfx] [PATCH resend for CI 2/2] drm/i915: Use shorter route to dev_private where possible

[Chris Wilson]

On Thu, Mar 17, 2016 at 01:04:10PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Where we have a request we can use req->i915 directly instead
> of going through the engine and device. Coccinelle script:
> 
> @@
> function f;
> identifier r;
> @@
> f(..., struct drm_i915_gem_request *r, ...)
> {
> ...
> - engine->dev->dev_private
> + r->i915
> ...
> }
> @@
> struct drm_i915_gem_request *req;
> @@
> (
>   req->
> - engine->dev->dev_private
> + i915
> )

struct intel_engine_cs *e;
- e->dev->dev_private
+ e->i915

Pretty please?

INTEL_INFO(engine->dev) (IS_GEN, HAS_ etc)
if r: INTEL_INFO(r->i915)
if e: INTEL_INFO(e->i915)
?
-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 RESEND 6/7] drm/i915/bios: drop has_mipi in favor of intel_bios_is_dsi_present

[Daniel Vetter]

On Wed, Mar 16, 2016 at 12:43:34PM +0200, Jani Nikula wrote:
> Favor a single point of truth instead of duplicating the information.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  1 -
>  drivers/gpu/drm/i915/intel_bios.c | 12 +++-
>  2 files changed, 3 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 9c7402c062b9..cff4b6ec79d8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1415,7 +1415,6 @@ struct intel_vbt_data {
>   unsigned int lvds_use_ssc:1;
>   unsigned int display_clock_mode:1;
>   unsigned int fdi_rx_polarity_inverted:1;
> - unsigned int has_mipi:1;
>   int lvds_ssc_freq;
>   unsigned int bios_lvds_val; /* initial [PCH_]LVDS reg val in VBIOS */
>  
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 4b6bd6f2e193..aa90dc662e7f 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -706,7 +706,7 @@ parse_mipi_config(struct drm_i915_private *dev_priv,
>   const struct mipi_pps_data *pps;
>  
>   /* parse MIPI blocks only if LFP type is MIPI */
> - if (!dev_priv->vbt.has_mipi)
> + if (!intel_bios_is_dsi_present(dev_priv, NULL))
>   return;
>  
>   /* Initialize this to undefined indicating no generic MIPI support */
> @@ -1232,13 +1232,6 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
>   continue;
>   }
>  
> - if (p_child->common.dvo_port >= DVO_PORT_MIPIA
> - && p_child->common.dvo_port <= DVO_PORT_MIPID
> - &_child->common.device_type & DEVICE_TYPE_MIPI_OUTPUT) {

New code also rejects DVO_PORT_MIPIC, you should mention that robustness
fix in the commit message. With this added:

Reviewed-by: Daniel Vetter 

> - DRM_DEBUG_KMS("Found MIPI as LFP\n");
> - dev_priv->vbt.has_mipi = 1;
> - }
> -
>   child_dev_ptr = dev_priv->vbt.child_dev + count;
>   count++;
>  
> @@ -1580,7 +1573,8 @@ bool intel_bios_is_dsi_present(struct drm_i915_private 
> *dev_priv,
>   switch (dvo_port) {
>   case DVO_PORT_MIPIA:
>   case DVO_PORT_MIPIC:
> - *port = dvo_port - DVO_PORT_MIPIA;
> + if (port)
> + *port = dvo_port - DVO_PORT_MIPIA;
>   return true;
>   case DVO_PORT_MIPIB:
>   case DVO_PORT_MIPID:
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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

[Intel-gfx] [PATCH v2 0/6] drm/i915/bxt: add dsi transcoders

[Jani Nikula]

v2 of adding bxt dsi transcoder support [1], addressing Ville's review,
which makes this cleaner.

BR,
Jani.

[1] http://mid.gmane.org/cover.1458070699.git.jani.nik...@intel.com

Jani Nikula (6):
  drm/i915: split get/set pipe timings to timings and src size
  drm/i915: split set pipeconf to pipeconf, pipemisc, pipe_gamma
  drm/i915: abstract get config for cpu transcoder
  drm/i915/bxt: add dsi transcoders
  drm/i915/dsi: use the BIT macro for clarity
  drm/i915/bxt: allow dsi on any pipe

 drivers/gpu/drm/i915/i915_drv.h |  13 ++
 drivers/gpu/drm/i915/intel_ddi.c|   6 +
 drivers/gpu/drm/i915/intel_display.c| 230 
 drivers/gpu/drm/i915/intel_drv.h|   3 +-
 drivers/gpu/drm/i915/intel_dsi.c|  28 +++-
 drivers/gpu/drm/i915/intel_runtime_pm.c |   6 +
 6 files changed, 223 insertions(+), 63 deletions(-)

-- 
2.1.4

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

[Intel-gfx] [PATCH] drm/i915: Modify reset func to handle per engine resets

[Mika Kuoppala]

In full gpu reset we prime all engines and reset domains corresponding to
each engine. Per engine reset is just a special case of this process
wherein only a single engine is reset. This change is aimed to modify
relevant functions to achieve this. There are some other steps we carry out
in case of engine reset which are addressed in later patches.

Reset func now accepts a mask of all engines that need to be reset. Where
per engine resets are supported, error handler populates the mask
accordingly otherwise all engines are specified.

v2: ALL_ENGINES mask fixup, better for_each_ring_masked (Chris)

Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
Signed-off-by: Arun Siluvery 
---
 drivers/gpu/drm/i915/i915_drv.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h |  8 ++-
 drivers/gpu/drm/i915/i915_gem.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_context.c |  2 +-
 drivers/gpu/drm/i915/i915_reg.h |  2 +
 drivers/gpu/drm/i915/intel_uncore.c | 88 -
 6 files changed, 77 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 20e82008b8b6..3648b73b48da 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -881,7 +881,7 @@ int i915_reset(struct drm_device *dev)
 
simulated = dev_priv->gpu_error.stop_rings != 0;
 
-   ret = intel_gpu_reset(dev);
+   ret = intel_gpu_reset(dev, ALL_ENGINES);
 
/* Also reset the gpu hangman. */
if (simulated) {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 80b14f1ba302..0386310e59c5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1971,6 +1971,10 @@ static inline struct drm_i915_private 
*guc_to_i915(struct intel_guc *guc)
for ((i__) = 0; (i__) < I915_NUM_RINGS; (i__)++) \
for_each_if ring__) = &(dev_priv__)->ring[(i__)]), 
intel_ring_initialized((ring__
 
+#define for_each_ring_masked(ring__, dev_priv__, mask__) \
+   for ((ring__) = _priv->ring[0]; (ring__) < 
_priv->ring[I915_NUM_RINGS]; (ring__)++) \
+   for_each_if (intel_ring_flag((ring__)) & (mask__) && 
intel_ring_initialized((ring__)))
+
 enum hdmi_force_audio {
HDMI_AUDIO_OFF_DVI = -2,/* no aux data for HDMI-DVI converter */
HDMI_AUDIO_OFF, /* force turn off HDMI audio */
@@ -2553,6 +2557,8 @@ struct drm_i915_cmd_table {
 #define BLT_RING   (1<ring_mask & BSD_RING)
 #define HAS_BSD2(dev)  (INTEL_INFO(dev)->ring_mask & BSD2_RING)
 #define HAS_BLT(dev)   (INTEL_INFO(dev)->ring_mask & BLT_RING)
@@ -2681,7 +2687,7 @@ extern void i915_driver_postclose(struct drm_device *dev,
 extern long i915_compat_ioctl(struct file *filp, unsigned int cmd,
  unsigned long arg);
 #endif
-extern int intel_gpu_reset(struct drm_device *dev);
+extern int intel_gpu_reset(struct drm_device *dev, u32 engine_mask);
 extern bool intel_has_gpu_reset(struct drm_device *dev);
 extern int i915_reset(struct drm_device *dev);
 extern unsigned long i915_chipset_val(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b854af2c4141..68d766af2ed0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5018,7 +5018,7 @@ i915_gem_cleanup_ringbuffer(struct drm_device *dev)
  * expects the system to be in execlists mode on startup,
  * so we need to reset the GPU back to legacy mode.
  */
-intel_gpu_reset(dev);
+   intel_gpu_reset(dev, ALL_ENGINES);
 }
 
 static void
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5dd84e148bba..3251539a6cbe 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -413,7 +413,7 @@ void i915_gem_context_fini(struct drm_device *dev)
/* The only known way to stop the gpu from accessing the hw 
context is
 * to reset it. Do this as the very last operation to avoid 
confusing
 * other code, leading to spurious errors. */
-   intel_gpu_reset(dev);
+   intel_gpu_reset(dev, ALL_ENGINES);
 
/* When default context is created and switched to, base object 
refcount
 * will be 2 (+1 from object creation and +1 from do_switch()).
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7dfc4007f3fa..69359d918a4a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -164,6 +164,8 @@ 

Re: [Intel-gfx] [PATCH v2] drm/i915: Tune down init error message due to failure injection

[Chris Wilson]

On Thu, Mar 17, 2016 at 09:50:19PM +0200, Imre Deak wrote:
> On Thu, 2016-03-17 at 19:41 +, Chris Wilson wrote:
> > On Thu, Mar 17, 2016 at 06:08:05PM +0200, Imre Deak wrote:
> > > On Thu, 2016-03-17 at 15:55 +, Chris Wilson wrote:
> > > > 80cols rules still apply to messages :)
> > > > 
> > > > "Device initialization failed (%d). "
> > > > "Please file a bug at https://bugs.freedesktop.org/enter_bug.cgi
> > > > "
> > > > "against DRI/DRM/Intel providing the dmesg log by booting "
> > > > "with drm.debug=0xf\n",
> > > 
> > > I thought for strings emitted to dmesg it's discouraged, since you
> > > can't easily grep then. But I can make the link more precise.
> > 
> > Hmm, we haven't abided by that. I don't mind really :)
> 
> Ok, will follow this rule then.
> 
> > > > I would personally make i915_load_error() a proper function and
> > > > add
> > > > the "Please..." output there at a lower logging level than ERROR.
> > > 
> > > Using a function is not straightforward since there is no vprintf
> > > like
> > > interface for DRM_ERROR. But I can move that part of the message to
> > > macro.
> > 
> > In that case, I'm happy enough with ditching the DRM_ERROR here and
> > go
> > with dev_err(). Another nail in the DRM_ERROR coffin.
> 
> Hm, there doesn't seem to be vprintf like dev_err either. And dev_dbg
> depends on CONFIG_DEBUG while DRM_DEBUG doesn't.

It uses dev_printk_emit(KERN_ERR, dev, fmt, va_list) underneath.

Does that help?
-Chris

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

[Intel-gfx] [PATCH v2 2/6] drm/i915: split set pipeconf to pipeconf, pipemisc, pipe_gamma

[Jani Nikula]

Prep work for DSI transcoders. No functional changes.

v2: call split functions at a higher level (Ville)

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_display.c | 32 ++--
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a356a0a78b82..eece50ed3ea6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -102,6 +102,8 @@ static void intel_cpu_transcoder_set_m_n(struct intel_crtc 
*crtc,
 struct intel_link_m_n *m2_n2);
 static void ironlake_set_pipeconf(struct drm_crtc *crtc);
 static void haswell_set_pipeconf(struct drm_crtc *crtc);
+static void haswell_set_pipe_gamma(struct drm_crtc *crtc);
+static void haswell_set_pipemisc(struct drm_crtc *crtc);
 static void intel_set_pipe_csc(struct drm_crtc *crtc);
 static void vlv_prepare_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *pipe_config);
@@ -4928,6 +4930,8 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
}
 
haswell_set_pipeconf(crtc);
+   haswell_set_pipe_gamma(crtc);
+   haswell_set_pipemisc(crtc);
 
intel_set_pipe_csc(crtc);
 
@@ -8764,16 +8768,12 @@ static void intel_set_pipe_csc(struct drm_crtc *crtc)
 
 static void haswell_set_pipeconf(struct drm_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = crtc->dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   enum pipe pipe = intel_crtc->pipe;
enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
-   uint32_t val;
+   u32 val = 0;
 
-   val = 0;
-
-   if (IS_HASWELL(dev) && intel_crtc->config->dither)
+   if (IS_HASWELL(dev_priv) && intel_crtc->config->dither)
val |= (PIPECONF_DITHER_EN | PIPECONF_DITHER_TYPE_SP);
 
if (intel_crtc->config->base.adjusted_mode.flags & 
DRM_MODE_FLAG_INTERLACE)
@@ -8783,12 +8783,24 @@ static void haswell_set_pipeconf(struct drm_crtc *crtc)
 
I915_WRITE(PIPECONF(cpu_transcoder), val);
POSTING_READ(PIPECONF(cpu_transcoder));
+}
+
+static void haswell_set_pipe_gamma(struct drm_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = crtc->dev->dev_private;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 
I915_WRITE(GAMMA_MODE(intel_crtc->pipe), GAMMA_MODE_MODE_8BIT);
POSTING_READ(GAMMA_MODE(intel_crtc->pipe));
+}
+
+static void haswell_set_pipemisc(struct drm_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = crtc->dev->dev_private;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 
-   if (IS_BROADWELL(dev) || INTEL_INFO(dev)->gen >= 9) {
-   val = 0;
+   if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {
+   u32 val = 0;
 
switch (intel_crtc->config->pipe_bpp) {
case 18:
@@ -8811,7 +8823,7 @@ static void haswell_set_pipeconf(struct drm_crtc *crtc)
if (intel_crtc->config->dither)
val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
 
-   I915_WRITE(PIPEMISC(pipe), val);
+   I915_WRITE(PIPEMISC(intel_crtc->pipe), val);
}
 }
 
-- 
2.1.4

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

Re: [Intel-gfx] [RFC PATCH 04/10] drm/i915/bxt: fix dsi hw state pipe readout

[Jani Nikula]

On Wed, 16 Mar 2016, Ville Syrjälä  wrote:
> On Tue, Mar 15, 2016 at 09:51:12PM +0200, Jani Nikula wrote:
>> BXT isn't as limited as BYT and CHT regarding DSI pipes and ports.
>> 
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/i915/i915_reg.h  |  1 +
>>  drivers/gpu/drm/i915/intel_dsi.c | 14 +-
>>  2 files changed, 14 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 7dfc4007f3fa..a5035991dd57 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -8144,6 +8144,7 @@ enum skl_disp_power_wells {
>>  #define  READ_REQUEST_PRIORITY_HIGH (3 << 3)
>>  #define  RGB_FLIP_TO_BGR(1 << 2)
>>  
>> +#define  BXT_PIPE_SELECT_SHIFT  7
>>  #define  BXT_PIPE_SELECT_MASK   (7 << 7)
>>  #define  BXT_PIPE_SELECT(pipe)  ((pipe) << 7)
>
> These defines look a little misplaced, but that's separate topic.
>
> Reviewed-by: Ville Syrjälä 

Pushed patches 1-4 to drm-intel-next-queued, as they are mostly
harmless. Fixed the eDP string to match spec in the earlier patch.

BR,
Jani.

>
>>  
>> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
>> b/drivers/gpu/drm/i915/intel_dsi.c
>> index 6574b9ac3698..73c15210fdb1 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi.c
>> @@ -700,7 +700,19 @@ static bool intel_dsi_get_hw_state(struct intel_encoder 
>> *encoder,
>>  if (!(I915_READ(MIPI_DEVICE_READY(port)) & DEVICE_READY))
>>  continue;
>>  
>> -*pipe = port == PORT_A ? PIPE_A : PIPE_B;
>> +if (IS_BROXTON(dev_priv)) {
>> +u32 tmp = I915_READ(MIPI_CTRL(port));
>> +tmp &= BXT_PIPE_SELECT_MASK;
>> +tmp >>= BXT_PIPE_SELECT_SHIFT;
>> +
>> +if (WARN_ON(tmp > PIPE_C))
>> +continue;
>> +
>> +*pipe = tmp;
>> +} else {
>> +*pipe = port == PORT_A ? PIPE_A : PIPE_B;
>> +}
>> +
>>  active = true;
>>  break;
>>  }
>> -- 
>> 2.1.4

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

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915/bxt: allow dsi on any pipe

[Ville Syrjälä]

On Fri, Mar 18, 2016 at 05:05:44PM +0200, Jani Nikula wrote:
> BXT isn't as limited as BYT and CHT regarding DSI pipes and ports.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_dsi.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index dd6f7bc4f444..456676c00059 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -1198,8 +1198,13 @@ void intel_dsi_init(struct drm_device *dev)
>   intel_connector->get_hw_state = intel_connector_get_hw_state;
>   intel_connector->unregister = intel_connector_unregister;
>  
> - /* Pipe A maps to MIPI DSI port A, pipe B maps to MIPI DSI port C */
> - if (port == PORT_A)
> + /*
> +  * On BYT/CHV, pipe A maps to MIPI DSI port A, pipe B maps to MIPI DSI
> +  * port C. BXT isn't limited like this.
> +  */
> + if (IS_BROXTON(dev_priv))
> + intel_encoder->crtc_mask = BIT(PIPE_A) | BIT(PIPE_B) | 
> BIT(PIPE_C);
> + else if (port == PORT_A)
>   intel_encoder->crtc_mask = BIT(PIPE_A);
>   else
>   intel_encoder->crtc_mask = BIT(PIPE_B);
> -- 
> 2.1.4

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Get rid of intel_dp_dpcd_read_wake()

[Ville Syrjälä]

On Fri, Mar 18, 2016 at 04:13:45PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 17, 2016 at 11:40:45AM -0400, Lyude wrote:
> > Since we've fixed up drm_dp_dpcd_read() to allow for retries when things
> > timeout, there's no use for having this function anymore. Good riddens.
> > 
> > Signed-off-by: Lyude 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 79 
> > -
> >  1 file changed, 22 insertions(+), 57 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index cdc2c15..fb4cbbe5 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3190,47 +3190,14 @@ static void chv_dp_post_pll_disable(struct 
> > intel_encoder *encoder)
> >  }
> >  
> >  /*
> > - * Native read with retry for link status and receiver capability reads for
> > - * cases where the sink may still be asleep.
> > - *
> > - * Sinks are *supposed* to come up within 1ms from an off state, but we're 
> > also
> > - * supposed to retry 3 times per the spec.
> > - */
> > -static ssize_t
> > -intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, unsigned int offset,
> > -   void *buffer, size_t size)
> > -{
> > -   ssize_t ret;
> > -   int i;
> > -
> > -   /*
> > -* Sometime we just get the same incorrect byte repeated
> > -* over the entire buffer. Doing just one throw away read
> > -* initially seems to "solve" it.
> > -*/
> > -   drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer, 1);
> 
> NAK
> 
> If people keep intentionally breaking my shit I'm going to become
> really grumpy soon.

Oh, and just in case someone wants to come up with a better kludge,
I just spent a few minutes analyzing the behavior of this crappy
monitor a.

What happens is that when the monitor is fully powered up (LED is blue)
things are fine. After the monitor goes to sleep (LED turns orange)
the first DPCD read will produce garbage. Further DPCD reads are fine,
even if I wait a significant amount of time between the reads, as long
as the monitor didn't do a power on->off cycle in between. So it looks
like it's always just the first read after power down that gets
corrupted.

Now I think I'll go and test how writes behave, assuming I can find a
decently sized chunk of DPCD address space I can write. And maybe I
should also try i2c-over-aux...
 
> 
> > -
> > -   for (i = 0; i < 3; i++) {
> > -   ret = drm_dp_dpcd_read(aux, offset, buffer, size);
> > -   if (ret == size)
> > -   return ret;
> > -   msleep(1);
> > -   }
> > -
> > -   return ret;
> > -}
> > -
> > -/*
> >   * Fetch AUX CH registers 0x202 - 0x207 which contain
> >   * link status information
> >   */
> >  bool
> >  intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t 
> > link_status[DP_LINK_STATUS_SIZE])
> >  {
> > -   return intel_dp_dpcd_read_wake(_dp->aux,
> > -  DP_LANE0_1_STATUS,
> > -  link_status,
> > -  DP_LINK_STATUS_SIZE) == 
> > DP_LINK_STATUS_SIZE;
> > +   return drm_dp_dpcd_read(_dp->aux, DP_LANE0_1_STATUS, link_status,
> > +   DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
> >  }
> >  
> >  /* These are source-specific values. */
> > @@ -3865,8 +3832,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > uint8_t rev;
> >  
> > -   if (intel_dp_dpcd_read_wake(_dp->aux, 0x000, intel_dp->dpcd,
> > -   sizeof(intel_dp->dpcd)) < 0)
> > +   if (drm_dp_dpcd_read(_dp->aux, 0x000, intel_dp->dpcd,
> > +sizeof(intel_dp->dpcd)) < 0)
> > return false; /* aux transfer failed */
> >  
> > DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd), 
> > intel_dp->dpcd);
> > @@ -3877,9 +3844,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > /* Check if the panel supports PSR */
> > memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
> > if (is_edp(intel_dp)) {
> > -   intel_dp_dpcd_read_wake(_dp->aux, DP_PSR_SUPPORT,
> > -   intel_dp->psr_dpcd,
> > -   sizeof(intel_dp->psr_dpcd));
> > +   drm_dp_dpcd_read(_dp->aux, DP_PSR_SUPPORT,
> > +intel_dp->psr_dpcd,
> > +sizeof(intel_dp->psr_dpcd));
> > if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
> > dev_priv->psr.sink_support = true;
> > DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
> > @@ -3890,9 +3857,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > uint8_t frame_sync_cap;
> >  
> > dev_priv->psr.sink_support = true;
> > -   intel_dp_dpcd_read_wake(_dp->aux,
> > -   DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> > -

Re: [Intel-gfx] [RFC] drm/i915: Smarten up and use to_i915() everywhere

[Jani Nikula]

On Thu, 17 Mar 2016, Tvrtko Ursulin  wrote:
> From: Tvrtko Ursulin 
>
> There is a lot of ways to get to our dev_priv depending on which
> object is at hand and often what was chosen by the developer.
>
> We can make to_i915() accept different pointers by using compile
> time magic. Like:
>
>   dev_priv = to_i915(request);
>   dev_priv = to_i915(engine);
>   dev_priv = to_i915(ctx);
>   dev_priv = to_i915(dev);
>   dev_priv = to_i915(guc);
>   dev_priv = to_i915(device);
>
> If an unknown pointer is passed to the function it will cause
> a compile time failure.
>
> Main advantage is that with this in place we could add and
> remove shourtcuts to dev_priv from supported structures easily
> and without touching the code which uses it. If we wanted to
> fiddle with the balance of structure sizes and number of pointer
> dereferencing for example. And it makes the code a bit tidier
> and uniform.
>
> Signed-off-by: Tvrtko Ursulin 
> Cc: Chris Wilson 
> --
> However the churn is huge so I don't really think this is a
> must have.

The "magic" __I915__() macro was added to support a transition from
using dev pointer to using dev_priv pointer. I like the transition, and
we slowly keep doing it.

IMO there have been two problems with that. First, the transition is
slow, because there's nothing forcing us to switch. This was expected,
as we explicitly didn't want a huge patch (like this). Second, it
appears to *still* confuse people after over a year that you can pass
either type of pointer to the macros in C.

I object to this patch both because it's huge (and I'll get my fair
share of the conflicts) and, more importantly, because it promotes an
appearance of a sort of dynamic typing in a statically typed
language. The latter contains an element of surprise to the programmer,
and surprising is not a quality I want to associate with code.

I think I'd rather promote a sensible set of T_to_i915() macros for
cleanly doing the conversion from various types we often use, and slowly
keep transitioning.

BR,
Jani.


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

Re: [Intel-gfx] [PATCH v6] igt/gem_trtt: Exercise the TRTT hardware

[Chris Wilson]

On Fri, Mar 18, 2016 at 02:31:23PM +0530, Goel, Akash wrote:
> 
> 
> On 3/18/2016 2:06 PM, Chris Wilson wrote:
> >On Fri, Mar 18, 2016 at 02:07:40PM +0530, akash.g...@intel.com wrote:
> >>+/* emit_store_qword
> >>+ * populate batch buffer with MI_STORE_DWORD_IMM command
> >>+ * @fd: drm file descriptor
> >>+ * @cmd_buf: batch buffer
> >>+ * @dw_offset: write offset in batch buffer
> >>+ * @vaddr: destination Virtual address
> >>+ * @data: u64 data to be stored at destination
> >>+ */
> >>+static int emit_store_qword(int fd, uint32_t *cmd_buf, uint32_t dw_offset,
> >>+   uint64_t vaddr, uint64_t data)
> >>+{
> >>+   /* Check that softpin addresses are in the correct form */
> >>+   igt_assert_eq_u64(vaddr, igt_canonical_addr(vaddr));
> >>+
> >>+   /* SDI cannot write to unaligned addresses */
> >>+   igt_assert((vaddr & 3) == 0);
> >
> >If I remember correctly a qword write from SDI must be 8 byte aligned.
> >Right?
> 
> Yes right. Sorry, my bad..
> >
> >>+
> >>+   cmd_buf[dw_offset++] = MI_STORE_DWORD_IMM | 0x3;
> >>+   cmd_buf[dw_offset++] = (uint32_t)vaddr;
> >>+   cmd_buf[dw_offset++] = (uint32_t)(vaddr >> 32);
> >>+   cmd_buf[dw_offset++] = data;
> >>+   cmd_buf[dw_offset++] = data >> 32;
> >>+
> >>+   return dw_offset;
> >>+}
> >
> >Hopefully final comments!
> >
> >Missed EINTR handling during evict, If you repeat the busy/hang tests
> >within the igt_fork_signal_helper(); igt_stop_signal_helper() that
> >should cover catching an inopportune signal.
> 
> Fine will add, thanks for suggesting this
> So the signal will interrupt the Driver, which would be waiting for
> the vma unbind to complete, from the eviction path.

Right, and we will report the error back to userspace as EINTR and
userspace will restart the syscall and we expect it to succeed
(eventually). Just useful for flushing out the error handling.

Having just remembered how useful this might be, I just extended
gem_softpin for similar reasons:
+   igt_subtest("evict-active-interruptible") {
+   struct timespec start = {};
+   while (igt_seconds_elapsed() < 20)
+   test_evict_active(fd);
+   }
-Chris

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

[Intel-gfx] [PATCH 3/3] drm/i915: Update i915.reset to handle engine resets

[Arun Siluvery]

In preparation for engine reset work update this parameter to handle more
than one type of reset. Default at the moment is still full gpu reset.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Arun Siluvery 
---
 drivers/gpu/drm/i915/i915_params.c | 6 +++---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 1779f02..e4f9d6a 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -45,7 +45,7 @@ struct i915_params i915 __read_mostly = {
.fastboot = 0,
.prefault_disable = 0,
.load_detect_test = 0,
-   .reset = true,
+   .reset = 1,
.invert_brightness = 0,
.disable_display = 0,
.enable_cmd_parser = 1,
@@ -108,8 +108,8 @@ MODULE_PARM_DESC(vbt_sdvo_panel_type,
"Override/Ignore selection of SDVO panel mode in the VBT "
"(-2=ignore, -1=auto [default], index in VBT BIOS table)");
 
-module_param_named_unsafe(reset, i915.reset, bool, 0600);
-MODULE_PARM_DESC(reset, "Attempt GPU resets (default: true)");
+module_param_named_unsafe(reset, i915.reset, int, 0600);
+MODULE_PARM_DESC(reset, "Attempt GPU resets (0=disabled, 1=full gpu reset 
[default], 2=engine reset)");
 
 module_param_named_unsafe(enable_hangcheck, i915.enable_hangcheck, bool, 0644);
 MODULE_PARM_DESC(enable_hangcheck,
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 02bc278..9b13c10 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -34,6 +34,7 @@ struct i915_params {
int lvds_channel_mode;
int panel_use_ssc;
int vbt_sdvo_panel_type;
+   int reset;
int enable_rc6;
int enable_dc;
int enable_fbc;
@@ -55,7 +56,6 @@ struct i915_params {
bool fastboot;
bool prefault_disable;
bool load_detect_test;
-   bool reset;
bool disable_display;
bool enable_guc_submission;
bool verbose_state_checks;
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 03/16] drm/i915: Implement WaPixelRepeatModeFixForC0:chv

[Ville Syrjälä]

On Wed, Mar 16, 2016 at 11:27:05AM +0200, Jani Nikula wrote:
> On Tue, 15 Mar 2016, ville.syrj...@linux.intel.com wrote:
> > [ text/plain ]
> > From: Ville Syrjälä 
> >
> > DPLL_MD(PIPE_C) is AWOL on CHV. Instead of fixing it someone added
> > chicken bits to propagate the pixel multiplier from DPLL_MD(PIPE_B)
> > to either pipe B or C. So do that to make pixel repeat work on pipes
> > B and C. Pipe A is fine without any tricks.
> >
> > Fortunately the pixel repeat propagation appears to be a oneshot
> > operation, so once the value has been written we can clear the
> > chicken bits. So it is still possible to drive pipe B and C with
> > different pixel multipliers simultaneosly.
> >
> > Looks like DPLL_VGA_MODE_DIS must also be set in DPLL(PIPE_B)
> > for this to work. But since we keep that bit always set in all
> > DPLLs there's no problem.
> >
> > This of course means we can't reliably read out the pixel multiplier
> > for pipes B and C. That would make the state checker unhappy, so I
> > added shadow copies of those registers in to dev_priv. The other
> > option would have been to skip pixel multiplier, dpll_md an dotclock
> > checks entirely on CHV, but that feels like a serious loss of cross
> > checking, so just pretending that we have working DPLL MD registers
> > seemed better. Obviously with the shadow copies we can't detect if
> > the pixel multiplier was properly configured, nor can we take over
> > its state from the BIOS, but hopefully people won't have displays
> > that would be limitd to such crappy modes.
> >
> > There is one strange flicker still remaining. It's visible on
> > pipe C/HDMID when HDMIB is enabled while driven by pipe B.
> > It doesn't occur if pipe A drives HDMIB, nor is there any glitch
> > on pipe B/HDMIB when port C/HDMID starts up. I don't have a board
> > with HDMIC so not sure if it happens there too. So I'm not sure
> > if it's somehow tied in with this strange linkage between pipe B
> > and C. Sadly I was unable to find an enable sequence that would
> > avoid the glitch, but at least it's not fatal ie. the output
> > recovers afterwards.
> >
> > Signed-off-by: Ville Syrjälä 
> 
> I didn't dig up the specs, but the code seems to do what the commit
> message says.

The "spec" wouldn't help much either, apart from showing where
the chicken bits live. I might have a powerpoint somewhere about
this, but it IIRC it didn't really tell you how to do things in
practice. As far as I can remember, I just used the standard
trial and error method to implement this.

> 
> Reviewed-by: Jani Nikula 
> 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  7 +++
> >  drivers/gpu/drm/i915/i915_reg.h  |  4 
> >  drivers/gpu/drm/i915/intel_display.c | 30 ++
> >  3 files changed, 37 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 80b14f1ba302..31689e1b19e6 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1871,7 +1871,14 @@ struct drm_i915_private {
> >  
> > u32 fdi_rx_config;
> >  
> > +   /* Shadow for DISPLAY_PHY_CONTROL which can't be safely read */
> > u32 chv_phy_control;
> > +   /*
> > +* Shadows for CHV DPLL_MD regs to keep the state
> > +* checker somewhat working in the presence hardware
> > +* crappiness (can't read out DPLL_MD for pipes B & C).
> > +*/
> > +   u32 chv_dpll_md[I915_MAX_PIPES];
> >  
> > u32 suspend_count;
> > bool suspended_to_idle;
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 7dfc4007f3fa..f138588a88cd 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4778,6 +4778,10 @@ enum skl_disp_power_wells {
> >  #define  CBR_PND_DEADLINE_DISABLE  (1<<31)
> >  #define  CBR_PWM_CLOCK_MUX_SELECT  (1<<30)
> >  
> > +#define CBR4_VLV   _MMIO(VLV_DISPLAY_BASE + 0x70450)
> > +#define  CBR_DPLLBMD_PIPE_C(1<<29)
> > +#define  CBR_DPLLBMD_PIPE_B(1<<18)
> > +
> >  /* FIFO watermark sizes etc */
> >  #define G4X_FIFO_LINE_SIZE 64
> >  #define I915_FIFO_LINE_SIZE64
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 414ed5007e60..18158b0324ed 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -1635,9 +1635,27 @@ static void chv_enable_pll(struct intel_crtc *crtc,
> > if (wait_for(((I915_READ(DPLL(pipe)) & DPLL_LOCK_VLV) == 
> > DPLL_LOCK_VLV), 1))
> > DRM_ERROR("PLL %d failed to lock\n", pipe);
> >  
> > -   /* not sure when this should be written */
> > -   I915_WRITE(DPLL_MD(pipe), pipe_config->dpll_hw_state.dpll_md);
> > -   POSTING_READ(DPLL_MD(pipe));
> > +   if (pipe != PIPE_A) {
> > +   /*
> > +

[Intel-gfx] [PATCH v3 04/19] drm/i915: Move load time init of display/audio hooks earlier

[Imre Deak]

All of this is SW only initialization so we can move them earlier. Move
the mutex init where the rest of the locks are inited. While at it also
convert dev to dev_priv.

v2:
- use the term hook instead of callback for these functions (Jani)

CC: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_dma.c  |  3 ++
 drivers/gpu/drm/i915/intel_audio.c   | 16 +++
 drivers/gpu/drm/i915/intel_display.c | 82 +---
 drivers/gpu/drm/i915/intel_drv.h |  3 +-
 4 files changed, 51 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 4cf7bd4..44f15de 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1015,6 +1015,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
mutex_init(_priv->modeset_restore_lock);
mutex_init(_priv->av_mutex);
mutex_init(_priv->wm.wm_mutex);
+   mutex_init(_priv->pps_mutex);
 
ret = i915_workqueues_init(dev_priv);
if (ret < 0)
@@ -1027,6 +1028,8 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
intel_init_dpio(dev_priv);
intel_power_domains_init(dev_priv);
intel_irq_init(dev_priv);
+   intel_init_display_hooks(dev_priv);
+   intel_init_audio_hooks(dev_priv);
 
intel_runtime_pm_get(dev_priv);
 
diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index 30f9214..fdc8b2a 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -564,23 +564,21 @@ void intel_audio_codec_disable(struct intel_encoder 
*intel_encoder)
 }
 
 /**
- * intel_init_audio - Set up chip specific audio functions
- * @dev: drm device
+ * intel_init_audio_hooks - Set up chip specific audio hooks
+ * @dev_priv: device private
  */
-void intel_init_audio(struct drm_device *dev)
+void intel_init_audio_hooks(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = dev->dev_private;
-
-   if (IS_G4X(dev)) {
+   if (IS_G4X(dev_priv)) {
dev_priv->display.audio_codec_enable = g4x_audio_codec_enable;
dev_priv->display.audio_codec_disable = g4x_audio_codec_disable;
-   } else if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
+   } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
dev_priv->display.audio_codec_enable = ilk_audio_codec_enable;
dev_priv->display.audio_codec_disable = ilk_audio_codec_disable;
-   } else if (IS_HASWELL(dev) || INTEL_INFO(dev)->gen >= 8) {
+   } else if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8) {
dev_priv->display.audio_codec_enable = hsw_audio_codec_enable;
dev_priv->display.audio_codec_disable = hsw_audio_codec_disable;
-   } else if (HAS_PCH_SPLIT(dev)) {
+   } else if (HAS_PCH_SPLIT(dev_priv)) {
dev_priv->display.audio_codec_enable = ilk_audio_codec_enable;
dev_priv->display.audio_codec_disable = ilk_audio_codec_disable;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ce55f0b..f623342 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14827,23 +14827,24 @@ static const struct drm_mode_config_funcs 
intel_mode_funcs = {
.atomic_state_clear = intel_atomic_state_clear,
 };
 
-/* Set up chip specific display functions */
-static void intel_init_display(struct drm_device *dev)
+/**
+ * intel_init_display_hooks - initialize the display modesetting hooks
+ * @dev_priv: device private
+ */
+void intel_init_display_hooks(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = dev->dev_private;
-
-   if (HAS_PCH_SPLIT(dev) || IS_G4X(dev))
+   if (HAS_PCH_SPLIT(dev_priv) || IS_G4X(dev_priv))
dev_priv->display.find_dpll = g4x_find_best_dpll;
-   else if (IS_CHERRYVIEW(dev))
+   else if (IS_CHERRYVIEW(dev_priv))
dev_priv->display.find_dpll = chv_find_best_dpll;
-   else if (IS_VALLEYVIEW(dev))
+   else if (IS_VALLEYVIEW(dev_priv))
dev_priv->display.find_dpll = vlv_find_best_dpll;
-   else if (IS_PINEVIEW(dev))
+   else if (IS_PINEVIEW(dev_priv))
dev_priv->display.find_dpll = pnv_find_best_dpll;
else
dev_priv->display.find_dpll = i9xx_find_best_dpll;
 
-   if (INTEL_INFO(dev)->gen >= 9) {
+   if (INTEL_INFO(dev_priv)->gen >= 9) {
dev_priv->display.get_pipe_config = haswell_get_pipe_config;
dev_priv->display.get_initial_plane_config =
skylake_get_initial_plane_config;
@@ -14851,7 +14852,7 @@ static void intel_init_display(struct drm_device *dev)
haswell_crtc_compute_clock;

Re: [Intel-gfx] [PATCH] drm/i915: fix sparse warning for using false as NULL

[Jani Nikula]

On Wed, 16 Mar 2016, Jani Nikula  wrote:
> drivers/gpu/drm/i915/intel_dpll_mgr.c:1200:32: warning: Using plain integer 
> as NULL pointer
>
> Fixes: 304b65cbdc8d ("drm/i915: Move SKL/KLB pll selection logic to 
> intel_dpll_mgr.c")

Forgot to Cc: Ander on this one.

BR,
Jani.

> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 74d5aecc0be5..e53d57c39056 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -1197,7 +1197,7 @@ skl_get_dpll(struct intel_crtc *crtc, struct 
> intel_crtc_state *crtc_state,
>   ctrl1 |= DPLL_CTRL1_HDMI_MODE(0);
>  
>   if (!skl_ddi_calculate_wrpll(clock * 1000, _params))
> - return false;
> + return NULL;
>  
>   cfgcr1 = DPLL_CFGCR1_FREQ_ENABLE |
>DPLL_CFGCR1_DCO_FRACTION(wrpll_params.dco_fraction) |

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix eDP low vswing for Broadwell

[Patchwork]

== Series Details ==

Series: drm/i915: Fix eDP low vswing for Broadwell
URL   : https://patchwork.freedesktop.org/series/4499/
State : failure

== Summary ==

Series 4499v1 drm/i915: Fix eDP low vswing for Broadwell
http://patchwork.freedesktop.org/api/1.0/series/4499/revisions/1/mbox/

Test drv_module_reload_basic:
pass   -> SKIP   (bdw-ultra)
Test gem_mmap_gtt:
Subgroup basic-small-copy:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_ringfill:
Subgroup basic-default-s3:
dmesg-warn -> PASS   (skl-i5k-2)
pass   -> DMESG-WARN (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-WARN (hsw-gt2)
dmesg-warn -> PASS   (hsw-brixbox)
Test kms_force_connector_basic:
Subgroup force-connector-state:
pass   -> SKIP   (ivb-t430s)
Subgroup force-edid:
pass   -> SKIP   (ivb-t430s)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a:
dmesg-warn -> PASS   (bdw-nuci7)
Subgroup suspend-read-crc-pipe-c:
pass   -> INCOMPLETE (hsw-gt2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
fail   -> DMESG-FAIL (snb-x220t)
pass   -> DMESG-WARN (hsw-brixbox)
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:194  pass:182  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:194  pass:172  dwarn:0   dfail:0   fail:0   skip:22 
bsw-nuc-2total:194  pass:156  dwarn:1   dfail:0   fail:0   skip:37 
byt-nuc  total:194  pass:155  dwarn:4   dfail:0   fail:0   skip:35 
hsw-brixbox  total:194  pass:171  dwarn:1   dfail:0   fail:0   skip:22 
hsw-gt2  total:74   pass:66   dwarn:1   dfail:0   fail:0   skip:6  
ivb-t430stotal:194  pass:167  dwarn:0   dfail:0   fail:0   skip:27 
skl-i5k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-i7k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:194  pass:183  dwarn:0   dfail:0   fail:0   skip:11 
snb-x220ttotal:194  pass:159  dwarn:1   dfail:1   fail:0   skip:33 

Results at /archive/results/CI_IGT_test/Patchwork_1612/

9f8709ffd099e85e5e116ed7d09f1b8009f40847 drm-intel-nightly: 
2016y-03m-16d-10h-30m-26s UTC integration manifest
e141f3750e10c3e21c12ba3649cd5c64f696e9ce drm/i915: Fix eDP low vswing for 
Broadwell

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

Re: [Intel-gfx] [PATCH] drm/i915: Restrict usage of live status check

[Jani Nikula]

On Thu, 17 Mar 2016, "Sharma, Shashank"  wrote:
> [ text/plain ]
> Hey Chris,
> I added comments for both Ville and you, please help me to understand this.
>
> Regards
> Shashank
>
> On 3/17/2016 9:51 PM, Ville Syrjälä wrote:
>> On Thu, Mar 17, 2016 at 09:35:30PM +0530, Sharma, Shashank wrote:
>>> Regards
>>> Shashank
>>>
>>> On 3/17/2016 9:31 PM, Ville Syrjälä wrote:
 On Thu, Mar 17, 2016 at 09:15:39PM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
>
> On 3/17/2016 6:34 PM, Ville Syrjälä wrote:
>> On Thu, Mar 17, 2016 at 01:29:25PM +0530, Shashank Sharma wrote:
>>> This patch restricts usage of live status check for HDMI detection.
>>> While testing certain (monitor + cable) combinations with various
>>> intel  platforms, it seems that live status register is not reliable
>>> on some older devices. So limit the live_status check from VLV onwards.
>>>
>>> This fixes a regression introduced in:
>>> commit: 237ed86 "drm/i915: Check live status"
>>> Author: Sonika Jindal 
>>> Date:   Tue Sep 15 09:44:20 2015 +0530
>>>
>>> Signed-off-by: Shashank Sharma 
>>> ---
>>> drivers/gpu/drm/i915/intel_hdmi.c | 22 ++
>>> 1 file changed, 14 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
>>> b/drivers/gpu/drm/i915/intel_hdmi.c
>>> index e2dab48..d24d18a 100644
>>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>>> @@ -1397,7 +1397,8 @@ intel_hdmi_detect(struct drm_connector 
>>> *connector, bool force)
>>> enum drm_connector_status status;
>>> struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>>> struct drm_i915_private *dev_priv = to_i915(connector->dev);
>>> -   bool live_status = false;
>>> +   struct drm_device *dev = connector->dev;
>>> +   bool live_status = true;
>>> unsigned int try;
>>>
>>> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
>>> @@ -1405,16 +1406,21 @@ intel_hdmi_detect(struct drm_connector 
>>> *connector, bool force)
>>>
>>> intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
>>>
>>> -   for (try = 0; !live_status && try < 9; try++) {
>>> -   if (try)
>>> -   msleep(10);
>>> -   live_status = intel_digital_port_connected(dev_priv,
>>> +   /*
>>> +   * Live status check for HDMI detection is not very
>>> +   * reliable on older platforms. So insist the live
>>> +   * status check for EDID read from VLV onwards.
>>> +   */
>>> +   if (INTEL_INFO(dev)->gen >= 7 && !IS_IVYBRIDGE(dev)) {
>>> +   for (try = 0; !live_status && try < 9; try++) {
>>> +   if (try)
>>> +   msleep(10);
>>> +   live_status = 
>>> intel_digital_port_connected(dev_priv,
>>> hdmi_to_dig_port(intel_hdmi));
>>> +   }
>>> +   DRM_DEBUG_KMS("Live status %s\n", live_status ? "up" : 
>>> "down");
>>> }
>>>
>>> -   if (!live_status)
>>> -   DRM_DEBUG_KMS("Live status not up!");
>>> -
>>
>> As I said before, I think this whole thing could be solved with a simple
>> two-liner here:
>>
>> +if (...)
>> +live_status = true;
>>
> Yes I remember, and I replied on that already that why we would like to
> keep the live status check. In fact I would be ok to remove this check
> if you can suggest some other way of making this work for other
> operating systems/sw platforms.

 My two liner would keep the check.

>>> Sorry, I might have not understood you properly.
>>> Do you mean:
>>> if (INTEL_INFO(dev)->gen < 7 && IS_IVYBRIDGE(dev)) {
>>> live_status = true;
>>> } else {
>>> do the same looping for retry;
>>> }
>>
>> No, I mean
>>
>> {
>>  ...
>>  do loop;
>>
>>  if (!live_status)
>>  DRM_DEBUG_KMS("Live status not up!");
>>
>> +if (don't trust live status)
>> +live_status = true;
>>  
>>  intel_hdmi_unset_edid();
>>  
>>  if (intel_hdmi_set_edid(live_status)) {
>>  ...
>> }
>>
>>
> In fact, this is what I have done.
> If you see the change in this patch,

Actually, not. You set live_status to true in the beginning, and your
loop condition has !live_status, i.e. you won't check live status even
once on any platform. Which is what I said in my review.

BR,
Jani.


>   /* Lets make live status true for < VLV platforms */
>   bool live_status = true;
>
>   blah
>   blah
>
>   /* Check live 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/csr: Allow matching unknown HW steppings with generic firmware

[Imre Deak]

On Mon, 2016-03-07 at 16:24 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/csr: Allow matching unknown HW steppings with
> generic firmware
> URL   : https://patchwork.freedesktop.org/series/4173/
> State : failure
> 
> == Summary ==
> 
> Series 4173v1 drm/i915/csr: Allow matching unknown HW steppings with
> generic firmware
> http://patchwork.freedesktop.org/api/1.0/series/4173/revisions/1/mbox
> /
> 
> Test gem_mmap_gtt:
> Subgroup basic-small-bo-tiledx:
> pass   -> FAIL   (ilk-hp8440p)

Unrelated platform, I opened a new bug:
https://bugs.freedesktop.org/show_bug.cgi?id=94571

> Test gem_sync:
> Subgroup basic-all:
> pass   -> DMESG-FAIL (ilk-hp8440p)

Unrelated platform, could be related to:
https://bugs.freedesktop.org/show_bug.cgi?id=94307

> Subgroup basic-bsd:
> dmesg-fail -> PASS   (ilk-hp8440p)
> Test kms_flip:
> Subgroup basic-flip-vs-modeset:
> pass   -> DMESG-WARN (skl-i5k-2)

Unrelated platform, I opened a new bug:
https://bugs.freedesktop.org/show_bug.cgi?id=94572

> dmesg-warn -> PASS   (bdw-ultra)
> Subgroup basic-flip-vs-wf_vblank:
> pass   -> DMESG-WARN (hsw-gt2)

Watermark programming while not powered, to be fixed by Matt's patch on
the list.

> Test kms_force_connector_basic:
> Subgroup force-edid:
> skip   -> PASS   (ilk-hp8440p)
> Test kms_frontbuffer_tracking:
> Subgroup basic:
> pass   -> DMESG-WARN (snb-x220t)
> pass   -> DMESG-WARN (hsw-gt2)

The same as the above watermark programming problem.

> dmesg-warn -> PASS   (hsw-brixbox)
> Test kms_pipe_crc_basic:
> Subgroup hang-read-crc-pipe-a:
> skip   -> PASS   (hsw-brixbox)
> Subgroup suspend-read-crc-pipe-a:
> pass   -> SKIP   (hsw-gt2)
> Subgroup suspend-read-crc-pipe-c:
> dmesg-warn -> PASS   (bsw-nuc-2)
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> pass   -> DMESG-WARN (snb-dellxps)

The above Watermark programming problem.

> Subgroup basic-rte:
> dmesg-warn -> PASS   (snb-x220t)
> dmesg-warn -> PASS   (bsw-nuc-2)
> 
> bdw-
> nuci7total:183  pass:172  dwarn:0   dfail:0   fail:0   skip:1
> 1 
> bdw-
> ultratotal:183  pass:165  dwarn:0   dfail:0   fail:0   skip:1
> 8 
> bsw-nuc-
> 2total:183  pass:149  dwarn:0   dfail:0   fail:0   skip:34 
> byt-
> nuc  total:183  pass:152  dwarn:0   dfail:0   fail:0   skip:3
> 1 
> hsw-
> brixbox  total:183  pass:164  dwarn:0   dfail:0   fail:0   skip:1
> 9 
> hsw-
> gt2  total:183  pass:166  dwarn:2   dfail:0   fail:0   skip:1
> 5 
> ilk-
> hp8440p  total:183  pass:122  dwarn:1   dfail:1   fail:1   skip:5
> 8 
> ivb-
> t430stotal:183  pass:162  dwarn:0   dfail:0   fail:0   skip:2
> 1 
> skl-i5k-
> 2total:183  pass:162  dwarn:1   dfail:0   fail:0   skip:20 
> skl-i7k-
> 2total:183  pass:163  dwarn:0   dfail:0   fail:0   skip:20 
> snb-
> dellxps  total:183  pass:152  dwarn:2   dfail:0   fail:0   skip:2
> 9 
> snb-
> x220ttotal:183  pass:153  dwarn:1   dfail:1   fail:0   skip:2
> 8 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_1535/
> 
> 81c9b9181265e083b7e2bb31ac8701bf57774657 drm-intel-nightly: 2016y-
> 03m-07d-15h-43m-50s UTC integration manifest
> 26beb3d09a245443974979bcf2dea7f0b6f18c9a drm/i915/csr: Allow matching
> unknown HW steppings with generic firmware
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Fix race condition in intel_dp_destroy_mst_connector()

[Lyude]

After unplugging a DP MST display from the system, we have to go through
and destroy all of the DRM connectors associated with it since none of
them are valid anymore. Unfortunately, intel_dp_destroy_mst_connector()
doesn't do a good enough job of ensuring that throughout the destruction
process that no modesettings can be done with the connectors. As it is
right now, intel_dp_destroy_mst_connector() works like this:

* Take all modeset locks
* Clear the configuration of the crtc on the connector, if there is one
* Drop all modeset locks, this is required because of circular
  dependency issues that arise with trying to remove the connector from
  sysfs with modeset locks held
* Unregister the connector
* Take all modeset locks, again
* Do the rest of the required cleaning for destroying the connector
* Finally drop all modeset locks for good

This only works sometimes. During the destruction process, it's very
possible that a userspace application will attempt to do a modesetting
using the connector. When we drop the modeset locks, an ioctl handler
such as drm_mode_setcrtc has the oppurtunity to take all of the modeset
locks from us. When this happens, one thing leads to another and
eventually we end up committing a mode with the non-existent connector:

[drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to 
enable link training
[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
[drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel 
equalization
[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
[drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi

And in some cases, such as with the T460s using an MST dock, this
results in breaking modesetting and/or panicking the system.

To work around this, we now unregister the connector at the very
beginning of intel_dp_destroy_mst_connector(), grab all the modesetting
locks, and then hold them until we finish the rest of the function.

CC: sta...@vger.kernel.org
Signed-off-by: Lyude 
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/i915/intel_dp_mst.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index fa0dabf..b21ac88 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -499,6 +499,8 @@ static void intel_dp_destroy_mst_connector(struct 
drm_dp_mst_topology_mgr *mgr,
struct intel_connector *intel_connector = to_intel_connector(connector);
struct drm_device *dev = connector->dev;
 
+   intel_connector->unregister(intel_connector);
+
/* need to nuke the connector */
drm_modeset_lock_all(dev);
if (connector->state->crtc) {
@@ -512,11 +514,7 @@ static void intel_dp_destroy_mst_connector(struct 
drm_dp_mst_topology_mgr *mgr,
 
WARN(ret, "Disabling mst crtc failed with %i\n", ret);
}
-   drm_modeset_unlock_all(dev);
 
-   intel_connector->unregister(intel_connector);
-
-   drm_modeset_lock_all(dev);
intel_connector_remove_from_fbdev(intel_connector);
drm_connector_cleanup(connector);
drm_modeset_unlock_all(dev);
-- 
2.5.0

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for Split driver init step to phases (rev3)

[Patchwork]

== Series Details ==

Series: Split driver init step to phases (rev3)
URL   : https://patchwork.freedesktop.org/series/4509/
State : warning

== Summary ==

Series 4509v3 Split driver init step to phases
http://patchwork.freedesktop.org/api/1.0/series/4509/revisions/3/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (bdw-ultra)
pass   -> DMESG-WARN (skl-i7k-2)
pass   -> DMESG-WARN (snb-x220t)
pass   -> DMESG-WARN (skl-nuci5)
pass   -> DMESG-WARN (bdw-nuci7)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
dmesg-warn -> PASS   (bdw-ultra)
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (snb-x220t)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b:
pass   -> DMESG-WARN (bdw-ultra)
Subgroup read-crc-pipe-b-frame-sequence:
dmesg-warn -> PASS   (snb-x220t)
Subgroup read-crc-pipe-c-frame-sequence:
dmesg-warn -> PASS   (hsw-gt2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
fail   -> DMESG-FAIL (snb-x220t)

bdw-nuci7total:194  pass:181  dwarn:1   dfail:0   fail:0   skip:12 
bdw-ultratotal:194  pass:171  dwarn:2   dfail:0   fail:0   skip:21 
bsw-nuc-2total:194  pass:155  dwarn:2   dfail:0   fail:0   skip:37 
byt-nuc  total:194  pass:155  dwarn:4   dfail:0   fail:0   skip:35 
hsw-gt2  total:194  pass:176  dwarn:1   dfail:0   fail:0   skip:17 
skl-i5k-2total:194  pass:170  dwarn:1   dfail:0   fail:0   skip:23 
skl-i7k-2total:194  pass:170  dwarn:1   dfail:0   fail:0   skip:23 
skl-nuci5total:194  pass:182  dwarn:1   dfail:0   fail:0   skip:11 
snb-x220ttotal:194  pass:159  dwarn:1   dfail:1   fail:0   skip:33 

Results at /archive/results/CI_IGT_test/Patchwork_1625/

8a9a911d489fe160df173580277983dac5952ed0 drm-intel-nightly: 
2016y-03m-17d-10h-02m-10s UTC integration manifest
b99e15d212c0d3595ccb0ce6cc20f627f237e69d drm/i915: Add fault injection support
708025ddfa837b37845b20d05af3c73bc0c7708e drm/i915: Fix power domain HW state 
cleanup on error path
54ae37dff154475dfe58998bfbedad9ec837321c drm/i915: Split out load time 
interface registration
ad31b795a1f0d8901700ecbd63f943463d09fafa drm/i915: Split out load time HW 
initialization
feac61f9eb8031a61ae9734e83e9fc9b0949c6b0 drm/i915: Split out load time MMIO 
initialization
69df569ebb5e3f93654526f1a03efb9703d82f94 drm/i915: Split out load time early 
initialization
a21acc33f9510155bcc1a5001d2e2c11943b715a drm/i915: Move unload time opregion 
unregistration earlier
0a5a224a5da3cfd1c0e7d3e927ceefdb894083ca drm/i915: Move unload time GTT, MSI 
IRQ cleanup later
50da5444e07e95c40ceae1eb6521ba19214fb2c0 drm/i915: Move unload time display 
power domain uninit later
ac894e86af964f1902a13cbf8e4ac6c82b8e383d drm/i915: Move load time audio 
component registration earlier
238ec5f2a1fa9180fbcbb1e19d44d9a69e84fd3e drm/i915: Move load time shrinker 
registration later
6fc3970b4da1f5131ad2a04345537e101a92cd16 drm/i915: Move load time runtime PM 
get later
f1c9058738a0b840385e9bbe80011a97238dfd5d drm/i915: Move load time gem_load_init 
earlier
6d19d18371db8aa0ecd3a6165c82be9c3d785a0f drm/i915: Move load time runtime 
device info init earlier
58c8dfd1314f0933a1fd7e710060617d3896a198 drm/i915: Move load time init of clock 
gating hooks earlier
13d5acf73a511929c6a5a17974e82b7e87cdd191 drm/i915: Move load time init of 
display/audio hooks earlier
620da462f78e10859a5e377ff974fee178099458 drm/i915: Move load time IRQ SW init 
earlier
da4d68b2404298afb9b4d44c3aed415b76fc3488 drm/i915: Move load time PCH detect, 
DPIO, power domain SW init earlier
145e6345dbd7b52172a7280f5c92d31019f4b8ef Fix MCHBAR cleanup on the driver init 
error path

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

[Intel-gfx] [PATCH resend for CI 2/2] drm/i915: Use shorter route to dev_private where possible

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Where we have a request we can use req->i915 directly instead
of going through the engine and device. Coccinelle script:

@@
function f;
identifier r;
@@
f(..., struct drm_i915_gem_request *r, ...)
{
...
- engine->dev->dev_private
+ r->i915
...
}
@@
struct drm_i915_gem_request *req;
@@
(
  req->
- engine->dev->dev_private
+ i915
)

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 2 +-
 drivers/gpu/drm/i915/i915_gem_context.c | 4 ++--
 drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
 drivers/gpu/drm/i915/intel_lrc.c| 2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9c4d9c186d91..042cb412e652 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2550,7 +2550,7 @@ void __i915_add_request(struct drm_i915_gem_request 
*request,
return;
 
engine = request->engine;
-   dev_priv = engine->dev->dev_private;
+   dev_priv = request->i915;
ringbuf = request->ringbuf;
 
/*
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 1993449ab7c5..6a3b4553119e 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -656,7 +656,7 @@ static int do_switch(struct drm_i915_gem_request *req)
 {
struct intel_context *to = req->ctx;
struct intel_engine_cs *engine = req->engine;
-   struct drm_i915_private *dev_priv = engine->dev->dev_private;
+   struct drm_i915_private *dev_priv = req->i915;
struct intel_context *from = engine->last_context;
u32 hw_flags = 0;
bool uninitialized = false;
@@ -829,7 +829,7 @@ unpin_out:
 int i915_switch_context(struct drm_i915_gem_request *req)
 {
struct intel_engine_cs *engine = req->engine;
-   struct drm_i915_private *dev_priv = engine->dev->dev_private;
+   struct drm_i915_private *dev_priv = req->i915;
 
WARN_ON(i915.enable_execlists);
WARN_ON(!mutex_is_locked(_priv->dev->struct_mutex));
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 9c752fe0f730..fb0f9637d46f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2192,7 +2192,7 @@ int i915_ppgtt_init_hw(struct drm_device *dev)
 
 int i915_ppgtt_init_ring(struct drm_i915_gem_request *req)
 {
-   struct drm_i915_private *dev_priv = req->engine->dev->dev_private;
+   struct drm_i915_private *dev_priv = req->i915;
struct i915_hw_ppgtt *ppgtt = dev_priv->mm.aliasing_ppgtt;
 
if (i915.enable_execlists)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f72782200226..7c636b3db156 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -897,7 +897,7 @@ int intel_logical_ring_begin(struct drm_i915_gem_request 
*req, int num_dwords)
int ret;
 
WARN_ON(req == NULL);
-   dev_priv = req->engine->dev->dev_private;
+   dev_priv = req->i915;
 
ret = i915_gem_check_wedge(_priv->gpu_error,
   dev_priv->mm.interruptible);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 015dc7db32b7..b7c8fc1a73a3 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2499,7 +2499,7 @@ int intel_ring_begin(struct drm_i915_gem_request *req,
 
WARN_ON(req == NULL);
engine = req->engine;
-   dev_priv = engine->dev->dev_private;
+   dev_priv = req->i915;
 
ret = i915_gem_check_wedge(_priv->gpu_error,
   dev_priv->mm.interruptible);
-- 
1.9.1

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

[Intel-gfx] [PATCH] drm/i915: add sanity check for partial view creation

[Matthew Auld]

Upon creating a partial view we should check that the offset + size is
valid relative to the size of the gem object.

v2:
(Tvrtko Ursulin)
- Don't use pages->nents to determine the page count
v3:
(Chris Wilson)
- Handle potential overflow
v4:
(Chris Wilson)
- Idiomatically handle overflow
- Less idiotic placement
- Treat as programmer error

Cc: Joonas Lahtinen 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index fb0f963..593eb15 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3356,6 +3356,14 @@ i915_gem_obj_lookup_or_create_ggtt_vma(struct 
drm_i915_gem_object *obj,
if (WARN_ON(!view))
return ERR_PTR(-EINVAL);
 
+   if (view->type == I915_GGTT_VIEW_PARTIAL) {
+   unsigned int page_count = obj->base.size >> PAGE_SHIFT;
+   if (WARN_ON(view->params.partial.offset > page_count ||
+   view->params.partial.size > page_count  -
+   view->params.partial.offset))
+   return ERR_PTR(-EINVAL);
+   }
+
vma = i915_gem_obj_to_ggtt_view(obj, view);
 
if (IS_ERR(vma))
-- 
2.4.3

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

Re: [Intel-gfx] [PATCH] drm/i915: Modify reset func to handle per engine resets

[Chris Wilson]

On Wed, Mar 16, 2016 at 01:52:04PM +0200, Mika Kuoppala wrote:
> In full gpu reset we prime all engines and reset domains corresponding to
> each engine. Per engine reset is just a special case of this process
> wherein only a single engine is reset. This change is aimed to modify
> relevant functions to achieve this. There are some other steps we carry out
> in case of engine reset which are addressed in later patches.
> 
> Reset func now accepts a mask of all engines that need to be reset. Where
> per engine resets are supported, error handler populates the mask
> accordingly otherwise all engines are specified.
> 
> v2: ALL_ENGINES mask fixup, better for_each_ring_masked (Chris)
> 
> Cc: Chris Wilson 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index b854af2c4141..68d766af2ed0 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -5018,7 +5018,7 @@ i915_gem_cleanup_ringbuffer(struct drm_device *dev)
>   * expects the system to be in execlists mode on startup,
>   * so we need to reset the GPU back to legacy mode.
>   */
> -intel_gpu_reset(dev);
> + intel_gpu_reset(dev, ALL_ENGINES);

Hmm, whitespace cleanup required around here?

> +/**
> + * gen6_reset_engines - reset individual engines
> + * @dev: DRM device
> + * @engine_mask: mask of intel_ring_flag() engines or ALL_ENGINES for full 
> reset
> + *
> + * This function will reset the individual engines that are set in 
> engine_mask.
> + * If you provide ALL_ENGINES as mask, full global domain reset will be 
> issued.
> + *
> + * Note: It is responsibility of the caller to handle the difference between
> + * asking full domain reset versus reset for all available individual 
> engines.
> + *
> + * Returns 0 on success, nonzero on error.
> + */
> +static int gen6_reset_engines(struct drm_device *dev, unsigned engine_mask)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_engine_cs *engine;
> + const u32 hw_engine_mask[I915_NUM_RINGS] = {
> + [RCS] = GEN6_GRDOM_RENDER,
> + [BCS] = GEN6_GRDOM_BLT,
> + [VCS] = GEN6_GRDOM_MEDIA,
> + [VCS2] = GEN8_GRDOM_MEDIA2,
> + [VECS] = GEN6_GRDOM_VECS,
> + };
> + int ret;
> + u32 hw_mask;

u32 hw_mask;
int ret;

looks neater;

>  
> - /* Spin waiting for the device to ack the reset request */
> - ret = wait_for((__raw_i915_read32(dev_priv, GEN6_GDRST) & 
> GEN6_GRDOM_FULL) == 0, 500);
> + if (engine_mask == ALL_ENGINES) {
> + hw_mask = GEN6_GRDOM_FULL;
> + } else {
> + hw_mask = 0;
> +
and this whitespace doesn't help since this block is entirely about the
computation of hw_mask

That's the sum total of my criticism.
Reviewed-by: Chris Wilson 
-Chris

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Rename local struct intel_engine_cs variables

[Tvrtko Ursulin]

On 16/03/16 15:56, Daniel Vetter wrote:

On Wed, Mar 16, 2016 at 4:45 PM, Tvrtko Ursulin
 wrote:

On 16/03/16 15:40, Ville Syrjälä wrote:


On Wed, Mar 16, 2016 at 03:35:13PM +, Tvrtko Ursulin wrote:



On 16/03/16 15:01, Patchwork wrote:


== Series Details ==

Series: series starting with [1/5] drm/i915: Rename local struct
intel_engine_cs variables
URL   : https://patchwork.freedesktop.org/series/4508/
State : failure

== Summary ==

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

Test drv_module_reload_basic:
   skip   -> PASS   (bdw-nuci7)
Test kms_flip:
   Subgroup basic-flip-vs-wf_vblank:
   pass   -> FAIL   (ivb-t430s)



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



I'd like people to add a bit more information to these analysis mails.
If there's just the bugzilla link I actually have to open it before
I can see what the problem was. Makes it harder to keep on top what
the most common BAT problems are.



Yeah in principle I agree but some of these are the usual suspects which
have been dragging for so long it would take an iron will (or something
nastier) to keep repeating the same analysis over and over again.


Someone is asking for a really nasty maintainer to provide motivation?

More seriously I'm not entirely sure how we can get out of
this "CI seems constantly broken" place :(


I've noticed people are working on some of those constant naggers so 
perhaps there is light at the end of the tunnel.


Key is having the right hardware, and IMHO, assigning people to critical 
BAT tagged Bugzilla's. There is plenty of those, with more or less links 
to CI failure example, so it looks to me there is certainly enough 
material already.


Regards,

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Rename local struct intel_engine_cs variables

[Daniel Vetter]

On Wed, Mar 16, 2016 at 4:45 PM, Tvrtko Ursulin
 wrote:
> On 16/03/16 15:40, Ville Syrjälä wrote:
>>
>> On Wed, Mar 16, 2016 at 03:35:13PM +, Tvrtko Ursulin wrote:
>>>
>>>
>>> On 16/03/16 15:01, Patchwork wrote:

 == Series Details ==

 Series: series starting with [1/5] drm/i915: Rename local struct
 intel_engine_cs variables
 URL   : https://patchwork.freedesktop.org/series/4508/
 State : failure

 == Summary ==

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

 Test drv_module_reload_basic:
   skip   -> PASS   (bdw-nuci7)
 Test kms_flip:
   Subgroup basic-flip-vs-wf_vblank:
   pass   -> FAIL   (ivb-t430s)
>>>
>>>
>>> Unrelated https://bugs.freedesktop.org/show_bug.cgi?id=94294
>>
>>
>> I'd like people to add a bit more information to these analysis mails.
>> If there's just the bugzilla link I actually have to open it before
>> I can see what the problem was. Makes it harder to keep on top what
>> the most common BAT problems are.
>
>
> Yeah in principle I agree but some of these are the usual suspects which
> have been dragging for so long it would take an iron will (or something
> nastier) to keep repeating the same analysis over and over again.

Someone is asking for a really nasty maintainer to provide motivation?

More seriously I'm not entirely sure how we can get out of
this "CI seems constantly broken" place :(
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: Codify our assumption that the Global GTT is <= 4GiB

[Mika Kuoppala]

Joonas Lahtinen  writes:

> [ text/plain ]
> From: Chris Wilson 
>
> Throughout the code base, we use u32 for offsets into the global GTT. If
> we ever see any hardware with a larger GGTT, then we run the real risk
> of silent corruption. So test for our assumption up front so that we
> have a nice reminder should the time come when it fails.
>
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Signed-off-by: Joonas Lahtinen 
> [Rebased and changed 1ull -> 1ULL]
> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 8a9fa03..ba144ba 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3191,6 +3191,13 @@ int i915_gem_gtt_init(struct drm_device *dev)
>   if (ret)
>   return ret;
>  
> + if ((ggtt->base.total - 1) >> 32) {
> + DRM_ERROR("We never expected a Global GTT with more than 32bits 
> of address space! Found %lldM!\n",
> +   ggtt->base.total >> 20);
> + ggtt->base.total = 1ULL << 32;
> + ggtt->mappable_end = min(ggtt->mappable_end,
> ggtt->base.total);

mappable_end is not u64 so perhaps 
s/min/min_t(u64,

The mappable_end is really confusing after you realize it is used in 2
different contexts where only in the other, it holds true. In the pa
space, it definitely is not end but len. If we would rename it to
mappable_len it would be ambivalent to context and more clear.

With min_t change,
Reviewed-by: Mika Kuoppala 

> + }
> +
>   /*
>* Initialise stolen early so that we may reserve preallocated
>* objects for the BIOS to KMS transition.
> -- 
> 2.5.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH RESEND 7/7] drm/i915: hide away VBT private data in a separate header

[Daniel Vetter]

On Wed, Mar 16, 2016 at 12:43:35PM +0200, Jani Nikula wrote:
> We've been accumulating code across the driver that depends on the VBT
> specific structures and defines. The VBT is an uncontrollable
> beast. Encourage encapsulation of the VBT data by hiding the structures
> and defines in a private header only to be included from intel_bios.c.
> 
> Signed-off-by: Jani Nikula 

Not going to check in detail whether you copypasted the structs correctly
(I think I've done that once before already, where was my r-b lost!). With
that caveat:

Reviewed-by: Daniel Vetter 

> ---
>  Documentation/DocBook/gpu.tmpl|   2 +-
>  drivers/gpu/drm/i915/intel_bios.c |   4 +-
>  drivers/gpu/drm/i915/intel_bios.h | 861 
> ++
>  drivers/gpu/drm/i915/intel_vbt_defs.h | 826 
>  4 files changed, 865 insertions(+), 828 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_vbt_defs.h
> 
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index 1692c4dd5487..ab7ffebf4b95 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -3334,7 +3334,7 @@ int num_ioctls;
>   Video BIOS Table (VBT)
>  !Pdrivers/gpu/drm/i915/intel_bios.c Video BIOS Table (VBT)
>  !Idrivers/gpu/drm/i915/intel_bios.c
> -!Idrivers/gpu/drm/i915/intel_bios.h
> +!Idrivers/gpu/drm/i915/intel_vbt_defs.h
>
>  
>  
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index aa90dc662e7f..083003b015f5 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -29,7 +29,9 @@
>  #include 
>  #include 
>  #include "i915_drv.h"
> -#include "intel_bios.h"
> +
> +#define _INTEL_BIOS_PRIVATE
> +#include "intel_vbt_defs.h"
>  
>  /**
>   * DOC: Video BIOS Table (VBT)
> diff --git a/drivers/gpu/drm/i915/intel_bios.h 
> b/drivers/gpu/drm/i915/intel_bios.h
> index 350d4e0f75a4..ab0ea315eddb 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright © 2006 Intel Corporation
> + * Copyright © 2016 Intel Corporation
>   *
>   * Permission is hereby granted, free of charge, to any person obtaining a
>   * copy of this software and associated documentation files (the "Software"),
> @@ -19,543 +19,16 @@
>   * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
> FROM,
>   * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
> THE
>   * SOFTWARE.
> - *
> - * Authors:
> - *Eric Anholt 
> - *
> - */
> -
> -#ifndef _INTEL_BIOS_H_
> -#define _INTEL_BIOS_H_
> -
> -/**
> - * struct vbt_header - VBT Header structure
> - * @signature:   VBT signature, always starts with "$VBT"
> - * @version: Version of this structure
> - * @header_size: Size of this structure
> - * @vbt_size:Size of VBT (VBT Header, BDB Header and data 
> blocks)
> - * @vbt_checksum:Checksum
> - * @reserved0:   Reserved
> - * @bdb_offset:  Offset of  bdb_header from beginning of 
> VBT
> - * @aim_offset:  Offsets of add-in data blocks from beginning of 
> VBT
> - */
> -struct vbt_header {
> - u8 signature[20];
> - u16 version;
> - u16 header_size;
> - u16 vbt_size;
> - u8 vbt_checksum;
> - u8 reserved0;
> - u32 bdb_offset;
> - u32 aim_offset[4];
> -} __packed;
> -
> -/**
> - * struct bdb_header - BDB Header structure
> - * @signature:   BDB signature "BIOS_DATA_BLOCK"
> - * @version: Version of the data block definitions
> - * @header_size: Size of this structure
> - * @bdb_size:Size of BDB (BDB Header and data blocks)
> - */
> -struct bdb_header {
> - u8 signature[16];
> - u16 version;
> - u16 header_size;
> - u16 bdb_size;
> -} __packed;
> -
> -/* strictly speaking, this is a "skip" block, but it has interesting info */
> -struct vbios_data {
> - u8 type; /* 0 == desktop, 1 == mobile */
> - u8 relstage;
> - u8 chipset;
> - u8 lvds_present:1;
> - u8 tv_present:1;
> - u8 rsvd2:6; /* finish byte */
> - u8 rsvd3[4];
> - u8 signon[155];
> - u8 copyright[61];
> - u16 code_segment;
> - u8 dos_boot_mode;
> - u8 bandwidth_percent;
> - u8 rsvd4; /* popup memory size */
> - u8 resize_pci_bios;
> - u8 rsvd5; /* is crt already on ddc2 */
> -} __packed;
> -
> -/*
> - * There are several types of BIOS data blocks (BDBs), each block has
> - * an ID and size in the first 3 bytes (ID in first, size in next 2).
> - * Known types are listed below.
>   */
> -#define BDB_GENERAL_FEATURES   1
> -#define BDB_GENERAL_DEFINITIONS2
> -#define BDB_OLD_TOGGLE_LIST3
> -#define BDB_MODE_SUPPORT_LIST  4
> -#define BDB_GENERIC_MODE_TABLE 5
> -#define BDB_EXT_MMIO_REGS  6
> -#define 

Re: [Intel-gfx] [PATCH] drm/i915: Restrict usage of live status check

[Ville Syrjälä]

On Thu, Mar 17, 2016 at 10:03:04PM +0530, Sharma, Shashank wrote:
> Hey Chris,
> I added comments for both Ville and you, please help me to understand this.
> 
> Regards
> Shashank
> 
> On 3/17/2016 9:51 PM, Ville Syrjälä wrote:
> > On Thu, Mar 17, 2016 at 09:35:30PM +0530, Sharma, Shashank wrote:
> >> Regards
> >> Shashank
> >>
> >> On 3/17/2016 9:31 PM, Ville Syrjälä wrote:
> >>> On Thu, Mar 17, 2016 at 09:15:39PM +0530, Sharma, Shashank wrote:
>  Regards
>  Shashank
> 
>  On 3/17/2016 6:34 PM, Ville Syrjälä wrote:
> > On Thu, Mar 17, 2016 at 01:29:25PM +0530, Shashank Sharma wrote:
> >> This patch restricts usage of live status check for HDMI detection.
> >> While testing certain (monitor + cable) combinations with various
> >> intel  platforms, it seems that live status register is not reliable
> >> on some older devices. So limit the live_status check from VLV onwards.
> >>
> >> This fixes a regression introduced in:
> >>commit: 237ed86 "drm/i915: Check live status"
> >>Author: Sonika Jindal 
> >>Date:   Tue Sep 15 09:44:20 2015 +0530
> >>
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >> drivers/gpu/drm/i915/intel_hdmi.c | 22 ++
> >> 1 file changed, 14 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> >> b/drivers/gpu/drm/i915/intel_hdmi.c
> >> index e2dab48..d24d18a 100644
> >> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> >> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> >> @@ -1397,7 +1397,8 @@ intel_hdmi_detect(struct drm_connector 
> >> *connector, bool force)
> >>enum drm_connector_status status;
> >>struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> >>struct drm_i915_private *dev_priv = to_i915(connector->dev);
> >> -  bool live_status = false;
> >> +  struct drm_device *dev = connector->dev;
> >> +  bool live_status = true;
> >>unsigned int try;
> >>
> >>DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> >> @@ -1405,16 +1406,21 @@ intel_hdmi_detect(struct drm_connector 
> >> *connector, bool force)
> >>
> >>intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
> >>
> >> -  for (try = 0; !live_status && try < 9; try++) {
> >> -  if (try)
> >> -  msleep(10);
> >> -  live_status = intel_digital_port_connected(dev_priv,
> >> +  /*
> >> +  * Live status check for HDMI detection is not very
> >> +  * reliable on older platforms. So insist the live
> >> +  * status check for EDID read from VLV onwards.
> >> +  */
> >> +  if (INTEL_INFO(dev)->gen >= 7 && !IS_IVYBRIDGE(dev)) {
> >> +  for (try = 0; !live_status && try < 9; try++) {
> >> +  if (try)
> >> +  msleep(10);
> >> +  live_status = 
> >> intel_digital_port_connected(dev_priv,
> >>hdmi_to_dig_port(intel_hdmi));
> >> +  }
> >> +  DRM_DEBUG_KMS("Live status %s\n", live_status ? "up" : 
> >> "down");
> >>}
> >>
> >> -  if (!live_status)
> >> -  DRM_DEBUG_KMS("Live status not up!");
> >> -
> >
> > As I said before, I think this whole thing could be solved with a simple
> > two-liner here:
> >
> > +   if (...)
> > +   live_status = true;
> >
>  Yes I remember, and I replied on that already that why we would like to
>  keep the live status check. In fact I would be ok to remove this check
>  if you can suggest some other way of making this work for other
>  operating systems/sw platforms.
> >>>
> >>> My two liner would keep the check.
> >>>
> >> Sorry, I might have not understood you properly.
> >> Do you mean:
> >>if (INTEL_INFO(dev)->gen < 7 && IS_IVYBRIDGE(dev)) {
> >>live_status = true;
> >>} else {
> >>do the same looping for retry;
> >>}
> >
> > No, I mean
> >
> > {
> > ...
> > do loop;
> >
> > if (!live_status)
> > DRM_DEBUG_KMS("Live status not up!");
> >
> > +   if (don't trust live status)
> > +   live_status = true;
> > 
> > intel_hdmi_unset_edid();
> > 
> > if (intel_hdmi_set_edid(live_status)) {
> > ...
> > }
> >
> >
> In fact, this is what I have done.
> If you see the change in this patch,
>   /* Lets make live status true for < VLV platforms */
>   bool live_status = true;
> 
>   blah
>   blah
> 
>   /* Check live status only for newer platforms */
>   if (this is VLV or later platforms) {
>   live_status = read_real_live_status();
>   }
>   

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2] mm/vmap: Add a notifier for when we run out of vmap address space (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v2] mm/vmap: Add a notifier for when we run out 
of vmap address space (rev2)
URL   : https://patchwork.freedesktop.org/series/4569/
State : failure

== Summary ==

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

Test gem_ringfill:
Subgroup basic-default-s3:
dmesg-warn -> PASS   (skl-nuci5)
Test gem_storedw_loop:
Subgroup basic-default:
dmesg-warn -> PASS   (skl-nuci5)
Test gem_sync:
Subgroup basic-vebox:
dmesg-warn -> PASS   (skl-nuci5)
Test kms_flip:
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (hsw-gt2)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (hsw-gt2)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (bsw-nuc-2)
Test pm_rpm:
Subgroup basic-rte:
pass   -> DMESG-WARN (bsw-nuc-2)

bdw-ultratotal:194  pass:172  dwarn:1   dfail:0   fail:0   skip:21 
bsw-nuc-2total:194  pass:155  dwarn:2   dfail:0   fail:0   skip:37 
hsw-brixbox  total:194  pass:171  dwarn:1   dfail:0   fail:0   skip:22 
hsw-gt2  total:194  pass:174  dwarn:3   dfail:0   fail:0   skip:17 
ivb-t430stotal:194  pass:168  dwarn:1   dfail:0   fail:0   skip:25 
skl-i5k-2total:194  pass:170  dwarn:1   dfail:0   fail:0   skip:23 
skl-i7k-2total:194  pass:170  dwarn:1   dfail:0   fail:0   skip:23 
skl-nuci5total:194  pass:182  dwarn:1   dfail:0   fail:0   skip:11 

Results at /archive/results/CI_IGT_test/Patchwork_1634/

10e913a48ca36790da9b58bed8729598ea79ebdb drm-intel-nightly: 
2016y-03m-17d-13h-22m-41s UTC integration manifest
7b584cab867d352cfb0810c6bc9ea234b455783e drm/i915/shrinker: Hook up vmap 
allocation failure notifier
9cace0d9d9756314b9a049b5314642e59f91fd5d mm/vmap: Add a notifier for when we 
run out of vmap address space

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

[Intel-gfx] [PATCH 2/2] drm/i915: Render decompression support for Gen9 and above

[Vandana Kannan]

This patch includes enabling render decompression (RC) after checking all the
requirements (format, tiling, rotation etc.). Along with this, the WAs
mentioned in BSpec Workaround page have been implemented.

TODO:
1. Disable stereo 3D when render decomp is enabled (bit 7:6)
2. Render decompression must not be used in VTd pass-through mode
3. Program hashing select CHICKEN_MISC1 bit 15
4. For Gen10, add support for RGB 1010102
5. RC-FBC workaround
6. RC watermark calculation

The reason for using a plane property instead of fb modifier:-
In Android, OGL passes a render compressed buffer to hardware composer (HWC),
which would then request a flip on that buffer after checking if the target
can support render compressed buffer. For example, only planes 1 and 2 on
pipes 1 and 2 can support RC. In case the target cannot support it, HWC will
revert back to OGL requesting for uncompressed buffer.
Here,
if plane property is used, OGL would send back the buffer (same ID) after
decompression, marked uncompressed. If fb modifier was used, a different
version of the buffer would have to be maintained for different combinations -
in the simple case of render compressed vs uncompressed buffer, there would be
2 fbs with 2 IDs. So, in this case, OGL would give a reference to a fb with a
different ID.
To avoid the difficulty of keeping track of multiple fbs and the subsequent
complexity in debug, the architecture forum decided to go ahead with a plane
property for RC.

[Mayuresh] Added the plane check in skl_check_compression()

Signed-off-by: Vandana Kannan 
Cc: Smith, Gary K 
Cc: Daniel Stone 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.h   |   1 +
 drivers/gpu/drm/i915/i915_reg.h   |  22 
 drivers/gpu/drm/i915/intel_atomic_plane.c |  24 +++-
 drivers/gpu/drm/i915/intel_display.c  | 206 +-
 drivers/gpu/drm/i915/intel_drv.h  |  24 +++-
 drivers/gpu/drm/i915/intel_sprite.c   |  42 +-
 6 files changed, 305 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f37ac12..bb47ee1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1929,6 +1929,7 @@ struct drm_i915_private {
 
struct drm_property *broadcast_rgb_property;
struct drm_property *force_audio_property;
+   struct drm_property *render_comp_property;
 
/* hda/i915 audio component */
struct i915_audio_component *audio_component;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7dfc400..773c37f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5756,6 +5756,28 @@ enum skl_disp_power_wells {
_ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
_ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
 
+#define PLANE_AUX_DIST_1_A 0x701c0
+#define PLANE_AUX_DIST_2_A 0x702c0
+#define PLANE_AUX_DIST_1_B 0x711c0
+#define PLANE_AUX_DIST_2_B 0x712c0
+#define _PLANE_AUX_DIST_1(pipe) \
+   _PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B)
+#define _PLANE_AUX_DIST_2(pipe) \
+   _PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B)
+#define PLANE_AUX_DIST(pipe, plane) \
+   _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), 
_PLANE_AUX_DIST_2(pipe))
+
+#define PLANE_AUX_OFFSET_1_A   0x701c4
+#define PLANE_AUX_OFFSET_2_A   0x702c4
+#define PLANE_AUX_OFFSET_1_B   0x711c4
+#define PLANE_AUX_OFFSET_2_B   0x712c4
+#define _PLANE_AUX_OFFSET_1(pipe)   \
+   _PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B)
+#define _PLANE_AUX_OFFSET_2(pipe)   \
+   _PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B)
+#define PLANE_AUX_OFFSET(pipe, plane)   \
+   _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), 
_PLANE_AUX_OFFSET_2(pipe))
+
 /* legacy palette */
 #define _LGC_PALETTE_A   0x4a000
 #define _LGC_PALETTE_B   0x4a800
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index e0b851a..c431333 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -230,8 +230,16 @@ intel_plane_atomic_get_property(struct drm_plane *plane,
struct drm_property *property,
uint64_t *val)
 {
-   DRM_DEBUG_KMS("Unknown plane property '%s'\n", property->name);
-   return -EINVAL;
+   struct drm_i915_private *dev_priv = state->plane->dev->dev_private;
+   struct intel_plane_state *intel_state = to_intel_plane_state(state);
+
+   if (property == dev_priv->render_comp_property) {
+   *val = intel_state->render_comp_enable;
+   } else {
+ 

Re: [Intel-gfx] [PATCH v2] drm/i915: Tune down init error message due to failure injection

[Imre Deak]

On Thu, 2016-03-17 at 21:03 +, Chris Wilson wrote:
> On Thu, Mar 17, 2016 at 10:53:08PM +0200, Imre Deak wrote:
> > On Thu, 2016-03-17 at 20:44 +, Chris Wilson wrote:
> > > On Thu, Mar 17, 2016 at 09:50:19PM +0200, Imre Deak wrote:
> > > > On Thu, 2016-03-17 at 19:41 +, Chris Wilson wrote:
> > > > > On Thu, Mar 17, 2016 at 06:08:05PM +0200, Imre Deak wrote:
> > > > > > On Thu, 2016-03-17 at 15:55 +, Chris Wilson wrote:
> > > > > > > 80cols rules still apply to messages :)
> > > > > > > 
> > > > > > > "Device initialization failed (%d). "
> > > > > > > "Please file a bug at https://bugs.freedesktop.org/enter_
> > > > > > > bug.
> > > > > > > cgi
> > > > > > > "
> > > > > > > "against DRI/DRM/Intel providing the dmesg log by booting
> > > > > > > "
> > > > > > > "with drm.debug=0xf\n",
> > > > > > 
> > > > > > I thought for strings emitted to dmesg it's discouraged,
> > > > > > since
> > > > > > you
> > > > > > can't easily grep then. But I can make the link more
> > > > > > precise.
> > > > > 
> > > > > Hmm, we haven't abided by that. I don't mind really :)
> > > > 
> > > > Ok, will follow this rule then.
> > > > 
> > > > > > > I would personally make i915_load_error() a proper
> > > > > > > function
> > > > > > > and
> > > > > > > add
> > > > > > > the "Please..." output there at a lower logging level
> > > > > > > than
> > > > > > > ERROR.
> > > > > > 
> > > > > > Using a function is not straightforward since there is no
> > > > > > vprintf
> > > > > > like
> > > > > > interface for DRM_ERROR. But I can move that part of the
> > > > > > message to
> > > > > > macro.
> > > > > 
> > > > > In that case, I'm happy enough with ditching the DRM_ERROR
> > > > > here
> > > > > and
> > > > > go
> > > > > with dev_err(). Another nail in the DRM_ERROR coffin.
> > > > 
> > > > Hm, there doesn't seem to be vprintf like dev_err either. And
> > > > dev_dbg
> > > > depends on CONFIG_DEBUG while DRM_DEBUG doesn't.
> > > 
> > > It uses dev_printk_emit(KERN_ERR, dev, fmt, va_list) underneath.
> > > 
> > > Does that help?
> > 
> > It uses
> > 
> > __dev_printk(kern_level, dev, );
> > 
> > which is not exported. This one in turn translates to
> > 
> > dev_printk_emit(KERN_ERR[0] - '0', dev, "%s %s: %pV",
> > dev_driver_string(dev), dev_name(dev), vaf);
> > 
> > which we probably don't want to hard-code here.
> 
> dev_vprintk_emit() is exported. I am not sure why dev_vprintk() would
> not be...
> 
> I agree it is a nuisance. So just food for thought.

Well, I can follow-up on an export patch for that, but getting that
merged may take a while, so could we go with the current version until
that?

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

[Intel-gfx] [PATCH 1/2] drm: Add aux plane verification in addFB2

[Vandana Kannan]

From: Daniel Vetter 

For render compression, userspace passes aux stride and offset values as an
additional entry in the fb structure. This should not be treated as garbage
and discarded as data belonging to no plane.
This patch introduces a check related to AUX plane to support the
scenario of render compression.

v2: Based on a discussion with Siva
Move num_planes check below the increment.

Signed-off-by: Daniel Vetter 
Signed-off-by: Vandana Kannan 
Cc: Sivakumar Thulasimani 
---
 drivers/gpu/drm/drm_crtc.c  | 19 ++-
 drivers/gpu/drm/drm_ioctl.c |  3 +++
 include/drm/drm_crtc.h  |  3 +++
 include/uapi/drm/drm.h  |  1 +
 include/uapi/drm/drm_mode.h |  1 +
 5 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a4e90c7..8659748 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3287,6 +3287,16 @@ static int framebuffer_check(const struct 
drm_mode_fb_cmd2 *r)
}
}
 
+   if (r->flags & DRM_MODE_FB_AUX_PLANE) {
+   num_planes++;
+
+   if (num_planes == 4) {
+   DRM_DEBUG_KMS("Number of planes cannot exceed 3"
+   "(including aux plane)\n");
+   return -EINVAL;
+   }
+   }
+
for (i = num_planes; i < 4; i++) {
if (r->modifier[i]) {
DRM_DEBUG_KMS("non-zero modifier for unused plane 
%d\n", i);
@@ -3325,7 +3335,8 @@ internal_framebuffer_create(struct drm_device *dev,
struct drm_framebuffer *fb;
int ret;
 
-   if (r->flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS)) {
+   if (r->flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS |
+   DRM_MODE_FB_AUX_PLANE)) {
DRM_DEBUG_KMS("bad framebuffer flags 0x%08x\n", r->flags);
return ERR_PTR(-EINVAL);
}
@@ -3347,6 +3358,12 @@ internal_framebuffer_create(struct drm_device *dev,
return ERR_PTR(-EINVAL);
}
 
+   if (r->flags & DRM_MODE_FB_AUX_PLANE &&
+   !dev->mode_config.allow_aux_plane) {
+   DRM_DEBUG_KMS("driver does not support render compression\n");
+   return ERR_PTR(-EINVAL);
+   }
+
ret = framebuffer_check(r);
if (ret)
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 8ce2a0c..ee00782 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -312,6 +312,9 @@ static int drm_getcap(struct drm_device *dev, void *data, 
struct drm_file *file_
case DRM_CAP_ADDFB2_MODIFIERS:
req->value = dev->mode_config.allow_fb_modifiers;
break;
+   case DRM_CAP_RENDER_COMPRESSION:
+   req->value = dev->mode_config.allow_aux_plane;
+   break;
default:
return -EINVAL;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 7fad193..00b1f59 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -2141,6 +2141,9 @@ struct drm_mode_config {
/* whether the driver supports fb modifiers */
bool allow_fb_modifiers;
 
+   /* whether the driver supports render compression */
+   bool allow_aux_plane;
+
/* cursor size */
uint32_t cursor_width, cursor_height;
 };
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index a0ebfe7..01561834 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -632,6 +632,7 @@ struct drm_gem_open {
 #define DRM_CAP_CURSOR_WIDTH   0x8
 #define DRM_CAP_CURSOR_HEIGHT  0x9
 #define DRM_CAP_ADDFB2_MODIFIERS   0x10
+#define DRM_CAP_RENDER_COMPRESSION 0x11
 
 /** DRM_IOCTL_GET_CAP ioctl argument type */
 struct drm_get_cap {
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 50adb46..f900dc95 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -354,6 +354,7 @@ struct drm_mode_fb_cmd {
 
 #define DRM_MODE_FB_INTERLACED (1<<0) /* for interlaced framebuffers */
 #define DRM_MODE_FB_MODIFIERS  (1<<1) /* enables ->modifer[] */
+#define DRM_MODE_FB_AUX_PLANE   (1<<2) /* for compressed buffer */
 
 struct drm_mode_fb_cmd2 {
__u32 fb_id;
-- 
1.9.1

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

[Intel-gfx] FW: [PATCH] drm/i915: Restrict usage of live status check

[Sharma, Shashank]

+intel-gfx

Regards
Shashank
-Original Message-
From: Sharma, Shashank 
Sent: Thursday, March 17, 2016 9:37 AM
To: Jindal, Sonika; Vetter, Daniel; ville.syrj...@linux.intel.com; 
jani.nik...@linux.intel.com
Cc: Sharma, Shashank
Subject: [PATCH] drm/i915: Restrict usage of live status check

This patch restricts usage of live status check for HDMI detection.
While testing certain (monitor + cable) combinations with various intel  
platforms, it seems that live status register is not reliable on some older 
devices. So limit the live_status check from VLV onwards.

This fixes a regression introduced in:
commit: 237ed86 "drm/i915: Check live status"
Author: Sonika Jindal 
Date:   Tue Sep 15 09:44:20 2015 +0530

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index e2dab48..d24d18a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1397,7 +1397,8 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
enum drm_connector_status status;
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
struct drm_i915_private *dev_priv = to_i915(connector->dev);
-   bool live_status = false;
+   struct drm_device *dev = connector->dev;
+   bool live_status = true;
unsigned int try;
 
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
@@ -1405,16 +1406,21 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
 
intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
 
-   for (try = 0; !live_status && try < 9; try++) {
-   if (try)
-   msleep(10);
-   live_status = intel_digital_port_connected(dev_priv,
+   /*
+   * Live status check for HDMI detection is not very
+   * reliable on older platforms. So insist the live
+   * status check for EDID read from VLV onwards.
+   */
+   if (INTEL_INFO(dev)->gen >= 7 && !IS_IVYBRIDGE(dev)) {
+   for (try = 0; !live_status && try < 9; try++) {
+   if (try)
+   msleep(10);
+   live_status = intel_digital_port_connected(dev_priv,
hdmi_to_dig_port(intel_hdmi));
+   }
+   DRM_DEBUG_KMS("Live status %s\n", live_status ? "up" : "down");
}
 
-   if (!live_status)
-   DRM_DEBUG_KMS("Live status not up!");
-
intel_hdmi_unset_edid(connector);
 
if (intel_hdmi_set_edid(connector, live_status)) {
--
1.9.1

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

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Use an array of register tables in command parser

[Francisco Jerez]

Jordan Justen  writes:

> For Haswell, we will want another table of registers while retaining
> the large common table of whitelisted registers shared by all gen7
> devices.
>
> Signed-off-by: Jordan Justen 

Reviewed-by: Francisco Jerez 

> ---
>  drivers/gpu/drm/i915/i915_cmd_parser.c  | 101 
> +++-
>  drivers/gpu/drm/i915/intel_ringbuffer.h |  13 +---
>  2 files changed, 75 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
> b/drivers/gpu/drm/i915/i915_cmd_parser.c
> index 86d7cda..46ea40b 100644
> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> @@ -501,6 +501,32 @@ static const struct drm_i915_reg_descriptor 
> hsw_master_regs[] = {
>  #undef REG64
>  #undef REG32
>  
> +struct drm_i915_reg_table {
> + const struct drm_i915_reg_descriptor *regs;
> + int num_regs;
> + bool master;
> +};
> +
> +static const struct drm_i915_reg_table ivb_render_reg_tables[] = {
> + { gen7_render_regs, ARRAY_SIZE(gen7_render_regs), false },
> + { ivb_master_regs, ARRAY_SIZE(ivb_master_regs), true },
> +};
> +
> +static const struct drm_i915_reg_table ivb_blt_reg_tables[] = {
> + { gen7_blt_regs, ARRAY_SIZE(gen7_blt_regs), false },
> + { ivb_master_regs, ARRAY_SIZE(ivb_master_regs), true },
> +};
> +
> +static const struct drm_i915_reg_table hsw_render_reg_tables[] = {
> + { gen7_render_regs, ARRAY_SIZE(gen7_render_regs), false },
> + { hsw_master_regs, ARRAY_SIZE(hsw_master_regs), true },
> +};
> +
> +static const struct drm_i915_reg_table hsw_blt_reg_tables[] = {
> + { gen7_blt_regs, ARRAY_SIZE(gen7_blt_regs), false },
> + { hsw_master_regs, ARRAY_SIZE(hsw_master_regs), true },
> +};
> +
>  static u32 gen7_render_get_cmd_length_mask(u32 cmd_header)
>  {
>   u32 client = (cmd_header & INSTR_CLIENT_MASK) >> INSTR_CLIENT_SHIFT;
> @@ -614,9 +640,16 @@ static bool check_sorted(int ring_id,
>  
>  static bool validate_regs_sorted(struct intel_engine_cs *ring)
>  {
> - return check_sorted(ring->id, ring->reg_table, ring->reg_count) &&
> - check_sorted(ring->id, ring->master_reg_table,
> -  ring->master_reg_count);
> + int i;
> + const struct drm_i915_reg_table *table;
> +
> + for (i = 0; i < ring->reg_table_count; i++) {
> + table = >reg_tables[i];
> + if (!check_sorted(ring->id, table->regs, table->num_regs))
> + return false;
> + }
> +
> + return true;
>  }
>  
>  struct cmd_node {
> @@ -711,15 +744,12 @@ int i915_cmd_parser_init_ring(struct intel_engine_cs 
> *ring)
>   cmd_table_count = ARRAY_SIZE(gen7_render_cmds);
>   }
>  
> - ring->reg_table = gen7_render_regs;
> - ring->reg_count = ARRAY_SIZE(gen7_render_regs);
> -
>   if (IS_HASWELL(ring->dev)) {
> - ring->master_reg_table = hsw_master_regs;
> - ring->master_reg_count = ARRAY_SIZE(hsw_master_regs);
> + ring->reg_tables = hsw_render_reg_tables;
> + ring->reg_table_count = 
> ARRAY_SIZE(hsw_render_reg_tables);
>   } else {
> - ring->master_reg_table = ivb_master_regs;
> - ring->master_reg_count = ARRAY_SIZE(ivb_master_regs);
> + ring->reg_tables = ivb_render_reg_tables;
> + ring->reg_table_count = 
> ARRAY_SIZE(ivb_render_reg_tables);
>   }
>  
>   ring->get_cmd_length_mask = gen7_render_get_cmd_length_mask;
> @@ -738,15 +768,12 @@ int i915_cmd_parser_init_ring(struct intel_engine_cs 
> *ring)
>   cmd_table_count = ARRAY_SIZE(gen7_blt_cmds);
>   }
>  
> - ring->reg_table = gen7_blt_regs;
> - ring->reg_count = ARRAY_SIZE(gen7_blt_regs);
> -
>   if (IS_HASWELL(ring->dev)) {
> - ring->master_reg_table = hsw_master_regs;
> - ring->master_reg_count = ARRAY_SIZE(hsw_master_regs);
> + ring->reg_tables = hsw_blt_reg_tables;
> + ring->reg_table_count = ARRAY_SIZE(hsw_blt_reg_tables);
>   } else {
> - ring->master_reg_table = ivb_master_regs;
> - ring->master_reg_count = ARRAY_SIZE(ivb_master_regs);
> + ring->reg_tables = ivb_blt_reg_tables;
> + ring->reg_table_count = ARRAY_SIZE(ivb_blt_reg_tables);
>   }
>  
>   ring->get_cmd_length_mask = gen7_blt_get_cmd_length_mask;
> @@ -849,12 +876,31 @@ static const struct drm_i915_reg_descriptor *
>  find_reg(const struct drm_i915_reg_descriptor *table,
>int count, u32 addr)
>  {
> - if (table) {
> - int i;
> + int i;
> +
> + for (i = 0; i < count; i++) 

[Intel-gfx] ✗ Fi.CI.BAT: failure for Split driver init step to phases (rev2)

[Patchwork]

== Series Details ==

Series: Split driver init step to phases (rev2)
URL   : https://patchwork.freedesktop.org/series/4509/
State : failure

== Summary ==

Series 4509v2 Split driver init step to phases
2016-03-16T12:32:02.196998 
http://patchwork.freedesktop.org/api/1.0/series/4509/revisions/2/mbox/
Applying: Fix MCHBAR cleanup on the driver init error path
Applying: drm/i915: Move load time PCH detect, DPIO, power domain SW init 
earlier
Applying: drm/i915: Move load time IRQ SW init earlier
Applying: drm/i915: Move load time init of display/audio hooks earlier
Applying: drm/i915: Move load time init of clock gating hooks earlier
Applying: drm/i915: Move load time runtime device info init earlier
Applying: drm/i915: Move load time gem_load_init earlier
Applying: drm/i915: Move load time runtime PM get later
Applying: drm/i915: Move load time shrinker registration later
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/i915_dma.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/i915_dma.c
Applying: drm/i915: Move load time audio component registration earlier
Applying: drm/i915: Move unload time display power domain uninit later
Applying: drm/i915: Move unload time GTT, MSI IRQ cleanup later
Applying: drm/i915: Move unload time opregion unregistration earlier
Applying: drm/i915: Split out load time early initialization
Applying: drm/i915: Split out load time MMIO initialization
Applying: drm/i915: Split out load time HW initialization
Applying: drm/i915: Split out load time interface registration
Applying: drm/i915: Fix power domain HW state cleanup on error path
Applying: drm/i915: Add fault injection support
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0019 drm/i915: Add fault injection support

___
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: Render decompression support for Gen9 and above

[Daniel Stone]

Hi Vandana,

On 18 March 2016 at 16:50, Vandana Kannan  wrote:
> The reason for using a plane property instead of fb modifier:-
> In Android, OGL passes a render compressed buffer to hardware composer (HWC),
> which would then request a flip on that buffer after checking if the target
> can support render compressed buffer. For example, only planes 1 and 2 on
> pipes 1 and 2 can support RC. In case the target cannot support it, HWC will
> revert back to OGL requesting for uncompressed buffer.

I still don't believe we can support this in non-Android userspace, so
I don't have any other comment on this patch.

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Tune down init error message due to failure injection

[Chris Wilson]

On Thu, Mar 17, 2016 at 10:53:08PM +0200, Imre Deak wrote:
> On Thu, 2016-03-17 at 20:44 +, Chris Wilson wrote:
> > On Thu, Mar 17, 2016 at 09:50:19PM +0200, Imre Deak wrote:
> > > On Thu, 2016-03-17 at 19:41 +, Chris Wilson wrote:
> > > > On Thu, Mar 17, 2016 at 06:08:05PM +0200, Imre Deak wrote:
> > > > > On Thu, 2016-03-17 at 15:55 +, Chris Wilson wrote:
> > > > > > 80cols rules still apply to messages :)
> > > > > > 
> > > > > > "Device initialization failed (%d). "
> > > > > > "Please file a bug at https://bugs.freedesktop.org/enter_bug.
> > > > > > cgi
> > > > > > "
> > > > > > "against DRI/DRM/Intel providing the dmesg log by booting "
> > > > > > "with drm.debug=0xf\n",
> > > > > 
> > > > > I thought for strings emitted to dmesg it's discouraged, since
> > > > > you
> > > > > can't easily grep then. But I can make the link more precise.
> > > > 
> > > > Hmm, we haven't abided by that. I don't mind really :)
> > > 
> > > Ok, will follow this rule then.
> > > 
> > > > > > I would personally make i915_load_error() a proper function
> > > > > > and
> > > > > > add
> > > > > > the "Please..." output there at a lower logging level than
> > > > > > ERROR.
> > > > > 
> > > > > Using a function is not straightforward since there is no
> > > > > vprintf
> > > > > like
> > > > > interface for DRM_ERROR. But I can move that part of the
> > > > > message to
> > > > > macro.
> > > > 
> > > > In that case, I'm happy enough with ditching the DRM_ERROR here
> > > > and
> > > > go
> > > > with dev_err(). Another nail in the DRM_ERROR coffin.
> > > 
> > > Hm, there doesn't seem to be vprintf like dev_err either. And
> > > dev_dbg
> > > depends on CONFIG_DEBUG while DRM_DEBUG doesn't.
> > 
> > It uses dev_printk_emit(KERN_ERR, dev, fmt, va_list) underneath.
> > 
> > Does that help?
> 
> It uses
> 
> __dev_printk(kern_level, dev, );
> 
> which is not exported. This one in turn translates to
> 
> dev_printk_emit(KERN_ERR[0] - '0', dev, "%s %s: %pV",
> dev_driver_string(dev), dev_name(dev), vaf);
> 
> which we probably don't want to hard-code here.

dev_vprintk_emit() is exported. I am not sure why dev_vprintk() would
not be...

I agree it is a nuisance. So just food for thought.
-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 07/19] drm/i915: Move load time gem_load_init earlier

[Chris Wilson]

On Wed, Mar 16, 2016 at 01:38:56PM +0200, Imre Deak wrote:
> The only steps requiring device access is the fence and swizzling
> initialization, so split these out keeping them in their current place
> and move the rest of init steps earlier.
> 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_dma.c | 13 -
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/i915_gem.c | 34 --
>  3 files changed, 29 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index da96ccd..9ada500 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1031,6 +1031,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
> long flags)
>   intel_init_display_hooks(dev_priv);
>   intel_init_clock_gating_hooks(dev_priv);
>   intel_init_audio_hooks(dev_priv);
> + i915_gem_load_init(dev);
>  
>   intel_runtime_pm_get(dev_priv);
>  
> @@ -1114,7 +1115,9 @@ int i915_driver_load(struct drm_device *dev, unsigned 
> long flags)
>  
>   intel_opregion_setup(dev);
>  
> - i915_gem_load_init(dev);
> + i915_gem_load_init_fences(dev_priv);
> + i915_gem_detect_bit_6_swizzle(dev);

Pedant in me would say we want to detect the hw fence capabilties first.
Just move i915_gem_detect_bit_6_swizzle() into init_fences since they
are semantically related.
-Chris

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen9: add WaClearFlowControlGpgpuContextSave (rev3)

[Tvrtko Ursulin]

On 17/03/16 10:57, Gore, Tim wrote:

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



-Original Message-
From: Patchwork [mailto:patchw...@emeril.freedesktop.org]
Sent: Thursday, March 17, 2016 9:36 AM
To: Gore, Tim
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.BAT: failure for drm/i915/gen9: add
WaClearFlowControlGpgpuContextSave (rev3)

== Series Details ==

Series: drm/i915/gen9: add WaClearFlowControlGpgpuContextSave (rev3)
URL   : https://patchwork.freedesktop.org/series/4272/
State : failure

== Summary ==

Series 4272v3 drm/i915/gen9: add WaClearFlowControlGpgpuContextSave
http://patchwork.freedesktop.org/api/1.0/series/4272/revisions/3/mbox/

Test gem_ringfill:
 Subgroup basic-default-s3:
 dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_flip:
 Subgroup basic-flip-vs-wf_vblank:
 pass   -> DMESG-WARN (hsw-brixbox)


  Usual "Device suspended during HW access", 
https://bugs.freedesktop.org/show_bug.cgi?id=94349


 Subgroup basic-plain-flip:
 dmesg-warn -> PASS   (hsw-gt2)
 dmesg-warn -> PASS   (hsw-brixbox)
Test kms_pipe_crc_basic:
 Subgroup hang-read-crc-pipe-c:
 pass   -> SKIP   (hsw-brixbox)


This test is not shown in the Patchwork_1622 summary, not sure how it got in 
here!


 Subgroup nonblocking-crc-pipe-a:
 dmesg-warn -> PASS   (hsw-brixbox)
 Subgroup read-crc-pipe-b:
 dmesg-warn -> PASS   (hsw-gt2)
Test pm_rpm:
 Subgroup basic-rte:
 pass   -> DMESG-WARN (hsw-gt2)


  Usual "Device suspended during HW access", 
https://bugs.freedesktop.org/show_bug.cgi?id=94349



bdw-nuci7total:194  pass:181  dwarn:0   dfail:0   fail:0   skip:13
bdw-ultratotal:194  pass:173  dwarn:0   dfail:0   fail:0   skip:21
bsw-nuc-2total:194  pass:156  dwarn:1   dfail:0   fail:0   skip:37
byt-nuc  total:194  pass:155  dwarn:4   dfail:0   fail:0   skip:35
hsw-brixbox  total:194  pass:170  dwarn:1   dfail:0   fail:0   skip:23
hsw-gt2  total:194  pass:176  dwarn:1   dfail:0   fail:0   skip:17
ivb-t430stotal:194  pass:169  dwarn:0   dfail:0   fail:0   skip:25
skl-i5k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23
skl-i7k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23
skl-nuci5total:194  pass:183  dwarn:0   dfail:0   fail:0   skip:11

Results at /archive/results/CI_IGT_test/Patchwork_1622/

7107208595602ace943fb5afa0de1de45d62c2b8 drm-intel-nightly: 2016y-03m-
17d-08h-36m-48s UTC integration manifest
2b37e8a951958145dbc808de3fbbdf4a54988fda drm/i915/gen9: add
WaClearFlowControlGpgpuContextSave


Merged, thanks for the patch and review.

Regards,

Tvrtko

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Support for creating/using Stolen memory backed objects (rev12)

[Patchwork]

== Series Details ==

Series: Support for creating/using Stolen memory backed objects (rev12)
URL   : https://patchwork.freedesktop.org/series/659/
State : failure

== Summary ==

Series 659v12 Support for creating/using Stolen memory backed objects
http://patchwork.freedesktop.org/api/1.0/series/659/revisions/12/mbox/

Test gem_ringfill:
Subgroup basic-default-s3:
dmesg-warn -> PASS   (skl-nuci5)
Test gem_storedw_loop:
Subgroup basic-default:
dmesg-warn -> PASS   (skl-nuci5)
Test gem_sync:
Subgroup basic-vebox:
dmesg-warn -> PASS   (skl-nuci5)
Test kms_frontbuffer_tracking:
Subgroup basic:
dmesg-warn -> PASS   (hsw-gt2)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (hsw-gt2)
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (hsw-gt2)
Subgroup read-crc-pipe-c:
pass   -> DMESG-WARN (hsw-gt2)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-ultratotal:194  pass:172  dwarn:1   dfail:0   fail:0   skip:21 
bsw-nuc-2total:194  pass:156  dwarn:1   dfail:0   fail:0   skip:37 
byt-nuc  total:194  pass:155  dwarn:4   dfail:0   fail:0   skip:35 
hsw-brixbox  total:194  pass:171  dwarn:1   dfail:0   fail:0   skip:22 
hsw-gt2  total:194  pass:174  dwarn:3   dfail:0   fail:0   skip:17 
ivb-t430stotal:194  pass:168  dwarn:1   dfail:0   fail:0   skip:25 
skl-i5k-2total:194  pass:170  dwarn:1   dfail:0   fail:0   skip:23 
skl-i7k-2total:194  pass:170  dwarn:1   dfail:0   fail:0   skip:23 
skl-nuci5total:194  pass:182  dwarn:1   dfail:0   fail:0   skip:11 

Results at /archive/results/CI_IGT_test/Patchwork_1639/

10e913a48ca36790da9b58bed8729598ea79ebdb drm-intel-nightly: 
2016y-03m-17d-13h-22m-41s UTC integration manifest
a33c5e5ef7d25051677decad5dbb56fd57d6c5e6 drm/i915: Disable use of stolen area 
by User when Intel RST is present
125421c6924cfc7f5a12665261972964f958643c drm/i915: Migrate stolen objects 
before hibernation
ba20ee3bc2135fc7ab5c298e7e49d1b958bd713a drm/i915: Support for pread/pwrite 
from/to non shmem backed objects
768f7acfea69c8b9aa60de167a9c6b9dc3ec6233 drm/i915: Add support for stealing 
purgable stolen pages
727695e43033e3adef6c494689eb790b4cebdfb9 drm/i915: Propagating correct error 
codes to the userspace
01a610e77b3a53cfd098bfd1480998588be7a365 drm/i915: Support for creating Stolen 
memory backed objects
0a35d991c4066e37a795b341564dadc639513fb0 drm/i915: Clearing buffer objects via 
CPU/GTT
e50ab57a0682b743a1a1b70abebddbdff3a4c581 drm/i915: Use insert_page for 
pwrite_fast
43a70c2afadb9ee62b99c3c4c818719e17a94366 drm/i915: Introduce 
i915_gem_object_get_dma_address()
1547273f797c2b40a65b9c885e7a1a234b3e6bd5 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

Re: [Intel-gfx] [PATCH] prime_mmap_coherency: Add return error tests for prime sync ioctl

[Chris Wilson]

On Thu, Mar 17, 2016 at 03:18:03PM -0300, Tiago Vignatti wrote:
> This patch adds ioctl-errors subtest to be used for exercising prime sync 
> ioctl
> errors.
> 
> The subtest constantly interrupts via signals a function doing concurrent blit
> to stress out the right usage of prime_sync_*, making sure these ioctl errors
> are handled accordingly. Important to note that in case of failure (e.g. in a
> case where the ioctl wouldn't try again in a return error) this test does not
> reliably catch the problem with 100% of accuracy.
> 
> Cc: Chris Wilson 
> Signed-off-by: Tiago Vignatti 
> ---
> 
> Chris, your unpolished dma-buf patch for adding return error into the ioctl
> calls lgtm. Let me know if you think this kind of test is useful now in igt.
> 
> Thanks
> 
> Tiago
> 
>  tests/prime_mmap_coherency.c | 87 
> 
>  1 file changed, 87 insertions(+)
> 
> diff --git a/tests/prime_mmap_coherency.c b/tests/prime_mmap_coherency.c
> index 180d8a4..bae2144 100644
> --- a/tests/prime_mmap_coherency.c
> +++ b/tests/prime_mmap_coherency.c
> @@ -180,6 +180,88 @@ static void test_write_flush(bool expect_stale_cache)
>   munmap(ptr_cpu, width * height);
>  }
>  
> +static void blit_and_cmp(void)
> +{
> + drm_intel_bo *bo_1;
> + drm_intel_bo *bo_2;
> + uint32_t *ptr_cpu;
> + uint32_t *ptr2_cpu;
> + int dma_buf_fd, dma_buf2_fd, i;
> + int local_fd;
> + drm_intel_bufmgr *local_bufmgr;
> + struct intel_batchbuffer *local_batch;
> +
> + /* recreate process local variables */
> + local_fd = drm_open_driver(DRIVER_INTEL);
> + local_bufmgr = drm_intel_bufmgr_gem_init(local_fd, 4096);
> + igt_assert(local_bufmgr);
> +
> + local_batch = intel_batchbuffer_alloc(local_bufmgr, 
> intel_get_drm_devid(local_fd));
> + igt_assert(local_batch);
> +
> + bo_1 = drm_intel_bo_alloc(local_bufmgr, "BO 1", width * height * 4, 
> 4096);
> + dma_buf_fd = prime_handle_to_fd_for_mmap(local_fd, bo_1->handle);
> + igt_skip_on(errno == EINVAL);
> +
> + ptr_cpu = mmap(NULL, width * height, PROT_READ | PROT_WRITE,
> + MAP_SHARED, dma_buf_fd, 0);
> + igt_assert(ptr_cpu != MAP_FAILED);
> +
> + bo_2 = drm_intel_bo_alloc(local_bufmgr, "BO 2", width * height * 4, 
> 4096);
> + dma_buf2_fd = prime_handle_to_fd_for_mmap(local_fd, bo_2->handle);
> +
> + ptr2_cpu = mmap(NULL, width * height, PROT_READ | PROT_WRITE,
> + MAP_SHARED, dma_buf2_fd, 0);
> + igt_assert(ptr2_cpu != MAP_FAILED);
> +
> + /* Fill up BO 1 with '1's and BO 2 with '0's */
> + prime_sync_start(dma_buf_fd, true);
> + memset(ptr_cpu, 0x11, width * height);
> + prime_sync_end(dma_buf_fd, true);
> +
> + prime_sync_start(dma_buf2_fd, true);
> + memset(ptr2_cpu, 0x00, width * height);
> + prime_sync_end(dma_buf2_fd, true);
> +
> + /* Copy BO 1 into BO 2, using blitter. */
> + intel_copy_bo(local_batch, bo_2, bo_1, width * height);
> + usleep(0); /* let someone else claim the mutex */
> +
> + /* Compare BOs. If prime_sync_* were executed properly, the caches
> +  * should be synced. */
> + prime_sync_start(dma_buf2_fd, true);

Maybe false here? Note that it makes any difference for the driver atm.

> + for (i = 0; i < (width * height) / 4; i++)
> + igt_fail_on_f(ptr2_cpu[i] != 0x, "Found 0x%08x at 
> offset 0x%08x\n", ptr2_cpu[i], i);
> + prime_sync_end(dma_buf2_fd, true);
> +
> + drm_intel_bo_unreference(bo_1);
> + drm_intel_bo_unreference(bo_2);
> + munmap(ptr_cpu, width * height);
> + munmap(ptr2_cpu, width * height);

Do we have anything that verifies that dmabuf maps persist beyond
gem_close() on the original bo?

Yes, that test should hit all interruptible paths we have in dmabuf and
would be a great addition to igt.
-Chris

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

[Intel-gfx] [PATCH 6/6] drm/i915: Teach to_i915() how to extract drm_i915_private from engines

[Chris Wilson]

This is primarily intended to simplify later patches that add various
backpointers to the structs, but in the meantime we can enjoy various
little syntactic conveniences.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c |  12 +-
 drivers/gpu/drm/i915/i915_drv.h|   9 ++
 drivers/gpu/drm/i915/i915_gem.c|   9 +-
 drivers/gpu/drm/i915/i915_gem_context.c|  19 ++-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   2 +-
 drivers/gpu/drm/i915/i915_irq.c|  26 ++--
 drivers/gpu/drm/i915/intel_display.c   |   2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 122 
 drivers/gpu/drm/i915/intel_ringbuffer.c| 219 +
 drivers/gpu/drm/i915/intel_uncore.c|   4 +-
 10 files changed, 195 insertions(+), 229 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 2c50142be559..efbba19bb0b2 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -696,12 +696,12 @@ int i915_cmd_parser_init_ring(struct intel_engine_cs 
*engine)
int cmd_table_count;
int ret;
 
-   if (!IS_GEN7(engine->dev))
+   if (!IS_GEN7(engine))
return 0;
 
switch (engine->id) {
case RCS:
-   if (IS_HASWELL(engine->dev)) {
+   if (IS_HASWELL(engine)) {
cmd_tables = hsw_render_ring_cmds;
cmd_table_count =
ARRAY_SIZE(hsw_render_ring_cmds);
@@ -713,7 +713,7 @@ int i915_cmd_parser_init_ring(struct intel_engine_cs 
*engine)
engine->reg_table = gen7_render_regs;
engine->reg_count = ARRAY_SIZE(gen7_render_regs);
 
-   if (IS_HASWELL(engine->dev)) {
+   if (IS_HASWELL(engine)) {
engine->master_reg_table = hsw_master_regs;
engine->master_reg_count = ARRAY_SIZE(hsw_master_regs);
} else {
@@ -729,7 +729,7 @@ int i915_cmd_parser_init_ring(struct intel_engine_cs 
*engine)
engine->get_cmd_length_mask = gen7_bsd_get_cmd_length_mask;
break;
case BCS:
-   if (IS_HASWELL(engine->dev)) {
+   if (IS_HASWELL(engine)) {
cmd_tables = hsw_blt_ring_cmds;
cmd_table_count = ARRAY_SIZE(hsw_blt_ring_cmds);
} else {
@@ -740,7 +740,7 @@ int i915_cmd_parser_init_ring(struct intel_engine_cs 
*engine)
engine->reg_table = gen7_blt_regs;
engine->reg_count = ARRAY_SIZE(gen7_blt_regs);
 
-   if (IS_HASWELL(engine->dev)) {
+   if (IS_HASWELL(engine)) {
engine->master_reg_table = hsw_master_regs;
engine->master_reg_count = ARRAY_SIZE(hsw_master_regs);
} else {
@@ -968,7 +968,7 @@ bool i915_needs_cmd_parser(struct intel_engine_cs *engine)
if (!engine->needs_cmd_parser)
return false;
 
-   if (!USES_PPGTT(engine->dev))
+   if (!USES_PPGTT(engine))
return false;
 
return (i915.enable_cmd_parser == 1);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d6840d380ca5..85c8d93cbb0f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1987,6 +1987,11 @@ static inline struct drm_i915_private 
*__guc_to_i915(struct intel_guc *guc)
return container_of(guc, struct drm_i915_private, guc);
 }
 
+static inline struct drm_i915_private *__engine_to_i915(struct intel_engine_cs 
*engine)
+{
+   return __to_i915(engine->dev);
+}
+
 /* Iterate over initialised rings */
 #define for_each_engine(ring__, ptr__, i__) \
for ((i__) = 0; (i__) < I915_NUM_ENGINES; (i__)++) \
@@ -2473,6 +2478,10 @@ struct drm_i915_cmd_table {
__p = __guc_to_i915((struct intel_guc *)p); \
else if (__builtin_types_compatible_p(typeof(*p), struct 
drm_i915_gem_request)) \
__p = __request_to_i915((struct drm_i915_gem_request *)(p)); \
+   else if (__builtin_types_compatible_p(typeof(*p), struct 
intel_engine_cs)) \
+   __p = __engine_to_i915((struct intel_engine_cs *)(p)); \
+   else if (__builtin_types_compatible_p(typeof(*p), struct 
intel_ringbuffer)) \
+   __p = __engine_to_i915(((struct intel_ringbuffer 
*)(p))->engine); \
else \
BUILD_BUG(); \
__p; \
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7e98cf884972..045c609e8e9e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1242,8 +1242,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
struct intel_rps_client *rps)
 {
struct intel_engine_cs *engine = 

[Intel-gfx] [PATCH] igt/gem_pread: Check for stolen memory support before pread/pwrite

[ankitprasad . r . sharma]

From: Ankitprasad Sharma 

This checks if the kernel supports creation of stolen backed objects
before doing a pread/pwrite on stolen backed objects.

Also correcting the CREATE_VERSION ioctl number in getparam ioctl,
due to kernel changes added in between.

Signed-off-by: Ankitprasad Sharma 
---
 lib/ioctl_wrappers.c | 3 +--
 tests/gem_pread.c| 3 +++
 tests/gem_pwrite.c   | 2 ++
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 4071260..9ff8c31 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -415,7 +415,6 @@ void gem_sync(int fd, uint32_t handle)
errno = 0;
 }
 
-
 bool gem_create__has_stolen_support(int fd)
 {
static int has_stolen_support = -1;
@@ -424,7 +423,7 @@ bool gem_create__has_stolen_support(int fd)
 
if (has_stolen_support < 0) {
memset(, 0, sizeof(gp));
-   gp.param = 36; /* CREATE_VERSION */
+   gp.param = 38; /* CREATE_VERSION */
gp.value = 
 
/* Do we have the extended gem_create_ioctl? */
diff --git a/tests/gem_pread.c b/tests/gem_pread.c
index afa072d..f4cf472 100644
--- a/tests/gem_pread.c
+++ b/tests/gem_pread.c
@@ -152,6 +152,7 @@ int main(int argc, char **argv)
}
 
igt_subtest("stolen-normal") {
+   gem_require_stolen_support(fd);
for (count = 1; count <= 1<<17; count <<= 1) {
struct timeval start, end;
 
@@ -167,6 +168,7 @@ int main(int argc, char **argv)
}
for (c = cache; c->level != -1; c++) {
igt_subtest_f("stolen-%s", c->name) {
+   gem_require_stolen_support(fd);
gem_set_caching(fd, src_stolen, c->level);
 
for (count = 1; count <= 1<<17; count <<= 1) {
@@ -190,6 +192,7 @@ int main(int argc, char **argv)
 * user space buffer
 */
igt_subtest("pagefault-pread") {
+   gem_require_stolen_support(fd);
large_stolen = gem_create_stolen(fd, LARGE_OBJECT_SIZE);
stolen_nopf_user = (uint32_t *) mmap(NULL, LARGE_OBJECT_SIZE,
PROT_WRITE,
diff --git a/tests/gem_pwrite.c b/tests/gem_pwrite.c
index 42206d7..5d99b29 100644
--- a/tests/gem_pwrite.c
+++ b/tests/gem_pwrite.c
@@ -206,6 +206,7 @@ int main(int argc, char **argv)
}
 
igt_subtest("stolen-normal") {
+   gem_require_stolen_support(fd);
for (count = 1; count <= 1<<17; count <<= 1) {
struct timeval start, end;
 
@@ -222,6 +223,7 @@ int main(int argc, char **argv)
}
 
for (c = cache; c->level != -1; c++) {
+   gem_require_stolen_support(fd);
igt_subtest_f("stolen-%s", c->name) {
gem_set_caching(fd, dst, c->level);
for (count = 1; count <= 1<<17; count <<= 1) {
-- 
1.9.1

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: simplify bind_to_vm init code

[Patchwork]

== Series Details ==

Series: drm/i915: simplify bind_to_vm init code
URL   : https://patchwork.freedesktop.org/series/4531/
State : failure

== Summary ==

Series 4531v1 drm/i915: simplify bind_to_vm init code
http://patchwork.freedesktop.org/api/1.0/series/4531/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (hsw-gt2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (hsw-gt2)
dmesg-warn -> PASS   (bdw-ultra)
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (hsw-brixbox)
Subgroup basic-plain-flip:
dmesg-warn -> PASS   (hsw-brixbox)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-c-frame-sequence:
dmesg-warn -> PASS   (hsw-gt2)
pass   -> DMESG-WARN (hsw-brixbox)
Test pm_rpm:
Subgroup basic-rte:
pass   -> DMESG-WARN (bsw-nuc-2)
dmesg-warn -> PASS   (hsw-brixbox)

bdw-nuci7total:194  pass:182  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:194  pass:173  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:194  pass:155  dwarn:2   dfail:0   fail:0   skip:37 
byt-nuc  total:194  pass:155  dwarn:4   dfail:0   fail:0   skip:35 
hsw-brixbox  total:194  pass:170  dwarn:2   dfail:0   fail:0   skip:22 
hsw-gt2  total:194  pass:176  dwarn:1   dfail:0   fail:0   skip:17 
ivb-t430stotal:194  pass:169  dwarn:0   dfail:0   fail:0   skip:25 
skl-i5k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-i7k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:194  pass:183  dwarn:0   dfail:0   fail:0   skip:11 

Results at /archive/results/CI_IGT_test/Patchwork_1623/

8a9a911d489fe160df173580277983dac5952ed0 drm-intel-nightly: 
2016y-03m-17d-10h-02m-10s UTC integration manifest
11854942755899b97e78942213f304b118a3a4ef drm/i915: simplify bind_to_vm init code

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

[Intel-gfx] [PATCH 2/8] drm/i915/dsi: add support for DSI sequence block v2 gpio element

[Jani Nikula]

In sequence block v2, and only in v2, the gpio source (i.e. IOSF port)
is specified separately.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index f687b2e9d8ca..765dd5cd23ac 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -198,7 +198,7 @@ static const u8 *mipi_exec_delay(struct intel_dsi 
*intel_dsi, const u8 *data)
 
 static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data)
 {
-   u8 gpio_index, action;
+   u8 gpio_source, gpio_index, action, port;
u16 function, pad;
u32 val;
struct drm_device *dev = intel_dsi->base.base.dev;
@@ -209,6 +209,9 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
 
gpio_index = *data++;
 
+   /* gpio source in sequence v2 only */
+   gpio_source = (*data >> 1) & 3;
+
/* pull up/down */
action = *data++ & 1;
 
@@ -225,6 +228,17 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
if (dev_priv->vbt.dsi.seq_version >= 3) {
DRM_DEBUG_KMS("GPIO element v3 not supported\n");
goto out;
+   } else if (dev_priv->vbt.dsi.seq_version == 2) {
+   if (gpio_source == 0) {
+   port = IOSF_PORT_GPIO_NC;
+   } else if (gpio_source == 1) {
+   port = IOSF_PORT_GPIO_SC;
+   } else {
+   DRM_DEBUG_KMS("unknown gpio source %u\n", gpio_source);
+   goto out;
+   }
+   } else {
+   port = IOSF_PORT_GPIO_NC;
}
 
function = gtable[gpio_index].function_reg;
@@ -234,15 +248,14 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
if (!gtable[gpio_index].init) {
/* program the function */
/* FIXME: remove constant below */
-   vlv_iosf_sb_write(dev_priv, IOSF_PORT_GPIO_NC, function,
- 0x2000CC00);
+   vlv_iosf_sb_write(dev_priv, port, function, 0x2000CC00);
gtable[gpio_index].init = 1;
}
 
val = 0x4 | action;
 
/* pull up/down */
-   vlv_iosf_sb_write(dev_priv, IOSF_PORT_GPIO_NC, pad, val);
+   vlv_iosf_sb_write(dev_priv, port, pad, val);
mutex_unlock(_priv->sb_lock);
 
 out:
-- 
2.1.4

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

[Intel-gfx] [PATCH v3 15/19] drm/i915: Split out load time MMIO initialization

[Imre Deak]

According to the new init phases scheme we should have a definite step
in the init sequence where MMIO access is setup, so move the
corresponding code to a separate function. This also has the benefit of
making the error path cleaner both in the new function and in
i915_driver_load()/unload().

No functional change.

Suggested by Chris.

Cc: Chris Wilson 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_dma.c | 69 +
 1 file changed, 50 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 93e7951..ab97404 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1051,6 +1051,50 @@ static void i915_mmio_cleanup(struct drm_device *dev)
 }
 
 /**
+ * i915_driver_init_mmio - setup device MMIO
+ * @dev_priv: device private
+ *
+ * Setup minimal device state necessary for MMIO accesses later in the
+ * initialization sequence. The setup here should avoid any other device-wide
+ * side effects or exposing the driver via kernel internal or user space
+ * interfaces.
+ */
+static int i915_driver_init_mmio(struct drm_i915_private *dev_priv)
+{
+   struct drm_device *dev = dev_priv->dev;
+   int ret;
+
+   if (i915_get_bridge_dev(dev))
+   return -EIO;
+
+   ret = i915_mmio_setup(dev);
+   if (ret < 0)
+   goto put_bridge;
+
+   intel_uncore_init(dev);
+
+   return 0;
+
+put_bridge:
+   pci_dev_put(dev_priv->bridge_dev);
+
+   return ret;
+}
+
+/**
+ * i915_driver_cleanup_mmio - cleanup the setup done in i915_driver_init_mmio()
+ * @dev_priv: device private
+ */
+static void i915_driver_cleanup_mmio(struct drm_i915_private *dev_priv)
+{
+   struct drm_device *dev = dev_priv->dev;
+
+   intel_uncore_fini(dev);
+   i915_mmio_cleanup(dev);
+   pci_dev_put(dev_priv->bridge_dev);
+}
+
+/**
  * i915_driver_load - setup chip and create an initial config
  * @dev: DRM device
  * @flags: startup flags
@@ -1081,22 +1125,15 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
 
intel_runtime_pm_get(dev_priv);
 
-   if (i915_get_bridge_dev(dev)) {
-   ret = -EIO;
-   goto out_runtime_pm_put;
-   }
-
-   ret = i915_mmio_setup(dev);
+   ret = i915_driver_init_mmio(dev_priv);
if (ret < 0)
-   goto put_bridge;
-
-   intel_uncore_init(dev);
+   goto out_runtime_pm_put;
 
intel_device_info_runtime_init(dev);
 
ret = i915_gem_gtt_init(dev);
if (ret)
-   goto out_uncore_fini;
+   goto out_cleanup_mmio;
 
/* WARNING: Apparently we must kick fbdev drivers before vgacon,
 * otherwise the vga fbdev driver falls over. */
@@ -1219,11 +1256,8 @@ out_disable_msi:
io_mapping_free(dev_priv->gtt.mappable);
 out_gtt:
i915_global_gtt_cleanup(dev);
-out_uncore_fini:
-   intel_uncore_fini(dev);
-   i915_mmio_cleanup(dev);
-put_bridge:
-   pci_dev_put(dev_priv->bridge_dev);
+out_cleanup_mmio:
+   i915_driver_cleanup_mmio(dev_priv);
 out_runtime_pm_put:
intel_runtime_pm_put(dev_priv);
i915_driver_cleanup_early(dev_priv);
@@ -1304,10 +1338,7 @@ int i915_driver_unload(struct drm_device *dev)
io_mapping_free(dev_priv->gtt.mappable);
i915_global_gtt_cleanup(dev);
 
-   intel_uncore_fini(dev);
-   i915_mmio_cleanup(dev);
-
-   pci_dev_put(dev_priv->bridge_dev);
+   i915_driver_cleanup_mmio(dev_priv);
 
intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
 
-- 
2.5.0

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

Re: [Intel-gfx] [PATCH 6/8] dmi: Move memdev_dmi_entry definition to dmi.h (v2)

[Jean Delvare]

Hi Matt,

On Tue,  8 Mar 2016 10:32:37 -0800, Matt Roper wrote:
> A couple of the EDAC drivers have a nice memdev_dmi_entry structure for
> decoding DMI memory device entries.  Move the structure definition to
> dmi.h so that it can be shared between those drivers and also other
> parts of the kernel; the i915 graphics driver is going to need to use
> this structure soon as well.  As part of this move we rename the
> structure s/memdev_dmi_entry/dmi_entry_memdev/ to ensure it has a proper
> 'dmi' prefix.
> 
> v2:
>  - Rename structure to dmi_entry_memdev.  (Jean)
>  - Use __packed instead of __attribute__((__packed__)) for consistency
>with the rest of the dmi.h header.  (Jean)

Looks better. One more comment inline below:

> (...)
> diff --git a/drivers/edac/i7core_edac.c b/drivers/edac/i7core_edac.c
> index 01087a3..fbfb06f 100644
> --- a/drivers/edac/i7core_edac.c
> +++ b/drivers/edac/i7core_edac.c
> (...)
> @@ -1946,28 +1921,28 @@ static void decode_dclk(const struct dmi_header *dh, 
> void *_dclk_freq)
>   return;
>  
>   if (dh->type == DMI_ENTRY_MEM_DEVICE) {
> - struct memdev_dmi_entry *memdev_dmi_entry =
> - (struct memdev_dmi_entry *)dh;
> + struct dmi_entry_memdev *dmi_entry_memdev =
> + (struct dmi_entry_memdev *)dh;
>   unsigned long conf_mem_clk_speed_offset =
> - (unsigned long)_dmi_entry->conf_mem_clk_speed -
> - (unsigned long)_dmi_entry->type;
> + (unsigned long)_entry_memdev->conf_mem_clk_speed -
> + (unsigned long)_entry_memdev->type;
>   unsigned long speed_offset =
> - (unsigned long)_dmi_entry->speed -
> - (unsigned long)_dmi_entry->type;
> + (unsigned long)_entry_memdev->speed -
> + (unsigned long)_entry_memdev->type;
>  
>   /* Check that a DIMM is present */
> - if (memdev_dmi_entry->size == 0)
> + if (dmi_entry_memdev->size == 0)
>   return;
>  
>   /*
>* Pick the configured speed if it's available, otherwise
>* pick the DIMM speed, or we don't have a speed.
>*/
> - if (memdev_dmi_entry->length > conf_mem_clk_speed_offset) {
> + if (dmi_entry_memdev->length > conf_mem_clk_speed_offset) {
>   dmi_mem_clk_speed =
> - memdev_dmi_entry->conf_mem_clk_speed;
> - } else if (memdev_dmi_entry->length > speed_offset) {
> - dmi_mem_clk_speed = memdev_dmi_entry->speed;
> + dmi_entry_memdev->conf_mem_clk_speed;
> + } else if (dmi_entry_memdev->length > speed_offset) {
> + dmi_mem_clk_speed = dmi_entry_memdev->speed;
>   } else {
>   *dclk_freq = -1;
>   return;

You do not need all of these changes. memdev_dmi_entry was both the
structure name and the variable name in the original code (something I
usually avoid, but C allows it.) Just because you renamed the structure
doesn't mean you have to rename the variable.

Other than that, looks good to me.

Reviewed-by: Jean Delvare 

-- 
Jean Delvare
SUSE L3 Support
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Modify reset func to handle per engine resets

[Mika Kuoppala]

In full gpu reset we prime all engines and reset domains corresponding to
each engine. Per engine reset is just a special case of this process
wherein only a single engine is reset. This change is aimed to modify
relevant functions to achieve this. There are some other steps we carry out
in case of engine reset which are addressed in later patches.

Reset func now accepts a mask of all engines that need to be reset. Where
per engine resets are supported, error handler populates the mask
accordingly otherwise all engines are specified.

v2: ALL_ENGINES mask fixup, better for_each_ring_masked (Chris)
v3: Whitespace fixes (Chris)
v4: Rebase due to s/ring/engine

Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
Signed-off-by: Arun Siluvery 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h |  8 ++-
 drivers/gpu/drm/i915/i915_gem.c | 14 +++---
 drivers/gpu/drm/i915/i915_gem_context.c |  2 +-
 drivers/gpu/drm/i915/i915_reg.h |  2 +
 drivers/gpu/drm/i915/intel_uncore.c | 87 -
 6 files changed, 82 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 20e82008b8b6..3648b73b48da 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -881,7 +881,7 @@ int i915_reset(struct drm_device *dev)
 
simulated = dev_priv->gpu_error.stop_rings != 0;
 
-   ret = intel_gpu_reset(dev);
+   ret = intel_gpu_reset(dev, ALL_ENGINES);
 
/* Also reset the gpu hangman. */
if (simulated) {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fd1ed66dd298..8940b38ed57f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1971,6 +1971,10 @@ static inline struct drm_i915_private 
*guc_to_i915(struct intel_guc *guc)
for ((i__) = 0; (i__) < I915_NUM_ENGINES; (i__)++) \
for_each_if ring__) = &(dev_priv__)->engine[(i__)]), 
intel_engine_initialized((ring__
 
+#define for_each_engine_masked(engine__, dev_priv__, mask__) \
+   for ((engine__) = _priv->engine[0]; (engine__) < 
_priv->engine[I915_NUM_ENGINES]; (engine__)++) \
+   for_each_if (intel_engine_flag((engine__)) & (mask__) && 
intel_engine_initialized((engine__)))
+
 enum hdmi_force_audio {
HDMI_AUDIO_OFF_DVI = -2,/* no aux data for HDMI-DVI converter */
HDMI_AUDIO_OFF, /* force turn off HDMI audio */
@@ -2553,6 +2557,8 @@ struct drm_i915_cmd_table {
 #define BLT_RING   (1<ring_mask & BSD_RING)
 #define HAS_BSD2(dev)  (INTEL_INFO(dev)->ring_mask & BSD2_RING)
 #define HAS_BLT(dev)   (INTEL_INFO(dev)->ring_mask & BLT_RING)
@@ -2681,7 +2687,7 @@ extern void i915_driver_postclose(struct drm_device *dev,
 extern long i915_compat_ioctl(struct file *filp, unsigned int cmd,
  unsigned long arg);
 #endif
-extern int intel_gpu_reset(struct drm_device *dev);
+extern int intel_gpu_reset(struct drm_device *dev, u32 engine_mask);
 extern bool intel_has_gpu_reset(struct drm_device *dev);
 extern int i915_reset(struct drm_device *dev);
 extern unsigned long i915_chipset_val(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 31652c1da761..a25109aa033c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5012,13 +5012,13 @@ i915_gem_cleanup_engines(struct drm_device *dev)
for_each_engine(engine, dev_priv, i)
dev_priv->gt.cleanup_engine(engine);
 
-if (i915.enable_execlists)
-/*
- * Neither the BIOS, ourselves or any other kernel
- * expects the system to be in execlists mode on startup,
- * so we need to reset the GPU back to legacy mode.
- */
-intel_gpu_reset(dev);
+   if (i915.enable_execlists)
+   /*
+* Neither the BIOS, ourselves or any other kernel
+* expects the system to be in execlists mode on startup,
+* so we need to reset the GPU back to legacy mode.
+*/
+   intel_gpu_reset(dev, ALL_ENGINES);
 }
 
 static void
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 1993449ab7c5..c114665a24b3 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -413,7 +413,7 @@ void i915_gem_context_fini(struct drm_device *dev)
/* The only known way to stop the gpu from accessing the 

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: Codify our assumption that the Global GTT is <= 4GiB

[Tvrtko Ursulin]

On 18/03/16 08:42, Joonas Lahtinen wrote:

From: Chris Wilson 

Throughout the code base, we use u32 for offsets into the global GTT. If
we ever see any hardware with a larger GGTT, then we run the real risk
of silent corruption. So test for our assumption up front so that we
have a nice reminder should the time come when it fails.

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Signed-off-by: Joonas Lahtinen 
[Rebased and changed 1ull -> 1ULL]
---
  drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8a9fa03..ba144ba 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3191,6 +3191,13 @@ int i915_gem_gtt_init(struct drm_device *dev)
if (ret)
return ret;

+   if ((ggtt->base.total - 1) >> 32) {
+   DRM_ERROR("We never expected a Global GTT with more than 32bits of 
address space! Found %lldM!\n",
+ ggtt->base.total >> 20);


MB or MiB?


+   ggtt->base.total = 1ULL << 32;
+   ggtt->mappable_end = min(ggtt->mappable_end, ggtt->base.total);
+   }
+
/*
 * Initialise stolen early so that we may reserve preallocated
 * objects for the BIOS to KMS transition.



Reviewed-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] ✗ Fi.CI.BAT: failure for series starting with [v2,1/4] drm/i915/gtt: Reference mappable_end variable from pointer

[Joonas Lahtinen]

On pe, 2016-03-18 at 12:11 +, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [v2,1/4] drm/i915/gtt: Reference mappable_end 
> variable from pointer
> URL   : https://patchwork.freedesktop.org/series/4620/
> State : failure
> 
> == Summary ==
> 
> Series 4620v1 Series without cover letter
> http://patchwork.freedesktop.org/api/1.0/series/4620/revisions/1/mbox/
> 
> Test gem_mmap_gtt:
> Subgroup basic-write-gtt-no-prefault:
> dmesg-warn -> PASS   (bsw-nuc-2)
> Test kms_flip:
> Subgroup basic-flip-vs-dpms:
> pass   -> DMESG-WARN (hsw-brixbox)

HDA problem

> Subgroup basic-flip-vs-wf_vblank:
> dmesg-warn -> PASS   (hsw-brixbox)
> pass   -> DMESG-WARN (bdw-ultra)

HDA problem too.

> Subgroup basic-plain-flip:
> dmesg-warn -> PASS   (hsw-brixbox)
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> dmesg-fail -> FAIL   (snb-x220t)

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

> dmesg-warn -> PASS   (snb-dellxps)
> Subgroup basic-rte:
> dmesg-warn -> PASS   (bsw-nuc-2)
> pass   -> DMESG-WARN (snb-dellxps)

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

So, merging in the series.

> 
> bdw-nuci7total:194  pass:181  dwarn:1   dfail:0   fail:0   skip:12 
> bdw-ultratotal:194  pass:171  dwarn:2   dfail:0   fail:0   skip:21 
> bsw-nuc-2total:194  pass:156  dwarn:1   dfail:0   fail:0   skip:37 
> hsw-brixbox  total:194  pass:170  dwarn:2   dfail:0   fail:0   skip:22 
> hsw-gt2  total:194  pass:176  dwarn:1   dfail:0   fail:0   skip:17 
> ivb-t430stotal:194  pass:168  dwarn:1   dfail:0   fail:0   skip:25 
> skl-i5k-2total:194  pass:170  dwarn:1   dfail:0   fail:0   skip:23 
> skl-i7k-2total:194  pass:170  dwarn:1   dfail:0   fail:0   skip:23 
> skl-nuci5total:194  pass:182  dwarn:1   dfail:0   fail:0   skip:11 
> snb-dellxps  total:194  pass:158  dwarn:2   dfail:0   fail:0   skip:34 
> snb-x220ttotal:194  pass:158  dwarn:2   dfail:0   fail:1   skip:33 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_1641/
> 
> 851d270da650c16883e87bdaad7ca8b37ccbdea3 drm-intel-nightly: 
> 2016y-03m-18d-11h-13m-55s UTC integration manifest
> c40d12b65ef06d0af913c73d77260bcf2d10a9c7 drm/i915: Codify our assumption that 
> the Global GTT is <= 4GiB
> eee60d55ce416f67c8000b69dea7bb098753593b drm/i915/gtt: Clean up GGTT probing 
> code
> 33074c8e629ff0374da6cbb656433bd82a708c20 drm/i915: Rename dev_priv->gtt to 
> dev_priv->ggtt
> 645ac6515415f359a5d43741a4eb87d8c048554e drm/i915/gtt: Reference mappable_end 
> variable from pointer
> 
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Support to enable TRTT on GEN9 (rev8)

[Patchwork]

== Series Details ==

Series: drm/i915: Support to enable TRTT on GEN9 (rev8)
URL   : https://patchwork.freedesktop.org/series/2321/
State : failure

== Summary ==

  CC  drivers/usb/host/xhci-pci.o
  CC [M]  drivers/net/usb/ax88179_178a.o
  LD  drivers/usb/storage/usb-storage.o
  LD  drivers/net/ethernet/synopsys/built-in.o
  CC [M]  drivers/net/usb/cdc_ether.o
  LD  drivers/usb/storage/built-in.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_mac.o
  CC [M]  drivers/net/usb/cdc_eem.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_nvm.o
  CC [M]  drivers/net/usb/smsc75xx.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_phy.o
  CC [M]  drivers/net/usb/smsc95xx.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_mbx.o
  CC [M]  drivers/net/usb/mcs7830.o
  CC [M]  drivers/net/usb/usbnet.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_i210.o
  CC [M]  drivers/net/usb/cdc_ncm.o
  CC [M]  drivers/net/ethernet/intel/igb/igb_ptp.o
  CC [M]  drivers/net/ethernet/intel/igb/igb_hwmon.o
  LD  drivers/usb/host/xhci-hcd.o
  LD  drivers/usb/host/built-in.o
  LD  drivers/usb/built-in.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD  net/xfrm/built-in.o
  LD  net/built-in.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/net/built-in.o
Makefile:950: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

Re: [Intel-gfx] [PATCH 15/21] drm/i915: Adjust obj tiling vs. fb modifier rules

[Matthew Auld]

s/requite/require

s/presumaly/presumably

s/disalling/disabling

I think this makes sense so:

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

[Intel-gfx] [PATCH v4] drm/i915: Tune down init error message due to failure injection

[Imre Deak]

Atm, in case failure injection forces an error the subsequent
"*ERROR* failed to init modeset" error message will make automated
tests (CI) report this event as a breakage even though the event is
expected. To fix this print the error message with debug log level
in this case.

While at it print the error message for any init failure and change it
to
"""
*ERROR* Device initialization failed (errno)
Please file a bug at https://bugs.freedesktop.org/enter_bug.cgi?product=DRI
against DRM/Intel providing the dmesg log by booting with drm.debug=0xf
"""
and export a helper printing error messages using this same format.
A follow-up patch will convert all uses of DRM_ERROR reporting a user facing
problem to use this new helper instead.

v2:
- Include the problematic error message in the commit log, add a
  request to file an fdo bug to the message (Chris)
v3:
- Include the new error message too in the commit log, make the
  fdo link more precise and print part of the message with info log
  level (Chris)
v4: (Chris)
- Use dev_printk instead of DRM_ERROR/INFO and use NOTICE instead of
  NOTE loglevel
- Export a helper for printing user facing error messages

CC: Chris Wilson 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_dma.c | 56 +
 drivers/gpu/drm/i915/i915_drv.h |  6 +
 2 files changed, 57 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 68592b0..241206c 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -66,6 +66,52 @@ bool __i915_inject_load_failure(const char *func, int line)
return false;
 }
 
+#define FDO_BUG_URL "https://bugs.freedesktop.org/enter_bug.cgi?product=DRI;
+#define FDO_BUG_MSG "Please file a bug at " FDO_BUG_URL " against DRM/Intel " \
+   "providing the dmesg log by booting with drm.debug=0xf"
+
+void
+__i915_printk(struct drm_i915_private *dev_priv, const char *level,
+   const char *fmt, ...)
+{
+   struct device *dev = dev_priv->dev->dev;
+   bool is_error = level[1] <= KERN_ERR[1];
+   struct va_format vaf;
+   va_list args;
+
+   va_start(args, fmt);
+
+   vaf.fmt = fmt;
+   vaf.va = 
+
+   dev_printk(level, dev, "%s%pV", is_error ? "*ERROR* " : "", );
+   if (is_error)
+   dev_printk(KERN_NOTICE, dev, "%s", FDO_BUG_MSG);
+
+   va_end(args);
+}
+
+static void __printf(2, 3)
+i915_load_error(struct drm_i915_private *dev_priv, const char *fmt, ...)
+{
+   struct va_format vaf;
+   va_list args;
+   bool forced_error;
+
+   forced_error = i915.inject_load_failure &&
+  i915_load_fail_count == i915.inject_load_failure;
+
+   va_start(args, fmt);
+
+   vaf.fmt = fmt;
+   vaf.va = 
+
+   __i915_printk(dev_priv, forced_error ? KERN_DEBUG : KERN_ERR, "%pV",
+ );
+
+   va_end(args);
+}
+
 static int i915_getparam(struct drm_device *dev, void *data,
 struct drm_file *file_priv)
 {
@@ -972,8 +1018,6 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
if (i915_inject_load_failure())
return -ENODEV;
 
-   dev_priv->dev = dev;
-
/* Setup the write-once "constant" device info */
device_info = (struct intel_device_info *)_priv->info;
memcpy(device_info, info, sizeof(dev_priv->info));
@@ -1303,6 +1347,8 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
return -ENOMEM;
 
dev->dev_private = dev_priv;
+   /* Must be set before calling __i915_printk */
+   dev_priv->dev = dev;
 
ret = i915_driver_init_early(dev_priv, dev,
 (struct intel_device_info *)flags);
@@ -1332,10 +1378,8 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
}
 
ret = i915_load_modeset_init(dev);
-   if (ret < 0) {
-   DRM_ERROR("failed to init modeset\n");
+   if (ret < 0)
goto out_cleanup_vblank;
-   }
 
i915_driver_register(dev_priv);
 
@@ -1357,6 +1401,8 @@ out_runtime_pm_put:
 out_free_priv:
kfree(dev_priv);
 
+   i915_load_error(dev_priv, "Device initialization failed (%d)\n", ret);
+
return ret;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 00c41a4..ca79b15 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2696,6 +2696,12 @@ extern int i915_suspend_switcheroo(struct drm_device 
*dev, pm_message_t state);
 extern int i915_resume_switcheroo(struct drm_device *dev);
 
 /* i915_dma.c */
+void __printf(3, 4)
+__i915_printk(struct drm_i915_private *dev_priv, const char *level,
+   const char *fmt, ...);
+#define i915_report_error(dev_priv, fmt, ...) \
+   __i915_printk(dev_priv, KERN_ERR, 

Re: [Intel-gfx] [PATCH RESEND 3/7] drm/i915: move VBT based eDP port check to intel_bios.c

[Daniel Vetter]

On Wed, Mar 16, 2016 at 12:43:31PM +0200, Jani Nikula wrote:
> Hide knowledge about VBT child devices in intel_bios.c.
> 
> Signed-off-by: Jani Nikula 

Patches 2&3: Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_bios.c | 33 +
>  drivers/gpu/drm/i915/intel_dp.c   | 21 +
>  3 files changed, 35 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5fb7a22e802b..c6ec7029f691 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3336,6 +3336,7 @@ int intel_bios_init(struct drm_i915_private *dev_priv);
>  bool intel_bios_is_valid_vbt(const void *buf, size_t size);
>  bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
>  bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8 
> *i2c_pin);
> +bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port 
> port);
>  
>  /* intel_opregion.c */
>  #ifdef CONFIG_ACPI
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 4f7eba36a849..7f61ca8165f0 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1522,3 +1522,36 @@ bool intel_bios_is_lvds_present(struct 
> drm_i915_private *dev_priv, u8 *i2c_pin)
>  
>   return false;
>  }
> +
> +/**
> + * intel_bios_is_port_edp - is the device in given port eDP
> + * @dev_priv:i915 device instance
> + * @port:port to check
> + *
> + * Return true if the device in %port is eDP.
> + */
> +bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port 
> port)
> +{
> + union child_device_config *p_child;
> + static const short port_mapping[] = {
> + [PORT_B] = DVO_PORT_DPB,
> + [PORT_C] = DVO_PORT_DPC,
> + [PORT_D] = DVO_PORT_DPD,
> + [PORT_E] = DVO_PORT_DPE,
> + };
> + int i;
> +
> + if (!dev_priv->vbt.child_dev_num)
> + return false;
> +
> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> + p_child = dev_priv->vbt.child_dev + i;
> +
> + if (p_child->common.dvo_port == port_mapping[port] &&
> + (p_child->common.device_type & DEVICE_TYPE_eDP_BITS) ==
> + (DEVICE_TYPE_eDP & DEVICE_TYPE_eDP_BITS))
> + return true;
> + }
> +
> + return false;
> +}
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 0e326e776e8f..2f8ce53df9cb 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4990,14 +4990,6 @@ put_power:
>  bool intel_dp_is_edp(struct drm_device *dev, enum port port)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
> - union child_device_config *p_child;
> - int i;
> - static const short port_mapping[] = {
> - [PORT_B] = DVO_PORT_DPB,
> - [PORT_C] = DVO_PORT_DPC,
> - [PORT_D] = DVO_PORT_DPD,
> - [PORT_E] = DVO_PORT_DPE,
> - };
>  
>   /*
>* eDP not supported on g4x. so bail out early just
> @@ -5009,18 +5001,7 @@ bool intel_dp_is_edp(struct drm_device *dev, enum port 
> port)
>   if (port == PORT_A)
>   return true;
>  
> - if (!dev_priv->vbt.child_dev_num)
> - return false;
> -
> - for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> - p_child = dev_priv->vbt.child_dev + i;
> -
> - if (p_child->common.dvo_port == port_mapping[port] &&
> - (p_child->common.device_type & DEVICE_TYPE_eDP_BITS) ==
> - (DEVICE_TYPE_eDP & DEVICE_TYPE_eDP_BITS))
> - return true;
> - }
> - return false;
> + return intel_bios_is_port_edp(dev_priv, port);
>  }
>  
>  void
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: Restrict usage of live status check

[Sharma, Shashank]

Regards
Shashank

On 3/17/2016 10:17 PM, Ville Syrjälä wrote:

On Thu, Mar 17, 2016 at 10:03:04PM +0530, Sharma, Shashank wrote:

Hey Chris,
I added comments for both Ville and you, please help me to understand this.

Regards
Shashank

On 3/17/2016 9:51 PM, Ville Syrjälä wrote:

On Thu, Mar 17, 2016 at 09:35:30PM +0530, Sharma, Shashank wrote:

Regards
Shashank

On 3/17/2016 9:31 PM, Ville Syrjälä wrote:

On Thu, Mar 17, 2016 at 09:15:39PM +0530, Sharma, Shashank wrote:

Regards
Shashank

On 3/17/2016 6:34 PM, Ville Syrjälä wrote:

On Thu, Mar 17, 2016 at 01:29:25PM +0530, Shashank Sharma wrote:

This patch restricts usage of live status check for HDMI detection.
While testing certain (monitor + cable) combinations with various
intel  platforms, it seems that live status register is not reliable
on some older devices. So limit the live_status check from VLV onwards.

This fixes a regression introduced in:
commit: 237ed86 "drm/i915: Check live status"
Author: Sonika Jindal 
Date:   Tue Sep 15 09:44:20 2015 +0530

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index e2dab48..d24d18a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1397,7 +1397,8 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
enum drm_connector_status status;
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
struct drm_i915_private *dev_priv = to_i915(connector->dev);
-   bool live_status = false;
+   struct drm_device *dev = connector->dev;
+   bool live_status = true;
unsigned int try;

DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
@@ -1405,16 +1406,21 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)

intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);

-   for (try = 0; !live_status && try < 9; try++) {
-   if (try)
-   msleep(10);
-   live_status = intel_digital_port_connected(dev_priv,
+   /*
+   * Live status check for HDMI detection is not very
+   * reliable on older platforms. So insist the live
+   * status check for EDID read from VLV onwards.
+   */
+   if (INTEL_INFO(dev)->gen >= 7 && !IS_IVYBRIDGE(dev)) {
+   for (try = 0; !live_status && try < 9; try++) {
+   if (try)
+   msleep(10);
+   live_status = intel_digital_port_connected(dev_priv,
hdmi_to_dig_port(intel_hdmi));
+   }
+   DRM_DEBUG_KMS("Live status %s\n", live_status ? "up" : "down");
}

-   if (!live_status)
-   DRM_DEBUG_KMS("Live status not up!");
-


As I said before, I think this whole thing could be solved with a simple
two-liner here:

+   if (...)
+   live_status = true;


Yes I remember, and I replied on that already that why we would like to
keep the live status check. In fact I would be ok to remove this check
if you can suggest some other way of making this work for other
operating systems/sw platforms.


My two liner would keep the check.


Sorry, I might have not understood you properly.
Do you mean:
if (INTEL_INFO(dev)->gen < 7 && IS_IVYBRIDGE(dev)) {
live_status = true;
} else {
do the same looping for retry;
}


No, I mean

{
...
do loop;

if (!live_status)
DRM_DEBUG_KMS("Live status not up!");

+   if (don't trust live status)
+   live_status = true;

intel_hdmi_unset_edid();

if (intel_hdmi_set_edid(live_status)) {
...
}



In fact, this is what I have done.
If you see the change in this patch,
/* Lets make live status true for < VLV platforms */
bool live_status = true;

blah
blah

/* Check live status only for newer platforms */
if (this is VLV or later platforms) {
live_status = read_real_live_status();
}
intel_hdmi_unset_edid();
intel_hdmi_set_edid(live_status);

Now, my question is, do you want to remove live_status check for VLV and
other platforms too ? or this is good enough ?


No, I'm objecting to changing the entire code when you could just add
two lines. Also my way has the extra benefit that we keep the live
status check mostly working on these presumed "broken" platforms.

So the only difference to the current situation is that we would still
attempt the EDID read even if live_status came out as false, but thanks
to the extra delay from the live status polling we would hopefully
avoid spurious detection results since the EDID read gets 

Re: [Intel-gfx] [PATCH igt] lib/igt_aux: Framework for measuring latency in raising signals

[Chris Wilson]

On Fri, Mar 18, 2016 at 07:16:37PM +, Chris Wilson wrote:
> Not sure how best to put this to use yet, we need a set of benchmarks to
> track changes as well as a few hard fail criteria. But at least this is a
> start towards measuring how long we block signals whilst in the driver.

I think I'm leaning towards using an ioctl preloader to measure
siglatency of real applications and asking who actually cares about
siglatency within the render thread? X and other single threaded
monoliths. struct_mutex contention being far more important. So write a
tool to poke around applications and wait some future fireworks.
-Chris

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

Re: [Intel-gfx] [PATCH] drm/i915: Restrict usage of live status check

[Sharma, Shashank]

Regards
Shashank

On 3/17/2016 11:29 PM, Jani Nikula wrote:

On Thu, 17 Mar 2016, "Sharma, Shashank"  wrote:

[ text/plain ]
Hey Chris,
I added comments for both Ville and you, please help me to understand this.

Regards
Shashank

On 3/17/2016 9:51 PM, Ville Syrjälä wrote:

On Thu, Mar 17, 2016 at 09:35:30PM +0530, Sharma, Shashank wrote:

Regards
Shashank

On 3/17/2016 9:31 PM, Ville Syrjälä wrote:

On Thu, Mar 17, 2016 at 09:15:39PM +0530, Sharma, Shashank wrote:

Regards
Shashank

On 3/17/2016 6:34 PM, Ville Syrjälä wrote:

On Thu, Mar 17, 2016 at 01:29:25PM +0530, Shashank Sharma wrote:

This patch restricts usage of live status check for HDMI detection.
While testing certain (monitor + cable) combinations with various
intel  platforms, it seems that live status register is not reliable
on some older devices. So limit the live_status check from VLV onwards.

This fixes a regression introduced in:
commit: 237ed86 "drm/i915: Check live status"
Author: Sonika Jindal 
Date:   Tue Sep 15 09:44:20 2015 +0530

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index e2dab48..d24d18a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1397,7 +1397,8 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
enum drm_connector_status status;
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
struct drm_i915_private *dev_priv = to_i915(connector->dev);
-   bool live_status = false;
+   struct drm_device *dev = connector->dev;
+   bool live_status = true;
unsigned int try;

DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
@@ -1405,16 +1406,21 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)

intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);

-   for (try = 0; !live_status && try < 9; try++) {
-   if (try)
-   msleep(10);
-   live_status = intel_digital_port_connected(dev_priv,
+   /*
+   * Live status check for HDMI detection is not very
+   * reliable on older platforms. So insist the live
+   * status check for EDID read from VLV onwards.
+   */
+   if (INTEL_INFO(dev)->gen >= 7 && !IS_IVYBRIDGE(dev)) {
+   for (try = 0; !live_status && try < 9; try++) {
+   if (try)
+   msleep(10);
+   live_status = intel_digital_port_connected(dev_priv,
hdmi_to_dig_port(intel_hdmi));
+   }
+   DRM_DEBUG_KMS("Live status %s\n", live_status ? "up" : "down");
}

-   if (!live_status)
-   DRM_DEBUG_KMS("Live status not up!");
-


As I said before, I think this whole thing could be solved with a simple
two-liner here:

+   if (...)
+   live_status = true;


Yes I remember, and I replied on that already that why we would like to
keep the live status check. In fact I would be ok to remove this check
if you can suggest some other way of making this work for other
operating systems/sw platforms.


My two liner would keep the check.


Sorry, I might have not understood you properly.
Do you mean:
if (INTEL_INFO(dev)->gen < 7 && IS_IVYBRIDGE(dev)) {
live_status = true;
} else {
do the same looping for retry;
}


No, I mean

{
...
do loop;

if (!live_status)
DRM_DEBUG_KMS("Live status not up!");

+   if (don't trust live status)
+   live_status = true;

intel_hdmi_unset_edid();

if (intel_hdmi_set_edid(live_status)) {
...
}



In fact, this is what I have done.
If you see the change in this patch,


Actually, not. You set live_status to true in the beginning, and your
loop condition has !live_status, i.e. you won't check live status even
once on any platform. Which is what I said in my review.

BR,
Jani.
Ah.. damn. While splitting the patch into two, I missed this part. 
Thanks for pointing this out.




/* Lets make live status true for < VLV platforms */
bool live_status = true;

blah
blah

/* Check live status only for newer platforms */
if (this is VLV or later platforms) {
live_status = read_real_live_status();
}
intel_hdmi_unset_edid();
intel_hdmi_set_edid(live_status);

Now, my question is, do you want to remove live_status check for VLV and
other platforms too ? or this is good enough ?




intel_hdmi_unset_edid(connector);

if (intel_hdmi_set_edid(connector, live_status)) {
--
1.9.1

[Intel-gfx] [PATCH i-g-t v2] igt/gem_pipe_control_store_loop: Add qword write tests

[Michał Winiarski]

Test description suggested that all platforms were testing qword writes,
while in fact only gen4-gen5 did.

v2: Test dword/qword writes for all available platforms

Cc: Chris Wilson 
Signed-off-by: Michał Winiarski 
---
 tests/gem_pipe_control_store_loop.c | 49 +
 1 file changed, 33 insertions(+), 16 deletions(-)

diff --git a/tests/gem_pipe_control_store_loop.c 
b/tests/gem_pipe_control_store_loop.c
index a155ad1..cab3ed5 100644
--- a/tests/gem_pipe_control_store_loop.c
+++ b/tests/gem_pipe_control_store_loop.c
@@ -26,7 +26,7 @@
  */
 
 /*
- * Testcase: (TLB-)Coherency of pipe_control QW writes
+ * Testcase: (TLB-)Coherency of pipe_control writes
  *
  * Writes a counter-value into an always newly allocated target bo (by 
disabling
  * buffer reuse). Decently trashes on tlb inconsistencies, too.
@@ -43,7 +43,7 @@
 #include "drm.h"
 #include "intel_bufmgr.h"
 
-IGT_TEST_DESCRIPTION("Test (TLB-)Coherency of pipe_control QW writes.");
+IGT_TEST_DESCRIPTION("Test (TLB-)Coherency of pipe_control writes.");
 
 static drm_intel_bufmgr *bufmgr;
 struct intel_batchbuffer *batch;
@@ -60,13 +60,20 @@ uint32_t devid;
 #define   PIPE_CONTROL_CS_STALL(1<<20)
 #define   PIPE_CONTROL_GLOBAL_GTT (1<<2) /* in addr dword */
 
+#define PIPE_CONTROL_STATE_BUFFER_REUSED   (1 << 0)
+#define PIPE_CONTROL_STATE_QWORD_WRITE (1 << 1)
+#define PIPE_CONTROL_STATE_ALL_FLAGS (PIPE_CONTROL_STATE_BUFFER_REUSED | \
+ PIPE_CONTROL_STATE_QWORD_WRITE)
+
 /* Like the store dword test, but we create new command buffers each time */
 static void
-store_pipe_control_loop(bool preuse_buffer)
+store_pipe_control_loop(uint32_t flags)
 {
int i, val = 0;
uint32_t *buf;
drm_intel_bo *target_bo;
+   const bool preuse_buffer = flags & PIPE_CONTROL_STATE_BUFFER_REUSED;
+   const bool qword_write = flags & PIPE_CONTROL_STATE_QWORD_WRITE;
 
for (i = 0; i < SLOW_QUICK(0x1, 4); i++) {
/* we want to check tlb consistency of the pipe_control target,
@@ -98,15 +105,16 @@ store_pipe_control_loop(bool preuse_buffer)
 * creating new batchbuffers - with buffer reuse disabled, the
 * support code will do that for us. */
if (batch->gen >= 8) {
-   BEGIN_BATCH(4, 1);
-   OUT_BATCH(GFX_OP_PIPE_CONTROL + 1);
+   BEGIN_BATCH(4 + qword_write, 1);
+   OUT_BATCH(GFX_OP_PIPE_CONTROL + 1 + qword_write);
OUT_BATCH(PIPE_CONTROL_WRITE_IMMEDIATE);
OUT_RELOC_FENCED(target_bo,
 I915_GEM_DOMAIN_INSTRUCTION, 
I915_GEM_DOMAIN_INSTRUCTION,
 PIPE_CONTROL_GLOBAL_GTT);
OUT_BATCH(val); /* write data */
+   if (qword_write)
+   OUT_BATCH(~val); /* high dword */
ADVANCE_BATCH();
-
} else if (batch->gen >= 6) {
/* work-around hw issue, see 
intel_emit_post_sync_nonzero_flush
 * in mesa sources. */
@@ -118,24 +126,27 @@ store_pipe_control_loop(bool preuse_buffer)
OUT_BATCH(0); /* write data */
ADVANCE_BATCH();
 
-   BEGIN_BATCH(4, 1);
-   OUT_BATCH(GFX_OP_PIPE_CONTROL);
+   BEGIN_BATCH(4 + qword_write, 1);
+   OUT_BATCH(GFX_OP_PIPE_CONTROL + qword_write);
OUT_BATCH(PIPE_CONTROL_WRITE_IMMEDIATE);
OUT_RELOC(target_bo,
 I915_GEM_DOMAIN_INSTRUCTION, 
I915_GEM_DOMAIN_INSTRUCTION, 
 PIPE_CONTROL_GLOBAL_GTT);
OUT_BATCH(val); /* write data */
+   if (qword_write)
+   OUT_BATCH(~val); /* high dword */
ADVANCE_BATCH();
} else if (batch->gen >= 4) {
-   BEGIN_BATCH(4, 1);
+   BEGIN_BATCH(3 + qword_write, 1);
OUT_BATCH(GFX_OP_PIPE_CONTROL | PIPE_CONTROL_WC_FLUSH |
PIPE_CONTROL_TC_FLUSH |
-   PIPE_CONTROL_WRITE_IMMEDIATE | 2);
+   PIPE_CONTROL_WRITE_IMMEDIATE | (1 + 
qword_write));
OUT_RELOC(target_bo,
I915_GEM_DOMAIN_INSTRUCTION, 
I915_GEM_DOMAIN_INSTRUCTION,
PIPE_CONTROL_GLOBAL_GTT);
OUT_BATCH(val);
-   OUT_BATCH(0xdeadbeef);
+   if (qword_write)
+   OUT_BATCH(~val); /* high dword */
ADVANCE_BATCH();
   

Re: [Intel-gfx] [PATCH v2] drm/i915: Tune down init error message due to failure injection

[Chris Wilson]

On Fri, Mar 18, 2016 at 10:59:41AM +0200, Joonas Lahtinen wrote:
> On pe, 2016-03-18 at 00:18 +0200, Imre Deak wrote:
> > On Thu, 2016-03-17 at 22:14 +, Chris Wilson wrote:
> > > 
> > > On Fri, Mar 18, 2016 at 12:09:30AM +0200, Imre Deak wrote:
> > > > 
> > > > On Thu, 2016-03-17 at 21:48 +, Chris Wilson wrote:
> > > > > 
> > > > > I would also like this to be the preferred
> > > > > DRM_ERROR reporting mechanism i.e. anytime we emit an ERROR we
> > > > > should
> > > > > be
> > > > > encouraging the user to file a bug, and do so in a user friendly
> > > > > fashion.
> > > > Ok, but only in i915 I assume. Should we also convert then all
> > > > DRM_ERROR to dev_err - with an *ERROR* prefix - or still use
> > > > DRM_ERROR?
> > > Within i915. I am thinking along the lines that no DRM_ERROR should
> > > exist that doesn't acknowlege that it is a user facing error message
> > > (i.e. written in plain English and is informative, and includes a bug
> > > reporting reference). So i915_report_error() or somesuch.
> > Ok, will give it a go.
> 
> Daniel didn't want i915 debugging/erroring mechanisms to deviate from
> core DRM. So I guess this would follow in the same category.

Too late really. We have key messages for i915 failures now being
generted by other subsystems using pr_err/dev_err, which for some
strange reason are using the core reporting mechanims not DRM's.
-Chris

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix race condition in intel_dp_destroy_mst_connector()

[Ville Syrjälä]

On Wed, Mar 16, 2016 at 03:18:04PM -0400, Lyude wrote:
> After unplugging a DP MST display from the system, we have to go through
> and destroy all of the DRM connectors associated with it since none of
> them are valid anymore. Unfortunately, intel_dp_destroy_mst_connector()
> doesn't do a good enough job of ensuring that throughout the destruction
> process that no modesettings can be done with the connectors. As it is
> right now, intel_dp_destroy_mst_connector() works like this:
> 
> * Take all modeset locks
> * Clear the configuration of the crtc on the connector, if there is one
> * Drop all modeset locks, this is required because of circular
>   dependency issues that arise with trying to remove the connector from
>   sysfs with modeset locks held
> * Unregister the connector
> * Take all modeset locks, again
> * Do the rest of the required cleaning for destroying the connector
> * Finally drop all modeset locks for good

So pretty much what I suspected
https://lists.freedesktop.org/archives/intel-gfx/2016-February/087734.html

> 
> This only works sometimes. During the destruction process, it's very
> possible that a userspace application will attempt to do a modesetting
> using the connector. When we drop the modeset locks, an ioctl handler
> such as drm_mode_setcrtc has the oppurtunity to take all of the modeset
> locks from us. When this happens, one thing leads to another and
> eventually we end up committing a mode with the non-existent connector:
> 
>   [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to 
> enable link training
>   [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
>   [drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel 
> equalization
>   [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
>   [drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi
> 
> And in some cases, such as with the T460s using an MST dock, this
> results in breaking modesetting and/or panicking the system.

Are these just kernel oopses etc.? If the hardware gets upset from
modesetting when the sink is gone, well, then we still have a problem
because the user can of course yank the cable while the modeset is already
underway.

> 
> To work around this, we now unregister the connector at the very
> beginning of intel_dp_destroy_mst_connector(), grab all the modesetting
> locks, and then hold them until we finish the rest of the function.
> 
> CC: sta...@vger.kernel.org
> Signed-off-by: Lyude 
> Signed-off-by: Rob Clark 

These sobs don't make much sense to me.

Patch itself does make sense to me, so 
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_dp_mst.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index fa0dabf..b21ac88 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -499,6 +499,8 @@ static void intel_dp_destroy_mst_connector(struct 
> drm_dp_mst_topology_mgr *mgr,
>   struct intel_connector *intel_connector = to_intel_connector(connector);
>   struct drm_device *dev = connector->dev;
>  
> + intel_connector->unregister(intel_connector);
> +
>   /* need to nuke the connector */
>   drm_modeset_lock_all(dev);
>   if (connector->state->crtc) {
> @@ -512,11 +514,7 @@ static void intel_dp_destroy_mst_connector(struct 
> drm_dp_mst_topology_mgr *mgr,
>  
>   WARN(ret, "Disabling mst crtc failed with %i\n", ret);
>   }
> - drm_modeset_unlock_all(dev);
>  
> - intel_connector->unregister(intel_connector);
> -
> - drm_modeset_lock_all(dev);
>   intel_connector_remove_from_fbdev(intel_connector);
>   drm_connector_cleanup(connector);
>   drm_modeset_unlock_all(dev);
> -- 
> 2.5.0
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Intel-gfx] [PATCH] drm/i915/userptr: Replace get_user_pages()

[Chris Wilson]

Although the long term future of get_user_pages_locked() itself is
doubtful, the kernel currently recommends:

/* get_user_pages should be phased out in favor of
 * get_user_pages_locked|unlocked or get_user_pages_fast. Nothing
 * should use get_user_pages because it cannot pass
 * FAULT_FLAG_ALLOW_RETRY to handle_mm_fault.
 */

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_userptr.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 54088a4d6498..fa7d8a8b66ef 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -500,20 +500,22 @@ __i915_gem_userptr_get_pages_worker(struct work_struct 
*_work)
pvec = drm_malloc_ab(npages, sizeof(struct page *));
if (pvec != NULL) {
struct mm_struct *mm = obj->userptr.mm->mm;
+   int locked = 1;
 
down_read(>mmap_sem);
while (pinned < npages) {
-   ret = get_user_pages(work->task, mm,
-obj->userptr.ptr + pinned * 
PAGE_SIZE,
-npages - pinned,
-!obj->userptr.read_only, 0,
-pvec + pinned, NULL);
+   ret = get_user_pages_locked(work->task, mm,
+   obj->userptr.ptr + pinned * 
PAGE_SIZE,
+   npages - pinned,
+   !obj->userptr.read_only, 0,
+   pvec + pinned, );
if (ret < 0)
break;
 
pinned += ret;
}
-   up_read(>mmap_sem);
+   if (locked)
+   up_read(>mmap_sem);
}
 
mutex_lock(>struct_mutex);
-- 
2.7.0

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

Re: [Intel-gfx] [PATCH i-g-t v3] igt/gem_pipe_control_store_loop: Add qword write tests

[Chris Wilson]

On Thu, Mar 17, 2016 at 05:15:39PM +0100, Michał Winiarski wrote:
> Test description suggested that all platforms were testing qword writes,
> while in fact only gen4-gen5 did.
> 
> v2: Test dword/qword writes for all available platforms.
> v3: Rewrite, drop libdrm/intel_batchbuffer dependencies,
> drop brw_emit_post_sync_nonzero_flush WA for gen6/gen7,
> drop WC_FLUSH/TC_FLUSH on gen4/gen5,
> drop preuse tests, use gem_wait instead of set_domain.

Sorry was too hasty on the preuse. The problem is the comment is
misleading! The goal is to create a PIN_USER vma (i.e. a vma with no
global GTT alias) and then use it in the execbuf. Bonus points for
making it busy and throwing SIGINTS at it. This is because on gen6 we
have to use the global GTT for the pipecontrol and so we need to fixup
the vma to have the PIN_GLOBAL alias even though we see it is already
allocated in the aliasing-ppgtt.

Along the same lines, in this test I would very much prefer not to use
the PWRITE_IOCTL (gem_write) and use a CPU mmap for uploading. Again,
the goal is be absolutely sure that the PIN_GLOBAL vma does not exist
before we issue the execbuf.
-Chris

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

[Intel-gfx] [PATCH v2 9/9] drm/i915/bxt: add bxt dsi gpio element support

[Jani Nikula]

Use a table similar to vlv to check for accepted gpio indexes. For now,
add all, but this list should be trimmed down. Use managed gpio request,
which will be automatically released when the driver is detached.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 667 -
 1 file changed, 666 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index f8d3f608e9c8..6b8dc15f3656 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -114,6 +115,636 @@ static struct vlv_gpio_map vlv_gpio_table[] = {
 #define CHV_GPIO_CFG_HIZ   0x8100
 #define CHV_GPIO_CFG_TX_STATE_SHIFT1
 
+#define BXT_HV_DDI0_DDC_SDA_PIN187
+#define BXT_HV_DDI0_DDC_SCL_PIN188
+#define BXT_HV_DDI1_DDC_SDA_PIN189
+#define BXT_HV_DDI1_DDC_SCL_PIN190
+#define BXT_DBI_SDA_PIN191
+#define BXT_DBI_SCL_PIN192
+#define BXT_PANEL0_VDDEN_PIN   193
+#define BXT_PANEL0_BKLTEN_PIN  194
+#define BXT_PANEL0_BKLTCTL_PIN 195
+#define BXT_PANEL1_VDDEN_PIN   196
+#define BXT_PANEL1_BKLTEN_PIN  197
+#define BXT_PANEL1_BKLTCTL_PIN 198
+#define BXT_DBI_CSX_PIN199
+#define BXT_DBI_RESX_PIN   200
+#define BXT_GP_INTD_DSI_TE1_PIN201
+#define BXT_GP_INTD_DSI_TE2_PIN202
+#define BXT_USB_OC0_B_PIN  203
+#define BXT_USB_OC1_B_PIN  204
+#define BXT_MEX_WAKE0_B_PIN205
+#define BXT_MEX_WAKE1_B_PIN206
+#define BXT_EMMC0_CLK_PIN  156
+#define BXT_EMMC0_D0_PIN   157
+#define BXT_EMMC0_D1_PIN   158
+#define BXT_EMMC0_D2_PIN   159
+#define BXT_EMMC0_D3_PIN   160
+#define BXT_EMMC0_D4_PIN   161
+#define BXT_EMMC0_D5_PIN   162
+#define BXT_EMMC0_D6_PIN   163
+#define BXT_EMMC0_D7_PIN   164
+#define BXT_EMMC0_CMD_PIN  165
+#define BXT_SDIO_CLK_PIN   166
+#define BXT_SDIO_D0_PIN167
+#define BXT_SDIO_D1_PIN168
+#define BXT_SDIO_D2_PIN169
+#define BXT_SDIO_D3_PIN170
+#define BXT_SDIO_CMD_PIN   171
+#define BXT_SDCARD_CLK_PIN 172
+#define BXT_SDCARD_D0_PIN  173
+#define BXT_SDCARD_D1_PIN  174
+#define BXT_SDCARD_D2_PIN  175
+#define BXT_SDCARD_D3_PIN  176
+#define BXT_SDCARD_CD_B_PIN177
+#define BXT_SDCARD_CMD_PIN 178
+#define BXT_SDCARD_LVL_CLK_FB_PIN  179
+#define BXT_SDCARD_LVL_CMD_DIR_PIN 180
+#define BXT_SDCARD_LVL_DAT_DIR_PIN 181
+#define BXT_EMMC0_STROBE_PIN   182
+#define BXT_SDIO_PWR_DOWN_B_PIN183
+#define BXT_SDCARD_PWR_DOWN_B_PIN  184
+#define BXT_SDCARD_LVL_SEL_PIN 185
+#define BXT_SDCARD_LVL_WP_PIN  186
+#define BXT_LPSS_I2C0_SDA_PIN  124
+#define BXT_LPSS_I2C0_SCL_PIN  125
+#define BXT_LPSS_I2C1_SDA_PIN  126
+#define BXT_LPSS_I2C1_SCL_PIN  127
+#define BXT_LPSS_I2C2_SDA_PIN  128
+#define BXT_LPSS_I2C2_SCL_PIN  129
+#define BXT_LPSS_I2C3_SDA_PIN  130
+#define BXT_LPSS_I2C3_SCL_PIN  131
+#define BXT_LPSS_I2C4_SDA_PIN  132
+#define BXT_LPSS_I2C4_SCL_PIN  133
+#define BXT_LPSS_I2C5_SDA_PIN  134
+#define BXT_LPSS_I2C5_SCL_PIN  135
+#define BXT_LPSS_I2C6_SDA_PIN  136
+#define BXT_LPSS_I2C6_SCL_PIN  137
+#define BXT_LPSS_I2C7_SDA_PIN  138
+#define BXT_LPSS_I2C7_SCL_PIN  139
+#define BXT_ISH_I2C0_SDA_PIN   140
+#define BXT_ISH_I2C0_SCL_PIN   141
+#define BXT_ISH_I2C1_SDA_PIN   142
+#define BXT_ISH_I2C1_SCL_PIN   143
+#define BXT_ISH_I2C2_SDA_PIN   144
+#define BXT_ISH_I2C2_SCL_PIN   145
+#define BXT_ISH_GPIO_0_PIN 146
+#define BXT_ISH_GPIO_1_PIN 147
+#define BXT_ISH_GPIO_2_PIN 148
+#define BXT_ISH_GPIO_3_PIN 149
+#define BXT_ISH_GPIO_4_PIN 150
+#define BXT_ISH_GPIO_5_PIN 151
+#define BXT_ISH_GPIO_6_PIN 152
+#define BXT_ISH_GPIO_7_PIN 153
+#define BXT_ISH_GPIO_8_PIN 154
+#define BXT_ISH_GPIO_9_PIN 155
+#define BXT_AVS_I2S1_MCLK_PIN  74
+#define BXT_AVS_I2S1_BCLK_PIN  75
+#define BXT_AVS_I2S1_WS_SYNC_PIN   76
+#define BXT_AVS_I2S1_SDI_PIN   77
+#define BXT_AVS_I2S1_SDO_PIN   78
+#define BXT_AVS_M_CLK_A1_PIN   79
+#define BXT_AVS_M_CLK_B1_PIN   80
+#define BXT_AVS_M_DATA_1_PIN   

[Intel-gfx] linux-firmware-i915 pull request (skl guc 6.1)

[Vivi, Rodrigo]

Hi,

Please consider pulling i915 updates to linux-firmware.git:

The following changes since commit
0a0c97667d0e80c56de8fd999d17bf2b553aab8f:

  linux-firmware/i915: Major GuC release for Skylake - ver 6.1 (2016-03
-16 15:35:42 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~vivijim/linux-firmware-i915 master

for you to fetch changes up to
0a0c97667d0e80c56de8fd999d17bf2b553aab8f:

  linux-firmware/i915: Major GuC release for Skylake - ver 6.1 (2016-03
-16 15:35:42 -0700)



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

[Intel-gfx] [PATCH] drm/i915: Restrict usage of live status check

[Shashank Sharma]

This patch restricts usage of live status check for HDMI detection.
While testing certain (monitor + cable) combinations with various
intel  platforms, it seems that live status register is not reliable
on some older devices. So limit the live_status check from VLV onwards.

This fixes a regression introduced in:
commit: 237ed86 "drm/i915: Check live status"
Author: Sonika Jindal 
Date:   Tue Sep 15 09:44:20 2015 +0530

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index e2dab48..d24d18a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1397,7 +1397,8 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
enum drm_connector_status status;
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
struct drm_i915_private *dev_priv = to_i915(connector->dev);
-   bool live_status = false;
+   struct drm_device *dev = connector->dev;
+   bool live_status = true;
unsigned int try;
 
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
@@ -1405,16 +1406,21 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
 
intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
 
-   for (try = 0; !live_status && try < 9; try++) {
-   if (try)
-   msleep(10);
-   live_status = intel_digital_port_connected(dev_priv,
+   /*
+   * Live status check for HDMI detection is not very
+   * reliable on older platforms. So insist the live
+   * status check for EDID read from VLV onwards.
+   */
+   if (INTEL_INFO(dev)->gen >= 7 && !IS_IVYBRIDGE(dev)) {
+   for (try = 0; !live_status && try < 9; try++) {
+   if (try)
+   msleep(10);
+   live_status = intel_digital_port_connected(dev_priv,
hdmi_to_dig_port(intel_hdmi));
+   }
+   DRM_DEBUG_KMS("Live status %s\n", live_status ? "up" : "down");
}
 
-   if (!live_status)
-   DRM_DEBUG_KMS("Live status not up!");
-
intel_hdmi_unset_edid(connector);
 
if (intel_hdmi_set_edid(connector, live_status)) {
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH RESEND 6/7] drm/i915/bios: drop has_mipi in favor of intel_bios_is_dsi_present

[Jani Nikula]

On Wed, 16 Mar 2016, Daniel Vetter  wrote:
> On Wed, Mar 16, 2016 at 12:43:34PM +0200, Jani Nikula wrote:
>> Favor a single point of truth instead of duplicating the information.
>> 
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/i915/i915_drv.h   |  1 -
>>  drivers/gpu/drm/i915/intel_bios.c | 12 +++-
>>  2 files changed, 3 insertions(+), 10 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 9c7402c062b9..cff4b6ec79d8 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -1415,7 +1415,6 @@ struct intel_vbt_data {
>>  unsigned int lvds_use_ssc:1;
>>  unsigned int display_clock_mode:1;
>>  unsigned int fdi_rx_polarity_inverted:1;
>> -unsigned int has_mipi:1;
>>  int lvds_ssc_freq;
>>  unsigned int bios_lvds_val; /* initial [PCH_]LVDS reg val in VBIOS */
>>  
>> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
>> b/drivers/gpu/drm/i915/intel_bios.c
>> index 4b6bd6f2e193..aa90dc662e7f 100644
>> --- a/drivers/gpu/drm/i915/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/intel_bios.c
>> @@ -706,7 +706,7 @@ parse_mipi_config(struct drm_i915_private *dev_priv,
>>  const struct mipi_pps_data *pps;
>>  
>>  /* parse MIPI blocks only if LFP type is MIPI */
>> -if (!dev_priv->vbt.has_mipi)
>> +if (!intel_bios_is_dsi_present(dev_priv, NULL))
>>  return;
>>  
>>  /* Initialize this to undefined indicating no generic MIPI support */
>> @@ -1232,13 +1232,6 @@ parse_device_mapping(struct drm_i915_private 
>> *dev_priv,
>>  continue;
>>  }
>>  
>> -if (p_child->common.dvo_port >= DVO_PORT_MIPIA
>> -&& p_child->common.dvo_port <= DVO_PORT_MIPID
>> -&_child->common.device_type & DEVICE_TYPE_MIPI_OUTPUT) {
>
> New code also rejects DVO_PORT_MIPIC, you should mention that robustness
> fix in the commit message. With this added:
>
> Reviewed-by: Daniel Vetter 

Pushed patches 1-6 to drm-intel-next-queued, thanks for the review, I'll
hold on to patch 7 for a little while longer. Sparse doesn't compain on
patch 4, and amended commit message on this one while applying.

BR,
Jani.




>
>> -DRM_DEBUG_KMS("Found MIPI as LFP\n");
>> -dev_priv->vbt.has_mipi = 1;
>> -}
>> -
>>  child_dev_ptr = dev_priv->vbt.child_dev + count;
>>  count++;
>>  
>> @@ -1580,7 +1573,8 @@ bool intel_bios_is_dsi_present(struct drm_i915_private 
>> *dev_priv,
>>  switch (dvo_port) {
>>  case DVO_PORT_MIPIA:
>>  case DVO_PORT_MIPIC:
>> -*port = dvo_port - DVO_PORT_MIPIA;
>> +if (port)
>> +*port = dvo_port - DVO_PORT_MIPIA;
>>  return true;
>>  case DVO_PORT_MIPIB:
>>  case DVO_PORT_MIPID:
>> -- 
>> 2.1.4
>> 
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Get rid of intel_dp_dpcd_read_wake()

[Ville Syrjälä]

On Fri, Mar 18, 2016 at 06:12:35PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 18, 2016 at 04:13:45PM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 17, 2016 at 11:40:45AM -0400, Lyude wrote:
> > > Since we've fixed up drm_dp_dpcd_read() to allow for retries when things
> > > timeout, there's no use for having this function anymore. Good riddens.
> > > 
> > > Signed-off-by: Lyude 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c | 79 
> > > -
> > >  1 file changed, 22 insertions(+), 57 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index cdc2c15..fb4cbbe5 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -3190,47 +3190,14 @@ static void chv_dp_post_pll_disable(struct 
> > > intel_encoder *encoder)
> > >  }
> > >  
> > >  /*
> > > - * Native read with retry for link status and receiver capability reads 
> > > for
> > > - * cases where the sink may still be asleep.
> > > - *
> > > - * Sinks are *supposed* to come up within 1ms from an off state, but 
> > > we're also
> > > - * supposed to retry 3 times per the spec.
> > > - */
> > > -static ssize_t
> > > -intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, unsigned int offset,
> > > - void *buffer, size_t size)
> > > -{
> > > - ssize_t ret;
> > > - int i;
> > > -
> > > - /*
> > > -  * Sometime we just get the same incorrect byte repeated
> > > -  * over the entire buffer. Doing just one throw away read
> > > -  * initially seems to "solve" it.
> > > -  */
> > > - drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer, 1);
> > 
> > NAK
> > 
> > If people keep intentionally breaking my shit I'm going to become
> > really grumpy soon.
> 
> Oh, and just in case someone wants to come up with a better kludge,
> I just spent a few minutes analyzing the behavior of this crappy
> monitor a.
> 
> What happens is that when the monitor is fully powered up (LED is blue)
> things are fine. After the monitor goes to sleep (LED turns orange)
> the first DPCD read will produce garbage. Further DPCD reads are fine,
> even if I wait a significant amount of time between the reads, as long
> as the monitor didn't do a power on->off cycle in between. So it looks
> like it's always just the first read after power down that gets
> corrupted.
> 
> Now I think I'll go and test how writes behave, assuming I can find a
> decently sized chunk of DPCD address space I can write. And maybe I
> should also try i2c-over-aux...

The first DPCD write after powerdown also got corrupted. But i2c-over-aux
seems unaffected for whatever reason.

>  
> > 
> > > -
> > > - for (i = 0; i < 3; i++) {
> > > - ret = drm_dp_dpcd_read(aux, offset, buffer, size);
> > > - if (ret == size)
> > > - return ret;
> > > - msleep(1);
> > > - }
> > > -
> > > - return ret;
> > > -}
> > > -
> > > -/*
> > >   * Fetch AUX CH registers 0x202 - 0x207 which contain
> > >   * link status information
> > >   */
> > >  bool
> > >  intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t 
> > > link_status[DP_LINK_STATUS_SIZE])
> > >  {
> > > - return intel_dp_dpcd_read_wake(_dp->aux,
> > > -DP_LANE0_1_STATUS,
> > > -link_status,
> > > -DP_LINK_STATUS_SIZE) == 
> > > DP_LINK_STATUS_SIZE;
> > > + return drm_dp_dpcd_read(_dp->aux, DP_LANE0_1_STATUS, link_status,
> > > + DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
> > >  }
> > >  
> > >  /* These are source-specific values. */
> > > @@ -3865,8 +3832,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > >   struct drm_i915_private *dev_priv = dev->dev_private;
> > >   uint8_t rev;
> > >  
> > > - if (intel_dp_dpcd_read_wake(_dp->aux, 0x000, intel_dp->dpcd,
> > > - sizeof(intel_dp->dpcd)) < 0)
> > > + if (drm_dp_dpcd_read(_dp->aux, 0x000, intel_dp->dpcd,
> > > +  sizeof(intel_dp->dpcd)) < 0)
> > >   return false; /* aux transfer failed */
> > >  
> > >   DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd), 
> > > intel_dp->dpcd);
> > > @@ -3877,9 +3844,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > >   /* Check if the panel supports PSR */
> > >   memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
> > >   if (is_edp(intel_dp)) {
> > > - intel_dp_dpcd_read_wake(_dp->aux, DP_PSR_SUPPORT,
> > > - intel_dp->psr_dpcd,
> > > - sizeof(intel_dp->psr_dpcd));
> > > + drm_dp_dpcd_read(_dp->aux, DP_PSR_SUPPORT,
> > > +  intel_dp->psr_dpcd,
> > > +  sizeof(intel_dp->psr_dpcd));
> > >   if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
> > >   dev_priv->psr.sink_support = true;
> > >   DRM_DEBUG_KMS("Detected EDP PSR 

[Intel-gfx] [PATCH 2/2] drm/i915: Get rid of intel_dp_dpcd_read_wake()

[Lyude]

Since we've fixed up drm_dp_dpcd_read() to allow for retries when things
timeout, there's no use for having this function anymore. Good riddens.

Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/intel_dp.c | 79 -
 1 file changed, 22 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index cdc2c15..fb4cbbe5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3190,47 +3190,14 @@ static void chv_dp_post_pll_disable(struct 
intel_encoder *encoder)
 }
 
 /*
- * Native read with retry for link status and receiver capability reads for
- * cases where the sink may still be asleep.
- *
- * Sinks are *supposed* to come up within 1ms from an off state, but we're also
- * supposed to retry 3 times per the spec.
- */
-static ssize_t
-intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, unsigned int offset,
-   void *buffer, size_t size)
-{
-   ssize_t ret;
-   int i;
-
-   /*
-* Sometime we just get the same incorrect byte repeated
-* over the entire buffer. Doing just one throw away read
-* initially seems to "solve" it.
-*/
-   drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer, 1);
-
-   for (i = 0; i < 3; i++) {
-   ret = drm_dp_dpcd_read(aux, offset, buffer, size);
-   if (ret == size)
-   return ret;
-   msleep(1);
-   }
-
-   return ret;
-}
-
-/*
  * Fetch AUX CH registers 0x202 - 0x207 which contain
  * link status information
  */
 bool
 intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t 
link_status[DP_LINK_STATUS_SIZE])
 {
-   return intel_dp_dpcd_read_wake(_dp->aux,
-  DP_LANE0_1_STATUS,
-  link_status,
-  DP_LINK_STATUS_SIZE) == 
DP_LINK_STATUS_SIZE;
+   return drm_dp_dpcd_read(_dp->aux, DP_LANE0_1_STATUS, link_status,
+   DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
 }
 
 /* These are source-specific values. */
@@ -3865,8 +3832,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dev->dev_private;
uint8_t rev;
 
-   if (intel_dp_dpcd_read_wake(_dp->aux, 0x000, intel_dp->dpcd,
-   sizeof(intel_dp->dpcd)) < 0)
+   if (drm_dp_dpcd_read(_dp->aux, 0x000, intel_dp->dpcd,
+sizeof(intel_dp->dpcd)) < 0)
return false; /* aux transfer failed */
 
DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd), 
intel_dp->dpcd);
@@ -3877,9 +3844,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
/* Check if the panel supports PSR */
memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
if (is_edp(intel_dp)) {
-   intel_dp_dpcd_read_wake(_dp->aux, DP_PSR_SUPPORT,
-   intel_dp->psr_dpcd,
-   sizeof(intel_dp->psr_dpcd));
+   drm_dp_dpcd_read(_dp->aux, DP_PSR_SUPPORT,
+intel_dp->psr_dpcd,
+sizeof(intel_dp->psr_dpcd));
if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
dev_priv->psr.sink_support = true;
DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
@@ -3890,9 +3857,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
uint8_t frame_sync_cap;
 
dev_priv->psr.sink_support = true;
-   intel_dp_dpcd_read_wake(_dp->aux,
-   DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
-   _sync_cap, 1);
+   drm_dp_dpcd_read(_dp->aux,
+DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
+_sync_cap, 1);
dev_priv->psr.aux_frame_sync = frame_sync_cap ? true : 
false;
/* PSR2 needs frame sync as well */
dev_priv->psr.psr2_support = 
dev_priv->psr.aux_frame_sync;
@@ -3908,15 +3875,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
/* Intermediate frequency support */
if (is_edp(intel_dp) &&
(intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] & 
DP_DPCD_DISPLAY_CONTROL_CAPABLE) &&
-   (intel_dp_dpcd_read_wake(_dp->aux, DP_EDP_DPCD_REV, , 1) 
== 1) &&
+   (drm_dp_dpcd_read(_dp->aux, DP_EDP_DPCD_REV, , 1) == 1) &&
(rev >= 0x03)) { /* eDp v1.4 or higher */
__le16 sink_rates[DP_MAX_SUPPORTED_RATES];
int i;
 
-   intel_dp_dpcd_read_wake(_dp->aux,
-   DP_SUPPORTED_LINK_RATES,
-   sink_rates,
-   

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/4] drm/i915/gtt: Reference mappable_end variable from pointer

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/4] drm/i915/gtt: Reference mappable_end 
variable from pointer
URL   : https://patchwork.freedesktop.org/series/4620/
State : failure

== Summary ==

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

Test gem_mmap_gtt:
Subgroup basic-write-gtt-no-prefault:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (hsw-brixbox)
Subgroup basic-flip-vs-wf_vblank:
dmesg-warn -> PASS   (hsw-brixbox)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup basic-plain-flip:
dmesg-warn -> PASS   (hsw-brixbox)
Test pm_rpm:
Subgroup basic-pci-d3-state:
dmesg-fail -> FAIL   (snb-x220t)
dmesg-warn -> PASS   (snb-dellxps)
Subgroup basic-rte:
dmesg-warn -> PASS   (bsw-nuc-2)
pass   -> DMESG-WARN (snb-dellxps)

bdw-nuci7total:194  pass:181  dwarn:1   dfail:0   fail:0   skip:12 
bdw-ultratotal:194  pass:171  dwarn:2   dfail:0   fail:0   skip:21 
bsw-nuc-2total:194  pass:156  dwarn:1   dfail:0   fail:0   skip:37 
hsw-brixbox  total:194  pass:170  dwarn:2   dfail:0   fail:0   skip:22 
hsw-gt2  total:194  pass:176  dwarn:1   dfail:0   fail:0   skip:17 
ivb-t430stotal:194  pass:168  dwarn:1   dfail:0   fail:0   skip:25 
skl-i5k-2total:194  pass:170  dwarn:1   dfail:0   fail:0   skip:23 
skl-i7k-2total:194  pass:170  dwarn:1   dfail:0   fail:0   skip:23 
skl-nuci5total:194  pass:182  dwarn:1   dfail:0   fail:0   skip:11 
snb-dellxps  total:194  pass:158  dwarn:2   dfail:0   fail:0   skip:34 
snb-x220ttotal:194  pass:158  dwarn:2   dfail:0   fail:1   skip:33 

Results at /archive/results/CI_IGT_test/Patchwork_1641/

851d270da650c16883e87bdaad7ca8b37ccbdea3 drm-intel-nightly: 
2016y-03m-18d-11h-13m-55s UTC integration manifest
c40d12b65ef06d0af913c73d77260bcf2d10a9c7 drm/i915: Codify our assumption that 
the Global GTT is <= 4GiB
eee60d55ce416f67c8000b69dea7bb098753593b drm/i915/gtt: Clean up GGTT probing 
code
33074c8e629ff0374da6cbb656433bd82a708c20 drm/i915: Rename dev_priv->gtt to 
dev_priv->ggtt
645ac6515415f359a5d43741a4eb87d8c048554e drm/i915/gtt: Reference mappable_end 
variable from pointer

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

Re: [Intel-gfx] [PATCH v2 (rebased) 2/4] drm/i915: Perform dpll commit first, v2.

[Ander Conselvan De Oliveira]

On Mon, 2016-03-14 at 09:27 +0100, Maarten Lankhorst wrote:
> Warn for the wrong mask in enable only. Disable will have the wrong mask now
> because the new state is committed before disabling the old state.
> 
> Changes since v1:
> - Use crtc_mask (Durgadoss)
> - Rebase.

Reviewed-by: Ander Conselvan de Oliveira 

> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_display.c  | 5 ++---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 +-
>  2 files changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index f8f02ec201b7..17d07a729cc0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13536,7 +13536,8 @@ static int intel_atomic_commit(struct drm_device *dev,
>   }
>  
>   drm_atomic_helper_swap_state(dev, state);
> - dev_priv->wm.config = to_intel_atomic_state(state)->wm_config;
> + dev_priv->wm.config = intel_state->wm_config;
> + intel_shared_dpll_commit(state);
>  
>   if (intel_state->modeset) {
>   memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
> @@ -13588,8 +13589,6 @@ static int intel_atomic_commit(struct drm_device *dev,
>   intel_modeset_update_crtc_state(state);
>  
>   if (intel_state->modeset) {
> - intel_shared_dpll_commit(state);
> -
>   drm_atomic_helper_update_legacy_modeset_state(state->dev,
> state);
>  
>   if (dev_priv->display.modeset_commit_cdclk &&
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index e5f67efec32d..213862e8cd04 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -156,7 +156,7 @@ void intel_disable_shared_dpll(struct intel_crtc *crtc)
>   if (pll == NULL)
>   return;
>  
> - if (WARN_ON(!(pll->config.crtc_mask & crtc_mask)))
> + if (WARN_ON(!(pll->active_mask & crtc_mask)))
>   return;
>  
>   DRM_DEBUG_KMS("disable %s (active %x, on? %d) for crtc %d\n",
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/3] drm/i915/gtt: Reference mappable_end variable from pointer

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915/gtt: Reference mappable_end 
variable from pointer
URL   : https://patchwork.freedesktop.org/series/4618/
State : warning

== Summary ==

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

Test gem_sync:
Subgroup basic-bsd:
dmesg-fail -> PASS   (ilk-hp8440p)
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-wf_vblank:
dmesg-warn -> PASS   (hsw-brixbox)
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (skl-nuci5)
pass   -> DMESG-WARN (hsw-brixbox)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b:
pass   -> DMESG-WARN (hsw-brixbox)
Subgroup suspend-read-crc-pipe-a:
skip   -> PASS   (hsw-gt2)
Subgroup suspend-read-crc-pipe-c:
skip   -> PASS   (hsw-gt2)

bdw-nuci7total:194  pass:181  dwarn:1   dfail:0   fail:0   skip:12 
bdw-ultratotal:194  pass:172  dwarn:1   dfail:0   fail:0   skip:21 
bsw-nuc-2total:194  pass:156  dwarn:1   dfail:0   fail:0   skip:37 
hsw-brixbox  total:194  pass:169  dwarn:3   dfail:0   fail:0   skip:22 
hsw-gt2  total:194  pass:176  dwarn:1   dfail:0   fail:0   skip:17 
ilk-hp8440p  total:194  pass:129  dwarn:2   dfail:0   fail:0   skip:63 
ivb-t430stotal:194  pass:168  dwarn:1   dfail:0   fail:0   skip:25 
skl-i5k-2total:194  pass:170  dwarn:1   dfail:0   fail:0   skip:23 
skl-i7k-2total:194  pass:170  dwarn:1   dfail:0   fail:0   skip:23 
skl-nuci5total:194  pass:181  dwarn:2   dfail:0   fail:0   skip:11 
snb-dellxps  total:194  pass:158  dwarn:2   dfail:0   fail:0   skip:34 

Results at /archive/results/CI_IGT_test/Patchwork_1640/

5eae5b23e137dee059f6a9a104ce59a0552ddaa8 drm-intel-nightly: 
2016y-03m-18d-10h-29m-49s UTC integration manifest
c27fbdad28f945be9aede4a72fac18993981fa5c drm/i915/gtt: Clean up GGTT probing 
code
d347579298226bbde0ce88b8799891ed1fe52cbd drm/i915: Rename dev_priv->gtt to 
dev_priv->ggtt
7f63b76cdc4c681e2a8f3e616d68cdf597d6 drm/i915/gtt: Reference mappable_end 
variable from pointer

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

[Intel-gfx] [PATCH v3 12/19] drm/i915: Move unload time GTT, MSI IRQ cleanup later

[Imre Deak]

Move the GTT,MSI IRQ cleanup later so that it matches their
corresponding init order. Also fix the order of these calls wrt. each
other to match their corresponding init order.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_dma.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b50d111..7ab8ac5 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1221,9 +1221,6 @@ int i915_driver_unload(struct drm_device *dev)
 
i915_teardown_sysfs(dev);
 
-   io_mapping_free(dev_priv->gtt.mappable);
-   arch_phys_wc_del(dev_priv->gtt.mtrr);
-
acpi_video_unregister();
i915_gem_shrinker_cleanup(dev_priv);
 
@@ -1254,9 +1251,6 @@ int i915_driver_unload(struct drm_device *dev)
cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
i915_destroy_error_state(dev);
 
-   if (dev->pdev->msi_enabled)
-   pci_disable_msi(dev->pdev);
-
intel_opregion_fini(dev);
 
/* Flush any outstanding unpin_work. */
@@ -1271,8 +1265,11 @@ int i915_driver_unload(struct drm_device *dev)
 
intel_power_domains_fini(dev_priv);
 
+   if (dev->pdev->msi_enabled)
+   pci_disable_msi(dev->pdev);
pm_qos_remove_request(_priv->pm_qos);
-
+   arch_phys_wc_del(dev_priv->gtt.mtrr);
+   io_mapping_free(dev_priv->gtt.mappable);
i915_global_gtt_cleanup(dev);
 
intel_uncore_fini(dev);
-- 
2.5.0

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

[Intel-gfx] [PATCH v4 19/19] drm/i915: Add fault injection support

[Imre Deak]

Add support for forcing an error at selected places in the driver. As an
example add 4 options to fail during driver loading.

Requested by Chris.

v2:
- Add fault point for modeset initialization
- Print debug message when injecting an error
v3:
- Rename inject_fault to inject_load_failure, rename the related macros
  and helper accordingly (Chris)
- Use a counter instead of a mask to identify the failure point (Daniel)
- Mark the module option as _unsafe and keep i915_params ordered (Joonas)
v4:
- Rebase on latest -nightly

CC: Chris Wilson 
CC: Daniel Vetter 
CC: Joonas Lahtinen 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_dma.c| 27 +++
 drivers/gpu/drm/i915/i915_drv.h|  4 
 drivers/gpu/drm/i915/i915_params.c |  4 
 drivers/gpu/drm/i915/i915_params.h |  1 +
 4 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index cbbcada..8b9ac44 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -50,6 +50,21 @@
 #include 
 #include 
 
+static unsigned int i915_load_fail_count;
+
+bool __i915_inject_load_failure(const char *func, int line)
+{
+   if (i915_load_fail_count >= i915.inject_load_failure)
+   return false;
+
+   if (++i915_load_fail_count == i915.inject_load_failure) {
+   DRM_DEBUG_DRIVER("Injecting failure at checkpoint %u [%s:%d]\n",
+i915.inject_load_failure, func, line);
+   return true;
+   }
+
+   return false;
+}
 
 static int i915_getparam(struct drm_device *dev, void *data,
 struct drm_file *file_priv)
@@ -370,6 +385,9 @@ static int i915_load_modeset_init(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
int ret;
 
+   if (i915_inject_load_failure())
+   return -ENODEV;
+
ret = intel_bios_init(dev_priv);
if (ret)
DRM_INFO("failed to find VBIOS tables\n");
@@ -951,6 +969,9 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
struct intel_device_info *device_info;
int ret = 0;
 
+   if (i915_inject_load_failure())
+   return -ENODEV;
+
dev_priv->dev = dev;
 
/* Setup the write-once "constant" device info */
@@ -1065,6 +1086,9 @@ static int i915_driver_init_mmio(struct drm_i915_private 
*dev_priv)
struct drm_device *dev = dev_priv->dev;
int ret;
 
+   if (i915_inject_load_failure())
+   return -ENODEV;
+
if (i915_get_bridge_dev(dev))
return -EIO;
 
@@ -1108,6 +1132,9 @@ static int i915_driver_init_hw(struct drm_i915_private 
*dev_priv)
uint32_t aperture_size;
int ret;
 
+   if (i915_inject_load_failure())
+   return -ENODEV;
+
intel_device_info_runtime_init(dev);
 
ret = i915_gem_gtt_init(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 180cae0..a518525 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -98,6 +98,10 @@
 #define I915_STATE_WARN_ON(x)  \
I915_STATE_WARN((x), "%s", "WARN_ON(" __stringify(x) ")")
 
+bool __i915_inject_load_failure(const char *func, int line);
+#define i915_inject_load_failure() \
+   __i915_inject_load_failure(__func__, __LINE__)
+
 static inline const char *yesno(bool v)
 {
return v ? "yes" : "no";
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 97691f1..1779f02 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_submission = false,
.guc_log_level = -1,
.enable_dp_mst = true,
+   .inject_load_failure = 0,
 };
 
 module_param_named(modeset, i915.modeset, int, 0400);
@@ -206,3 +207,6 @@ MODULE_PARM_DESC(guc_log_level,
 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)");
+module_param_named_unsafe(inject_load_failure, i915.inject_load_failure, uint, 
0400);
+MODULE_PARM_DESC(inject_load_failure,
+   "Force an error after a number of failure check points (0:disabled 
(default), N:force failure at the Nth failure check point)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 87153b0..02bc278 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -49,6 +49,7 @@ struct i915_params {
int use_mmio_flip;
int mmio_debug;
int edp_vswing;
+   unsigned int inject_load_failure;
/* leave bools 

[Intel-gfx] [PATCH] drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit

[Dongwon Kim]

For BXT, description of polarities of PORT_PLL_REF_SEL
has been reversed for newer Gen9LP steppings according to the
recent update in Bspec. This bit now should be set for
"Non-SSC" mode for all Gen9LP starting from B0 stepping.

v2: Only B0 and newer stepping should be affected by this
change.

Signed-off-by: Dongwon Kim 
---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 4b636c4..c84589e 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -1285,7 +1285,15 @@ static void bxt_ddi_pll_enable(struct drm_i915_private 
*dev_priv,
enum port port = (enum port)pll->id;/* 1:1 port->PLL mapping */
 
temp = I915_READ(BXT_PORT_PLL_ENABLE(port));
-   temp &= ~PORT_PLL_REF_SEL;
+   /*
+* Definition of each bit polarity has been changed
+* after A1 stepping
+*/
+   if (IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1))
+   temp &= ~PORT_PLL_REF_SEL;
+   else
+   temp |= PORT_PLL_REF_SEL;
+
/* Non-SSC reference */
I915_WRITE(BXT_PORT_PLL_ENABLE(port), temp);
 
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Restrict usage of live status check

[Sharma, Shashank]

Hey Chris,
I added comments for both Ville and you, please help me to understand this.

Regards
Shashank

On 3/17/2016 9:51 PM, Ville Syrjälä wrote:

On Thu, Mar 17, 2016 at 09:35:30PM +0530, Sharma, Shashank wrote:

Regards
Shashank

On 3/17/2016 9:31 PM, Ville Syrjälä wrote:

On Thu, Mar 17, 2016 at 09:15:39PM +0530, Sharma, Shashank wrote:

Regards
Shashank

On 3/17/2016 6:34 PM, Ville Syrjälä wrote:

On Thu, Mar 17, 2016 at 01:29:25PM +0530, Shashank Sharma wrote:

This patch restricts usage of live status check for HDMI detection.
While testing certain (monitor + cable) combinations with various
intel  platforms, it seems that live status register is not reliable
on some older devices. So limit the live_status check from VLV onwards.

This fixes a regression introduced in:
commit: 237ed86 "drm/i915: Check live status"
Author: Sonika Jindal 
Date:   Tue Sep 15 09:44:20 2015 +0530

Signed-off-by: Shashank Sharma 
---
drivers/gpu/drm/i915/intel_hdmi.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index e2dab48..d24d18a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1397,7 +1397,8 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
enum drm_connector_status status;
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
struct drm_i915_private *dev_priv = to_i915(connector->dev);
-   bool live_status = false;
+   struct drm_device *dev = connector->dev;
+   bool live_status = true;
unsigned int try;

DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
@@ -1405,16 +1406,21 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)

intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);

-   for (try = 0; !live_status && try < 9; try++) {
-   if (try)
-   msleep(10);
-   live_status = intel_digital_port_connected(dev_priv,
+   /*
+   * Live status check for HDMI detection is not very
+   * reliable on older platforms. So insist the live
+   * status check for EDID read from VLV onwards.
+   */
+   if (INTEL_INFO(dev)->gen >= 7 && !IS_IVYBRIDGE(dev)) {
+   for (try = 0; !live_status && try < 9; try++) {
+   if (try)
+   msleep(10);
+   live_status = intel_digital_port_connected(dev_priv,
hdmi_to_dig_port(intel_hdmi));
+   }
+   DRM_DEBUG_KMS("Live status %s\n", live_status ? "up" : "down");
}

-   if (!live_status)
-   DRM_DEBUG_KMS("Live status not up!");
-


As I said before, I think this whole thing could be solved with a simple
two-liner here:

+   if (...)
+   live_status = true;


Yes I remember, and I replied on that already that why we would like to
keep the live status check. In fact I would be ok to remove this check
if you can suggest some other way of making this work for other
operating systems/sw platforms.


My two liner would keep the check.


Sorry, I might have not understood you properly.
Do you mean:
if (INTEL_INFO(dev)->gen < 7 && IS_IVYBRIDGE(dev)) {
live_status = true;
} else {
do the same looping for retry;
}


No, I mean

{
...
do loop;

if (!live_status)
DRM_DEBUG_KMS("Live status not up!");

+   if (don't trust live status)
+   live_status = true;

intel_hdmi_unset_edid();

if (intel_hdmi_set_edid(live_status)) {
...
}



In fact, this is what I have done.
If you see the change in this patch,
/* Lets make live status true for < VLV platforms */
bool live_status = true;

blah
blah

/* Check live status only for newer platforms */
if (this is VLV or later platforms) {
live_status = read_real_live_status();
}
intel_hdmi_unset_edid();
intel_hdmi_set_edid(live_status);

Now, my question is, do you want to remove live_status check for VLV and 
other platforms too ? or this is good enough ?





intel_hdmi_unset_edid(connector);

if (intel_hdmi_set_edid(connector, live_status)) {
--
1.9.1







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

[Intel-gfx] [PATCH 03/10] drm/i915: Use insert_page for pwrite_fast

[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)

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

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 31652c1..caaadabb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -61,6 +61,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(>gtt.base.mm, node,
+  size, 0, 0, 0,
+  i915->gtt.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)
@@ -760,20 +778,33 @@ fast_user_write(struct io_mapping *mapping,
  * user into the GTT, uncached.
  */
 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 = dev->dev_private;
-   ssize_t remain;
-   loff_t offset, page_base;
+   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)
@@ -783,31 +814,39 @@ i915_gem_gtt_pwrite_fast(struct drm_device *dev,
if (ret)
goto out_unpin;
 
-   user_data = 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 = 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 page_base = node.start;
+   unsigned page_offset = offset_in_page(offset);
+   

[Intel-gfx] [PATCH] drm/i915: add another virtual PCH bridge for passthrough support

[Jesse Barnes]

Some configs use the P2X type but some use a P3X type PCH, so add that
to the detect_pch function so things work correctly.

Signed-off-by: Jesse Barnes 
---
 drivers/gpu/drm/i915/i915_drv.c | 1 +
 drivers/gpu/drm/i915/i915_drv.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 20e8200..6ad4390 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -504,6 +504,7 @@ void intel_detect_pch(struct drm_device *dev)
WARN_ON(!IS_SKYLAKE(dev) &&
!IS_KABYLAKE(dev));
} else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
+  (id == INTEL_PCH_P3X_DEVICE_ID_TYPE) ||
   ((id == INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
pch->subsystem_vendor == 0x1af4 &&
pch->subsystem_device == 0x1100)) {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9e76bfc..e53cd42 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2695,6 +2695,7 @@ struct drm_i915_cmd_table {
 #define INTEL_PCH_SPT_DEVICE_ID_TYPE   0xA100
 #define INTEL_PCH_SPT_LP_DEVICE_ID_TYPE0x9D00
 #define INTEL_PCH_P2X_DEVICE_ID_TYPE   0x7100
+#define INTEL_PCH_P3X_DEVICE_ID_TYPE   0x7000
 #define INTEL_PCH_QEMU_DEVICE_ID_TYPE  0x2900 /* qemu q35 has 2918 */
 
 #define INTEL_PCH_TYPE(dev) (__I915__(dev)->pch_type)
-- 
1.9.1

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

Re: [Intel-gfx] [RFC] drm/i915: Smarten up and use to_i915() everywhere

[Tvrtko Ursulin]

On 18/03/16 00:36, Arun Siluvery wrote:

On 17/03/2016 16:00, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

There is a lot of ways to get to our dev_priv depending on which
object is at hand and often what was chosen by the developer.

We can make to_i915() accept different pointers by using compile
time magic. Like:

   dev_priv = to_i915(request);
   dev_priv = to_i915(engine);
   dev_priv = to_i915(ctx);
   dev_priv = to_i915(dev);
   dev_priv = to_i915(guc);
   dev_priv = to_i915(device);

If an unknown pointer is passed to the function it will cause
a compile time failure.

Main advantage is that with this in place we could add and
remove shourtcuts to dev_priv from supported structures easily
and without touching the code which uses it. If we wanted to
fiddle with the balance of structure sizes and number of pointer
dereferencing for example. And it makes the code a bit tidier
and uniform.


I get the readability aspect but is it advisable to hide too many things
under macros? In the new code is it expected to always use these macros?
if yes then in that case aren't we forcing certain usage? good or bad.
This has even wider impact than ring/engine renaming. If we must go this
route then we should at least do it in stages to minimize impact.


No worries it was just an RFC, like an OCD code tidy thing, and I 
definitely agree it is not useful enough in the general scheme of things 
to justify another big disruption.


However, going back to Jani's comment, I am not sure that multiple 
T_to_i915(p) are better than a little bit of fake dynamic typing for 
this special case.


Doing it in stages is a good idea, maybe roughly by a set of related 
files at convenient times. TBD. :)


Regards,

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs (rev3)

[Imre Deak]

On Wed, 2016-03-16 at 14:37 +0200, Tomi Sarvela wrote:
> On Wednesday 16 March 2016 10:48:43 Imre Deak wrote:
> > Tomi, noticed two things that maybe infrastructure related, see
> > below:
> > 
> > > Test drv_module_reload_basic:
> > > skip   -> PASS   (bdw-nuci7)
> > > Test gem_ringfill:
> > > Subgroup basic-default-s3:
> > > pass   -> DMESG-WARN (skl-nuci5)
> > > Test gem_storedw_loop:
> > > Subgroup basic-bsd:
> > > pass   -> DMESG-WARN (skl-nuci5)
> > > Subgroup basic-bsd1:
> > > pass   -> DMESG-WARN (skl-nuci5)
> > 
> > Unrelated platform. All of the above are SND resume failures. Ville
> > said he contacted Takashi about them.
> 
> SND is recurring problem. I'd like to see drm-intel-nightly not
> breaking when 
> pulling sound updates.
> 
> > > Test kms_flip:
> > > Subgroup basic-flip-vs-wf_vblank:
> > > dmesg-warn -> PASS   (hsw-brixbox)
> > > pass   -> DMESG-WARN (bdw-ultra)
> > 
> > Unrelated platform.
> > Tomi, there are ACPI erros in the log, maybe needs a BIOS upgrade?
> > It's
> > also affected by
> > https://bugs.freedesktop.org/show_bug.cgi?id=94349
> 
> Brixbox is at the newest BIOS available. Did you mean Intel Ultrabook
> 2in1?

No not that one but the above bdw-ultra. See the ACPI errors in
archive/results/CI_IGT_test/Patchwork_1607/bdw-ultra/html/bdw-ultra@Patchwork_1607@1/igt@kms_flip@basic-flip-vs-wf_vblank.html

--Imre

> 
> > > Test kms_pipe_crc_basic:
> > > Subgroup read-crc-pipe-c:
> > > fail   -> PASS   (hsw-brixbox)
> > > Subgroup suspend-read-crc-pipe-b:
> > > dmesg-warn -> PASS   (skl-nuci5)
> > > Subgroup suspend-read-crc-pipe-c:
> > > pass   -> INCOMPLETE (skl-nuci5)
> > 
> > Unrelated platform, I opened a new bug:
> > https://bugs.freedesktop.org/show_bug.cgi?id=94566
> 
> Suspend-read-crc-pipes are notoriously unstable, and main reason (in
> addition 
> to drv_module_reload_basic) to hangs.
> 
> > Tomi, basic-rte has also DMESG-WARN on snb-dellxps, yet not on this
> > list.
> 
> SNB-dellxps is in a bad state, there's alsa blocking shutdown and
> startup 
> within set timelimits. It'll be probably out until snd is fixed.
> 
> Tomi
___
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: Get rid of intel_dp_dpcd_read_wake()

[Daniel Vetter]

On Fri, Mar 18, 2016 at 06:41:40PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 18, 2016 at 06:12:35PM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 18, 2016 at 04:13:45PM +0200, Ville Syrjälä wrote:
> > > On Thu, Mar 17, 2016 at 11:40:45AM -0400, Lyude wrote:
> > > > Since we've fixed up drm_dp_dpcd_read() to allow for retries when things
> > > > timeout, there's no use for having this function anymore. Good riddens.
> > > > 
> > > > Signed-off-by: Lyude 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp.c | 79 
> > > > -
> > > >  1 file changed, 22 insertions(+), 57 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index cdc2c15..fb4cbbe5 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -3190,47 +3190,14 @@ static void chv_dp_post_pll_disable(struct 
> > > > intel_encoder *encoder)
> > > >  }
> > > >  
> > > >  /*
> > > > - * Native read with retry for link status and receiver capability 
> > > > reads for
> > > > - * cases where the sink may still be asleep.
> > > > - *
> > > > - * Sinks are *supposed* to come up within 1ms from an off state, but 
> > > > we're also
> > > > - * supposed to retry 3 times per the spec.
> > > > - */
> > > > -static ssize_t
> > > > -intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, unsigned int offset,
> > > > -   void *buffer, size_t size)
> > > > -{
> > > > -   ssize_t ret;
> > > > -   int i;
> > > > -
> > > > -   /*
> > > > -* Sometime we just get the same incorrect byte repeated
> > > > -* over the entire buffer. Doing just one throw away read
> > > > -* initially seems to "solve" it.
> > > > -*/
> > > > -   drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer, 1);
> > > 
> > > NAK
> > > 
> > > If people keep intentionally breaking my shit I'm going to become
> > > really grumpy soon.
> > 
> > Oh, and just in case someone wants to come up with a better kludge,
> > I just spent a few minutes analyzing the behavior of this crappy
> > monitor a.
> > 
> > What happens is that when the monitor is fully powered up (LED is blue)
> > things are fine. After the monitor goes to sleep (LED turns orange)
> > the first DPCD read will produce garbage. Further DPCD reads are fine,
> > even if I wait a significant amount of time between the reads, as long
> > as the monitor didn't do a power on->off cycle in between. So it looks
> > like it's always just the first read after power down that gets
> > corrupted.
> > 
> > Now I think I'll go and test how writes behave, assuming I can find a
> > decently sized chunk of DPCD address space I can write. And maybe I
> > should also try i2c-over-aux...
> 
> The first DPCD write after powerdown also got corrupted. But i2c-over-aux
> seems unaffected for whatever reason.

Do you have an amd card nearby to test there? Would be interesting to
confirm that this is indeed a sink bug, and hence that it really all
should be in the shared code.
-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

[Intel-gfx] [PATCH v3] prime_mmap_coherency: Add return error tests for prime sync ioctl

[Tiago Vignatti]

This patch adds ioctl-errors subtest to be used for exercising prime sync ioctl
errors.

The subtest constantly interrupts via signals a function doing concurrent blit
to stress out the right usage of prime_sync_*, making sure these ioctl errors
are handled accordingly. Important to note that in case of failure (e.g. in a
case where the ioctl wouldn't try again in a return error) this test does not
reliably catch the problem with 100% of accuracy.

v2: fix prime sync direction when reading mmap'ed file.
v3: change the upper bound using time rather than loops
 
Cc: Chris Wilson 
Signed-off-by: Tiago Vignatti 
---
 tests/prime_mmap_coherency.c | 89 
 1 file changed, 89 insertions(+)

diff --git a/tests/prime_mmap_coherency.c b/tests/prime_mmap_coherency.c
index 180d8a4..d2b2a4f 100644
--- a/tests/prime_mmap_coherency.c
+++ b/tests/prime_mmap_coherency.c
@@ -180,6 +180,90 @@ static void test_write_flush(bool expect_stale_cache)
munmap(ptr_cpu, width * height);
 }
 
+static void blit_and_cmp(void)
+{
+   drm_intel_bo *bo_1;
+   drm_intel_bo *bo_2;
+   uint32_t *ptr_cpu;
+   uint32_t *ptr2_cpu;
+   int dma_buf_fd, dma_buf2_fd, i;
+   int local_fd;
+   drm_intel_bufmgr *local_bufmgr;
+   struct intel_batchbuffer *local_batch;
+
+   /* recreate process local variables */
+   local_fd = drm_open_driver(DRIVER_INTEL);
+   local_bufmgr = drm_intel_bufmgr_gem_init(local_fd, 4096);
+   igt_assert(local_bufmgr);
+
+   local_batch = intel_batchbuffer_alloc(local_bufmgr, 
intel_get_drm_devid(local_fd));
+   igt_assert(local_batch);
+
+   bo_1 = drm_intel_bo_alloc(local_bufmgr, "BO 1", width * height * 4, 
4096);
+   dma_buf_fd = prime_handle_to_fd_for_mmap(local_fd, bo_1->handle);
+   igt_skip_on(errno == EINVAL);
+
+   ptr_cpu = mmap(NULL, width * height, PROT_READ | PROT_WRITE,
+   MAP_SHARED, dma_buf_fd, 0);
+   igt_assert(ptr_cpu != MAP_FAILED);
+
+   bo_2 = drm_intel_bo_alloc(local_bufmgr, "BO 2", width * height * 4, 
4096);
+   dma_buf2_fd = prime_handle_to_fd_for_mmap(local_fd, bo_2->handle);
+
+   ptr2_cpu = mmap(NULL, width * height, PROT_READ | PROT_WRITE,
+   MAP_SHARED, dma_buf2_fd, 0);
+   igt_assert(ptr2_cpu != MAP_FAILED);
+
+   /* Fill up BO 1 with '1's and BO 2 with '0's */
+   prime_sync_start(dma_buf_fd, true);
+   memset(ptr_cpu, 0x11, width * height);
+   prime_sync_end(dma_buf_fd, true);
+
+   prime_sync_start(dma_buf2_fd, true);
+   memset(ptr2_cpu, 0x00, width * height);
+   prime_sync_end(dma_buf2_fd, true);
+
+   /* Copy BO 1 into BO 2, using blitter. */
+   intel_copy_bo(local_batch, bo_2, bo_1, width * height);
+   usleep(0); /* let someone else claim the mutex */
+
+   /* Compare BOs. If prime_sync_* were executed properly, the caches
+* should be synced. */
+   prime_sync_start(dma_buf2_fd, false);
+   for (i = 0; i < (width * height) / 4; i++)
+   igt_fail_on_f(ptr2_cpu[i] != 0x, "Found 0x%08x at 
offset 0x%08x\n", ptr2_cpu[i], i);
+   prime_sync_end(dma_buf2_fd, false);
+
+   drm_intel_bo_unreference(bo_1);
+   drm_intel_bo_unreference(bo_2);
+   munmap(ptr_cpu, width * height);
+   munmap(ptr2_cpu, width * height);
+}
+
+/*
+ * Constantly interrupt concurrent blits to stress out prime_sync_* and make
+ * sure these ioctl errors are handled accordingly.
+ *
+ * Important to note that in case of failure (e.g. in a case where the ioctl
+ * wouldn't try again in a return error) this test does not reliably catch the
+ * problem with 100% of accuracy.
+ */
+static void test_ioctl_errors(void)
+{
+   int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
+
+   igt_fork_signal_helper();
+   for (int num_children = 1; num_children <= 8 *ncpus; num_children <<= 
1) {
+   igt_fork(child, num_children) {
+   struct timespec start = {};
+   while (igt_nsec_elapsed() <= num_children)
+   blit_and_cmp();
+   }
+   igt_waitchildren();
+   }
+   igt_stop_signal_helper();
+}
+
 int main(int argc, char **argv)
 {
int i;
@@ -235,6 +319,11 @@ int main(int argc, char **argv)
igt_fail_on_f(!stale, "couldn't find any stale cache lines\n");
}
 
+   igt_subtest("ioctl-errors") {
+   igt_info("exercising concurrent blit to get ioctl errors\n");
+   test_ioctl_errors();
+   }
+
igt_fixture {
intel_batchbuffer_free(batch);
drm_intel_bufmgr_destroy(bufmgr);
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH 11/16] drm/i915: Compute DSI PLL parameters during .compute_config()

[Ville Syrjälä]

On Wed, Mar 16, 2016 at 10:56:33AM +0200, Jani Nikula wrote:
> On Tue, 15 Mar 2016, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > Compute the DSI PLL parameters during .compute_config() rather than
> > .pre_pll_enable() so that we can fail gracefully if we can't find
> > suitable parameters.
> >
> > In order to do that we need to store the DSI PLL parameters in
> > pipe_config.
> >
> > v2: Handle BXT too
> >
> > Signed-off-by: Ville Syrjälä 
> 
> [snip]
> 
> > @@ -317,15 +328,9 @@ static u32 bxt_dsi_get_pclk(struct intel_encoder 
> > *encoder, int pipe_bpp)
> > return 0;
> > }
> >  
> > -   dsi_ratio = I915_READ(BXT_DSI_PLL_CTL) &
> > -   BXT_DSI_PLL_RATIO_MASK;
> > +   config->dsi_pll.ctrl = I915_READ(BXT_DSI_PLL_CTL);
> >  
> > -   /* Invalid DSI ratio ? */
> > -   if (dsi_ratio < BXT_DSI_PLL_RATIO_MIN ||
> > -   dsi_ratio > BXT_DSI_PLL_RATIO_MAX) {
> > -   DRM_ERROR("Invalid DSI pll ratio(%u) programmed\n", dsi_ratio);
> > -   return 0;
> > -   }
> 
> So you expect this to show up in the state checker instead now?

Frankly I'm not expecting it to show up at all. If the BIOS does program
an invalid value, well, then we should sanitize it somewhere without
spewing errors. If we misprogram it, then the state checker could catch
it (unless we have a bug in the compute phase already and somehow
compute the correct clock w/ an incorrect ratio).

> 
> Reviewed-by: Jani Nikula 
> 
> 
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
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 1/2] drm: Add aux plane verification in addFB2

[Ville Syrjälä]

On Fri, Mar 18, 2016 at 10:20:52PM +0530, Vandana Kannan wrote:
> From: Daniel Vetter 
> 
> For render compression, userspace passes aux stride and offset values as an
> additional entry in the fb structure. This should not be treated as garbage
> and discarded as data belonging to no plane.
> This patch introduces a check related to AUX plane to support the
> scenario of render compression.
> 
> v2: Based on a discussion with Siva
> Move num_planes check below the increment.
> 
> Signed-off-by: Daniel Vetter 
> Signed-off-by: Vandana Kannan 
> Cc: Sivakumar Thulasimani 
> ---
>  drivers/gpu/drm/drm_crtc.c  | 19 ++-
>  drivers/gpu/drm/drm_ioctl.c |  3 +++
>  include/drm/drm_crtc.h  |  3 +++
>  include/uapi/drm/drm.h  |  1 +
>  include/uapi/drm/drm_mode.h |  1 +
>  5 files changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index a4e90c7..8659748 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3287,6 +3287,16 @@ static int framebuffer_check(const struct 
> drm_mode_fb_cmd2 *r)
>   }
>   }
>  
> + if (r->flags & DRM_MODE_FB_AUX_PLANE) {
> + num_planes++;
> +
> + if (num_planes == 4) {
> + DRM_DEBUG_KMS("Number of planes cannot exceed 3"
> + "(including aux plane)\n");
> + return -EINVAL;
> + }
> + }

That's not going to work. For one drm_format_plane_cpp() doesn't know
anything about your AUX plane. None of this code can really understand
anything about the AUX plane since that's hw specific pretty much by
definition.

> +
>   for (i = num_planes; i < 4; i++) {
>   if (r->modifier[i]) {
>   DRM_DEBUG_KMS("non-zero modifier for unused plane 
> %d\n", i);
> @@ -3325,7 +3335,8 @@ internal_framebuffer_create(struct drm_device *dev,
>   struct drm_framebuffer *fb;
>   int ret;
>  
> - if (r->flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS)) {
> + if (r->flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS |
> + DRM_MODE_FB_AUX_PLANE)) {
>   DRM_DEBUG_KMS("bad framebuffer flags 0x%08x\n", r->flags);
>   return ERR_PTR(-EINVAL);
>   }
> @@ -3347,6 +3358,12 @@ internal_framebuffer_create(struct drm_device *dev,
>   return ERR_PTR(-EINVAL);
>   }
>  
> + if (r->flags & DRM_MODE_FB_AUX_PLANE &&
> + !dev->mode_config.allow_aux_plane) {
> + DRM_DEBUG_KMS("driver does not support render compression\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
>   ret = framebuffer_check(r);
>   if (ret)
>   return ERR_PTR(ret);
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 8ce2a0c..ee00782 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -312,6 +312,9 @@ static int drm_getcap(struct drm_device *dev, void *data, 
> struct drm_file *file_
>   case DRM_CAP_ADDFB2_MODIFIERS:
>   req->value = dev->mode_config.allow_fb_modifiers;
>   break;
> + case DRM_CAP_RENDER_COMPRESSION:
> + req->value = dev->mode_config.allow_aux_plane;
> + break;
>   default:
>   return -EINVAL;
>   }
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 7fad193..00b1f59 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -2141,6 +2141,9 @@ struct drm_mode_config {
>   /* whether the driver supports fb modifiers */
>   bool allow_fb_modifiers;
>  
> + /* whether the driver supports render compression */
> + bool allow_aux_plane;
> +
>   /* cursor size */
>   uint32_t cursor_width, cursor_height;
>  };
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index a0ebfe7..01561834 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -632,6 +632,7 @@ struct drm_gem_open {
>  #define DRM_CAP_CURSOR_WIDTH 0x8
>  #define DRM_CAP_CURSOR_HEIGHT0x9
>  #define DRM_CAP_ADDFB2_MODIFIERS 0x10
> +#define DRM_CAP_RENDER_COMPRESSION   0x11
>  
>  /** DRM_IOCTL_GET_CAP ioctl argument type */
>  struct drm_get_cap {
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 50adb46..f900dc95 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -354,6 +354,7 @@ struct drm_mode_fb_cmd {
>  
>  #define DRM_MODE_FB_INTERLACED   (1<<0) /* for interlaced framebuffers */
>  #define DRM_MODE_FB_MODIFIERS(1<<1) /* enables ->modifer[] */
> +#define DRM_MODE_FB_AUX_PLANE   (1<<2) /* for compressed buffer */
>  
>  struct drm_mode_fb_cmd2 {
>   __u32 fb_id;
> -- 
> 1.9.1
> 
> ___
> Intel-gfx