Re: [Intel-gfx] [PATCH 02/10] drm/i915: Drop some unused fields from i915_execbuffer_params

2017-01-31 Thread Joonas Lahtinen
On ti, 2017-01-31 at 13:15 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> dev, file and ctx are unused.
> 
> Signed-off-by: Tvrtko Ursulin 

Could either squash this to the previous commit, or have this before
previous commit, to avoid going through removed code in previous patch
(easier for rebasing etc.)

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


Re: [Intel-gfx] [PATCH 03/10] drm/i915: Tidy execbuf_submit

2017-01-31 Thread Joonas Lahtinen
On ti, 2017-01-31 at 13:15 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Use a local variable for storing the request and engine
> and at the same time drop the engine field from
> i915_execbuffer_params since it is available from the
> request.
> 
>  textdata bss dec hex filename
>   1085402   263982628 1114428  11013c i915.ko.0
>   1085354   263982628 1114380  11010c i915.ko.1
> 
> Signed-off-by: Tvrtko Ursulin 

Reviewed-by: Joonas Lahtinen 

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


Re: [Intel-gfx] [PATCH 01/10] drm/i915: Tidy i915_gem_do_execbuffer

2017-01-31 Thread Joonas Lahtinen
On ti, 2017-01-31 at 13:15 +, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin 
> 
> Instead of sprinkling around usage and initialization of
> i915_execbuffer_params we can consolidate it just before
> execbuf_submit for maintability and readability.
> 
> That way we can also drop the memset since it becomes
> easy to spot we initialize all the fields.
> 
>  textdata bss dec hex filename
>   1085466   263982628 1114492  11017c i915.ko.0
>   1085402   263982628 1114428  11013c i915.ko.1
> 
> Signed-off-by: Tvrtko Ursulin 



> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -50,14 +50,14 @@
>  #define BATCH_OFFSET_BIAS (256*1024)
>  
>  struct i915_execbuffer_params {
> - struct drm_device   *dev;
> - struct drm_file *file;
> - struct i915_vma *batch;
> - u32 dispatch_flags;
> - u32 args_batch_start_offset;
> - struct intel_engine_cs  *engine;
> - struct i915_gem_context *ctx;
> - struct drm_i915_gem_request *request;
> + struct drm_device   *dev;
> + struct drm_file *file;
> + struct i915_vma *batch;
> + u32 dispatch_flags;
> + u32 batch_start;
> + struct intel_engine_cs  *engine;
> + struct i915_gem_context *ctx;
> + struct drm_i915_gem_request *request;
>  };

You could just drop the pretty spaces totally. Otherwise, when
something gets changed, the whole struct has to be re-indented.

Reviewed-by: Joonas Lahtinen 

Regards, Joonas

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


Re: [Intel-gfx] [PATCH 1/3] drm/i915/bxt: Enable IPC support

2017-01-31 Thread Mahesh Kumar

Hi,


On Tuesday 31 January 2017 09:26 PM, Ander Conselvan De Oliveira wrote:

On Tue, 2017-01-31 at 20:27 +0530, Mahesh Kumar wrote:

This patch adds IPC support for platforms. This patch enables IPC
only for BXT/KBL platform as for SKL recommendation is to keep it disabled.
IPC (Isochronous Priority Control) is the hardware feature, which
dynamically controls the memory read priority of Display.

When IPC is enabled, plane read requests are sent at high priority until
filling above the transition watermark, then the requests are sent at
lower priority until dropping below the level 0 watermark.
The lower priority requests allow other memory clients to have better
memory access. When IPC is disabled, all plane read requests are sent at
high priority.

Changes since V1:
  - Remove commandline parameter to disable ipc
  - Address Paulo's comments
Changes since V2:
  - Address review comments
  - Set ipc_enabled flag
Changes since V3:
  - move ipc_enabled flag assignment inside intel_ipc_enable function
Changes since V4:
  - Re-enable IPC after suspend/resume

Signed-off-by: Mahesh Kumar 
---
  drivers/gpu/drm/i915/i915_drv.c  |  4 +++-
  drivers/gpu/drm/i915/i915_reg.h  |  1 +
  drivers/gpu/drm/i915/intel_display.c |  1 +
  drivers/gpu/drm/i915/intel_drv.h |  1 +
  drivers/gpu/drm/i915/intel_pm.c  | 16 
  5 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ca168b22ee26..5f3b22946971 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1246,7 +1246,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct
pci_device_id *ent)
  
  	intel_runtime_pm_enable(dev_priv);
  
-	dev_priv->ipc_enabled = false;

+   intel_enable_ipc(dev_priv);
  
  	/* Everything is in place, we can now relax! */

DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
@@ -2439,6 +2439,8 @@ static int intel_runtime_resume(struct device *kdev)
  
  	enable_rpm_wakeref_asserts(dev_priv);
  
+	intel_enable_ipc(dev_priv);

+
if (ret)
DRM_ERROR("Runtime resume failed, disabling it (%d)\n", ret);
else
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 72f9f36ae5ce..36e0a33f876c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6466,6 +6466,7 @@ enum {
  #define  DISP_FBC_WM_DIS  (1<<15)
  #define DISP_ARB_CTL2 _MMIO(0x45004)
  #define  DISP_DATA_PARTITION_5_6  (1<<6)
+#define  DISP_IPC_ENABLE   (1<<3)
  #define DBUF_CTL  _MMIO(0x45008)
  #define  DBUF_POWER_REQUEST   (1<<31)
  #define  DBUF_POWER_STATE (1<<30)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0bf8e1bfbe7e..1aa708b6f55e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -17222,6 +17222,7 @@ void intel_display_resume(struct drm_device *dev)
if (!ret)
ret = __intel_display_resume(dev, state);
  
+	intel_enable_ipc(dev_priv);

drm_modeset_drop_locks();
drm_modeset_acquire_fini();
mutex_unlock(>mode_config.mutex);
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 0cec0013ace0..ab7423b0a41b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1787,6 +1787,7 @@ bool skl_ddb_allocation_overlaps(const struct
skl_ddb_entry **entries,
  uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config);
  bool ilk_disable_lp_wm(struct drm_device *dev);
  int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
+void intel_enable_ipc(struct drm_i915_private *dev_priv);
  static inline int intel_enable_rc6(void)
  {
return i915.enable_rc6;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 249623d45be0..16e83efa1118 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4667,6 +4667,22 @@ void intel_update_watermarks(struct intel_crtc *crtc)
dev_priv->display.update_wm(crtc);
  }
  
+void intel_enable_ipc(struct drm_i915_private *dev_priv)

+{
+   u32 val;
+
+   dev_priv->ipc_enabled = false;
+   if (!(IS_BROXTON(dev_priv) || IS_KABYLAKE(dev_priv)))
+   return;

Do we want this enabled in Geminilake?

Ander
yes, we need to enable this for Gemnilake also, but we need "Transition 
WM" patch, before enabling it for GLK.


-Mahesh



+
+   val = I915_READ(DISP_ARB_CTL2);
+
+   val |= DISP_IPC_ENABLE;
+
+   I915_WRITE(DISP_ARB_CTL2, val);
+   dev_priv->ipc_enabled = true;
+}
+
  /*
   * Lock protecting IPS related data structures
   */


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH i-g-t v4 03/11] lib/igt_kms: export properties names

2017-01-31 Thread Robert Foss
From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
---
 lib/igt_kms.c |  6 +++---
 lib/igt_kms.h | 23 +++
 2 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 41acce45..142658a6 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -157,7 +157,7 @@ const unsigned char* igt_kms_get_base_edid(void)
 #define EDID_NAME alt_edid
 #include "igt_edid_template.h"
 
-static const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
+const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
"SRC_X",
"SRC_Y",
"SRC_W",
@@ -172,7 +172,7 @@ static const char 
*igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
"rotation"
 };
 
-static const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
+const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
"background_color",
"CTM",
"DEGAMMA_LUT",
@@ -181,7 +181,7 @@ static const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] 
= {
"ACTIVE"
 };
 
-static const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
+const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
"scaling mode",
"CRTC_ID"
 };
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 25626187..00e0dc68 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -97,12 +97,28 @@ enum igt_atomic_crtc_properties {
IGT_NUM_CRTC_PROPS
 };
 
+/**
+ * igt_crtc_prop_names
+ *
+ * igt_crtc_prop_names contains a list of crtc property names,
+ * as indexed by the igt_atomic_crtc_properties enum.
+ */
+extern const char *igt_crtc_prop_names[];
+
 enum igt_atomic_connector_properties {
IGT_CONNECTOR_SCALING_MODE = 0,
IGT_CONNECTOR_CRTC_ID,
IGT_NUM_CONNECTOR_PROPS
 };
 
+/**
+ * igt_connector_prop_names
+ *
+ * igt_connector_prop_names contains a list of crtc property names,
+ * as indexed by the igt_atomic_connector_properties enum.
+ */
+extern const char *igt_connector_prop_names[];
+
 struct kmstest_connector_config {
drmModeCrtc *crtc;
drmModeConnector *connector;
@@ -237,6 +253,13 @@ enum igt_atomic_plane_properties {
IGT_NUM_PLANE_PROPS
 };
 
+/**
+ * igt_plane_prop_names
+ *
+ * igt_plane_prop_names contains a list of crtc property names,
+ * as indexed by the igt_atomic_plane_properties enum.
+ */
+extern const char *igt_plane_prop_names[];
 
 typedef struct igt_display igt_display_t;
 typedef struct igt_pipe igt_pipe_t;
-- 
2.11.0.453.g787f75f05

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


[Intel-gfx] [PATCH i-g-t v4 11/11] lib/igt_kms: Added igt_pipe_get_last_out_fence()

2017-01-31 Thread Robert Foss
Added the igt_pipe_get_last_out_fence() helper function
that wraps accesses to pipe->fence_out.

Signed-off-by: Robert Foss 
---
 lib/igt_kms.c | 8 
 lib/igt_kms.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index a1eaf411..b99b0398 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1938,6 +1938,14 @@ static igt_output_t *igt_pipe_get_output(igt_pipe_t 
*pipe)
return NULL;
 }
 
+int igt_pipe_get_last_out_fence(igt_pipe_t *pipe)
+{
+   int fd = (int) pipe->out_fence_fd;
+   pipe->out_fence_fd = -1;
+
+   return fd;
+}
+
 bool igt_pipe_get_property(igt_pipe_t *pipe, const char *name,
   uint32_t *prop_id, uint64_t *value,
   drmModePropertyPtr *prop)
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 6754d00e..8fb327d9 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -390,6 +390,7 @@ igt_plane_t *igt_output_get_plane_type(igt_output_t 
*output, int plane_type);
 igt_output_t *igt_output_from_connector(igt_display_t *display,
 drmModeConnector *connector);
 igt_plane_t *igt_pipe_get_plane_type(igt_pipe_t *pipe, int plane_type);
+int igt_pipe_get_last_out_fence(igt_pipe_t *pipe);
 bool igt_pipe_get_property(igt_pipe_t *pipe, const char *name,
   uint32_t *prop_id, uint64_t *value,
   drmModePropertyPtr *prop);
-- 
2.11.0.453.g787f75f05

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


[Intel-gfx] [PATCH i-g-t v4 02/11] lib/igt_kms: move igt_kms_get_alt_edid() to the right place

2017-01-31 Thread Robert Foss
From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
---
 lib/igt_kms.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 4ba6316d..41acce45 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -157,23 +157,6 @@ const unsigned char* igt_kms_get_base_edid(void)
 #define EDID_NAME alt_edid
 #include "igt_edid_template.h"
 
-/**
- * igt_kms_get_alt_edid:
- *
- * Get an alternate edid block, which includes the following modes:
- *
- *  - 1400x1050 60Hz
- *  - 1920x1080 60Hz
- *  - 1280x720 60Hz
- *  - 1024x768 60Hz
- *  - 800x600 60Hz
- *  - 640x480 60Hz
- *
- * This can be extended with further features using functions such as
- * #kmstest_edid_add_3d.
- *
- * Returns: an alternate edid block
- */
 static const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
"SRC_X",
"SRC_Y",
@@ -301,6 +284,23 @@ igt_atomic_fill_pipe_props(igt_display_t *display, 
igt_pipe_t *pipe,
drmModeFreeObjectProperties(props);
 }
 
+/**
+ * igt_kms_get_alt_edid:
+ *
+ * Get an alternate edid block, which includes the following modes:
+ *
+ *  - 1400x1050 60Hz
+ *  - 1920x1080 60Hz
+ *  - 1280x720 60Hz
+ *  - 1024x768 60Hz
+ *  - 800x600 60Hz
+ *  - 640x480 60Hz
+ *
+ * This can be extended with further features using functions such as
+ * #kmstest_edid_add_3d.
+ *
+ * Returns: an alternate edid block
+ */
 const unsigned char* igt_kms_get_alt_edid(void)
 {
update_edid_csum(alt_edid);
-- 
2.11.0.453.g787f75f05

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


[Intel-gfx] [PATCH i-g-t v4 08/11] tests/kms_atomic_transition: add fencing parameter to run_transition_tests

2017-01-31 Thread Robert Foss
From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
---
 tests/kms_atomic_transition.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index 095af515..72429759 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -264,7 +264,7 @@ retry:
  */
 static void
 run_transition_test(igt_display_t *display, enum pipe pipe, igt_output_t 
*output,
-   enum transition_type type, bool nonblocking)
+   enum transition_type type, bool nonblocking, bool fencing)
 {
struct igt_fb fb, argb_fb, sprite_fb;
drmModeModeInfo *mode, override_mode;
@@ -674,19 +674,19 @@ igt_main
 
igt_subtest("plane-all-transition")
for_each_pipe_with_valid_output(, pipe, output)
-   run_transition_test(, pipe, output, 
TRANSITION_PLANES, false);
+   run_transition_test(, pipe, output, 
TRANSITION_PLANES, false, false);
 
igt_subtest("plane-all-transition-nonblocking")
for_each_pipe_with_valid_output(, pipe, output)
-   run_transition_test(, pipe, output, 
TRANSITION_PLANES, true);
+   run_transition_test(, pipe, output, 
TRANSITION_PLANES, true, false);
 
igt_subtest("plane-all-modeset-transition")
for_each_pipe_with_valid_output(, pipe, output)
-   run_transition_test(, pipe, output, 
TRANSITION_MODESET, false);
+   run_transition_test(, pipe, output, 
TRANSITION_MODESET, false, false);
 
igt_subtest("plane-toggle-modeset-transition")
for_each_pipe_with_valid_output(, pipe, output)
-   run_transition_test(, pipe, output, 
TRANSITION_MODESET_DISABLE, false);
+   run_transition_test(, pipe, output, 
TRANSITION_MODESET_DISABLE, false, false);
 
for (i = 1; i <= I915_MAX_PIPES; i++) {
igt_subtest_f("%ix-modeset-transitions", i)
-- 
2.11.0.453.g787f75f05

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


[Intel-gfx] [PATCH i-g-t v4 09/11] tests/kms_atomic_transition: add out_fences tests

2017-01-31 Thread Robert Foss
Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
---
 lib/igt_kms.c |  16 +
 tests/kms_atomic_transition.c | 153 --
 2 files changed, 164 insertions(+), 5 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 7bf3fa3a..64f8b337 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -53,6 +53,7 @@
 #include "intel_chipset.h"
 #include "igt_debugfs.h"
 #include "igt_sysfs.h"
+#include "sw_sync.h"
 
 /**
  * SECTION:igt_kms
@@ -2470,6 +2471,21 @@ static int igt_atomic_commit(igt_display_t *display, 
uint32_t flags, void *user_
}
 
ret = drmModeAtomicCommit(display->drm_fd, req, flags, user_data);
+   if (!ret) {
+
+   for_each_pipe(display, pipe) {
+   igt_pipe_t *pipe_obj = >pipes[pipe];
+
+   if (pipe_obj->out_fence_fd == -1)
+   continue;
+
+   igt_assert(pipe_obj->out_fence_fd >= 0);
+   ret = sync_fence_wait(pipe_obj->out_fence_fd, 1000);
+   igt_assert(ret == 0);
+   close(pipe_obj->out_fence_fd);
+   }
+   }
+
drmModeAtomicFree(req);
return ret;
 
diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index 72429759..4b1278a4 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -23,7 +23,9 @@
 
 #include "igt.h"
 #include "drmtest.h"
+#include "sw_sync.h"
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -253,6 +255,94 @@ retry:
 sprite_width, sprite_height, alpha);
 }
 
+int *timeline;
+pthread_t *thread;
+int *seqno;
+
+static void prepare_fencing(igt_display_t *display, enum pipe pipe)
+{
+   igt_plane_t *plane;
+   int n_planes;
+
+   igt_require_sw_sync();
+
+   n_planes = display->pipes[pipe].n_planes;
+   timeline = calloc(sizeof(*timeline), n_planes);
+   igt_assert_f(timeline != NULL, "Failed to allocate memory for 
timelines\n");
+   thread = calloc(sizeof(*thread), n_planes);
+   igt_assert_f(thread != NULL, "Failed to allocate memory for thread\n");
+   seqno = calloc(sizeof(*seqno), n_planes);
+   igt_assert_f(seqno != NULL, "Failed to allocate memory for seqno\n");
+
+   for_each_plane_on_pipe(display, pipe, plane)
+   timeline[plane->index] = sw_sync_timeline_create();
+}
+
+static void unprepare_fencing(igt_display_t *display, enum pipe pipe)
+{
+   igt_plane_t *plane;
+
+   for_each_plane_on_pipe(display, pipe, plane)
+   close(timeline[plane->index]);
+
+   free(timeline);
+   free(thread);
+   free(seqno);
+}
+
+static void *fence_inc_thread(void *arg)
+{
+   int t = *((int *) arg);
+
+   pthread_detach(pthread_self());
+
+   usleep(5000);
+   sw_sync_timeline_inc(t, 1);
+   return NULL;
+}
+
+static void configure_fencing(igt_display_t *display, enum pipe pipe)
+{
+   igt_plane_t *plane;
+   int i, fd, ret;
+
+   for_each_plane_on_pipe(display, pipe, plane) {
+
+   if (!plane->fb)
+   continue;
+
+   i = plane->index;
+
+   seqno[i]++;
+   fd = sw_sync_timeline_create_fence(timeline[i], seqno[i]);
+   igt_plane_set_fence_fd(plane, fd);
+   close(fd);
+   ret = pthread_create([i], NULL, fence_inc_thread, 
[i]);
+   igt_assert_eq(ret, 0);
+   }
+}
+
+static void clear_fencing(igt_display_t *display, enum pipe pipe)
+{
+   igt_plane_t *plane;
+
+   for_each_plane_on_pipe(display, pipe, plane)
+   igt_plane_set_fence_fd(plane, -1);
+}
+
+static void atomic_commit(igt_display_t *display, enum pipe pipe, unsigned int 
flags, void *data, bool fencing)
+{
+   if (fencing) {
+   configure_fencing(display, pipe);
+   igt_pipe_request_out_fence(>pipes[pipe]);
+   }
+
+   igt_display_commit_atomic(display, flags, data);
+
+   if (fencing)
+   clear_fencing(display, pipe);
+}
+
 /*
  * 1. Set primary plane to a known fb.
  * 2. Make sure getcrtc returns the correct fb id.
@@ -273,6 +363,10 @@ run_transition_test(igt_display_t *display, enum pipe 
pipe, igt_output_t *output
struct plane_parms parms[display->pipes[pipe].n_planes];
bool skip_test = false;
unsigned flags = DRM_MODE_PAGE_FLIP_EVENT;
+   int ret;
+
+   if (fencing)
+   prepare_fencing(display, pipe);
 
if (nonblocking)
flags |= DRM_MODE_ATOMIC_NONBLOCK;
@@ -307,12 +401,48 @@ run_transition_test(igt_display_t *display, enum pipe 
pipe, igt_output_t *output
 
setup_parms(display, pipe, mode, _fb, _fb, parms);
 
+   /*
+* In some configurations the tests may not run to completion with all
+* sprite planes lit up at 4k 

[Intel-gfx] [PATCH i-g-t v4 01/11] tests/kms_atomic_transition: use igt timeout instead of blocking

2017-01-31 Thread Robert Foss
From: Gustavo Padovan 

If the event never arrives we can timeout and end the test.

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
---
 tests/kms_atomic_transition.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index 5fdb6175..095af515 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -383,7 +383,9 @@ static void commit_display(igt_display_t *display, unsigned 
event_mask, bool non
struct drm_event_vblank *vblank = (void *)buf;
uint32_t crtc_id, pipe = I915_MAX_PIPES;
 
+   igt_set_timeout(3, "Timed out while reading drm_fd\n");
ret = read(display->drm_fd, buf, sizeof(buf));
+   igt_reset_timeout();
if (ret < 0 && (errno == EINTR || errno == EAGAIN))
continue;
 
-- 
2.11.0.453.g787f75f05

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


[Intel-gfx] [PATCH i-g-t v4 04/11] tests/kms_atomic: use global atomic properties definitions

2017-01-31 Thread Robert Foss
From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
---
 tests/kms_atomic.c | 123 -
 1 file changed, 37 insertions(+), 86 deletions(-)

diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
index e6d71c31..8df51ccd 100644
--- a/tests/kms_atomic.c
+++ b/tests/kms_atomic.c
@@ -105,55 +105,6 @@ static const char 
*plane_type_prop_names[NUM_PLANE_TYPE_PROPS] = {
"Cursor"
 };
 
-enum plane_properties {
-   PLANE_SRC_X = 0,
-   PLANE_SRC_Y,
-   PLANE_SRC_W,
-   PLANE_SRC_H,
-   PLANE_CRTC_X,
-   PLANE_CRTC_Y,
-   PLANE_CRTC_W,
-   PLANE_CRTC_H,
-   PLANE_FB_ID,
-   PLANE_CRTC_ID,
-   PLANE_TYPE,
-   NUM_PLANE_PROPS
-};
-
-static const char *plane_prop_names[NUM_PLANE_PROPS] = {
-   "SRC_X",
-   "SRC_Y",
-   "SRC_W",
-   "SRC_H",
-   "CRTC_X",
-   "CRTC_Y",
-   "CRTC_W",
-   "CRTC_H",
-   "FB_ID",
-   "CRTC_ID",
-   "type"
-};
-
-enum crtc_properties {
-   CRTC_MODE_ID = 0,
-   CRTC_ACTIVE,
-   NUM_CRTC_PROPS
-};
-
-static const char *crtc_prop_names[NUM_CRTC_PROPS] = {
-   "MODE_ID",
-   "ACTIVE"
-};
-
-enum connector_properties {
-   CONNECTOR_CRTC_ID = 0,
-   NUM_CONNECTOR_PROPS
-};
-
-static const char *connector_prop_names[NUM_CONNECTOR_PROPS] = {
-   "CRTC_ID"
-};
-
 struct kms_atomic_blob {
uint32_t id; /* 0 if not already allocated */
size_t len;
@@ -197,9 +148,9 @@ struct kms_atomic_state {
 
 struct kms_atomic_desc {
int fd;
-   uint32_t props_connector[NUM_CONNECTOR_PROPS];
-   uint32_t props_crtc[NUM_CRTC_PROPS];
-   uint32_t props_plane[NUM_PLANE_PROPS];
+   uint32_t props_connector[IGT_NUM_CONNECTOR_PROPS];
+   uint32_t props_crtc[IGT_NUM_CRTC_PROPS];
+   uint32_t props_plane[IGT_NUM_PLANE_PROPS];
uint64_t props_plane_type[NUM_PLANE_TYPE_PROPS];
 };
 
@@ -280,7 +231,7 @@ connector_get_current_state(struct 
kms_atomic_connector_state *connector)
for (i = 0; i < props->count_props; i++) {
uint32_t *prop_ids = connector->state->desc->props_connector;
 
-   if (props->props[i] == prop_ids[CONNECTOR_CRTC_ID])
+   if (props->props[i] == prop_ids[IGT_CONNECTOR_CRTC_ID])
connector->crtc_id = props->prop_values[i];
}
drmModeFreeObjectProperties(props);
@@ -348,16 +299,16 @@ find_connector(struct kms_atomic_state *state,
 static void plane_populate_req(struct kms_atomic_plane_state *plane,
   drmModeAtomicReq *req)
 {
-   plane_set_prop(req, plane, PLANE_CRTC_ID, plane->crtc_id);
-   plane_set_prop(req, plane, PLANE_FB_ID, plane->fb_id);
-   plane_set_prop(req, plane, PLANE_SRC_X, plane->src_x);
-   plane_set_prop(req, plane, PLANE_SRC_Y, plane->src_y);
-   plane_set_prop(req, plane, PLANE_SRC_W, plane->src_w);
-   plane_set_prop(req, plane, PLANE_SRC_H, plane->src_h);
-   plane_set_prop(req, plane, PLANE_CRTC_X, plane->crtc_x);
-   plane_set_prop(req, plane, PLANE_CRTC_Y, plane->crtc_y);
-   plane_set_prop(req, plane, PLANE_CRTC_W, plane->crtc_w);
-   plane_set_prop(req, plane, PLANE_CRTC_H, plane->crtc_h);
+   plane_set_prop(req, plane, IGT_PLANE_CRTC_ID, plane->crtc_id);
+   plane_set_prop(req, plane, IGT_PLANE_FB_ID, plane->fb_id);
+   plane_set_prop(req, plane, IGT_PLANE_SRC_X, plane->src_x);
+   plane_set_prop(req, plane, IGT_PLANE_SRC_Y, plane->src_y);
+   plane_set_prop(req, plane, IGT_PLANE_SRC_W, plane->src_w);
+   plane_set_prop(req, plane, IGT_PLANE_SRC_H, plane->src_h);
+   plane_set_prop(req, plane, IGT_PLANE_CRTC_X, plane->crtc_x);
+   plane_set_prop(req, plane, IGT_PLANE_CRTC_Y, plane->crtc_y);
+   plane_set_prop(req, plane, IGT_PLANE_CRTC_W, plane->crtc_w);
+   plane_set_prop(req, plane, IGT_PLANE_CRTC_H, plane->crtc_h);
 }
 
 static void plane_get_current_state(struct kms_atomic_plane_state *plane)
@@ -373,27 +324,27 @@ static void plane_get_current_state(struct 
kms_atomic_plane_state *plane)
for (i = 0; i < props->count_props; i++) {
uint32_t *prop_ids = desc->props_plane;
 
-   if (props->props[i] == prop_ids[PLANE_CRTC_ID])
+   if (props->props[i] == prop_ids[IGT_PLANE_CRTC_ID])
plane->crtc_id = props->prop_values[i];
-   else if (props->props[i] == prop_ids[PLANE_FB_ID])
+   else if (props->props[i] == prop_ids[IGT_PLANE_FB_ID])
plane->fb_id = props->prop_values[i];
-   else if (props->props[i] == prop_ids[PLANE_CRTC_X])
+   else if (props->props[i] == prop_ids[IGT_PLANE_CRTC_X])
plane->crtc_x = props->prop_values[i];
-   else if (props->props[i] == 

[Intel-gfx] [PATCH i-g-t v4 05/11] lib/igt_kms: Add support for the IN_FENCE_FD property

2017-01-31 Thread Robert Foss
Add support dor the IN_FENCE_FD property to enable setting in fences for atomic
commits.

Signed-off-by: Robert Foss 
---
 lib/igt_kms.c | 25 +
 lib/igt_kms.h |  5 +
 2 files changed, 30 insertions(+)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 142658a6..9b60d74a 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -168,6 +168,7 @@ const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
"CRTC_H",
"FB_ID",
"CRTC_ID",
+   "IN_FENCE_FD",
"type",
"rotation"
 };
@@ -1667,6 +1668,7 @@ void igt_display_init(igt_display_t *display, int drm_fd)
plane->type = type;
plane->pipe = pipe;
plane->drm_plane = drm_plane;
+   plane->fence_fd = -1;
 
if (is_atomic == 0) {
display->is_atomic = 1;
@@ -1994,6 +1996,11 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane, 
igt_pipe_t *pipe,
plane->index,
fb_id);
 
+   if (plane->fence_fd >= 0) {
+   uint64_t fence_fd = (int64_t) plane->fence_fd;
+   igt_atomic_populate_plane_req(req, plane, 
IGT_PLANE_IN_FENCE_FD, fence_fd);
+   }
+
if (plane->fb_changed) {
igt_atomic_populate_plane_req(req, plane, IGT_PLANE_CRTC_ID, 
fb_id ? crtc_id : 0);
igt_atomic_populate_plane_req(req, plane, IGT_PLANE_FB_ID, 
fb_id);
@@ -2815,6 +2822,24 @@ void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb 
*fb)
plane->size_changed = true;
 }
 
+/**
+ * igt_plane_set_fence_fd:
+ * @plane: plane
+ * @fence_fd: fence fd, disable fence_fd by setting it to -1
+ *
+ * This function sets a fence fd to enable a commit to wait for some event to
+ * occur before completing.
+ */
+void igt_plane_set_fence_fd(igt_plane_t *plane, int fence_fd)
+{
+   close(plane->fence_fd);
+
+   if (fcntl(fence_fd, F_GETFD) != -1)
+   plane->fence_fd = dup(fence_fd);
+   else
+   plane->fence_fd = -1;
+}
+
 void igt_plane_set_position(igt_plane_t *plane, int x, int y)
 {
igt_pipe_t *pipe = plane->pipe;
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 00e0dc68..8acad8ef 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -248,6 +248,7 @@ enum igt_atomic_plane_properties {
 
IGT_PLANE_FB_ID,
IGT_PLANE_CRTC_ID,
+   IGT_PLANE_IN_FENCE_FD,
IGT_PLANE_TYPE,
IGT_PLANE_ROTATION,
IGT_NUM_PLANE_PROPS
@@ -306,6 +307,9 @@ typedef struct {
uint32_t src_h;
 
igt_rotation_t rotation;
+
+   /* in fence fd */
+   int fence_fd;
uint32_t atomic_props_plane[IGT_NUM_PLANE_PROPS];
 } igt_plane_t;
 
@@ -396,6 +400,7 @@ void igt_pipe_set_ctm_matrix(igt_pipe_t *pipe, void *ptr, 
size_t length);
 void igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length);
 
 void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb *fb);
+void igt_plane_set_fence_fd(igt_plane_t *plane, int fence_fd);
 void igt_plane_set_position(igt_plane_t *plane, int x, int y);
 void igt_plane_set_size(igt_plane_t *plane, int w, int h);
 void igt_plane_set_rotation(igt_plane_t *plane, igt_rotation_t rotation);
-- 
2.11.0.453.g787f75f05

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


[Intel-gfx] [PATCH i-g-t v4 00/11] tests/kms_atomic_transition add fence testing

2017-01-31 Thread Robert Foss
This series adds in/out fence testing to kms_atomic_transition test and makes 
some minor cleanups.

This series can be found here:
https://git.collabora.com/cgit/user/robertfoss/intel-gpu-tools.git/log/?h=fences_$VER


Changes since v3:
  Rebased on upstream/master

  lib/igt_kms:
   - Change out_fence from int64_t to int32_t
   - Fixed build error halfway in the series
   - Change IN_FENCE_FD to be an int always
   - Change name of out_fence to out_fence_fd
   - Removed useless assert
   - Fixed erroneous fence_fd check in igt_atomic_commit()
   - Implemented igt_plane_set_fence_fd FD close logic
   - Properly close fd in igt_atomic_prepare_plane_commit()

  tests/kms_atomic:
   - Changed type of out_fence_ptr to int32_t

  tests/kms_atomic_transition:
   - Fixed indentation errors in prepare_fencing()
   - Added close() to callers of igt_plane_set_fence_fd with valid FDs
   - Move change atomic_commit to earlier commit to remove inter commit changes


Changes since v2:
  Rebased on upstream/master

  lib/igt_kms:
- Reset plane->fence_fd to -1 during igt_atomic_prepare_plane_commit()
- Rework out_fencs_ptr to be an int64_t named out_fence
- Add igt_pipe_request_out_fence()

  tests/:
- Switch to using igt_pipe_request_out_fence()
- Close out_fence fd
- Change out_fence to int64_t in run_transition_test()
- Added comments noting that two testcases are not invalid
- Added igt_pipe_get_last_out_fence() that wraps pipe->fence_out


Changes since v1:

  lib/igt_kms:
   - Added gtk-doc for exported symbols
   - Changed integer casting to avoid potential issues
   - Changed out_fence_ptr type to int64_t*
   - Fixed igt_plane_set_fence_fd comment

  tests/:
   - Rework timeout change in commit_display()
   - Extract plane_invalid_params_fence() out plane_invalid_params()
   - Extract crtc_invalid_params_fence() out crtc_invalid_params()
   - Prevent add igt_require_sw_sync to subtests using sw_sync



Gustavo Padovan (8):
  tests/kms_atomic_transition: use igt timeout instead of blocking
  lib/igt_kms: move igt_kms_get_alt_edid() to the right place
  lib/igt_kms: export properties names
  tests/kms_atomic: use global atomic properties definitions
  lib/igt_kms: Add support for the OUT_FENCE_PTR property
  tests/kms_atomic: stress possible fence settings
  tests/kms_atomic_transition: add fencing parameter to
run_transition_tests
  tests/kms_atomic_transition: add in_fences tests

Robert Foss (3):
  lib/igt_kms: Add support for the IN_FENCE_FD property
  tests/kms_atomic_transition: add out_fences tests
  lib/igt_kms: Added igt_pipe_get_last_out_fence()

 lib/igt_kms.c | 115 +---
 lib/igt_kms.h |  35 -
 tests/kms_atomic.c| 310 +-
 tests/kms_atomic_transition.c | 184 +++--
 tools/intel_vbt_decode| Bin 0 -> 384448 bytes
 5 files changed, 511 insertions(+), 133 deletions(-)
 create mode 100755 tools/intel_vbt_decode

-- 
2.11.0.453.g787f75f05

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


[Intel-gfx] [PATCH i-g-t v4 06/11] lib/igt_kms: Add support for the OUT_FENCE_PTR property

2017-01-31 Thread Robert Foss
From: Gustavo Padovan 

Add support for the OUT_FENCE_PTR property to enable setting out fences for
atomic commits.

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
---
 lib/igt_kms.c | 23 ++-
 lib/igt_kms.h |  6 +-
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 9b60d74a..7bf3fa3a 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -179,7 +179,8 @@ const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
"DEGAMMA_LUT",
"GAMMA_LUT",
"MODE_ID",
-   "ACTIVE"
+   "ACTIVE",
+   "OUT_FENCE_PTR"
 };
 
 const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
@@ -2385,6 +2386,14 @@ static void igt_atomic_prepare_crtc_commit(igt_pipe_t 
*pipe_obj, drmModeAtomicRe
igt_atomic_populate_crtc_req(req, pipe_obj, IGT_CRTC_ACTIVE, 
!!output);
}
 
+   pipe_obj->out_fence_fd = -1;
+   if (pipe_obj->out_fence_requested)
+   {
+   pipe_obj->out_fence_requested = false;
+   igt_atomic_populate_crtc_req(req, pipe_obj, 
IGT_CRTC_OUT_FENCE_PTR,
+   (uint64_t)(uintptr_t) _obj->out_fence_fd);
+   }
+
/*
 *  TODO: Add all crtc level properties here
 */
@@ -2959,6 +2968,18 @@ void igt_plane_set_rotation(igt_plane_t *plane, 
igt_rotation_t rotation)
plane->rotation_changed = true;
 }
 
+/**
+ * igt_pipe_request_out_fence:
+ * @pipe: pipe pointer to which background color to be set
+ *
+ * Marks this pipe for requesting an out fence at the next atomic commit
+ * will contain the fd number of the out fence created by KMS.
+ */
+void igt_pipe_request_out_fence(igt_pipe_t *pipe)
+{
+   pipe->out_fence_requested = true;
+}
+
 void
 igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t length)
 {
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 8acad8ef..6754d00e 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -94,6 +94,7 @@ enum igt_atomic_crtc_properties {
IGT_CRTC_GAMMA_LUT,
IGT_CRTC_MODE_ID,
IGT_CRTC_ACTIVE,
+   IGT_CRTC_OUT_FENCE_PTR,
IGT_NUM_CRTC_PROPS
 };
 
@@ -341,6 +342,9 @@ struct igt_pipe {
 
uint64_t mode_blob;
bool mode_changed;
+
+   int32_t out_fence_fd;
+   bool out_fence_requested;
 };
 
 typedef struct {
@@ -394,7 +398,7 @@ static inline bool igt_plane_supports_rotation(igt_plane_t 
*plane)
 {
return plane->rotation_property != 0;
 }
-
+void igt_pipe_request_out_fence(igt_pipe_t *pipe);
 void igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t length);
 void igt_pipe_set_ctm_matrix(igt_pipe_t *pipe, void *ptr, size_t length);
 void igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length);
-- 
2.11.0.453.g787f75f05

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


[Intel-gfx] [PATCH i-g-t v4 07/11] tests/kms_atomic: stress possible fence settings

2017-01-31 Thread Robert Foss
From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
Reviewed-by: Brian Starkey 
---
 tests/kms_atomic.c | 187 ++---
 1 file changed, 177 insertions(+), 10 deletions(-)

diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
index 8df51ccd..e794a62b 100644
--- a/tests/kms_atomic.c
+++ b/tests/kms_atomic.c
@@ -44,6 +44,7 @@
 #include "drmtest.h"
 #include "igt.h"
 #include "igt_aux.h"
+#include "sw_sync.h"
 
 #ifndef DRM_CLIENT_CAP_ATOMIC
 #define DRM_CLIENT_CAP_ATOMIC 3
@@ -126,6 +127,7 @@ struct kms_atomic_plane_state {
uint32_t fb_id; /* 0 to disable */
uint32_t src_x, src_y, src_w, src_h; /* 16.16 fixed-point */
uint32_t crtc_x, crtc_y, crtc_w, crtc_h; /* normal integers */
+   int32_t fence_fd;
 };
 
 struct kms_atomic_crtc_state {
@@ -133,6 +135,7 @@ struct kms_atomic_crtc_state {
uint32_t obj;
int idx;
bool active;
+   int32_t *out_fence_ptr;
struct kms_atomic_blob mode;
 };
 
@@ -190,11 +193,13 @@ static uint32_t blob_duplicate(int fd, uint32_t id_orig)
crtc_populate_req(crtc, req); \
plane_populate_req(plane, req); \
do_atomic_commit((crtc)->state->desc->fd, req, flags); \
-   crtc_check_current_state(crtc, plane, relax); \
-   plane_check_current_state(plane, relax); \
+   if (!(flags & DRM_MODE_ATOMIC_TEST_ONLY)) { \
+   crtc_check_current_state(crtc, plane, relax); \
+   plane_check_current_state(plane, relax); \
+   } \
 }
 
-#define crtc_commit_atomic_err(crtc, plane, crtc_old, plane_old, req, relax, 
e) { \
+#define crtc_commit_atomic_err(crtc, plane, crtc_old, plane_old, req, flags, 
relax, e) { \
drmModeAtomicSetCursor(req, 0); \
crtc_populate_req(crtc, req); \
plane_populate_req(plane, req); \
@@ -299,6 +304,9 @@ find_connector(struct kms_atomic_state *state,
 static void plane_populate_req(struct kms_atomic_plane_state *plane,
   drmModeAtomicReq *req)
 {
+   if (plane->fence_fd)
+   plane_set_prop(req, plane, IGT_PLANE_IN_FENCE_FD, 
plane->fence_fd);
+
plane_set_prop(req, plane, IGT_PLANE_CRTC_ID, plane->crtc_id);
plane_set_prop(req, plane, IGT_PLANE_FB_ID, plane->fb_id);
plane_set_prop(req, plane, IGT_PLANE_SRC_X, plane->src_x);
@@ -433,6 +441,10 @@ find_plane(struct kms_atomic_state *state, enum plane_type 
type,
 static void crtc_populate_req(struct kms_atomic_crtc_state *crtc,
  drmModeAtomicReq *req)
 {
+   if (crtc->out_fence_ptr)
+   crtc_set_prop(req, crtc, IGT_CRTC_OUT_FENCE_PTR,
+ (uint64_t) crtc->out_fence_ptr);
+
crtc_set_prop(req, crtc, IGT_CRTC_MODE_ID, crtc->mode.id);
crtc_set_prop(req, crtc, IGT_CRTC_ACTIVE, crtc->active);
 }
@@ -1061,6 +1073,37 @@ static void plane_invalid_params(struct 
kms_atomic_crtc_state *crtc,
drmModeAtomicFree(req);
 }
 
+static void plane_invalid_params_fence(struct kms_atomic_crtc_state *crtc,
+   struct kms_atomic_plane_state *plane_old,
+   struct kms_atomic_connector_state *conn)
+{
+   struct kms_atomic_plane_state plane = *plane_old;
+   drmModeAtomicReq *req = drmModeAtomicAlloc();
+   int timeline, fence_fd;
+
+   igt_require_sw_sync();
+
+   /* invalid fence fd */
+   plane.fence_fd = plane.state->desc->fd;
+   plane.crtc_id = plane_old->crtc_id;
+   plane_commit_atomic_err(, plane_old, req,
+   ATOMIC_RELAX_NONE, EINVAL);
+
+   /* Valid fence_fd but invalid CRTC */
+   timeline = sw_sync_timeline_create();
+   fence_fd =  sw_sync_timeline_create_fence(timeline, 1);
+   plane.fence_fd = fence_fd;
+   plane.crtc_id = ~0U;
+   plane_commit_atomic_err(, plane_old, req,
+   ATOMIC_RELAX_NONE, EINVAL);
+
+   plane.fence_fd = -1;
+   close(fence_fd);
+   close(timeline);
+
+   drmModeAtomicFree(req);
+}
+
 static void crtc_invalid_params(struct kms_atomic_crtc_state *crtc_old,
struct kms_atomic_plane_state *plane,
struct kms_atomic_connector_state *conn)
@@ -1072,30 +1115,32 @@ static void crtc_invalid_params(struct 
kms_atomic_crtc_state *crtc_old,
 
/* Pass a series of invalid object IDs for the mode ID. */
crtc.mode.id = plane->obj;
-   crtc_commit_atomic_err(, plane, crtc_old, plane, req,
+   crtc_commit_atomic_err(, plane, crtc_old, plane, req, 0,
   ATOMIC_RELAX_NONE, EINVAL);
 
crtc.mode.id = crtc.obj;
-   crtc_commit_atomic_err(, plane, crtc_old, plane, req,
+   crtc_commit_atomic_err(, plane, crtc_old, plane, req, 0,

Re: [Intel-gfx] [PATCH i-g-t v3 11/11] tests/kms_atomic_transition: add in_fences tests

2017-01-31 Thread Robert Foss



On 2017-01-31 11:52 AM, Brian Starkey wrote:

On Mon, Jan 30, 2017 at 08:58:47PM -0500, Robert Foss wrote:

From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
---
lib/igt_kms.c |  3 +++
tests/kms_atomic_transition.c | 48
++-
2 files changed, 32 insertions(+), 19 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 523f3f57..bc815363 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -2009,6 +2009,9 @@ igt_atomic_prepare_plane_commit(igt_plane_t
*plane, igt_pipe_t *pipe,
if (plane->fence_fd >= 0) {
uint64_t fence_fd = (int64_t) plane->fence_fd;
igt_atomic_populate_plane_req(req, plane,
IGT_PLANE_IN_FENCE_FD, fence_fd);
+
+/* reset fence_fd to prevent it from being set for the next
commit */
+plane->fence_fd = -1;


Who closes it?


Fixed in v4.




}

if (plane->fb_changed) {
diff --git a/tests/kms_atomic_transition.c
b/tests/kms_atomic_transition.c
index eebb5d66..0876bbb3 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -23,7 +23,9 @@

#include "igt.h"
#include "drmtest.h"
+#include "sw_sync.h"
#include 
+#include 
#include 
#include 
#include 
@@ -362,6 +364,9 @@ run_transition_test(igt_display_t *display, enum
pipe pipe, igt_output_t *output
unsigned flags = DRM_MODE_PAGE_FLIP_EVENT;
int ret;

+if (fencing)
+prepare_fencing(display, pipe);
+
if (nonblocking)
flags |= DRM_MODE_ATOMIC_NONBLOCK;

@@ -404,18 +409,19 @@ run_transition_test(igt_display_t *display, enum
pipe pipe, igt_output_t *output
wm_setup_plane(display, pipe, iter_max - 1, parms);

if (fencing)
-igt_pipe_set_out_fence_ptr(>pipes[pipe],
-(int64_t *) _fence);
+igt_pipe_request_out_fence(>pipes[pipe]);
+


Hopefully this can get rebased away? I'm getting confused about
what's actually being added/changed in this commit.


Fixed in v4.
The igt_pipe_set_out_fence_ptr calls were really spread about.




ret = igt_display_try_commit_atomic(display,
DRM_MODE_ATOMIC_TEST_ONLY | DRM_MODE_ATOMIC_ALLOW_MODESET, NULL);

-if (ret != -EINVAL || n_planes < 3)
+if (ret != -EINVAL || display->pipes[pipe].n_planes < 3)
break;

ret = 0;
for_each_plane_on_pipe(display, pipe, plane) {
i = plane->index;

-if (plane->is_primary || plane->is_cursor)
+if (plane->type == DRM_PLANE_TYPE_PRIMARY ||
+plane->type == DRM_PLANE_TYPE_CURSOR)
continue;


This seems spurious?

...

A bit more add/remove churn below which can hopefully go away with a
rebase.



Ack, removing churn in v4.


Cheers,
-Brian


if (parms[i].width <= 512)
@@ -436,10 +442,8 @@ run_transition_test(igt_display_t *display, enum
pipe pipe, igt_output_t *output

wm_setup_plane(display, pipe, i, parms);

-if (fencing)
-igt_pipe_set_out_fence_ptr(>pipes[pipe],
_fence);
+atomic_commit(display, pipe, flags, (void *)(unsigned long)i,
fencing);

-igt_display_commit_atomic(display, flags, (void *)(unsigned
long)i);
drmHandleEvent(display->drm_fd, _events);

if (type == TRANSITION_MODESET_DISABLE) {
@@ -463,19 +467,14 @@ run_transition_test(igt_display_t *display, enum
pipe pipe, igt_output_t *output
if (type == TRANSITION_MODESET)
igt_output_override_mode(output, _mode);

-if (fencing)
-igt_pipe_set_out_fence_ptr(>pipes[pipe],
_fence);
-
-igt_display_commit_atomic(display, flags, (void
*)(unsigned long)j);
+atomic_commit(display, pipe, flags, (void *)(unsigned
long)i, fencing);
drmHandleEvent(display->drm_fd, _events);

wm_setup_plane(display, pipe, i, parms);
if (type == TRANSITION_MODESET)
igt_output_override_mode(output, NULL);

-if (fencing)
-igt_pipe_set_out_fence_ptr(>pipes[pipe],
_fence);
-
+atomic_commit(display, pipe, flags, (void *)(unsigned
long)i, fencing);
igt_display_commit_atomic(display, flags, (void
*)(unsigned long)i);
drmHandleEvent(display->drm_fd, _events);
}
@@ -483,6 +482,8 @@ run_transition_test(igt_display_t *display, enum
pipe pipe, igt_output_t *output
}

cleanup:
+unprepare_fencing(display, pipe);
+
igt_output_set_pipe(output, PIPE_NONE);

for_each_plane_on_pipe(display, pipe, plane)
@@ -617,7 +618,7 @@ static void collect_crcs_mask(igt_pipe_crc_t
**pipe_crcs, unsigned mask, igt_crc
}
}

-static void run_modeset_tests(igt_display_t *display, int howmany,
bool nonblocking)
+static void run_modeset_tests(igt_display_t *display, int howmany,
bool nonblocking, 

Re: [Intel-gfx] [PATCH v2] drm/i915: Get correct display clock on 945gm

2017-01-31 Thread kbuild test robot
Hi Arthur,

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

url:
https://github.com/0day-ci/linux/commits/Arthur-Heymans/drm-i915-Get-correct-display-clock-on-945gm/20170201-072757
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-i0-01312305 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_display.c: In function 'intel_init_display_hooks':
>> drivers/gpu/drm/i915/intel_display.c:16240:45: warning: assignment from 
>> incompatible pointer type
  dev_priv->display.get_display_clock_speed =
^

vim +16240 drivers/gpu/drm/i915/intel_display.c

88212941 Imre Deak  2016-03-16  16224IS_GEN6(dev_priv) || 
IS_IVYBRIDGE(dev_priv))
e70236a8 Jesse Barnes   2009-09-21  16225   
dev_priv->display.get_display_clock_speed =
e70236a8 Jesse Barnes   2009-09-21  16226   
i945_get_display_clock_speed;
88212941 Imre Deak  2016-03-16  16227   else if (IS_GM45(dev_priv))
34edce2f Ville Syrjälä  2015-05-22  16228   
dev_priv->display.get_display_clock_speed =
34edce2f Ville Syrjälä  2015-05-22  16229   
gm45_get_display_clock_speed;
c0f86832 Jani Nikula2016-12-07  16230   else if (IS_I965GM(dev_priv))
34edce2f Ville Syrjälä  2015-05-22  16231   
dev_priv->display.get_display_clock_speed =
34edce2f Ville Syrjälä  2015-05-22  16232   
i965gm_get_display_clock_speed;
88212941 Imre Deak  2016-03-16  16233   else if (IS_PINEVIEW(dev_priv))
34edce2f Ville Syrjälä  2015-05-22  16234   
dev_priv->display.get_display_clock_speed =
34edce2f Ville Syrjälä  2015-05-22  16235   
pnv_get_display_clock_speed;
88212941 Imre Deak  2016-03-16  16236   else if (IS_G33(dev_priv) || 
IS_G4X(dev_priv))
34edce2f Ville Syrjälä  2015-05-22  16237   
dev_priv->display.get_display_clock_speed =
34edce2f Ville Syrjälä  2015-05-22  16238   
g33_get_display_clock_speed;
88212941 Imre Deak  2016-03-16  16239   else if (IS_I915G(dev_priv))
e70236a8 Jesse Barnes   2009-09-21 @16240   
dev_priv->display.get_display_clock_speed =
e70236a8 Jesse Barnes   2009-09-21  16241   
i915_get_display_clock_speed;
52d2d756 Arthur Heymans 2017-02-01  16242   else if (IS_I845G(dev_priv))
e70236a8 Jesse Barnes   2009-09-21  16243   
dev_priv->display.get_display_clock_speed =
e70236a8 Jesse Barnes   2009-09-21  16244   
i9xx_misc_get_display_clock_speed;
52d2d756 Arthur Heymans 2017-02-01  16245   else if (IS_I945GM(dev_priv))
52d2d756 Arthur Heymans 2017-02-01  16246   
dev_priv->display.get_display_clock_speed =
52d2d756 Arthur Heymans 2017-02-01  16247   
i945gm_get_display_clock_speed;
88212941 Imre Deak  2016-03-16  16248   else if (IS_I915GM(dev_priv))

:: The code at line 16240 was first introduced by commit
:: e70236a8d3d0a4c100a0b9f7d394d9bda9c56aca drm/i915: split display 
functions by chip type

:: TO: Jesse Barnes <jbar...@virtuousgeek.org>
:: CC: Eric Anholt <e...@anholt.net>

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


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


[Intel-gfx] ✓ Fi.CI.BAT: success for Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2017-01-31 Thread Patchwork
== Series Details ==

Series: Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)
URL   : https://patchwork.freedesktop.org/series/18871/
State : success

== Summary ==

Series 18871v1 Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)
https://patchwork.freedesktop.org/api/1.0/series/18871/revisions/1/mbox/


fi-bdw-5557u total:247  pass:233  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:247  pass:208  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:247  pass:225  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:78   pass:65   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:247  pass:224  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:247  pass:227  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:247  pass:222  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:247  pass:215  dwarn:0   dfail:0   fail:0   skip:32 

83f390eaec64a1b0566f5f747d20741c077fcff5 drm-tip: 2017y-01m-31d-20h-19m-59s UTC 
integration manifest
9beee45 Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3659/
___
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 10/11] tests/kms_atomic_transition: add out_fences tests

2017-01-31 Thread Robert Foss



On 2017-01-31 11:52 AM, Brian Starkey wrote:

On Mon, Jan 30, 2017 at 08:58:46PM -0500, Robert Foss wrote:

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
---
lib/igt_kms.c |  35 ++
tests/kms_atomic_transition.c | 148
++
2 files changed, 169 insertions(+), 14 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index f14496dd..523f3f57 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -53,6 +53,7 @@
#include "intel_chipset.h"
#include "igt_debugfs.h"
#include "igt_sysfs.h"
+#include "sw_sync.h"

/**
 * SECTION:igt_kms
@@ -2479,6 +2480,21 @@ static int igt_atomic_commit(igt_display_t
*display, uint32_t flags, void *user_
}

ret = drmModeAtomicCommit(display->drm_fd, req, flags, user_data);
+if (!ret) {
+
+for_each_pipe(display, pipe) {
+igt_pipe_t *pipe_obj = >pipes[pipe];
+
+if (pipe_obj->out_fence != -1)
+continue;


Should be "if (pipe_obj->fence == -1)" ? The stuff below seems to be
assuming the fence is valid.



Correct, fixed in v4.


+
+igt_assert(pipe_obj->out_fence >= 0);
+ret = sync_fence_wait(pipe_obj->out_fence, 1000);
+igt_assert(ret == 0);
+close(pipe_obj->out_fence);
+}
+}
+
drmModeAtomicFree(req);
return ret;

@@ -2972,6 +2988,11 @@ void igt_plane_set_rotation(igt_plane_t *plane,
igt_rotation_t rotation)
plane->rotation_changed = true;
}

+void igt_pipe_request_out_fence(igt_pipe_t *pipe)


Oh here it is!


+{
+pipe->out_fence_requested = true;
+}
+
void
igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t length)
{
@@ -2994,20 +3015,6 @@ igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void
*ptr, size_t length)
}

/**
- * igt_pipe_set_out_fence_ptr:
- * @pipe: pipe pointer to which background color to be set
- * @fence_ptr: out fence pointer
- *
- * Sets the out fence pointer that will be passed to the kernel in
- * the atomic ioctl. When the kernel returns the out fence pointer
- * will contain the fd number of the out fence created by KMS.
- */
-void igt_pipe_set_out_fence_ptr(igt_pipe_t *pipe, int64_t *fence_ptr)


... and there this one goes. This deletion and the function above
need to be squashed into the earlier commit I suppose.



Ack, fixed in v4.


-{
-pipe->out_fence_ptr = fence_ptr;
-}
-
-/**
 * igt_crtc_set_background:
 * @pipe: pipe pointer to which background color to be set
 * @background: background color value in BGR 16bpc
diff --git a/tests/kms_atomic_transition.c
b/tests/kms_atomic_transition.c
index 72429759..eebb5d66 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -253,6 +253,93 @@ retry:
 sprite_width, sprite_height, alpha);
}

+int *timeline;
+pthread_t *thread;
+int *seqno;
+
+static void prepare_fencing(igt_display_t *display, enum pipe pipe)
+{
+igt_plane_t *plane;
+int n_planes;
+
+igt_require_sw_sync();
+
+n_planes = display->pipes[pipe].n_planes;
+timeline = calloc(sizeof(*timeline), n_planes);
+igt_assert_f(timeline != NULL, "Failed to allocate memory for
timelines\n");
+thread = calloc(sizeof(*thread), n_planes);
+igt_assert_f(thread != NULL, "Failed to allocate memory for
thread\n");
+seqno = calloc(sizeof(*seqno), n_planes);
+igt_assert_f(seqno != NULL, "Failed to allocate memory for
seqno\n");


The 6 lines above are space-indented



Ack, fixed in v4.


+
+for_each_plane_on_pipe(display, pipe, plane)
+timeline[plane->index] = sw_sync_timeline_create();
+}
+
+static void unprepare_fencing(igt_display_t *display, enum pipe pipe)
+{
+igt_plane_t *plane;
+
+for_each_plane_on_pipe(display, pipe, plane)
+close(timeline[plane->index]);
+
+free(timeline);
+free(thread);
+free(seqno);
+}
+
+static void *fence_inc_thread(void *arg)
+{
+int t = *((int *) arg);
+
+pthread_detach(pthread_self());
+
+usleep(5000);
+sw_sync_timeline_inc(t, 1);
+return NULL;
+}
+
+static void configure_fencing(igt_display_t *display, enum pipe pipe)
+{
+igt_plane_t *plane;
+int i, fd, ret;
+
+for_each_plane_on_pipe(display, pipe, plane) {
+
+if (!plane->fb)
+continue;
+
+i = plane->index;
+
+seqno[i]++;
+fd = sw_sync_timeline_create_fence(timeline[i], seqno[i]);
+igt_plane_set_fence_fd(plane, fd);
+ret = pthread_create([i], NULL, fence_inc_thread,
[i]);
+igt_assert_eq(ret, 0);
+}
+}
+
+static void clear_fencing(igt_display_t *display, enum pipe pipe)
+{
+igt_plane_t *plane;
+
+for_each_plane_on_pipe(display, pipe, plane)
+igt_plane_set_fence_fd(plane, -1);


Someone should close the old fence_fd if it's not -1.

I think igt_plane_set_fence_fd() should dup() the passed in fence, and
igt_display_atomic_commit() should set it to -1 after the 

Re: [Intel-gfx] [PATCH] drm: Don't race connector registration

2017-01-31 Thread Dave Hansen
I added some printk()s all over and gathered a bit more information
about what's going on.  It looks like the display doesn't work until the
drm connector code cleans up the *old* connector.  For some reason, it
isn't motivated to do that until I go to the console and back.

In this case, the display was connected to DP-4.
intel_dp_destroy_mst_connector() got called on it when I switched away,
but drm_connector_cleanup() did not get called.  Upon switching back
DP-3/5/6 get created.  One of these *eventually* ends up being
"enabled", but is not now.  When I switch over to the console,
drm_connector_cleanup() finally gets called on the old connector: DP-4
and I can switch back to X and I see one of DP-3/5/6 enabled and working.

Here are some snippets of dmesg interspersed with what I was doing:

Push DVI switch button to switch to other system:

> [ 6824.562838] drm_dp_destroy_port() kfree(8801ade46800)
> [ 6824.563164] drm_dp_destroy_connector_work() port: 8801ade42000 
> connector: 8801ade46000
> [ 6824.563178] intel_dp_destroy_mst_connector() connector: 8801ade46000 
> name: DP-3 : 8801ade46048 intel_connector: 8801ade46000
> [ 6824.563186] drm_sysfs_connector_remove() connector: 8801ade46000 kdev: 
> 8801a941b400
> [ 6824.571556] drm_connector_cleanup(8801ade46000)::329 
> connector->registered: 0 cpu: 3
> [ 6824.571570] drm_connector_cleanup() kfree() connector->name: 'DP-3' : 
> 8801ade46048
> [ 6824.571581] drm_dp_free_mst_port() kfree port: 8801ade42000
> [ 6824.571587] drm_dp_destroy_connector_work() port: 8801ade42800 
> connector: 8801ade47000
> [ 6824.571594] intel_dp_destroy_mst_connector() connector: 8801ade47000 
> name: DP-4 : 8801ade47048 intel_connector: 8801ade47000
> [ 6824.571601] drm_sysfs_connector_remove() connector: 8801ade47000 kdev: 
> 8801a941a000
> [ 6824.571915] drm_dp_free_mst_port() kfree port: 8801ade42800
> [ 6824.571925] drm_dp_destroy_connector_work() port: 8801ade40800 
> connector: 8801ade43000
> [ 6824.571934] intel_dp_destroy_mst_connector() connector: 8801ade43000 
> name: DP-6 : 8801ade43048 intel_connector: 8801ade43000
> [ 6824.571943] drm_sysfs_connector_remove() connector: 8801ade43000 kdev: 
> 8801a9419800
> [ 6824.572091] drm_connector_cleanup(8801ade43000)::329 
> connector->registered: 0 cpu: 3
> [ 6824.572101] drm_connector_cleanup() kfree() connector->name: 'DP-6' : 
> 8801ade43048
> [ 6824.572110] drm_dp_free_mst_branch_device() kfree mstb: 88030ac22600
> [ 6824.572117] drm_dp_free_mst_port() kfree port: 8801ade40800

Push button to switch back:

> [ 6837.349693] drm_connector_init() connector->name: 'DP-3' : 
> 88040231d848
> [ 6837.349894] drm_sysfs_connector_add() connector: 88040231d800 kdev: 
> 8801ae99f400
> [ 6837.352786] drm_connector_init() connector->name: 'DP-5' : 
> 880402318048
> [ 6837.352951] drm_sysfs_connector_add() connector: 880402318000 kdev: 
> 8801ae99c000
> [ 6837.353036] drm_connector_init() connector->name: 'DP-6' : 
> 88040d37f048
> [ 6837.353154] drm_sysfs_connector_add() connector: 88040d37f000 kdev: 
> 8801ae99ec00

I can type into the X session, but both screens are blank.  When I press
Ctrl-Alt-F2, I get:

> [ 6850.494310] drm_connector_cleanup(8801ade47000)::329 
> connector->registered: 0 cpu: 1
> [ 6850.494314] drm_connector_cleanup() kfree() connector->name: 'DP-4' : 
> 8801ade47048

Now I can switch back to X and everything is OK again.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Get correct display clock on 945gm (rev3)

2017-01-31 Thread Patchwork
== Series Details ==

Series: drm/i915: Get correct display clock on 945gm (rev3)
URL   : https://patchwork.freedesktop.org/series/18693/
State : success

== Summary ==

Series 18693v3 drm/i915: Get correct display clock on 945gm
https://patchwork.freedesktop.org/api/1.0/series/18693/revisions/3/mbox/


fi-bdw-5557u total:247  pass:233  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:247  pass:208  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:247  pass:225  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:78   pass:65   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:247  pass:224  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:247  pass:227  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:247  pass:222  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:247  pass:215  dwarn:0   dfail:0   fail:0   skip:32 

83f390eaec64a1b0566f5f747d20741c077fcff5 drm-tip: 2017y-01m-31d-20h-19m-59s UTC 
integration manifest
a784911 drm/i915: Get correct display clock on 945gm

== Logs ==

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


Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2017-01-31 Thread Rafael J. Wysocki
On Mon, Jan 30, 2017 at 11:44 PM, Rafael J. Wysocki
 wrote:
> On 1/24/2017 2:33 AM, Sedat Dilek wrote:
>>
>> On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki 
>> wrote:
>>>
>>> On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek 
>>> wrote:

 Hi,

 I have already reported this issue in [1].
 One of the issue was solved.
 Unfortunately, it looks like there is still a different problem here
 (Ubuntu/precise AMD64).

 I tried v4.10-rc1 and latest Linus tree up to...

 commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
 "mm/filemap: fix parameters to test_bit()"

 Here we go...

 [   29.636047] BUG: sleeping function called from invalid context at
 drivers/base/power/runtime.c:1032
 [   29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
 [   29.636058] 1 lock held by Xorg/1500:
 [   29.636060]  #0:  (>struct_mutex){+.+.+.}, at:
 [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
 [   29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
 4.10.0-rc1-6-iniza-amd64 #1
 [   29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
 [   29.636111] Call Trace:
 [   29.636120]  dump_stack+0x85/0xc2
 [   29.636124]  ___might_sleep+0x196/0x260
 [   29.636127]  __might_sleep+0x53/0xb0
 [   29.636131]  __pm_runtime_resume+0x7a/0x90
 [   29.636159]  intel_runtime_pm_get+0x25/0x90 [i915]
 [   29.636189]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
 [   29.636220]  i915_vma_bind+0xaf/0x1e0 [i915]
 [   29.636248]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
 [   29.636272]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250
 [i915]
 [   29.636275]  ? trace_hardirqs_on+0xd/0x10
 [   29.636294]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0
 [i915]
 [   29.636316]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
 [   29.636342]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
 [   29.636347]  ? __might_fault+0x4e/0xb0
 [   29.636373]  i915_gem_execbuffer2+0xc5/0x260 [i915]
 [   29.636376]  ? __might_fault+0x4e/0xb0
 [   29.636395]  drm_ioctl+0x206/0x450 [drm]
 [   29.636420]  ? i915_gem_execbuffer+0x340/0x340 [i915]
 [   29.636425]  ? __fget+0x5/0x200
 [   29.636429]  do_vfs_ioctl+0x91/0x6f0
 [   29.636431]  ? __fget+0x111/0x200
 [   29.636433]  ? __fget+0x5/0x200
 [   29.636436]  SyS_ioctl+0x79/0x90
 [   29.636441]  entry_SYSCALL_64_fastpath+0x23/0xc6

 On suspend/resume I see the same call trace.
 [2] points to the "BUG" line.
>>>
>>> Well, this appears to be an i915 issue, but not a serious one.
>>>
>>> Clearly, a function that may sleep (pm_runtime_get_sync() in
>>> intel_runtime_pm_get()) is called with disabled interrupts.  If I
>>> understand the code correctly, though, it actually is not going to
>>> sleep in this particular case, because pm_runtime_get_sync() has
>>> already been called once for this device in the same code path which
>>> means that this particular instance will return immediately, so this
>>> is a false-positive (most likely).
>>>
>>> Let me see if I the might_sleep_if() assertion in
>>> __pm_runtime_resume(() can be moved to a better place.
>>>
>> Hi Rafael,
>>
>> did you had a chance to look at this?
>> The problem still remains in Linux v4.10-rc5.
>
>
> No, I didn't.
>
> As I said, this is not a serious issue.

Something like the attached (untested).

Please try it and let me know if it makes the splat go away.

Thanks,
Rafael
---
 drivers/base/power/runtime.c |   11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

Index: linux-pm/drivers/base/power/runtime.c
===
--- linux-pm.orig/drivers/base/power/runtime.c
+++ linux-pm/drivers/base/power/runtime.c
@@ -966,13 +966,13 @@ int __pm_runtime_idle(struct device *dev
 	unsigned long flags;
 	int retval;
 
-	might_sleep_if(!(rpmflags & RPM_ASYNC) && !dev->power.irq_safe);
-
 	if (rpmflags & RPM_GET_PUT) {
 		if (!atomic_dec_and_test(>power.usage_count))
 			return 0;
 	}
 
+	might_sleep_if(!(rpmflags & RPM_ASYNC) && !dev->power.irq_safe);
+
 	spin_lock_irqsave(>power.lock, flags);
 	retval = rpm_idle(dev, rpmflags);
 	spin_unlock_irqrestore(>power.lock, flags);
@@ -998,13 +998,13 @@ int __pm_runtime_suspend(struct device *
 	unsigned long flags;
 	int retval;
 
-	might_sleep_if(!(rpmflags & RPM_ASYNC) && !dev->power.irq_safe);
-
 	if (rpmflags & RPM_GET_PUT) {
 		if (!atomic_dec_and_test(>power.usage_count))
 			return 0;
 	}
 
+	might_sleep_if(!(rpmflags & RPM_ASYNC) && !dev->power.irq_safe);
+
 	spin_lock_irqsave(>power.lock, flags);
 	retval = rpm_suspend(dev, rpmflags);
 	spin_unlock_irqrestore(>power.lock, flags);
@@ -1029,7 +1029,8 @@ int __pm_runtime_resume(struct device *d
 	

Re: [Intel-gfx] [PATCH v2] drm/i915: Get correct display clock on 945gm

2017-01-31 Thread kbuild test robot
Hi Arthur,

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

url:
https://github.com/0day-ci/linux/commits/Arthur-Heymans/drm-i915-Get-correct-display-clock-on-945gm/20170201-072757
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_display.c: In function 'intel_init_display_hooks':
>> drivers/gpu/drm/i915/intel_display.c:16240:45: error: assignment from 
>> incompatible pointer type [-Werror=incompatible-pointer-types]
  dev_priv->display.get_display_clock_speed =
^
   cc1: some warnings being treated as errors

vim +16240 drivers/gpu/drm/i915/intel_display.c

34edce2f Ville Syrjälä  2015-05-22  16234   
dev_priv->display.get_display_clock_speed =
34edce2f Ville Syrjälä  2015-05-22  16235   
pnv_get_display_clock_speed;
88212941 Imre Deak  2016-03-16  16236   else if (IS_G33(dev_priv) || 
IS_G4X(dev_priv))
34edce2f Ville Syrjälä  2015-05-22  16237   
dev_priv->display.get_display_clock_speed =
34edce2f Ville Syrjälä  2015-05-22  16238   
g33_get_display_clock_speed;
88212941 Imre Deak  2016-03-16  16239   else if (IS_I915G(dev_priv))
e70236a8 Jesse Barnes   2009-09-21 @16240   
dev_priv->display.get_display_clock_speed =
e70236a8 Jesse Barnes   2009-09-21  16241   
i915_get_display_clock_speed;
52d2d756 Arthur Heymans 2017-02-01  16242   else if (IS_I845G(dev_priv))
e70236a8 Jesse Barnes   2009-09-21  16243   
dev_priv->display.get_display_clock_speed =

:: The code at line 16240 was first introduced by commit
:: e70236a8d3d0a4c100a0b9f7d394d9bda9c56aca drm/i915: split display 
functions by chip type

:: TO: Jesse Barnes <jbar...@virtuousgeek.org>
:: CC: Eric Anholt <e...@anholt.net>

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


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


[Intel-gfx] [PATCH] drm/i915: Get correct display clock on 945gm

2017-01-31 Thread Arthur Heymans
This is according to Mobile Intel® 945 Express Chipset
Family datasheet.

Signed-off-by: Arthur Heymans 
---
 drivers/gpu/drm/i915/i915_reg.h  |  2 +-
 drivers/gpu/drm/i915/intel_display.c | 27 +--
 2 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 02a65ddae3a3..f0b7849ace17 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -119,7 +119,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define GCFGC  0xf0 /* 915+ only */
 #define   GC_LOW_FREQUENCY_ENABLE  (1 << 7)
 #define   GC_DISPLAY_CLOCK_190_200_MHZ (0 << 4)
-#define   GC_DISPLAY_CLOCK_333_MHZ (4 << 4)
+#define   GC_DISPLAY_CLOCK_333_320_MHZ (4 << 4)
 #define   GC_DISPLAY_CLOCK_267_MHZ_PNV (0 << 4)
 #define   GC_DISPLAY_CLOCK_333_MHZ_PNV (1 << 4)
 #define   GC_DISPLAY_CLOCK_444_MHZ_PNV (2 << 4)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ac25706b7d4d..998920ab3ec8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7407,6 +7407,26 @@ static int i945_get_display_clock_speed(struct 
drm_i915_private *dev_priv)
return 40;
 }
 
+static int i945gm_get_display_clock_speed(struct drm_i915_private *dev_priv)
+{
+   struct pci_dev *pdev = dev_priv->drm.pdev;
+   u16 gcfgc = 0;
+
+   pci_read_config_word(pdev, GCFGC, );
+
+   if (gcfgc & GC_LOW_FREQUENCY_ENABLE)
+   return 13;
+   else {
+   switch (gcfgc & GC_DISPLAY_CLOCK_MASK) {
+   case GC_DISPLAY_CLOCK_333_320_MHZ:
+   return 32;
+   default:
+   case GC_DISPLAY_CLOCK_190_200_MHZ:
+   return 20;
+   }
+   }
+}
+
 static int i915_get_display_clock_speed(struct drm_i915_private *dev_priv)
 {
return 33;
@@ -7453,7 +7473,7 @@ static int i915gm_get_display_clock_speed(struct 
drm_i915_private *dev_priv)
return 13;
else {
switch (gcfgc & GC_DISPLAY_CLOCK_MASK) {
-   case GC_DISPLAY_CLOCK_333_MHZ:
+   case GC_DISPLAY_CLOCK_333_320_MHZ:
return 33;
default:
case GC_DISPLAY_CLOCK_190_200_MHZ:
@@ -16244,9 +16264,12 @@ void intel_init_display_hooks(struct drm_i915_private 
*dev_priv)
else if (IS_I915G(dev_priv))
dev_priv->display.get_display_clock_speed =
i915_get_display_clock_speed;
-   else if (IS_I945GM(dev_priv) || IS_I845G(dev_priv))
+   else if (IS_I845G(dev_priv))
dev_priv->display.get_display_clock_speed =
i9xx_misc_get_display_clock_speed;
+   else if (IS_I945GM(dev_priv))
+   dev_priv->display.get_display_clock_speed =
+   i945gm_get_display_clock_speed;
else if (IS_I915GM(dev_priv))
dev_priv->display.get_display_clock_speed =
i915gm_get_display_clock_speed;
-- 
2.11.0

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Get correct display clock on 945gm (rev2)

2017-01-31 Thread Patchwork
== Series Details ==

Series: drm/i915: Get correct display clock on 945gm (rev2)
URL   : https://patchwork.freedesktop.org/series/18693/
State : failure

== Summary ==

  CC  drivers/acpi/acpica/utpredef.o
  CC [M]  drivers/gpu/drm/i915/i915_perf.o
  CC [M]  drivers/gpu/drm/i915/i915_oa_hsw.o
  CC  drivers/acpi/acpica/utresrc.o
  CC  drivers/acpi/acpica/utstate.o
  CC  drivers/acpi/acpica/utstring.o
  CC  drivers/acpi/acpica/utstrtoul64.o
  CC  drivers/acpi/acpica/utxface.o
  CC [M]  drivers/gpu/drm/i915/intel_gvt.o
  CC  drivers/acpi/acpica/utxfinit.o
  CC  drivers/acpi/acpica/utxferror.o
  LD  net/ipv6/built-in.o
  CC  drivers/acpi/acpica/utxfmutex.o
  CC [M]  drivers/gpu/drm/i915/gvt/aperture_gm.o
  CC [M]  drivers/gpu/drm/i915/gvt/gvt.o
  LD  drivers/iommu/built-in.o
  CC [M]  drivers/gpu/drm/i915/gvt/handlers.o
  CC [M]  drivers/gpu/drm/i915/gvt/vgpu.o
  CC [M]  drivers/gpu/drm/i915/gvt/trace_points.o
  CC [M]  drivers/gpu/drm/i915/gvt/interrupt.o
  CC [M]  drivers/gpu/drm/i915/gvt/firmware.o
  LD [M]  drivers/gpu/drm/vgem/vgem.o
  CC [M]  drivers/gpu/drm/i915/gvt/gtt.o
  CC [M]  drivers/gpu/drm/i915/gvt/cfg_space.o
  CC [M]  drivers/gpu/drm/i915/gvt/opregion.o
  CC [M]  drivers/gpu/drm/i915/gvt/mmio.o
  CC [M]  drivers/gpu/drm/i915/gvt/edid.o
  CC [M]  drivers/gpu/drm/i915/gvt/display.o
  CC [M]  drivers/gpu/drm/i915/gvt/sched_policy.o
  CC [M]  drivers/gpu/drm/i915/gvt/scheduler.o
  CC [M]  drivers/gpu/drm/i915/gvt/execlist.o
  CC [M]  drivers/gpu/drm/i915/gvt/render.o
  CC [M]  drivers/gpu/drm/i915/intel_lpe_audio.o
  CC [M]  drivers/gpu/drm/i915/gvt/cmd_parser.o
  LD  drivers/pci/built-in.o
  LD  drivers/usb/gadget/libcomposite.o
  LD  drivers/video/console/built-in.o
  LD  drivers/video/built-in.o
  LD  drivers/acpi/acpica/acpi.o
  LD  drivers/usb/gadget/udc/udc-core.o
  LD  drivers/gpu/drm/drm.o
  LD  drivers/usb/gadget/udc/built-in.o
  LD  drivers/usb/gadget/built-in.o
  LD  net/xfrm/built-in.o
  LD  drivers/scsi/sd_mod.o
  LD  drivers/scsi/built-in.o
  LD  drivers/acpi/acpica/built-in.o
  LD [M]  drivers/net/ethernet/broadcom/genet/genet.o
  LD  drivers/tty/serial/8250/8250_base.o
  LD  drivers/tty/serial/8250/built-in.o
  LD  drivers/tty/serial/built-in.o
  LD  drivers/acpi/built-in.o
drivers/gpu/drm/i915/intel_display.c: In function ‘intel_init_display_hooks’:
drivers/gpu/drm/i915/intel_display.c:16268:45: error: assignment from 
incompatible pointer type [-Werror=incompatible-pointer-types]
   dev_priv->display.get_display_clock_speed =
 ^
  LD  drivers/usb/host/xhci-hcd.o
  LD [M]  sound/pci/hda/snd-hda-codec-generic.o
  LD  sound/pci/built-in.o
  LD  fs/btrfs/btrfs.o
  LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
  LD  sound/built-in.o
  LD  fs/btrfs/built-in.o
  AR  lib/lib.a
  EXPORTS lib/lib-ksyms.o
  LD  lib/built-in.o
  LD  drivers/usb/core/usbcore.o
  LD  drivers/usb/core/built-in.o
  LD [M]  drivers/net/ethernet/intel/igbvf/igbvf.o
  CC  arch/x86/kernel/cpu/capflags.o
  LD  arch/x86/kernel/cpu/built-in.o
  LD  arch/x86/kernel/built-in.o
  LD  drivers/tty/vt/built-in.o
  LD  drivers/tty/built-in.o
  LD  drivers/md/md-mod.o
  LD  drivers/md/built-in.o
  LD  arch/x86/built-in.o
  LD  net/ipv4/built-in.o
  LD  drivers/usb/host/built-in.o
  LD  drivers/usb/built-in.o
  LD  fs/ext4/ext4.o
  LD  fs/ext4/built-in.o
  LD  net/core/built-in.o
  LD  fs/built-in.o
  LD  net/built-in.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/net/built-in.o
cc1: all warnings being treated as errors
scripts/Makefile.build:293: recipe for target 
'drivers/gpu/drm/i915/intel_display.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_display.o] Error 1
scripts/Makefile.build:551: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:551: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:551: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:988: 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


[Intel-gfx] [PATCH v2] drm/i915: Get correct display clock on 945gm

2017-01-31 Thread Arthur Heymans
This is according to Mobile Intel® 945 Express Chipset
Family datasheet.

Signed-off-by: Arthur Heymans 
---
 drivers/gpu/drm/i915/i915_reg.h  |  2 +-
 drivers/gpu/drm/i915/intel_display.c | 29 ++---
 2 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 02a65ddae3a3..f0b7849ace17 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -119,7 +119,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define GCFGC  0xf0 /* 915+ only */
 #define   GC_LOW_FREQUENCY_ENABLE  (1 << 7)
 #define   GC_DISPLAY_CLOCK_190_200_MHZ (0 << 4)
-#define   GC_DISPLAY_CLOCK_333_MHZ (4 << 4)
+#define   GC_DISPLAY_CLOCK_333_320_MHZ (4 << 4)
 #define   GC_DISPLAY_CLOCK_267_MHZ_PNV (0 << 4)
 #define   GC_DISPLAY_CLOCK_333_MHZ_PNV (1 << 4)
 #define   GC_DISPLAY_CLOCK_444_MHZ_PNV (2 << 4)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ac25706b7d4d..3e1deb501983 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7407,7 +7407,27 @@ static int i945_get_display_clock_speed(struct 
drm_i915_private *dev_priv)
return 40;
 }
 
-static int i915_get_display_clock_speed(struct drm_i915_private *dev_priv)
+static int i945gm_get_display_clock_speed(struct drm_i915_private *dev_priv)
+{
+   struct pci_dev *pdev = dev_priv->drm.pdev;
+   u16 gcfgc = 0;
+
+   pci_read_config_word(pdev, GCFGC, );
+
+   if (gcfgc & GC_LOW_FREQUENCY_ENABLE)
+   return 13;
+   else {
+   switch (gcfgc & GC_DISPLAY_CLOCK_MASK) {
+   case GC_DISPLAY_CLOCK_333_320_MHZ:
+   return 32;
+   default:
+   case GC_DISPLAY_CLOCK_190_200_MHZ:
+   return 20;
+   }
+   }
+}
+
+static int i915_get_display_clock_speed(struct drm_device *dev)
 {
return 33;
 }
@@ -7453,7 +7473,7 @@ static int i915gm_get_display_clock_speed(struct 
drm_i915_private *dev_priv)
return 13;
else {
switch (gcfgc & GC_DISPLAY_CLOCK_MASK) {
-   case GC_DISPLAY_CLOCK_333_MHZ:
+   case GC_DISPLAY_CLOCK_333_320_MHZ:
return 33;
default:
case GC_DISPLAY_CLOCK_190_200_MHZ:
@@ -16244,9 +16264,12 @@ void intel_init_display_hooks(struct drm_i915_private 
*dev_priv)
else if (IS_I915G(dev_priv))
dev_priv->display.get_display_clock_speed =
i915_get_display_clock_speed;
-   else if (IS_I945GM(dev_priv) || IS_I845G(dev_priv))
+   else if (IS_I845G(dev_priv))
dev_priv->display.get_display_clock_speed =
i9xx_misc_get_display_clock_speed;
+   else if (IS_I945GM(dev_priv))
+   dev_priv->display.get_display_clock_speed =
+   i945gm_get_display_clock_speed;
else if (IS_I915GM(dev_priv))
dev_priv->display.get_display_clock_speed =
i915gm_get_display_clock_speed;
-- 
2.11.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 08/11] tests/kms_atomic: stress possible fence settings

2017-01-31 Thread Robert Foss



On 2017-01-31 11:50 AM, Brian Starkey wrote:

This one lgtm, just need to swap all the uint64_t out_fence_ptrs for
int32_t.

-Brian


Fixed in v4.

Rob.



On Mon, Jan 30, 2017 at 08:58:44PM -0500, Robert Foss wrote:

From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
---
tests/kms_atomic.c | 187
++---
1 file changed, 177 insertions(+), 10 deletions(-)

diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
index 8df51ccd..09605e38 100644
--- a/tests/kms_atomic.c
+++ b/tests/kms_atomic.c
@@ -44,6 +44,7 @@
#include "drmtest.h"
#include "igt.h"
#include "igt_aux.h"
+#include "sw_sync.h"

#ifndef DRM_CLIENT_CAP_ATOMIC
#define DRM_CLIENT_CAP_ATOMIC 3
@@ -126,6 +127,7 @@ struct kms_atomic_plane_state {
uint32_t fb_id; /* 0 to disable */
uint32_t src_x, src_y, src_w, src_h; /* 16.16 fixed-point */
uint32_t crtc_x, crtc_y, crtc_w, crtc_h; /* normal integers */
+int32_t fence_fd;
};

struct kms_atomic_crtc_state {
@@ -133,6 +135,7 @@ struct kms_atomic_crtc_state {
uint32_t obj;
int idx;
bool active;
+uint64_t out_fence_ptr;
struct kms_atomic_blob mode;
};

@@ -190,11 +193,13 @@ static uint32_t blob_duplicate(int fd, uint32_t
id_orig)
crtc_populate_req(crtc, req); \
plane_populate_req(plane, req); \
do_atomic_commit((crtc)->state->desc->fd, req, flags); \
-crtc_check_current_state(crtc, plane, relax); \
-plane_check_current_state(plane, relax); \
+if (!(flags & DRM_MODE_ATOMIC_TEST_ONLY)) { \
+crtc_check_current_state(crtc, plane, relax); \
+plane_check_current_state(plane, relax); \
+} \
}

-#define crtc_commit_atomic_err(crtc, plane, crtc_old, plane_old, req,
relax, e) { \
+#define crtc_commit_atomic_err(crtc, plane, crtc_old, plane_old, req,
flags, relax, e) { \
drmModeAtomicSetCursor(req, 0); \
crtc_populate_req(crtc, req); \
plane_populate_req(plane, req); \
@@ -299,6 +304,9 @@ find_connector(struct kms_atomic_state *state,
static void plane_populate_req(struct kms_atomic_plane_state *plane,
   drmModeAtomicReq *req)
{
+if (plane->fence_fd)
+plane_set_prop(req, plane, IGT_PLANE_IN_FENCE_FD,
plane->fence_fd);
+
plane_set_prop(req, plane, IGT_PLANE_CRTC_ID, plane->crtc_id);
plane_set_prop(req, plane, IGT_PLANE_FB_ID, plane->fb_id);
plane_set_prop(req, plane, IGT_PLANE_SRC_X, plane->src_x);
@@ -433,6 +441,10 @@ find_plane(struct kms_atomic_state *state, enum
plane_type type,
static void crtc_populate_req(struct kms_atomic_crtc_state *crtc,
  drmModeAtomicReq *req)
{
+if (crtc->out_fence_ptr)
+crtc_set_prop(req, crtc, IGT_CRTC_OUT_FENCE_PTR,
+  crtc->out_fence_ptr);
+
crtc_set_prop(req, crtc, IGT_CRTC_MODE_ID, crtc->mode.id);
crtc_set_prop(req, crtc, IGT_CRTC_ACTIVE, crtc->active);
}
@@ -1061,6 +1073,37 @@ static void plane_invalid_params(struct
kms_atomic_crtc_state *crtc,
drmModeAtomicFree(req);
}

+static void plane_invalid_params_fence(struct kms_atomic_crtc_state
*crtc,
+struct kms_atomic_plane_state *plane_old,
+struct kms_atomic_connector_state *conn)
+{
+struct kms_atomic_plane_state plane = *plane_old;
+drmModeAtomicReq *req = drmModeAtomicAlloc();
+int timeline, fence_fd;
+
+igt_require_sw_sync();
+
+/* invalid fence fd */
+plane.fence_fd = plane.state->desc->fd;
+plane.crtc_id = plane_old->crtc_id;
+plane_commit_atomic_err(, plane_old, req,
+ATOMIC_RELAX_NONE, EINVAL);
+
+/* Valid fence_fd but invalid CRTC */
+timeline = sw_sync_timeline_create();
+fence_fd =  sw_sync_timeline_create_fence(timeline, 1);
+plane.fence_fd = fence_fd;
+plane.crtc_id = ~0U;
+plane_commit_atomic_err(, plane_old, req,
+ATOMIC_RELAX_NONE, EINVAL);
+
+plane.fence_fd = -1;
+close(fence_fd);
+close(timeline);
+
+drmModeAtomicFree(req);
+}
+
static void crtc_invalid_params(struct kms_atomic_crtc_state *crtc_old,
struct kms_atomic_plane_state *plane,
struct kms_atomic_connector_state *conn)
@@ -1072,30 +1115,32 @@ static void crtc_invalid_params(struct
kms_atomic_crtc_state *crtc_old,

/* Pass a series of invalid object IDs for the mode ID. */
crtc.mode.id = plane->obj;
-crtc_commit_atomic_err(, plane, crtc_old, plane, req,
+crtc_commit_atomic_err(, plane, crtc_old, plane, req, 0,
   ATOMIC_RELAX_NONE, EINVAL);

crtc.mode.id = crtc.obj;
-crtc_commit_atomic_err(, plane, crtc_old, plane, req,
+crtc_commit_atomic_err(, plane, crtc_old, plane, req, 0,
   ATOMIC_RELAX_NONE, EINVAL);

crtc.mode.id = conn->obj;
-crtc_commit_atomic_err(, plane, crtc_old, plane, req,
+crtc_commit_atomic_err(, plane, crtc_old, 

Re: [Intel-gfx] [PATCH i-g-t v3 07/11] lib/igt_kms: Add support for the OUT_FENCE_PTR property

2017-01-31 Thread Robert Foss



On 2017-01-31 11:49 AM, Brian Starkey wrote:

On Mon, Jan 30, 2017 at 08:58:43PM -0500, Robert Foss wrote:

From: Gustavo Padovan 

Add support for the OUT_FENCE_PTR property to enable setting out
fences for
atomic commits.

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
---
lib/igt_kms.c | 26 +-
lib/igt_kms.h |  6 +-
2 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index b79d2867..f14496dd 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -179,7 +179,8 @@ const char
*igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
"DEGAMMA_LUT",
"GAMMA_LUT",
"MODE_ID",
-"ACTIVE"
+"ACTIVE",
+"OUT_FENCE_PTR"
};

const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
@@ -2393,6 +2394,15 @@ static void
igt_atomic_prepare_crtc_commit(igt_pipe_t *pipe_obj, drmModeAtomicRe
igt_atomic_populate_crtc_req(req, pipe_obj, IGT_CRTC_ACTIVE,
!!output);
}

+pipe_obj->out_fence = -1;
+if (pipe_obj->out_fence_requested)
+{
+pipe_obj->out_fence_requested = false;
+igt_atomic_populate_crtc_req(req, pipe_obj,
IGT_CRTC_OUT_FENCE_PTR,
+(uint64_t)(uintptr_t) _obj->out_fence);
+igt_assert_f(pipe_obj->out_fence != -1, "Unable to get fence,
received -1 fd\n");


Doesn't this assertion always fail? You just set it to -1


Ack, fixed in v4


+}
+
/*
 *TODO: Add all crtc level properties here
 */
@@ -2984,6 +2994,20 @@ igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void
*ptr, size_t length)
}

/**
+ * igt_pipe_set_out_fence_ptr:
+ * @pipe: pipe pointer to which background color to be set
+ * @fence_ptr: out fence pointer
+ *
+ * Sets the out fence pointer that will be passed to the kernel in
+ * the atomic ioctl. When the kernel returns the out fence pointer
+ * will contain the fd number of the out fence created by KMS.
+ */
+void igt_pipe_set_out_fence_ptr(igt_pipe_t *pipe, int64_t *fence_ptr)
+{
+pipe->out_fence_ptr = fence_ptr;
+}


Is this ever used? You seem to use _obj->out_fence
unconditionally above (and igt_pipe has no member named
out_fence_ptr).

I guess is left over from the previous API and needs to be removed?


That's exactly what happened. Removed in v4.




+
+/**
 * igt_crtc_set_background:
 * @pipe: pipe pointer to which background color to be set
 * @background: background color value in BGR 16bpc
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 85688853..9672dadc 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -94,6 +94,7 @@ enum igt_atomic_crtc_properties {
   IGT_CRTC_GAMMA_LUT,
   IGT_CRTC_MODE_ID,
   IGT_CRTC_ACTIVE,
+   IGT_CRTC_OUT_FENCE_PTR,
   IGT_NUM_CRTC_PROPS
};

@@ -341,6 +342,9 @@ struct igt_pipe {

uint64_t mode_blob;
bool mode_changed;
+
+int64_t out_fence;
+bool out_fence_requested;
};

typedef struct {
@@ -395,7 +399,7 @@ static inline bool
igt_plane_supports_rotation(igt_plane_t *plane)
{
return plane->rotation_property != 0;
}
-
+void igt_pipe_request_out_fence(igt_pipe_t *pipe);


Not implemented? I think this patch got confused somewhere :-(

-Brian


Yes, some code has been moved around and this piece was not properly
moved. Fixed in v4.

Rob.



void igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t
length);
void igt_pipe_set_ctm_matrix(igt_pipe_t *pipe, void *ptr, size_t length);
void igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length);
--
2.11.0.453.g787f75f05


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


[Intel-gfx] ✓ Fi.CI.BAT: success for DisplayPort audio support on Cherrytrail

2017-01-31 Thread Patchwork
== Series Details ==

Series: DisplayPort audio support on Cherrytrail
URL   : https://patchwork.freedesktop.org/series/18864/
State : success

== Summary ==

Series 18864v1 DisplayPort audio support on Cherrytrail
https://patchwork.freedesktop.org/api/1.0/series/18864/revisions/1/mbox/


fi-bdw-5557u total:247  pass:233  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:247  pass:208  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:247  pass:225  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:78   pass:65   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:247  pass:224  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:247  pass:227  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:247  pass:222  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:247  pass:215  dwarn:0   dfail:0   fail:0   skip:32 

83f390eaec64a1b0566f5f747d20741c077fcff5 drm-tip: 2017y-01m-31d-20h-19m-59s UTC 
integration manifest
15954fb drm/i915: Pass platform device to LPE audio notifier
1358641 ALSA: x86: Use config base depending on the pipe
0545a59 ALSA: x86: intel_hdmi: add definitions and logic for DP audio
14efa05 drm/i915: Pass pipe to LPE audio notification
32b5514 drm/i915: Avoid MST pipe handling for LPE audio
82dd01f drm/i915: add DisplayPort amp unmute for LPE audio mode
9bf23c4 drm/i915: add DP support in LPE audio mode

== Logs ==

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


[Intel-gfx] [PATCH 6/7] ALSA: x86: Use config base depending on the pipe

2017-01-31 Thread Takashi Iwai
From: Pierre-Louis Bossart 

Now the pipe that is being used is passed over i915 notification, we
can re-setup the relevant register offset depending on pipe assignments
during hotplug.
This allows playback on single port machines such Zotac Pi330 or
dual-port machines such as Dell Wyse 3040 box

Signed-off-by: Pierre-Louis Bossart 
Signed-off-by: Takashi Iwai 
---
 sound/x86/intel_hdmi_lpe_audio.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/sound/x86/intel_hdmi_lpe_audio.c b/sound/x86/intel_hdmi_lpe_audio.c
index cea05dfc081a..6d630f20bca8 100644
--- a/sound/x86/intel_hdmi_lpe_audio.c
+++ b/sound/x86/intel_hdmi_lpe_audio.c
@@ -463,6 +463,22 @@ static void notify_audio_lpe(void *audio_ptr)
 
} else if (eld != NULL) {
 
+   switch (eld->pipe_id) {
+   case 0:
+   ctx->had_config_offset = AUDIO_HDMI_CONFIG_A;
+   break;
+   case 1:
+   ctx->had_config_offset = AUDIO_HDMI_CONFIG_B;
+   break;
+   case 2:
+   ctx->had_config_offset = AUDIO_HDMI_CONFIG_C;
+   break;
+   default:
+   dev_dbg(_pdev->dev, "Invalid pipe %d\n",
+   eld->pipe_id);
+   break;
+   }
+
hdmi_set_eld(eld->eld_data);
 
mid_hdmi_audio_signal_event(HAD_EVENT_HOT_PLUG);
@@ -560,15 +576,15 @@ static int hdmi_lpe_audio_probe(struct platform_device 
*pdev)
ctx->mmio_start = mmio_start;
ctx->tmds_clock_speed = DIS_SAMPLE_RATE_148_5;
 
-   if (pci_dev_present(cherryview_ids)) {
+   if (pci_dev_present(cherryview_ids))
dev_dbg(_pdev->dev, "%s: Cherrytrail LPE - Detected\n",
__func__);
-   ctx->had_config_offset = AUDIO_HDMI_CONFIG_C;
-   } else {
+   else
dev_dbg(_pdev->dev, "%s: Baytrail LPE - Assume\n",
__func__);
-   ctx->had_config_offset = AUDIO_HDMI_CONFIG_A;
-   }
+
+   /* assume pipe A as default */
+   ctx->had_config_offset = AUDIO_HDMI_CONFIG_A;
 
pdata = pdev->dev.platform_data;
 
-- 
2.11.0

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


[Intel-gfx] [PATCH 2/7] drm/i915: add DisplayPort amp unmute for LPE audio mode

2017-01-31 Thread Takashi Iwai
From: Pierre-Louis Bossart 

Enable unmute/mute amp notification. This doesn't seem to affect
HDMI support so this is done unconditionally.

An earlier version of this patch set a chicken bit at address 0x62F38
prior to the mute/unmute but this register doesn't seem to do anything
so this phase was removed.

Signed-off-by: Pierre-Louis Bossart 
Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/i915/i915_reg.h| 10 ++
 drivers/gpu/drm/i915/intel_lpe_audio.c | 17 +
 2 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a9ffc8df241b..8fcc80cb864b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2061,6 +2061,16 @@ enum skl_disp_power_wells {
 #define I915_HDMI_LPE_AUDIO_BASE   (VLV_DISPLAY_BASE + 0x65000)
 #define I915_HDMI_LPE_AUDIO_SIZE   0x1000
 
+/* DisplayPort Audio w/ LPE */
+#define VLV_AUD_PORT_EN_B_DBG  (VLV_DISPLAY_BASE + 0x62F20)
+#define VLV_AUD_PORT_EN_C_DBG  (VLV_DISPLAY_BASE + 0x62F30)
+#define VLV_AUD_PORT_EN_D_DBG  (VLV_DISPLAY_BASE + 0x62F34)
+#define VLV_AUD_PORT_EN_DBG(port)  _MMIO_PORT3((port) - PORT_B,   \
+   VLV_AUD_PORT_EN_B_DBG, \
+   VLV_AUD_PORT_EN_C_DBG, \
+   VLV_AUD_PORT_EN_D_DBG)
+#define VLV_AMP_MUTE   (1 << 1)
+
 #define GEN6_BSD_RNCID _MMIO(0x12198)
 
 #define GEN7_FF_THREAD_MODE_MMIO(0x20a0)
diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c 
b/drivers/gpu/drm/i915/intel_lpe_audio.c
index 245523e14418..f95624a46f27 100644
--- a/drivers/gpu/drm/i915/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
@@ -337,15 +337,25 @@ void intel_lpe_audio_notify(struct drm_i915_private 
*dev_priv,
 {
unsigned long irq_flags;
struct intel_hdmi_lpe_audio_pdata *pdata = NULL;
+   u32 audio_enable;
+   i915_reg_t mmio;
 
if (!HAS_LPE_AUDIO(dev_priv))
return;
 
+   if (port == PORT_A) {
+   DRM_ERROR("PORT_A is not valid for HDMI/DP usages\n");
+   return;
+   }
+
pdata = dev_get_platdata(
&(dev_priv->lpe_audio.platdev->dev));
 
spin_lock_irqsave(>lpe_audio_slock, irq_flags);
 
+   mmio = VLV_AUD_PORT_EN_DBG(port);
+   audio_enable = I915_READ(mmio);
+
if (eld != NULL) {
memcpy(pdata->eld.eld_data, eld,
HDMI_MAX_ELD_BYTES);
@@ -357,11 +367,18 @@ void intel_lpe_audio_notify(struct drm_i915_private 
*dev_priv,
pdata->tmds_clock_speed = tmds_clk_speed;
if (link_rate)
pdata->link_rate = link_rate;
+
+   /* Unmute the amp for both DP and HDMI */
+   I915_WRITE(mmio, audio_enable & ~VLV_AMP_MUTE);
+
} else {
memset(pdata->eld.eld_data, 0,
HDMI_MAX_ELD_BYTES);
pdata->hdmi_connected = false;
pdata->dp_output = false;
+
+   /* Mute the amp for both DP and HDMI */
+   I915_WRITE(mmio, audio_enable | VLV_AMP_MUTE);
}
 
if (pdata->notify_audio_lpe)
-- 
2.11.0

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


[Intel-gfx] [PATCH 4/7] drm/i915: Pass pipe to LPE audio notification

2017-01-31 Thread Takashi Iwai
The LPE audio configuration depends on the pipe, thus we need to pass
the currently used pipe.  It's now embedded in struct
intel_hdmi_lpe_audio_eld as well as port id.

Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/i915/i915_drv.h| 2 +-
 drivers/gpu/drm/i915/intel_audio.c | 6 +++---
 drivers/gpu/drm/i915/intel_lpe_audio.c | 3 ++-
 include/drm/intel_lpe_audio.h  | 1 +
 4 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 836d823d476b..27311a337e2b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3401,7 +3401,7 @@ int  intel_lpe_audio_init(struct drm_i915_private 
*dev_priv);
 void intel_lpe_audio_teardown(struct drm_i915_private *dev_priv);
 void intel_lpe_audio_irq_handler(struct drm_i915_private *dev_priv);
 void intel_lpe_audio_notify(struct drm_i915_private *dev_priv,
-   void *eld, int port, int tmds_clk_speed,
+   void *eld, int port, int pipe, int tmds_clk_speed,
bool dp_output, int link_rate);
 
 /* intel_i2c.c */
diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index d4e6d1136cfe..892169b7952b 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -634,12 +634,12 @@ void intel_audio_codec_enable(struct intel_encoder 
*intel_encoder,
 
switch (intel_encoder->type) {
case INTEL_OUTPUT_HDMI:
-   intel_lpe_audio_notify(dev_priv, connector->eld, port,
+   intel_lpe_audio_notify(dev_priv, connector->eld, port, pipe,
   crtc_state->port_clock,
   false, 0);
break;
case INTEL_OUTPUT_DP:
-   intel_lpe_audio_notify(dev_priv, connector->eld, port,
+   intel_lpe_audio_notify(dev_priv, connector->eld, port, pipe,
   adjusted_mode->crtc_clock,
   true, crtc_state->port_clock);
break;
@@ -680,7 +680,7 @@ void intel_audio_codec_disable(struct intel_encoder 
*intel_encoder)
 (int) port, (int) pipe);
}
 
-   intel_lpe_audio_notify(dev_priv, NULL, port, 0, false, 0);
+   intel_lpe_audio_notify(dev_priv, NULL, port, pipe, 0, false, 0);
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c 
b/drivers/gpu/drm/i915/intel_lpe_audio.c
index f95624a46f27..2ca3c775c6b1 100644
--- a/drivers/gpu/drm/i915/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
@@ -332,7 +332,7 @@ void intel_lpe_audio_teardown(struct drm_i915_private 
*dev_priv)
  * Notify lpe audio driver of eld change.
  */
 void intel_lpe_audio_notify(struct drm_i915_private *dev_priv,
-   void *eld, int port, int tmds_clk_speed,
+   void *eld, int port, int pipe, int tmds_clk_speed,
bool dp_output, int link_rate)
 {
unsigned long irq_flags;
@@ -360,6 +360,7 @@ void intel_lpe_audio_notify(struct drm_i915_private 
*dev_priv,
memcpy(pdata->eld.eld_data, eld,
HDMI_MAX_ELD_BYTES);
pdata->eld.port_id = port;
+   pdata->eld.pipe_id = pipe;
pdata->hdmi_connected = true;
 
pdata->dp_output = dp_output;
diff --git a/include/drm/intel_lpe_audio.h b/include/drm/intel_lpe_audio.h
index 857e0eafed79..410128e4cd70 100644
--- a/include/drm/intel_lpe_audio.h
+++ b/include/drm/intel_lpe_audio.h
@@ -31,6 +31,7 @@
 
 struct intel_hdmi_lpe_audio_eld {
int port_id;
+   int pipe_id;
unsigned char eld_data[HDMI_MAX_ELD_BYTES];
 };
 
-- 
2.11.0

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


[Intel-gfx] [PATCH 5/7] ALSA: x86: intel_hdmi: add definitions and logic for DP audio

2017-01-31 Thread Takashi Iwai
From: Pierre-Louis Bossart 

Imported from legacy patches

Note: the new code doesn't assume a modified ELD but
an explicit notification that DP is present. It appears
that the i915 code does change the ELD so we could use
the ELD-based tests to check for DP audio

Signed-off-by: Pierre-Louis Bossart 
Signed-off-by: Takashi Iwai 
---
 sound/x86/intel_hdmi_audio.c | 173 +--
 sound/x86/intel_hdmi_audio.h |   8 +-
 sound/x86/intel_hdmi_lpe_audio.c |  36 +++-
 sound/x86/intel_hdmi_lpe_audio.h |  29 +++
 4 files changed, 216 insertions(+), 30 deletions(-)

diff --git a/sound/x86/intel_hdmi_audio.c b/sound/x86/intel_hdmi_audio.c
index f30155446117..5ce139c1b21d 100644
--- a/sound/x86/intel_hdmi_audio.c
+++ b/sound/x86/intel_hdmi_audio.c
@@ -396,6 +396,7 @@ static int snd_intelhad_prog_audio_ctrl_v2(struct 
snd_pcm_substream *substream,
else
cfg_val.cfg_regx_v2.layout = LAYOUT1;
 
+   cfg_val.cfg_regx_v2.val_bit = 1;
had_write_register(AUD_CONFIG, cfg_val.cfg_regval);
return 0;
 }
@@ -447,6 +448,7 @@ static int snd_intelhad_prog_audio_ctrl_v1(struct 
snd_pcm_substream *substream,
 
}
 
+   cfg_val.cfg_regx.val_bit = 1;
had_write_register(AUD_CONFIG, cfg_val.cfg_regval);
return 0;
 }
@@ -548,6 +550,7 @@ void had_build_channel_allocation_map(struct snd_intelhad 
*intelhaddata)
}
 
had_get_caps(HAD_GET_ELD, >eeld);
+   had_get_caps(HAD_GET_DP_OUTPUT, >dp_output);
 
pr_debug("eeld.speaker_allocation_block = %x\n",
intelhaddata->eeld.speaker_allocation_block);
@@ -685,7 +688,7 @@ static void snd_intelhad_prog_dip_v1(struct 
snd_pcm_substream *substream,
 
/*Calculte the byte wide checksum for all valid DIP words*/
for (i = 0; i < BYTES_PER_WORD; i++)
-   checksum += (INFO_FRAME_WORD1 >> i*BITS_PER_BYTE) & MASK_BYTE0;
+   checksum += (HDMI_INFO_FRAME_WORD1 >> i*BITS_PER_BYTE) & 
MASK_BYTE0;
for (i = 0; i < BYTES_PER_WORD; i++)
checksum += (frame2.fr2_val >> i*BITS_PER_BYTE) & MASK_BYTE0;
for (i = 0; i < BYTES_PER_WORD; i++)
@@ -693,7 +696,7 @@ static void snd_intelhad_prog_dip_v1(struct 
snd_pcm_substream *substream,
 
frame2.fr2_regx.chksum = -(checksum);
 
-   had_write_register(AUD_HDMIW_INFOFR, INFO_FRAME_WORD1);
+   had_write_register(AUD_HDMIW_INFOFR, HDMI_INFO_FRAME_WORD1);
had_write_register(AUD_HDMIW_INFOFR, frame2.fr2_val);
had_write_register(AUD_HDMIW_INFOFR, frame3.fr3_val);
 
@@ -722,28 +725,35 @@ static void snd_intelhad_prog_dip_v2(struct 
snd_pcm_substream *substream,
union aud_info_frame2 frame2 = {.fr2_val = 0};
union aud_info_frame3 frame3 = {.fr3_val = 0};
u8 checksum = 0;
+   u32 info_frame;
int channels;
 
channels = substream->runtime->channels;
 
had_write_register(AUD_CNTL_ST, ctrl_state.ctrl_val);
 
-   frame2.fr2_regx.chnl_cnt = substream->runtime->channels - 1;
+   if (intelhaddata->dp_output) {
+   info_frame = DP_INFO_FRAME_WORD1;
+   frame2.fr2_val = 1;
+   } else {
+   info_frame = HDMI_INFO_FRAME_WORD1;
+   frame2.fr2_regx.chnl_cnt = substream->runtime->channels - 1;
 
-   frame3.fr3_regx.chnl_alloc = snd_intelhad_channel_allocation(
-   intelhaddata, channels);
+   frame3.fr3_regx.chnl_alloc = snd_intelhad_channel_allocation(
+   intelhaddata, channels);
 
-   /*Calculte the byte wide checksum for all valid DIP words*/
-   for (i = 0; i < BYTES_PER_WORD; i++)
-   checksum += (INFO_FRAME_WORD1 >> i*BITS_PER_BYTE) & MASK_BYTE0;
-   for (i = 0; i < BYTES_PER_WORD; i++)
-   checksum += (frame2.fr2_val >> i*BITS_PER_BYTE) & MASK_BYTE0;
-   for (i = 0; i < BYTES_PER_WORD; i++)
-   checksum += (frame3.fr3_val >> i*BITS_PER_BYTE) & MASK_BYTE0;
+   /*Calculte the byte wide checksum for all valid DIP words*/
+   for (i = 0; i < BYTES_PER_WORD; i++)
+   checksum += (info_frame >> i*BITS_PER_BYTE) & 
MASK_BYTE0;
+   for (i = 0; i < BYTES_PER_WORD; i++)
+   checksum += (frame2.fr2_val >> i*BITS_PER_BYTE) & 
MASK_BYTE0;
+   for (i = 0; i < BYTES_PER_WORD; i++)
+   checksum += (frame3.fr3_val >> i*BITS_PER_BYTE) & 
MASK_BYTE0;
 
-   frame2.fr2_regx.chksum = -(checksum);
+   frame2.fr2_regx.chksum = -(checksum);
+   }
 
-   had_write_register(AUD_HDMIW_INFOFR_v2, INFO_FRAME_WORD1);
+   had_write_register(AUD_HDMIW_INFOFR_v2, info_frame);
had_write_register(AUD_HDMIW_INFOFR_v2, frame2.fr2_val);
had_write_register(AUD_HDMIW_INFOFR_v2, frame3.fr3_val);
 
@@ 

[Intel-gfx] [PATCH 3/7] drm/i915: Avoid MST pipe handling for LPE audio

2017-01-31 Thread Takashi Iwai
The pipe gets cleared to -1 for non-MST before the ELD audio
notification due to the MST audio support.  This makes sense for
HD-audio that received the MST handling, but it's useless for LPE
audio.  Handle the MST pipe hack conditionally only for HD-audio.

Reported-by: Pierre-Louis Bossart 
Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/i915/intel_audio.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index 1645ce42b898..d4e6d1136cfe 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -624,13 +624,14 @@ void intel_audio_codec_enable(struct intel_encoder 
*intel_encoder,
dev_priv->av_enc_map[pipe] = intel_encoder;
mutex_unlock(_priv->av_mutex);
 
-   /* audio drivers expect pipe = -1 to indicate Non-MST cases */
-   if (intel_encoder->type != INTEL_OUTPUT_DP_MST)
-   pipe = -1;
-
-   if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
+   if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) {
+   /* audio drivers expect pipe = -1 to indicate Non-MST cases */
+   if (intel_encoder->type != INTEL_OUTPUT_DP_MST)
+   pipe = -1;
acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
 (int) port, (int) pipe);
+   }
+
switch (intel_encoder->type) {
case INTEL_OUTPUT_HDMI:
intel_lpe_audio_notify(dev_priv, connector->eld, port,
@@ -671,13 +672,13 @@ void intel_audio_codec_disable(struct intel_encoder 
*intel_encoder)
dev_priv->av_enc_map[pipe] = NULL;
mutex_unlock(_priv->av_mutex);
 
-   /* audio drivers expect pipe = -1 to indicate Non-MST cases */
-   if (intel_encoder->type != INTEL_OUTPUT_DP_MST)
-   pipe = -1;
-
-   if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
+   if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) {
+   /* audio drivers expect pipe = -1 to indicate Non-MST cases */
+   if (intel_encoder->type != INTEL_OUTPUT_DP_MST)
+   pipe = -1;
acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
 (int) port, (int) pipe);
+   }
 
intel_lpe_audio_notify(dev_priv, NULL, port, 0, false, 0);
 }
-- 
2.11.0

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


[Intel-gfx] [PATCH 7/7] drm/i915: Pass platform device to LPE audio notifier

2017-01-31 Thread Takashi Iwai
This allows the LPE HDMI driver to clean up its global variable
reference.

Also drop to pass the eld pointer because the connection status and
the ELD bytes can be retrieved from the attached pdata.

Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/i915/intel_lpe_audio.c |  3 +--
 include/drm/intel_lpe_audio.h  |  4 +++-
 sound/x86/intel_hdmi_lpe_audio.c   | 23 +++
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c 
b/drivers/gpu/drm/i915/intel_lpe_audio.c
index 2ca3c775c6b1..ef0e74830289 100644
--- a/drivers/gpu/drm/i915/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
@@ -383,8 +383,7 @@ void intel_lpe_audio_notify(struct drm_i915_private 
*dev_priv,
}
 
if (pdata->notify_audio_lpe)
-   pdata->notify_audio_lpe(
-   (eld != NULL) ? >eld : NULL);
+   pdata->notify_audio_lpe(dev_priv->lpe_audio.platdev);
else
pdata->notify_pending = true;
 
diff --git a/include/drm/intel_lpe_audio.h b/include/drm/intel_lpe_audio.h
index 410128e4cd70..e9892b4c3af1 100644
--- a/include/drm/intel_lpe_audio.h
+++ b/include/drm/intel_lpe_audio.h
@@ -27,6 +27,8 @@
 #include 
 #include 
 
+struct platform_device;
+
 #define HDMI_MAX_ELD_BYTES 128
 
 struct intel_hdmi_lpe_audio_eld {
@@ -42,7 +44,7 @@ struct intel_hdmi_lpe_audio_pdata {
bool dp_output;
int link_rate;
struct intel_hdmi_lpe_audio_eld eld;
-   void (*notify_audio_lpe)(void *audio_ptr);
+   void (*notify_audio_lpe)(struct platform_device *pdev);
spinlock_t lpe_audio_slock;
 };
 
diff --git a/sound/x86/intel_hdmi_lpe_audio.c b/sound/x86/intel_hdmi_lpe_audio.c
index 6d630f20bca8..3cb0f642575c 100644
--- a/sound/x86/intel_hdmi_lpe_audio.c
+++ b/sound/x86/intel_hdmi_lpe_audio.c
@@ -439,15 +439,14 @@ static irqreturn_t display_pipe_interrupt_handler(int 
irq, void *dev_id)
return IRQ_HANDLED;
 }
 
-static void notify_audio_lpe(void *audio_ptr)
+static void notify_audio_lpe(struct platform_device *pdev)
 {
-   struct hdmi_lpe_audio_ctx *ctx = get_hdmi_context();
-   struct intel_hdmi_lpe_audio_pdata *pdata = hlpe_pdev->dev.platform_data;
-   struct intel_hdmi_lpe_audio_eld *eld = audio_ptr;
+   struct hdmi_lpe_audio_ctx *ctx = platform_get_drvdata(pdev);
+   struct intel_hdmi_lpe_audio_pdata *pdata = pdev->dev.platform_data;
 
if (pdata->hdmi_connected != true) {
 
-   dev_dbg(_pdev->dev, "%s: Event: HAD_NOTIFY_HOT_UNPLUG\n",
+   dev_dbg(>dev, "%s: Event: HAD_NOTIFY_HOT_UNPLUG\n",
__func__);
 
if (hlpe_state == hdmi_connector_status_connected) {
@@ -458,10 +457,11 @@ static void notify_audio_lpe(void *audio_ptr)
mid_hdmi_audio_signal_event(
HAD_EVENT_HOT_UNPLUG);
} else
-   dev_dbg(_pdev->dev, "%s: Already Unplugged!\n",
+   dev_dbg(>dev, "%s: Already Unplugged!\n",
__func__);
 
-   } else if (eld != NULL) {
+   } else {
+   struct intel_hdmi_lpe_audio_eld *eld = >eld;
 
switch (eld->pipe_id) {
case 0:
@@ -474,7 +474,7 @@ static void notify_audio_lpe(void *audio_ptr)
ctx->had_config_offset = AUDIO_HDMI_CONFIG_C;
break;
default:
-   dev_dbg(_pdev->dev, "Invalid pipe %d\n",
+   dev_dbg(>dev, "Invalid pipe %d\n",
eld->pipe_id);
break;
}
@@ -485,7 +485,7 @@ static void notify_audio_lpe(void *audio_ptr)
 
hlpe_state = hdmi_connector_status_connected;
 
-   dev_dbg(_pdev->dev, "%s: HAD_NOTIFY_ELD : port = %d, tmds 
= %d\n",
+   dev_dbg(>dev, "%s: HAD_NOTIFY_ELD : port = %d, tmds = 
%d\n",
__func__, eld->port_id, pdata->tmds_clock_speed);
 
if (pdata->tmds_clock_speed) {
@@ -494,8 +494,7 @@ static void notify_audio_lpe(void *audio_ptr)
ctx->link_rate = pdata->link_rate;
mid_hdmi_audio_signal_event(HAD_EVENT_MODE_CHANGING);
}
-   } else
-   dev_dbg(_pdev->dev, "%s: Event: NULL EDID!!\n", __func__);
+   }
 }
 
 /**
@@ -606,7 +605,7 @@ static int hdmi_lpe_audio_probe(struct platform_device 
*pdev)
if (pdata->notify_pending) {
 
dev_dbg(_pdev->dev, "%s: handle pending notification\n", 
__func__);
-   notify_audio_lpe(>eld);
+   notify_audio_lpe(pdev);
pdata->notify_pending = false;
}
spin_unlock_irqrestore(>lpe_audio_slock, flag_irq);
-- 
2.11.0

___
Intel-gfx mailing list

[Intel-gfx] [PATCH 1/7] drm/i915: add DP support in LPE audio mode

2017-01-31 Thread Takashi Iwai
From: Pierre-Louis Bossart 

If DisplayPort is detected, pass flag and link rate to audio driver

Signed-off-by: Pierre-Louis Bossart 
Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/i915/i915_drv.h|  3 ++-
 drivers/gpu/drm/i915/intel_audio.c | 19 +++
 drivers/gpu/drm/i915/intel_lpe_audio.c |  7 ++-
 include/drm/intel_lpe_audio.h  |  2 ++
 4 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3e3102cedc82..836d823d476b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3401,7 +3401,8 @@ int  intel_lpe_audio_init(struct drm_i915_private 
*dev_priv);
 void intel_lpe_audio_teardown(struct drm_i915_private *dev_priv);
 void intel_lpe_audio_irq_handler(struct drm_i915_private *dev_priv);
 void intel_lpe_audio_notify(struct drm_i915_private *dev_priv,
-   void *eld, int port, int tmds_clk_speed);
+   void *eld, int port, int tmds_clk_speed,
+   bool dp_output, int link_rate);
 
 /* intel_i2c.c */
 extern int intel_setup_gmbus(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index 364f96207c40..1645ce42b898 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -631,9 +631,20 @@ void intel_audio_codec_enable(struct intel_encoder 
*intel_encoder,
if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
 (int) port, (int) pipe);
-
-   intel_lpe_audio_notify(dev_priv, connector->eld, port,
-   crtc_state->port_clock);
+   switch (intel_encoder->type) {
+   case INTEL_OUTPUT_HDMI:
+   intel_lpe_audio_notify(dev_priv, connector->eld, port,
+  crtc_state->port_clock,
+  false, 0);
+   break;
+   case INTEL_OUTPUT_DP:
+   intel_lpe_audio_notify(dev_priv, connector->eld, port,
+  adjusted_mode->crtc_clock,
+  true, crtc_state->port_clock);
+   break;
+   default:
+   break;
+   }
 }
 
 /**
@@ -668,7 +679,7 @@ void intel_audio_codec_disable(struct intel_encoder 
*intel_encoder)
acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
 (int) port, (int) pipe);
 
-   intel_lpe_audio_notify(dev_priv, NULL, port, 0);
+   intel_lpe_audio_notify(dev_priv, NULL, port, 0, false, 0);
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c 
b/drivers/gpu/drm/i915/intel_lpe_audio.c
index 27d94255872d..245523e14418 100644
--- a/drivers/gpu/drm/i915/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
@@ -332,7 +332,8 @@ void intel_lpe_audio_teardown(struct drm_i915_private 
*dev_priv)
  * Notify lpe audio driver of eld change.
  */
 void intel_lpe_audio_notify(struct drm_i915_private *dev_priv,
-   void *eld, int port, int tmds_clk_speed)
+   void *eld, int port, int tmds_clk_speed,
+   bool dp_output, int link_rate)
 {
unsigned long irq_flags;
struct intel_hdmi_lpe_audio_pdata *pdata = NULL;
@@ -351,12 +352,16 @@ void intel_lpe_audio_notify(struct drm_i915_private 
*dev_priv,
pdata->eld.port_id = port;
pdata->hdmi_connected = true;
 
+   pdata->dp_output = dp_output;
if (tmds_clk_speed)
pdata->tmds_clock_speed = tmds_clk_speed;
+   if (link_rate)
+   pdata->link_rate = link_rate;
} else {
memset(pdata->eld.eld_data, 0,
HDMI_MAX_ELD_BYTES);
pdata->hdmi_connected = false;
+   pdata->dp_output = false;
}
 
if (pdata->notify_audio_lpe)
diff --git a/include/drm/intel_lpe_audio.h b/include/drm/intel_lpe_audio.h
index 952de05a9d76..857e0eafed79 100644
--- a/include/drm/intel_lpe_audio.h
+++ b/include/drm/intel_lpe_audio.h
@@ -38,6 +38,8 @@ struct intel_hdmi_lpe_audio_pdata {
bool notify_pending;
int tmds_clock_speed;
bool hdmi_connected;
+   bool dp_output;
+   int link_rate;
struct intel_hdmi_lpe_audio_eld eld;
void (*notify_audio_lpe)(void *audio_ptr);
spinlock_t lpe_audio_slock;
-- 
2.11.0

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


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

2017-01-31 Thread Takashi Iwai
Hi,

the following patches enable DisplayPort Audio on Cherrytrail machines
when applied on top of my topic/intel-lpe-audio branch.  Tests of DP
audio were run on Dell Wyse 3040.  The regression test were performed
on Baytrail (Compute Stick) and Cherrytrail (Zotac PI330) in HDMI
mode.  On Cherrytrail there were no issues changing between HDMI and
DP connectors dynamically.

Could you i915 people review and give ACK if they are OK?
The changes in drm/i915 side are fairly trivial, so I'd like to take
them through sound git tree once after I receive your ACKs.


Changes since RFC:
 - reordered and squashed patches
 - clean-up of register definitions and offsets (based on feedback from
   Jani/Ville)
 - unmute amp for both HDMI and DP unconditionally
 - mute amp on invalid ELD (unplug)
 - remove test for chicken bit which seems to have no effect in hardware
 - cosmetic edits to make checkpatch happy
 - change i915 notification argument to pass the plataform device
   instead


Most of hard work in this patchset has been done by Pierre, so all
credits go to him.


thanks,

Takashi

===

Pierre-Louis Bossart (4):
  drm/i915: add DP support in LPE audio mode
  drm/i915: add DisplayPort amp unmute for LPE audio mode
  ALSA: x86: intel_hdmi: add definitions and logic for DP audio
  ALSA: x86: Use config base depending on the pipe

Takashi Iwai (3):
  drm/i915: Avoid MST pipe handling for LPE audio
  drm/i915: Pass pipe to LPE audio notification
  drm/i915: Pass platform device to LPE audio notifier

 drivers/gpu/drm/i915/i915_drv.h|   3 +-
 drivers/gpu/drm/i915/i915_reg.h|  10 ++
 drivers/gpu/drm/i915/intel_audio.c |  38 +---
 drivers/gpu/drm/i915/intel_lpe_audio.c |  28 +-
 include/drm/intel_lpe_audio.h  |   7 +-
 sound/x86/intel_hdmi_audio.c   | 173 -
 sound/x86/intel_hdmi_audio.h   |   8 +-
 sound/x86/intel_hdmi_lpe_audio.c   |  83 
 sound/x86/intel_hdmi_lpe_audio.h   |  29 ++
 9 files changed, 315 insertions(+), 64 deletions(-)

-- 
2.11.0

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


Re: [Intel-gfx] [PATCH 0/2] drm/i915: Backport vma fixes for 4.10-rc6

2017-01-31 Thread Daniel Vetter
On Tue, Jan 31, 2017 at 12:28:40PM -0800, Linus Torvalds wrote:
> On Tue, Jan 31, 2017 at 1:21 AM, Maarten Lankhorst
>  wrote:
> >
> > This is marked for rc6 because it seems the issue is triggerable on
> > mainline and resulting in an oops.
> 
> So I did apply my obvious "avoid the oops and just warn about it"
> patch: commit 39cb2c9a316e ("drm/i915: Check for NULL i915_vma in
> intel_unpin_fb_obj()").
> 
> I haven't actually triggered the problem since, so I don't know if
> there might be some other downstream issue, but the workaround *may*
> just be acceptable from a 4.10 standpoint.

You need sufficient memory pressure to start using partial views, and then
kill the X server while it's using that partial view still (i.e. not too
much memory pressure to prevent them from getting evicted). And it's
global gttt pressure, so not much do to with what's going on on your
machine. So hard to hit, but when you do the book-keeping is rather
completely wreaked since we throw away the views while they're still in
use.

> Some maintainer who knows the code better should make the judgment call.

It's a lot less scary than what I thought:
- the cherry picks needed are a lot less than what I feared, a lot of the
  prep work landed in 4.10 and a bunch of it in patches in linux-next
  aren't needed for 4.10 due to other reasons.
- we have a testcase to repro this instantly. It uses rotation instead of
  partial views (which depend upon allocation order to hit the bug,
  rotation is deterministic), but the same code blows up for the same
  reasons because it's a bug in the view code, not with a specific view.

The only thing that's mildly scary is that we need a drm core patch to
make it happen. But that one has been for a while in linux-next too, so
should be acceptable. Only thing left to do is let CI beat on this
specifically for a bit, so pull request should be ready for -rc7 I hope.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 0/2] drm/i915: Backport vma fixes for 4.10-rc6

2017-01-31 Thread Linus Torvalds
On Tue, Jan 31, 2017 at 1:21 AM, Maarten Lankhorst
 wrote:
>
> This is marked for rc6 because it seems the issue is triggerable on
> mainline and resulting in an oops.

So I did apply my obvious "avoid the oops and just warn about it"
patch: commit 39cb2c9a316e ("drm/i915: Check for NULL i915_vma in
intel_unpin_fb_obj()").

I haven't actually triggered the problem since, so I don't know if
there might be some other downstream issue, but the workaround *may*
just be acceptable from a 4.10 standpoint.

Some maintainer who knows the code better should make the judgment call.

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


Re: [Intel-gfx] [PATCH] drm-misc: Document small drivers expectations

2017-01-31 Thread Daniel Vetter
On Tue, Jan 31, 2017 at 02:31:32PM -0500, Sean Paul wrote:
> On Tue, Jan 31, 2017 at 07:01:44PM +0100, Daniel Vetter wrote:
> > For the experiement we have right now Eric (with vc4) and Sean Paul
> > (with rockchip and zte) volunteering, and Gerd (entire pile of qemu
> > drivers) and Boris (atmel) are also considering to participate. I
> > think that's enough to get started and figure things out as we go.
> > 
> > I tried to summarize the main points from the rfc discussions into a
> > short chapter.
> 
> Did we decide on whether we're using a topic branch to start out? Also, are 
> you
> on the hook for pull requests?

Hm, I guess that was too implicit. The idea is that anything small goes
directly into drm-misc-next, and only really huge stuff (I've picked an
arbitrary limit of 20+ patches) goes into a topic branch. That's
definitely something we need to refine as we go I think. But for one-off
patches I think the common tree is really a benefit, since no coordination
between subsytem wide refactoring and driver patches is needed through
pull requests.

And yes since it's the same tree I'm volunteering for pull requests. dim
status tells me when there's something pending (I wrote that a bit ago as
prep to make drm-misc easy for me).
-Daniel

> 
> Sean
> 
> > 
> > v2: Spelling fixes (Anholt).
> > 
> > Cc: Boris Brezillon 
> > Cc: Eric Anholt 
> > Cc: Sean Paul 
> > Cc: Gerd Hoffmann 
> > Cc: Mark Yao 
> > Cc: Shawn Guo 
> > Acked-by: Sean Paul 
> > Acked-by: Gerd Hoffmann 
> > Acked-by: Boris Brezillon 
> > Acked-by: Eric Anholt 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drm-misc.rst | 30 ++
> >  1 file changed, 30 insertions(+)
> > 
> > diff --git a/drm-misc.rst b/drm-misc.rst
> > index 3d711ec60047..7f7233cf3c61 100644
> > --- a/drm-misc.rst
> > +++ b/drm-misc.rst
> > @@ -93,6 +93,36 @@ Right now the only hard merge criteria are:
> >  * See also the extensive `committer guidelines for drm-intel
> >`_.
> >  
> > +Small Drivers
> > +=
> > +
> > +Small drivers, where a full tree is overkill, can be maintained in 
> > drm-misc. For
> > +now it's just an experiment with a few drivers to figure out a working 
> > process.
> > +Slightly different rules apply:
> > +
> > +* Small is measured in patches merged per kernel release. The occasional 
> > big
> > +  patch series is still acceptable if it's not a common thing (e.g. new hw
> > +  enabling once a year), and if the series is really big (more than 20 
> > patches)
> > +  it should probably be managed through a topic branch in drm-misc and 
> > with a
> > +  separate pull request to drm maintainer. dim_ supports this with the
> > +  create-branch command.
> > +
> > +* Group maintainership is assumed, i.e. all regular contributors (not just
> > +  the primary maintainer) will get commit rights.
> > +
> > +* Since even a broken driver is more useful than no driver minimal review
> > +  standards are a lot lower. The default should be some notes about what 
> > could
> > +  be improved in follow-up work and accepting patches by default. 
> > Maintainer
> > +  group for drivers can agree on stricter rules, especially when they have 
> > a
> > +  bigger user base that shouldn't suffer from regressions.
> > +
> > +* Minimal peer-review is also expected for drivers with just one 
> > contributor,
> > +  but obviously then only focuses on best practices for the interaction 
> > with drm
> > +  core and helpers. Plus a bit looking for common patterns in dealing with 
> > the
> > +  hardware, since display IP all has to handle the same issues in the end. 
> > In
> > +  most cases this will just along the lines of "Looks good, Ack".  drm-misc
> > +  maintainers will help out with getting that review market going.
> > +
> >  Tooling
> >  ===
> >  
> > -- 
> > 2.11.0
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

-- 
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-misc: Document small drivers expectations

2017-01-31 Thread Sean Paul
On Tue, Jan 31, 2017 at 07:01:44PM +0100, Daniel Vetter wrote:
> For the experiement we have right now Eric (with vc4) and Sean Paul
> (with rockchip and zte) volunteering, and Gerd (entire pile of qemu
> drivers) and Boris (atmel) are also considering to participate. I
> think that's enough to get started and figure things out as we go.
> 
> I tried to summarize the main points from the rfc discussions into a
> short chapter.

Did we decide on whether we're using a topic branch to start out? Also, are you
on the hook for pull requests?

Sean

> 
> v2: Spelling fixes (Anholt).
> 
> Cc: Boris Brezillon 
> Cc: Eric Anholt 
> Cc: Sean Paul 
> Cc: Gerd Hoffmann 
> Cc: Mark Yao 
> Cc: Shawn Guo 
> Acked-by: Sean Paul 
> Acked-by: Gerd Hoffmann 
> Acked-by: Boris Brezillon 
> Acked-by: Eric Anholt 
> Signed-off-by: Daniel Vetter 
> ---
>  drm-misc.rst | 30 ++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/drm-misc.rst b/drm-misc.rst
> index 3d711ec60047..7f7233cf3c61 100644
> --- a/drm-misc.rst
> +++ b/drm-misc.rst
> @@ -93,6 +93,36 @@ Right now the only hard merge criteria are:
>  * See also the extensive `committer guidelines for drm-intel
>`_.
>  
> +Small Drivers
> +=
> +
> +Small drivers, where a full tree is overkill, can be maintained in drm-misc. 
> For
> +now it's just an experiment with a few drivers to figure out a working 
> process.
> +Slightly different rules apply:
> +
> +* Small is measured in patches merged per kernel release. The occasional big
> +  patch series is still acceptable if it's not a common thing (e.g. new hw
> +  enabling once a year), and if the series is really big (more than 20 
> patches)
> +  it should probably be managed through a topic branch in drm-misc and with a
> +  separate pull request to drm maintainer. dim_ supports this with the
> +  create-branch command.
> +
> +* Group maintainership is assumed, i.e. all regular contributors (not just
> +  the primary maintainer) will get commit rights.
> +
> +* Since even a broken driver is more useful than no driver minimal review
> +  standards are a lot lower. The default should be some notes about what 
> could
> +  be improved in follow-up work and accepting patches by default. Maintainer
> +  group for drivers can agree on stricter rules, especially when they have a
> +  bigger user base that shouldn't suffer from regressions.
> +
> +* Minimal peer-review is also expected for drivers with just one contributor,
> +  but obviously then only focuses on best practices for the interaction with 
> drm
> +  core and helpers. Plus a bit looking for common patterns in dealing with 
> the
> +  hardware, since display IP all has to handle the same issues in the end. In
> +  most cases this will just along the lines of "Looks good, Ack".  drm-misc
> +  maintainers will help out with getting that review market going.
> +
>  Tooling
>  ===
>  
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH RFC] drm/i915: reduce cursor size for GEN5 hardware

2017-01-31 Thread Uwe Kleine-König
Hello,

On Tue, Jan 31, 2017 at 10:03:26AM +0100, Maarten Lankhorst wrote:
> Op 31-01-17 om 09:09 schreef Uwe Kleine-König:
> > From: Chris Wilson 
> >
> > As the introduced comment admits this is clearly a workaround, but for
> > me this is the only known way to make my Lenovo X201 work without
> > flickering and crashing.
> >
> > Signed-off-by: Uwe Kleine-König 
> > [uwe: added changelog, comment and restrict to GEN5]
> > ---
> > Hello,
> >
> > as I don't like having to compile my own kernel (which has this workaround) 
> > I
> > suggest to apply this patch until someone with more knowledge than me about
> > i915 finds the muse and time to work on this.
>
> Just curious, does this help?
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index ae2c0bb4b2e8..13de4c526ca6 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -1838,7 +1838,7 @@ static uint32_t ilk_compute_cur_wm(const struct 
> intel_crtc_state *cstate,
>* this is necessary to avoid flickering.
>*/
>   int cpp = 4;
> - int width = pstate->base.visible ? pstate->base.crtc_w : 64;
> + int width = 256;
>  
>   if (!cstate->base.active)
>   return 0;
> 

On a kernel with this patch applied I cannot reproduce the flickering. I
keep that kernel running but expect that it also fixes the crash.

Best regards
Uwe


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


Re: [Intel-gfx] [PATCH 3/3] drm/i915/gen9: WM memory bandwidth related workaround

2017-01-31 Thread kbuild test robot
Hi Mahesh,

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

url:
https://github.com/0day-ci/linux/commits/Mahesh-Kumar/Enable-IPC-WM-related-WA-s/20170131-230708
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from arch/x86/include/asm/string.h:2:0,
from include/linux/string.h:18,
from arch/x86/include/asm/page_32.h:34,
from arch/x86/include/asm/page.h:13,
from arch/x86/include/asm/processor.h:17,
from include/linux/mutex.h:19,
from include/linux/notifier.h:13,
from include/linux/clk.h:17,
from include/linux/cpufreq.h:14,
from drivers/gpu/drm/i915/intel_pm.c:28:
   drivers/gpu/drm/i915/intel_pm.c: In function 
'skl_compute_memory_bandwidth_wm_wa':
>> drivers/gpu/drm/i915/intel_pm.c:4118:56: warning: argument to 'sizeof' in 
>> '__builtin_memcpy' call is the same expression as the destination; did you 
>> mean to dereference it? [-Wsizeof-pointer-memaccess]
 memcpy(mem_attr, _priv->wm.skl_hw.mem_attr, sizeof(mem_attr));
   ^
   arch/x86/include/asm/string_32.h:182:48: note: in definition of macro 
'memcpy'
#define memcpy(t, f, n) __builtin_memcpy(t, f, n)
   ^

vim +4118 drivers/gpu/drm/i915/intel_pm.c

  4102  mem_attr->mem_wa = WATERMARK_WA_NONE;
  4103  return 0;
  4104  }
  4105  
  4106  if (!memdev_info->valid)
  4107  goto exit;
  4108  
  4109  /*
  4110   * We hold wm_mutex lock, so any other flip can't proceed 
beyond WM
  4111   * calculation step until this flip writes modified WM values.
  4112   * So it's safe to read plane_state of other pipes without 
taking CRTC lock
  4113   */
  4114  ret = drm_modeset_lock(_priv->wm.wm_ww_mutex, 
state->acquire_ctx);
  4115  if (ret)
  4116  return ret;
  4117  
> 4118  memcpy(mem_attr, _priv->wm.skl_hw.mem_attr, 
> sizeof(mem_attr));
  4119  
  4120  for_each_crtc_in_state(state, crtc, cstate, i) {
  4121  struct drm_plane *plane;
  4122  const struct drm_plane_state *pstate;
  4123  int active_planes = 0;
  4124  uint32_t max_plane_bw_kbps = 0;
  4125  
  4126  mem_attr->pipe_y_tiled[i] = false;

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


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


[Intel-gfx] [PATCH] drm-misc: Document small drivers expectations

2017-01-31 Thread Daniel Vetter
For the experiement we have right now Eric (with vc4) and Sean Paul
(with rockchip and zte) volunteering, and Gerd (entire pile of qemu
drivers) and Boris (atmel) are also considering to participate. I
think that's enough to get started and figure things out as we go.

I tried to summarize the main points from the rfc discussions into a
short chapter.

v2: Spelling fixes (Anholt).

Cc: Boris Brezillon 
Cc: Eric Anholt 
Cc: Sean Paul 
Cc: Gerd Hoffmann 
Cc: Mark Yao 
Cc: Shawn Guo 
Acked-by: Sean Paul 
Acked-by: Gerd Hoffmann 
Acked-by: Boris Brezillon 
Acked-by: Eric Anholt 
Signed-off-by: Daniel Vetter 
---
 drm-misc.rst | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drm-misc.rst b/drm-misc.rst
index 3d711ec60047..7f7233cf3c61 100644
--- a/drm-misc.rst
+++ b/drm-misc.rst
@@ -93,6 +93,36 @@ Right now the only hard merge criteria are:
 * See also the extensive `committer guidelines for drm-intel
   `_.
 
+Small Drivers
+=
+
+Small drivers, where a full tree is overkill, can be maintained in drm-misc. 
For
+now it's just an experiment with a few drivers to figure out a working process.
+Slightly different rules apply:
+
+* Small is measured in patches merged per kernel release. The occasional big
+  patch series is still acceptable if it's not a common thing (e.g. new hw
+  enabling once a year), and if the series is really big (more than 20 patches)
+  it should probably be managed through a topic branch in drm-misc and with a
+  separate pull request to drm maintainer. dim_ supports this with the
+  create-branch command.
+
+* Group maintainership is assumed, i.e. all regular contributors (not just
+  the primary maintainer) will get commit rights.
+
+* Since even a broken driver is more useful than no driver minimal review
+  standards are a lot lower. The default should be some notes about what could
+  be improved in follow-up work and accepting patches by default. Maintainer
+  group for drivers can agree on stricter rules, especially when they have a
+  bigger user base that shouldn't suffer from regressions.
+
+* Minimal peer-review is also expected for drivers with just one contributor,
+  but obviously then only focuses on best practices for the interaction with 
drm
+  core and helpers. Plus a bit looking for common patterns in dealing with the
+  hardware, since display IP all has to handle the same issues in the end. In
+  most cases this will just along the lines of "Looks good, Ack".  drm-misc
+  maintainers will help out with getting that review market going.
+
 Tooling
 ===
 
-- 
2.11.0

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


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

2017-01-31 Thread Daniel Vetter
Hi Dave,

2 patches to fix the oops Dave Hanse reported, plus a double kfree fix
Maarten discovered while backporting the fix for Linus.

For Linus' vma tracking oops the plan is to send you a dedicated pull with
the 2 patches we need, but since it's tricky we're letting CI beat on it a
bit more.

Cheers, Daniel


The following changes since commit 566cf877a1fcb6d6dc0126b076aad062054c2637:

  Linux 4.10-rc6 (2017-01-29 14:25:17 -0800)

are available in the git repository at:

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

for you to fetch changes up to 92c715fca907686f5298220ece53423e38ba3aed:

  drm/atomic: Fix double free in drm_atomic_state_default_clear (2017-01-31 
13:41:46 +0100)


Daniel Vetter (2):
  drm: prevent double-(un)registration for connectors
  drm: Don't race connector registration

Maarten Lankhorst (1):
  drm/atomic: Fix double free in drm_atomic_state_default_clear

 drivers/gpu/drm/drm_atomic.c| 13 -
 drivers/gpu/drm/drm_connector.c | 23 ++-
 drivers/gpu/drm/drm_drv.c   |  4 
 include/drm/drmP.h  |  1 +
 include/drm/drm_connector.h | 16 +++-
 5 files changed, 46 insertions(+), 11 deletions(-)

-- 
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 3/3] drm/i915/gen9: WM memory bandwidth related workaround

2017-01-31 Thread kbuild test robot
Hi Mahesh,

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

url:
https://github.com/0day-ci/linux/commits/Mahesh-Kumar/Enable-IPC-WM-related-WA-s/20170131-230708
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_pm.c: In function 
'skl_compute_memory_bandwidth_wm_wa':
>> drivers/gpu/drm/i915/intel_pm.c:4118:56: warning: argument to 'sizeof' in 
>> 'memcpy' call is the same expression as the destination; did you mean to 
>> dereference it? [-Wsizeof-pointer-memaccess]
 memcpy(mem_attr, _priv->wm.skl_hw.mem_attr, sizeof(mem_attr));
   ^

vim +4118 drivers/gpu/drm/i915/intel_pm.c

  4102  mem_attr->mem_wa = WATERMARK_WA_NONE;
  4103  return 0;
  4104  }
  4105  
  4106  if (!memdev_info->valid)
  4107  goto exit;
  4108  
  4109  /*
  4110   * We hold wm_mutex lock, so any other flip can't proceed 
beyond WM
  4111   * calculation step until this flip writes modified WM values.
  4112   * So it's safe to read plane_state of other pipes without 
taking CRTC lock
  4113   */
  4114  ret = drm_modeset_lock(_priv->wm.wm_ww_mutex, 
state->acquire_ctx);
  4115  if (ret)
  4116  return ret;
  4117  
> 4118  memcpy(mem_attr, _priv->wm.skl_hw.mem_attr, 
> sizeof(mem_attr));
  4119  
  4120  for_each_crtc_in_state(state, crtc, cstate, i) {
  4121  struct drm_plane *plane;
  4122  const struct drm_plane_state *pstate;
  4123  int active_planes = 0;
  4124  uint32_t max_plane_bw_kbps = 0;
  4125  
  4126  mem_attr->pipe_y_tiled[i] = false;

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


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


Re: [Intel-gfx] [PATCH i-g-t v3 05/11] lib/igt_kms: Added igt_pipe_get_last_out_fence()

2017-01-31 Thread Brian Starkey

On Mon, Jan 30, 2017 at 08:58:41PM -0500, Robert Foss wrote:

Added the igt_pipe_get_last_out_fence() helper function
that wraps accesses to pipe->fence_out.

Signed-off-by: Robert Foss 
---
lib/igt_kms.c | 8 
lib/igt_kms.h | 1 +
2 files changed, 9 insertions(+)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 142658a6..f0e38b75 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1934,6 +1934,14 @@ static igt_output_t *igt_pipe_get_output(igt_pipe_t 
*pipe)
return NULL;
}

+int igt_pipe_get_last_out_fence(igt_pipe_t *pipe)
+{
+   int fd = (int) pipe->out_fence;
+   pipe->out_fence = -1;
+
+   return fd;


If this wasn't the compile error you already found, then "out_fence"
doesn't seem to have been added to igt_pipe_t yet.

-Brian


+}
+
bool igt_pipe_get_property(igt_pipe_t *pipe, const char *name,
   uint32_t *prop_id, uint64_t *value,
   drmModePropertyPtr *prop)
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 00e0dc68..94ff27bb 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -382,6 +382,7 @@ igt_plane_t *igt_output_get_plane_type(igt_output_t 
*output, int plane_type);
igt_output_t *igt_output_from_connector(igt_display_t *display,
drmModeConnector *connector);
igt_plane_t *igt_pipe_get_plane_type(igt_pipe_t *pipe, int plane_type);
+int igt_pipe_get_last_out_fence(igt_pipe_t *pipe);
bool igt_pipe_get_property(igt_pipe_t *pipe, const char *name,
   uint32_t *prop_id, uint64_t *value,
   drmModePropertyPtr *prop);
--
2.11.0.453.g787f75f05


___
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 11/11] tests/kms_atomic_transition: add in_fences tests

2017-01-31 Thread Brian Starkey

On Mon, Jan 30, 2017 at 08:58:47PM -0500, Robert Foss wrote:

From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
---
lib/igt_kms.c |  3 +++
tests/kms_atomic_transition.c | 48 ++-
2 files changed, 32 insertions(+), 19 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 523f3f57..bc815363 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -2009,6 +2009,9 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane, 
igt_pipe_t *pipe,
if (plane->fence_fd >= 0) {
uint64_t fence_fd = (int64_t) plane->fence_fd;
igt_atomic_populate_plane_req(req, plane, 
IGT_PLANE_IN_FENCE_FD, fence_fd);
+
+   /* reset fence_fd to prevent it from being set for the next 
commit */
+   plane->fence_fd = -1;


Who closes it?


}

if (plane->fb_changed) {
diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index eebb5d66..0876bbb3 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -23,7 +23,9 @@

#include "igt.h"
#include "drmtest.h"
+#include "sw_sync.h"
#include 
+#include 
#include 
#include 
#include 
@@ -362,6 +364,9 @@ run_transition_test(igt_display_t *display, enum pipe pipe, 
igt_output_t *output
unsigned flags = DRM_MODE_PAGE_FLIP_EVENT;
int ret;

+   if (fencing)
+   prepare_fencing(display, pipe);
+
if (nonblocking)
flags |= DRM_MODE_ATOMIC_NONBLOCK;

@@ -404,18 +409,19 @@ run_transition_test(igt_display_t *display, enum pipe 
pipe, igt_output_t *output
wm_setup_plane(display, pipe, iter_max - 1, parms);

if (fencing)
-   igt_pipe_set_out_fence_ptr(>pipes[pipe],
-   (int64_t *) _fence);
+   igt_pipe_request_out_fence(>pipes[pipe]);
+


Hopefully this can get rebased away? I'm getting confused about
what's actually being added/changed in this commit.


ret = igt_display_try_commit_atomic(display, 
DRM_MODE_ATOMIC_TEST_ONLY | DRM_MODE_ATOMIC_ALLOW_MODESET, NULL);

-   if (ret != -EINVAL || n_planes < 3)
+   if (ret != -EINVAL || display->pipes[pipe].n_planes < 3)
break;

ret = 0;
for_each_plane_on_pipe(display, pipe, plane) {
i = plane->index;

-   if (plane->is_primary || plane->is_cursor)
+   if (plane->type == DRM_PLANE_TYPE_PRIMARY ||
+   plane->type == DRM_PLANE_TYPE_CURSOR)
continue;


This seems spurious?

...

A bit more add/remove churn below which can hopefully go away with a
rebase.

Cheers,
-Brian


if (parms[i].width <= 512)
@@ -436,10 +442,8 @@ run_transition_test(igt_display_t *display, enum pipe 
pipe, igt_output_t *output

wm_setup_plane(display, pipe, i, parms);

-   if (fencing)
-   igt_pipe_set_out_fence_ptr(>pipes[pipe], 
_fence);
+   atomic_commit(display, pipe, flags, (void *)(unsigned long)i, 
fencing);

-   igt_display_commit_atomic(display, flags, (void *)(unsigned 
long)i);
drmHandleEvent(display->drm_fd, _events);

if (type == TRANSITION_MODESET_DISABLE) {
@@ -463,19 +467,14 @@ run_transition_test(igt_display_t *display, enum pipe 
pipe, igt_output_t *output
if (type == TRANSITION_MODESET)
igt_output_override_mode(output, 
_mode);

-   if (fencing)
-   
igt_pipe_set_out_fence_ptr(>pipes[pipe], _fence);
-
-   igt_display_commit_atomic(display, flags, (void 
*)(unsigned long)j);
+   atomic_commit(display, pipe, flags, (void 
*)(unsigned long)i, fencing);
drmHandleEvent(display->drm_fd, _events);

wm_setup_plane(display, pipe, i, parms);
if (type == TRANSITION_MODESET)
igt_output_override_mode(output, NULL);

-   if (fencing)
-   
igt_pipe_set_out_fence_ptr(>pipes[pipe], _fence);
-
+   atomic_commit(display, pipe, flags, (void 
*)(unsigned long)i, fencing);
igt_display_commit_atomic(display, flags, (void 
*)(unsigned long)i);
drmHandleEvent(display->drm_fd, _events);
}
@@ -483,6 +482,8 @@ run_transition_test(igt_display_t *display, enum pipe pipe, 
igt_output_t *output
}

cleanup:
+   

Re: [Intel-gfx] [PATCH i-g-t v3 10/11] tests/kms_atomic_transition: add out_fences tests

2017-01-31 Thread Brian Starkey

On Mon, Jan 30, 2017 at 08:58:46PM -0500, Robert Foss wrote:

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
---
lib/igt_kms.c |  35 ++
tests/kms_atomic_transition.c | 148 ++
2 files changed, 169 insertions(+), 14 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index f14496dd..523f3f57 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -53,6 +53,7 @@
#include "intel_chipset.h"
#include "igt_debugfs.h"
#include "igt_sysfs.h"
+#include "sw_sync.h"

/**
 * SECTION:igt_kms
@@ -2479,6 +2480,21 @@ static int igt_atomic_commit(igt_display_t *display, 
uint32_t flags, void *user_
}

ret = drmModeAtomicCommit(display->drm_fd, req, flags, user_data);
+   if (!ret) {
+
+   for_each_pipe(display, pipe) {
+   igt_pipe_t *pipe_obj = >pipes[pipe];
+
+   if (pipe_obj->out_fence != -1)
+   continue;


Should be "if (pipe_obj->fence == -1)" ? The stuff below seems to be
assuming the fence is valid.


+
+   igt_assert(pipe_obj->out_fence >= 0);
+   ret = sync_fence_wait(pipe_obj->out_fence, 1000);
+   igt_assert(ret == 0);
+   close(pipe_obj->out_fence);
+   }
+   }
+
drmModeAtomicFree(req);
return ret;

@@ -2972,6 +2988,11 @@ void igt_plane_set_rotation(igt_plane_t *plane, 
igt_rotation_t rotation)
plane->rotation_changed = true;
}

+void igt_pipe_request_out_fence(igt_pipe_t *pipe)


Oh here it is!


+{
+   pipe->out_fence_requested = true;
+}
+
void
igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t length)
{
@@ -2994,20 +3015,6 @@ igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, 
size_t length)
}

/**
- * igt_pipe_set_out_fence_ptr:
- * @pipe: pipe pointer to which background color to be set
- * @fence_ptr: out fence pointer
- *
- * Sets the out fence pointer that will be passed to the kernel in
- * the atomic ioctl. When the kernel returns the out fence pointer
- * will contain the fd number of the out fence created by KMS.
- */
-void igt_pipe_set_out_fence_ptr(igt_pipe_t *pipe, int64_t *fence_ptr)


... and there this one goes. This deletion and the function above
need to be squashed into the earlier commit I suppose.


-{
-   pipe->out_fence_ptr = fence_ptr;
-}
-
-/**
 * igt_crtc_set_background:
 * @pipe: pipe pointer to which background color to be set
 * @background: background color value in BGR 16bpc
diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index 72429759..eebb5d66 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -253,6 +253,93 @@ retry:
 sprite_width, sprite_height, alpha);
}

+int *timeline;
+pthread_t *thread;
+int *seqno;
+
+static void prepare_fencing(igt_display_t *display, enum pipe pipe)
+{
+   igt_plane_t *plane;
+   int n_planes;
+
+   igt_require_sw_sync();
+
+   n_planes = display->pipes[pipe].n_planes;
+timeline = calloc(sizeof(*timeline), n_planes);
+igt_assert_f(timeline != NULL, "Failed to allocate memory for 
timelines\n");
+thread = calloc(sizeof(*thread), n_planes);
+igt_assert_f(thread != NULL, "Failed to allocate memory for thread\n");
+seqno = calloc(sizeof(*seqno), n_planes);
+igt_assert_f(seqno != NULL, "Failed to allocate memory for seqno\n");


The 6 lines above are space-indented


+
+   for_each_plane_on_pipe(display, pipe, plane)
+   timeline[plane->index] = sw_sync_timeline_create();
+}
+
+static void unprepare_fencing(igt_display_t *display, enum pipe pipe)
+{
+   igt_plane_t *plane;
+
+   for_each_plane_on_pipe(display, pipe, plane)
+   close(timeline[plane->index]);
+
+   free(timeline);
+   free(thread);
+   free(seqno);
+}
+
+static void *fence_inc_thread(void *arg)
+{
+   int t = *((int *) arg);
+
+   pthread_detach(pthread_self());
+
+   usleep(5000);
+   sw_sync_timeline_inc(t, 1);
+   return NULL;
+}
+
+static void configure_fencing(igt_display_t *display, enum pipe pipe)
+{
+   igt_plane_t *plane;
+   int i, fd, ret;
+
+   for_each_plane_on_pipe(display, pipe, plane) {
+
+   if (!plane->fb)
+   continue;
+
+   i = plane->index;
+
+   seqno[i]++;
+   fd = sw_sync_timeline_create_fence(timeline[i], seqno[i]);
+   igt_plane_set_fence_fd(plane, fd);
+   ret = pthread_create([i], NULL, fence_inc_thread, 
[i]);
+   igt_assert_eq(ret, 0);
+   }
+}
+
+static void clear_fencing(igt_display_t *display, enum pipe pipe)
+{
+   igt_plane_t *plane;
+
+   for_each_plane_on_pipe(display, pipe, plane)
+   igt_plane_set_fence_fd(plane, -1);


Someone should close 

Re: [Intel-gfx] [PATCH i-g-t v3 08/11] tests/kms_atomic: stress possible fence settings

2017-01-31 Thread Brian Starkey

This one lgtm, just need to swap all the uint64_t out_fence_ptrs for
int32_t.

-Brian

On Mon, Jan 30, 2017 at 08:58:44PM -0500, Robert Foss wrote:

From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
---
tests/kms_atomic.c | 187 ++---
1 file changed, 177 insertions(+), 10 deletions(-)

diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
index 8df51ccd..09605e38 100644
--- a/tests/kms_atomic.c
+++ b/tests/kms_atomic.c
@@ -44,6 +44,7 @@
#include "drmtest.h"
#include "igt.h"
#include "igt_aux.h"
+#include "sw_sync.h"

#ifndef DRM_CLIENT_CAP_ATOMIC
#define DRM_CLIENT_CAP_ATOMIC 3
@@ -126,6 +127,7 @@ struct kms_atomic_plane_state {
uint32_t fb_id; /* 0 to disable */
uint32_t src_x, src_y, src_w, src_h; /* 16.16 fixed-point */
uint32_t crtc_x, crtc_y, crtc_w, crtc_h; /* normal integers */
+   int32_t fence_fd;
};

struct kms_atomic_crtc_state {
@@ -133,6 +135,7 @@ struct kms_atomic_crtc_state {
uint32_t obj;
int idx;
bool active;
+   uint64_t out_fence_ptr;
struct kms_atomic_blob mode;
};

@@ -190,11 +193,13 @@ static uint32_t blob_duplicate(int fd, uint32_t id_orig)
crtc_populate_req(crtc, req); \
plane_populate_req(plane, req); \
do_atomic_commit((crtc)->state->desc->fd, req, flags); \
-   crtc_check_current_state(crtc, plane, relax); \
-   plane_check_current_state(plane, relax); \
+   if (!(flags & DRM_MODE_ATOMIC_TEST_ONLY)) { \
+   crtc_check_current_state(crtc, plane, relax); \
+   plane_check_current_state(plane, relax); \
+   } \
}

-#define crtc_commit_atomic_err(crtc, plane, crtc_old, plane_old, req, relax, 
e) { \
+#define crtc_commit_atomic_err(crtc, plane, crtc_old, plane_old, req, flags, 
relax, e) { \
drmModeAtomicSetCursor(req, 0); \
crtc_populate_req(crtc, req); \
plane_populate_req(plane, req); \
@@ -299,6 +304,9 @@ find_connector(struct kms_atomic_state *state,
static void plane_populate_req(struct kms_atomic_plane_state *plane,
   drmModeAtomicReq *req)
{
+   if (plane->fence_fd)
+   plane_set_prop(req, plane, IGT_PLANE_IN_FENCE_FD, 
plane->fence_fd);
+
plane_set_prop(req, plane, IGT_PLANE_CRTC_ID, plane->crtc_id);
plane_set_prop(req, plane, IGT_PLANE_FB_ID, plane->fb_id);
plane_set_prop(req, plane, IGT_PLANE_SRC_X, plane->src_x);
@@ -433,6 +441,10 @@ find_plane(struct kms_atomic_state *state, enum plane_type 
type,
static void crtc_populate_req(struct kms_atomic_crtc_state *crtc,
  drmModeAtomicReq *req)
{
+   if (crtc->out_fence_ptr)
+   crtc_set_prop(req, crtc, IGT_CRTC_OUT_FENCE_PTR,
+ crtc->out_fence_ptr);
+
crtc_set_prop(req, crtc, IGT_CRTC_MODE_ID, crtc->mode.id);
crtc_set_prop(req, crtc, IGT_CRTC_ACTIVE, crtc->active);
}
@@ -1061,6 +1073,37 @@ static void plane_invalid_params(struct 
kms_atomic_crtc_state *crtc,
drmModeAtomicFree(req);
}

+static void plane_invalid_params_fence(struct kms_atomic_crtc_state *crtc,
+   struct kms_atomic_plane_state *plane_old,
+   struct kms_atomic_connector_state *conn)
+{
+   struct kms_atomic_plane_state plane = *plane_old;
+   drmModeAtomicReq *req = drmModeAtomicAlloc();
+   int timeline, fence_fd;
+
+   igt_require_sw_sync();
+
+   /* invalid fence fd */
+   plane.fence_fd = plane.state->desc->fd;
+   plane.crtc_id = plane_old->crtc_id;
+   plane_commit_atomic_err(, plane_old, req,
+   ATOMIC_RELAX_NONE, EINVAL);
+
+   /* Valid fence_fd but invalid CRTC */
+   timeline = sw_sync_timeline_create();
+   fence_fd =  sw_sync_timeline_create_fence(timeline, 1);
+   plane.fence_fd = fence_fd;
+   plane.crtc_id = ~0U;
+   plane_commit_atomic_err(, plane_old, req,
+   ATOMIC_RELAX_NONE, EINVAL);
+
+   plane.fence_fd = -1;
+   close(fence_fd);
+   close(timeline);
+
+   drmModeAtomicFree(req);
+}
+
static void crtc_invalid_params(struct kms_atomic_crtc_state *crtc_old,
struct kms_atomic_plane_state *plane,
struct kms_atomic_connector_state *conn)
@@ -1072,30 +1115,32 @@ static void crtc_invalid_params(struct 
kms_atomic_crtc_state *crtc_old,

/* Pass a series of invalid object IDs for the mode ID. */
crtc.mode.id = plane->obj;
-   crtc_commit_atomic_err(, plane, crtc_old, plane, req,
+   crtc_commit_atomic_err(, plane, crtc_old, plane, req, 0,
   ATOMIC_RELAX_NONE, EINVAL);

crtc.mode.id = crtc.obj;
-   crtc_commit_atomic_err(, plane, crtc_old, plane, req,
+   

Re: [Intel-gfx] [PATCH i-g-t v3 07/11] lib/igt_kms: Add support for the OUT_FENCE_PTR property

2017-01-31 Thread Brian Starkey

On Mon, Jan 30, 2017 at 08:58:43PM -0500, Robert Foss wrote:

From: Gustavo Padovan 

Add support for the OUT_FENCE_PTR property to enable setting out fences for
atomic commits.

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
---
lib/igt_kms.c | 26 +-
lib/igt_kms.h |  6 +-
2 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index b79d2867..f14496dd 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -179,7 +179,8 @@ const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
"DEGAMMA_LUT",
"GAMMA_LUT",
"MODE_ID",
-   "ACTIVE"
+   "ACTIVE",
+   "OUT_FENCE_PTR"
};

const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
@@ -2393,6 +2394,15 @@ static void igt_atomic_prepare_crtc_commit(igt_pipe_t 
*pipe_obj, drmModeAtomicRe
igt_atomic_populate_crtc_req(req, pipe_obj, IGT_CRTC_ACTIVE, 
!!output);
}

+   pipe_obj->out_fence = -1;
+   if (pipe_obj->out_fence_requested)
+   {
+   pipe_obj->out_fence_requested = false;
+   igt_atomic_populate_crtc_req(req, pipe_obj, 
IGT_CRTC_OUT_FENCE_PTR,
+   (uint64_t)(uintptr_t) _obj->out_fence);
+   igt_assert_f(pipe_obj->out_fence != -1, "Unable to get fence, 
received -1 fd\n");


Doesn't this assertion always fail? You just set it to -1


+   }
+
/*
 *  TODO: Add all crtc level properties here
 */
@@ -2984,6 +2994,20 @@ igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, 
size_t length)
}

/**
+ * igt_pipe_set_out_fence_ptr:
+ * @pipe: pipe pointer to which background color to be set
+ * @fence_ptr: out fence pointer
+ *
+ * Sets the out fence pointer that will be passed to the kernel in
+ * the atomic ioctl. When the kernel returns the out fence pointer
+ * will contain the fd number of the out fence created by KMS.
+ */
+void igt_pipe_set_out_fence_ptr(igt_pipe_t *pipe, int64_t *fence_ptr)
+{
+   pipe->out_fence_ptr = fence_ptr;
+}


Is this ever used? You seem to use _obj->out_fence
unconditionally above (and igt_pipe has no member named
out_fence_ptr).

I guess is left over from the previous API and needs to be removed?


+
+/**
 * igt_crtc_set_background:
 * @pipe: pipe pointer to which background color to be set
 * @background: background color value in BGR 16bpc
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 85688853..9672dadc 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -94,6 +94,7 @@ enum igt_atomic_crtc_properties {
   IGT_CRTC_GAMMA_LUT,
   IGT_CRTC_MODE_ID,
   IGT_CRTC_ACTIVE,
+   IGT_CRTC_OUT_FENCE_PTR,
   IGT_NUM_CRTC_PROPS
};

@@ -341,6 +342,9 @@ struct igt_pipe {

uint64_t mode_blob;
bool mode_changed;
+
+   int64_t out_fence;
+   bool out_fence_requested;
};

typedef struct {
@@ -395,7 +399,7 @@ static inline bool igt_plane_supports_rotation(igt_plane_t 
*plane)
{
return plane->rotation_property != 0;
}
-
+void igt_pipe_request_out_fence(igt_pipe_t *pipe);


Not implemented? I think this patch got confused somewhere :-(

-Brian


void igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t length);
void igt_pipe_set_ctm_matrix(igt_pipe_t *pipe, void *ptr, size_t length);
void igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length);
--
2.11.0.453.g787f75f05


___
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 06/11] lib/igt_kms: Add support for the IN_FENCE_FD property

2017-01-31 Thread Brian Starkey

On Mon, Jan 30, 2017 at 08:58:42PM -0500, Robert Foss wrote:

Add support dor the IN_FENCE_FD property to enable setting in fences for atomic
commits.

Signed-off-by: Robert Foss 
---
lib/igt_kms.c | 20 
lib/igt_kms.h |  5 +
2 files changed, 25 insertions(+)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index f0e38b75..b79d2867 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -168,6 +168,7 @@ const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
"CRTC_H",
"FB_ID",
"CRTC_ID",
+   "IN_FENCE_FD",
"type",
"rotation"
};
@@ -1667,6 +1668,7 @@ void igt_display_init(igt_display_t *display, int drm_fd)
plane->type = type;
plane->pipe = pipe;
plane->drm_plane = drm_plane;
+   plane->fence_fd = -1;

if (is_atomic == 0) {
display->is_atomic = 1;
@@ -2002,6 +2004,11 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane, 
igt_pipe_t *pipe,
plane->index,
fb_id);

+   if (plane->fence_fd >= 0) {
+   uint64_t fence_fd = (int64_t) plane->fence_fd;
+   igt_atomic_populate_plane_req(req, plane, 
IGT_PLANE_IN_FENCE_FD, fence_fd);
+   }
+
if (plane->fb_changed) {
igt_atomic_populate_plane_req(req, plane, IGT_PLANE_CRTC_ID, 
fb_id ? crtc_id : 0);
igt_atomic_populate_plane_req(req, plane, IGT_PLANE_FB_ID, 
fb_id);
@@ -2823,6 +2830,19 @@ void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb 
*fb)
plane->size_changed = true;
}

+/**
+ * igt_plane_set_fence_fd:
+ * @plane: plane
+ * @fence_fd: fence fd, disable fence_fd by setting it to -1
+ *
+ * This function sets a fence fd to enable a commit to wait for some event to
+ * occur before completing.
+ */
+void igt_plane_set_fence_fd(igt_plane_t *plane, uint32_t fence_fd)


nitpick, but should that be "int fence_fd" ?

Also have some comments later in the series around the fd ownership.
If nothing else, the comment here could say what's expected.

-Brian


+{
+   plane->fence_fd = fence_fd;
+}
+
void igt_plane_set_position(igt_plane_t *plane, int x, int y)
{
igt_pipe_t *pipe = plane->pipe;
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 94ff27bb..85688853 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -248,6 +248,7 @@ enum igt_atomic_plane_properties {

   IGT_PLANE_FB_ID,
   IGT_PLANE_CRTC_ID,
+   IGT_PLANE_IN_FENCE_FD,
   IGT_PLANE_TYPE,
   IGT_PLANE_ROTATION,
   IGT_NUM_PLANE_PROPS
@@ -306,6 +307,9 @@ typedef struct {
uint32_t src_h;

igt_rotation_t rotation;
+
+   /* in fence fd */
+   int32_t fence_fd;
uint32_t atomic_props_plane[IGT_NUM_PLANE_PROPS];
} igt_plane_t;

@@ -397,6 +401,7 @@ void igt_pipe_set_ctm_matrix(igt_pipe_t *pipe, void *ptr, 
size_t length);
void igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length);

void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb *fb);
+void igt_plane_set_fence_fd(igt_plane_t *plane, uint32_t fence_fd);
void igt_plane_set_position(igt_plane_t *plane, int x, int y);
void igt_plane_set_size(igt_plane_t *plane, int w, int h);
void igt_plane_set_rotation(igt_plane_t *plane, igt_rotation_t rotation);
--
2.11.0.453.g787f75f05


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


Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915: Make intel_detect_preproduction_hw easier to extend

2017-01-31 Thread Chris Wilson
On Mon, Jan 30, 2017 at 05:54:14PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [v2,1/3] drm/i915: Make 
> intel_detect_preproduction_hw easier to extend
> URL   : https://patchwork.freedesktop.org/series/18758/
> State : success
> 
> == Summary ==
> 
> Series 18758v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/18758/revisions/1/mbox/
> 
> 
> fi-bdw-5557u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
> fi-bsw-n3050 total:246  pass:207  dwarn:0   dfail:0   fail:0   skip:39 
> fi-bxt-j4205 total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
> fi-bxt-t5700 total:78   pass:65   dwarn:0   dfail:0   fail:0   skip:12 
> fi-byt-j1900 total:246  pass:219  dwarn:0   dfail:0   fail:0   skip:27 
> fi-byt-n2820 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
> fi-hsw-4770  total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
> fi-hsw-4770r total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
> fi-ivb-3520m total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
> fi-ivb-3770  total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
> fi-skl-6260u total:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
> fi-skl-6700hqtotal:246  pass:226  dwarn:0   dfail:0   fail:0   skip:20 
> fi-skl-6700k total:246  pass:221  dwarn:4   dfail:0   fail:0   skip:21 
> fi-skl-6770hqtotal:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
> fi-snb-2520m total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
> fi-snb-2600  total:246  pass:214  dwarn:0   dfail:0   fail:0   skip:32 

Applied in spite of some late background noise about bxt-a0 support, a
bit late now.
-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 v2] drm/i915: Sanity check the computed size and base of stolen memory

2017-01-31 Thread Chris Wilson
On Tue, Jan 31, 2017 at 12:13:47PM +0200, Joonas Lahtinen wrote:
> On ma, 2017-01-30 at 13:47 +, Chris Wilson wrote:
> > Just do a quick check that the stolen memory address range doesn't
> > overflow our chosen integer type.
> > 
> > v2: Add add_overflows() to utils with the promise that gcc7 can do this
> > better than C and then maybe it will have a proper definition in core.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Joonas Lahtinen 
> 
> Reviewed-by: Joonas Lahtinen 

Applied, thanks,
-Chris

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


Re: [Intel-gfx] [PATCH 1/3] drm/i915/bxt: Enable IPC support

2017-01-31 Thread Ander Conselvan De Oliveira
On Tue, 2017-01-31 at 20:27 +0530, Mahesh Kumar wrote:
> This patch adds IPC support for platforms. This patch enables IPC
> only for BXT/KBL platform as for SKL recommendation is to keep it disabled.
> IPC (Isochronous Priority Control) is the hardware feature, which
> dynamically controls the memory read priority of Display.
> 
> When IPC is enabled, plane read requests are sent at high priority until
> filling above the transition watermark, then the requests are sent at
> lower priority until dropping below the level 0 watermark.
> The lower priority requests allow other memory clients to have better
> memory access. When IPC is disabled, all plane read requests are sent at
> high priority.
> 
> Changes since V1:
>  - Remove commandline parameter to disable ipc
>  - Address Paulo's comments
> Changes since V2:
>  - Address review comments
>  - Set ipc_enabled flag
> Changes since V3:
>  - move ipc_enabled flag assignment inside intel_ipc_enable function
> Changes since V4:
>  - Re-enable IPC after suspend/resume
> 
> Signed-off-by: Mahesh Kumar 
> ---
>  drivers/gpu/drm/i915/i915_drv.c  |  4 +++-
>  drivers/gpu/drm/i915/i915_reg.h  |  1 +
>  drivers/gpu/drm/i915/intel_display.c |  1 +
>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>  drivers/gpu/drm/i915/intel_pm.c  | 16 
>  5 files changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index ca168b22ee26..5f3b22946971 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1246,7 +1246,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct
> pci_device_id *ent)
>  
>   intel_runtime_pm_enable(dev_priv);
>  
> - dev_priv->ipc_enabled = false;
> + intel_enable_ipc(dev_priv);
>  
>   /* Everything is in place, we can now relax! */
>   DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
> @@ -2439,6 +2439,8 @@ static int intel_runtime_resume(struct device *kdev)
>  
>   enable_rpm_wakeref_asserts(dev_priv);
>  
> + intel_enable_ipc(dev_priv);
> +
>   if (ret)
>   DRM_ERROR("Runtime resume failed, disabling it (%d)\n", ret);
>   else
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 72f9f36ae5ce..36e0a33f876c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6466,6 +6466,7 @@ enum {
>  #define  DISP_FBC_WM_DIS (1<<15)
>  #define DISP_ARB_CTL2_MMIO(0x45004)
>  #define  DISP_DATA_PARTITION_5_6 (1<<6)
> +#define  DISP_IPC_ENABLE (1<<3)
>  #define DBUF_CTL _MMIO(0x45008)
>  #define  DBUF_POWER_REQUEST  (1<<31)
>  #define  DBUF_POWER_STATE(1<<30)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 0bf8e1bfbe7e..1aa708b6f55e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -17222,6 +17222,7 @@ void intel_display_resume(struct drm_device *dev)
>   if (!ret)
>   ret = __intel_display_resume(dev, state);
>  
> + intel_enable_ipc(dev_priv);
>   drm_modeset_drop_locks();
>   drm_modeset_acquire_fini();
>   mutex_unlock(>mode_config.mutex);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 0cec0013ace0..ab7423b0a41b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1787,6 +1787,7 @@ bool skl_ddb_allocation_overlaps(const struct
> skl_ddb_entry **entries,
>  uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config);
>  bool ilk_disable_lp_wm(struct drm_device *dev);
>  int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
> +void intel_enable_ipc(struct drm_i915_private *dev_priv);
>  static inline int intel_enable_rc6(void)
>  {
>   return i915.enable_rc6;
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 249623d45be0..16e83efa1118 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4667,6 +4667,22 @@ void intel_update_watermarks(struct intel_crtc *crtc)
>   dev_priv->display.update_wm(crtc);
>  }
>  
> +void intel_enable_ipc(struct drm_i915_private *dev_priv)
> +{
> + u32 val;
> +
> + dev_priv->ipc_enabled = false;
> + if (!(IS_BROXTON(dev_priv) || IS_KABYLAKE(dev_priv)))
> + return;

Do we want this enabled in Geminilake?

Ander

> +
> + val = I915_READ(DISP_ARB_CTL2);
> +
> + val |= DISP_IPC_ENABLE;
> +
> + I915_WRITE(DISP_ARB_CTL2, val);
> + dev_priv->ipc_enabled = true;
> +}
> +
>  /*
>   * Lock protecting IPS related data structures
>   */
___
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 00/11] tests/kms_atomic_transition add fence testing

2017-01-31 Thread Robert Foss



On 2017-01-31 05:18 AM, Chris Wilson wrote:

On Mon, Jan 30, 2017 at 08:58:36PM -0500, Robert Foss wrote:

This series adds in/out fence testing to kms_atomic_transition test and makes 
some minor cleanups.

This series is rebased ontop of the dyn_n_planes_v3 series.

This series can be found here:
https://git.collabora.com/cgit/user/robertfoss/intel-gpu-tools.git/log/?h=fences_$VER


Changes since v1:

  lib/igt_kms:
   - Added gtk-doc for exported symbols
   - Changed integer casting to avoid potential issues
   - Changed out_fence_ptr type to int64_t*
   - Fixed igt_plane_set_fence_fd comment

  tests/:
   - Rework timeout change in commit_display()
   - Extract plane_invalid_params_fence() out plane_invalid_params()
   - Extract crtc_invalid_params_fence() out crtc_invalid_params()
   - Prevent add igt_require_sw_sync to subtests using sw_sync


Changes since v2:
  Rebased on upstream/master

  lib/igt_kms:
- Reset plane->fence_fd to -1 during igt_atomic_prepare_plane_commit()
- Rework out_fencs_ptr to be an int64_t named out_fence
- Add igt_pipe_request_out_fence()
  tests/:
- Switch to using igt_pipe_request_out_fence()
- Close out_fence fd
- Change out_fence to int64_t in run_transition_test()
- Added comments noting that two testcases are not invalid
- Added igt_pipe_get_last_out_fence() that wraps pipe->fence_out


Looks like this this missing the uabi conversion to s32 (int).
-Chris


Correct, I'll submit a v4 with this fix later today if no other major 
issues are reported.


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


[Intel-gfx] [PATCH igt] intel-ci: Move start of gvt tests last

2017-01-31 Thread Chris Wilson
The purpose of the current placeholder gvt is to reload the module with
gvt enabled. As a reload, it should be last after the basic reload
checks.

Signed-off-by: Chris Wilson 
---
 tests/intel-ci/fast-feedback.testlist | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/intel-ci/fast-feedback.testlist 
b/tests/intel-ci/fast-feedback.testlist
index 0ca499a4..828bd3ff 100644
--- a/tests/intel-ci/fast-feedback.testlist
+++ b/tests/intel-ci/fast-feedback.testlist
@@ -130,7 +130,6 @@ igt@gem_tiled_pread_basic
 igt@gem_wait@basic-busy-all
 igt@gem_wait@basic-wait-all
 igt@gem_workarounds@basic-read
-igt@gvt_basic@invalid-placeholder-test
 igt@kms_addfb_basic@addfb25-bad-modifier
 igt@kms_addfb_basic@addfb25-framebuffer-vs-set-tiling
 igt@kms_addfb_basic@addfb25-modifier-no-flag
@@ -250,3 +249,4 @@ igt@drv_module_reload@basic-reload
 igt@drv_module_reload@basic-no-display
 igt@drv_module_reload@basic-reload-inject
 igt@drv_module_reload@basic-reload-final
+igt@gvt_basic@invalid-placeholder-test
-- 
2.11.0

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


[Intel-gfx] ✓ Fi.CI.BAT: success for Enable IPC & WM related WA's

2017-01-31 Thread Patchwork
== Series Details ==

Series: Enable IPC & WM related WA's
URL   : https://patchwork.freedesktop.org/series/18842/
State : success

== Summary ==

Series 18842v1 Enable IPC & WM related WA's
https://patchwork.freedesktop.org/api/1.0/series/18842/revisions/1/mbox/


fi-bdw-5557u total:247  pass:233  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:247  pass:208  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:247  pass:225  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:78   pass:65   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:247  pass:224  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:247  pass:227  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:247  pass:222  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:247  pass:215  dwarn:0   dfail:0   fail:0   skip:32 

a0695bf4e1c12de4863e775747fe850b92661dc6 drm-tip: 2017y-01m-31d-13h-38m-55s UTC 
integration manifest
7876fae drm/i915: Decode system memory bandwidth
41469f0 drm/i915/bxt: Enable IPC support

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for do_execbuffer tidy

2017-01-31 Thread Patchwork
== Series Details ==

Series: do_execbuffer tidy
URL   : https://patchwork.freedesktop.org/series/18838/
State : warning

== Summary ==

Series 18838v1 do_execbuffer tidy
https://patchwork.freedesktop.org/api/1.0/series/18838/revisions/1/mbox/

Test kms_force_connector_basic:
Subgroup force-connector-state:
pass   -> DMESG-WARN (fi-snb-2520m)

fi-bdw-5557u total:247  pass:233  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:247  pass:208  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:247  pass:225  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:78   pass:65   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:247  pass:224  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:247  pass:227  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:247  pass:222  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:247  pass:215  dwarn:1   dfail:0   fail:0   skip:31 
fi-snb-2600  total:247  pass:215  dwarn:0   dfail:0   fail:0   skip:32 

a0695bf4e1c12de4863e775747fe850b92661dc6 drm-tip: 2017y-01m-31d-13h-38m-55s UTC 
integration manifest
db7e420 drm/i915: Remove some unecessary line breaks
c87579b drm/i915: Pass file_priv to eb_select_engine
a436b4e drm/i915: eb_engine_select only needs flags
c17110c drm/i915: Drop unused engine parameter from i915_gem_validate_context
a07e08f drm/i915: Remove some single use locals i915_gem_do_execbuffer
d6e08ae drm/i915: Nuke i915_execbuffer_params
51324f0 drm/i915: Remove batch field from i915_execbuffer_params
84b1d2e drm/i915: Tidy execbuf_submit
eb4ad7b drm/i915: Drop some unused fields from i915_execbuffer_params
5029d71 drm/i915: Tidy i915_gem_do_execbuffer

== Logs ==

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


[Intel-gfx] [PATCH 1/3] drm/i915/bxt: Enable IPC support

2017-01-31 Thread Mahesh Kumar
This patch adds IPC support for platforms. This patch enables IPC
only for BXT/KBL platform as for SKL recommendation is to keep it disabled.
IPC (Isochronous Priority Control) is the hardware feature, which
dynamically controls the memory read priority of Display.

When IPC is enabled, plane read requests are sent at high priority until
filling above the transition watermark, then the requests are sent at
lower priority until dropping below the level 0 watermark.
The lower priority requests allow other memory clients to have better
memory access. When IPC is disabled, all plane read requests are sent at
high priority.

Changes since V1:
 - Remove commandline parameter to disable ipc
 - Address Paulo's comments
Changes since V2:
 - Address review comments
 - Set ipc_enabled flag
Changes since V3:
 - move ipc_enabled flag assignment inside intel_ipc_enable function
Changes since V4:
 - Re-enable IPC after suspend/resume

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/i915_drv.c  |  4 +++-
 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 drivers/gpu/drm/i915/intel_display.c |  1 +
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c  | 16 
 5 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ca168b22ee26..5f3b22946971 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1246,7 +1246,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
intel_runtime_pm_enable(dev_priv);
 
-   dev_priv->ipc_enabled = false;
+   intel_enable_ipc(dev_priv);
 
/* Everything is in place, we can now relax! */
DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
@@ -2439,6 +2439,8 @@ static int intel_runtime_resume(struct device *kdev)
 
enable_rpm_wakeref_asserts(dev_priv);
 
+   intel_enable_ipc(dev_priv);
+
if (ret)
DRM_ERROR("Runtime resume failed, disabling it (%d)\n", ret);
else
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 72f9f36ae5ce..36e0a33f876c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6466,6 +6466,7 @@ enum {
 #define  DISP_FBC_WM_DIS   (1<<15)
 #define DISP_ARB_CTL2  _MMIO(0x45004)
 #define  DISP_DATA_PARTITION_5_6   (1<<6)
+#define  DISP_IPC_ENABLE   (1<<3)
 #define DBUF_CTL   _MMIO(0x45008)
 #define  DBUF_POWER_REQUEST(1<<31)
 #define  DBUF_POWER_STATE  (1<<30)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0bf8e1bfbe7e..1aa708b6f55e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -17222,6 +17222,7 @@ void intel_display_resume(struct drm_device *dev)
if (!ret)
ret = __intel_display_resume(dev, state);
 
+   intel_enable_ipc(dev_priv);
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
mutex_unlock(>mode_config.mutex);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0cec0013ace0..ab7423b0a41b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1787,6 +1787,7 @@ bool skl_ddb_allocation_overlaps(const struct 
skl_ddb_entry **entries,
 uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config);
 bool ilk_disable_lp_wm(struct drm_device *dev);
 int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
+void intel_enable_ipc(struct drm_i915_private *dev_priv);
 static inline int intel_enable_rc6(void)
 {
return i915.enable_rc6;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 249623d45be0..16e83efa1118 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4667,6 +4667,22 @@ void intel_update_watermarks(struct intel_crtc *crtc)
dev_priv->display.update_wm(crtc);
 }
 
+void intel_enable_ipc(struct drm_i915_private *dev_priv)
+{
+   u32 val;
+
+   dev_priv->ipc_enabled = false;
+   if (!(IS_BROXTON(dev_priv) || IS_KABYLAKE(dev_priv)))
+   return;
+
+   val = I915_READ(DISP_ARB_CTL2);
+
+   val |= DISP_IPC_ENABLE;
+
+   I915_WRITE(DISP_ARB_CTL2, val);
+   dev_priv->ipc_enabled = true;
+}
+
 /*
  * Lock protecting IPS related data structures
  */
-- 
2.11.0

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


[Intel-gfx] [PATCH 2/3] drm/i915: Decode system memory bandwidth

2017-01-31 Thread Mahesh Kumar
This patch adds support to decode system memory bandwidth
which will be used for arbitrated display memory percentage
calculation in GEN9 based system.

Changes from v1:
 - Address comments from Paulo
 - implement decode function for SKL/KBL also
Changes from v2:
 - Rewrite the code as per HW team inputs
 - Addresses review comments
Changes from v3:
 - Fix compilation warning
Changes from v4:
 - Address review comments
 - Round-off the frequency & bandwidth results

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/i915_drv.c | 179 
 drivers/gpu/drm/i915/i915_drv.h |  12 +++
 drivers/gpu/drm/i915/i915_reg.h |  37 +
 3 files changed, 228 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5f3b22946971..b8d0dd2811a9 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -975,6 +975,179 @@ static void intel_sanitize_options(struct 
drm_i915_private *dev_priv)
DRM_DEBUG_DRIVER("use GPU sempahores? %s\n", yesno(i915.semaphores));
 }
 
+static enum rank
+skl_memdev_get_channel_rank(uint32_t val)
+{
+   uint8_t l_rank, s_rank;
+   uint8_t l_size, s_size;
+
+   if (!val)
+   return I915_DRAM_RANK_INVALID;
+
+   l_size = (val >> SKL_DRAM_SIZE_L_SHIFT) & SKL_DRAM_SIZE_MASK;
+   s_size = (val >> SKL_DRAM_SIZE_S_SHIFT) & SKL_DRAM_SIZE_MASK;
+   l_rank = (val >> SKL_DRAM_RANK_L_SHIFT) & SKL_DRAM_RANK_MASK;
+   s_rank = (val >> SKL_DRAM_RANK_S_SHIFT) & SKL_DRAM_RANK_MASK;
+
+   if ((l_size == 0) && (s_size == 0))
+   return I915_DRAM_RANK_INVALID;
+
+   if (l_rank == SKL_DRAM_RANK_DUAL || s_rank == SKL_DRAM_RANK_DUAL)
+   return I915_DRAM_RANK_DUAL;
+
+   if ((l_size && l_rank == SKL_DRAM_RANK_SINGLE) &&
+   (s_size && s_rank == SKL_DRAM_RANK_SINGLE))
+   return I915_DRAM_RANK_DUAL;
+   return I915_DRAM_RANK_SINGLE;
+}
+
+static int
+skl_get_memdev_info(struct drm_i915_private *dev_priv)
+{
+   struct memdev_info *memdev_info = _priv->memdev_info;
+   uint32_t mem_freq_khz;
+   uint32_t val;
+   enum rank ch0_rank, ch1_rank;
+
+   val = I915_READ(SKL_MC_BIOS_DATA_0_0_0_MCHBAR_PCU);
+   mem_freq_khz = DIV_ROUND_UP((val & SKL_REQ_DATA_MASK) *
+   SKL_MEMORY_FREQ_MULTIPLIER_HZ, 1000);
+
+   val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
+   ch0_rank = skl_memdev_get_channel_rank(val);
+   if (ch0_rank != I915_DRAM_RANK_INVALID)
+   memdev_info->num_channels++;
+
+   val = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
+   ch1_rank = skl_memdev_get_channel_rank(val);
+   if (ch1_rank != I915_DRAM_RANK_INVALID)
+   memdev_info->num_channels++;
+
+   if (memdev_info->num_channels == 0) {
+   DRM_ERROR("Number of mem channels are zero\n");
+   return -EINVAL;
+   }
+
+   memdev_info->bandwidth_kbps = memdev_info->num_channels *
+   mem_freq_khz * 8;
+
+   if (memdev_info->bandwidth_kbps == 0) {
+   DRM_ERROR("Couldn't get system memory bandwidth\n");
+   return -EINVAL;
+   }
+
+   /*
+* If any of channel is single rank channel, worst case output will be
+* same as if single rank memory, so consider single rank memory.
+*/
+   if (ch0_rank == I915_DRAM_RANK_SINGLE
+   || ch1_rank == I915_DRAM_RANK_SINGLE)
+   memdev_info->rank = I915_DRAM_RANK_SINGLE;
+   else
+   memdev_info->rank = max(ch0_rank, ch1_rank);
+
+   if (memdev_info->rank == I915_DRAM_RANK_INVALID) {
+   DRM_ERROR("couldn't get memory rank information\n");
+   return -EINVAL;
+   }
+
+   memdev_info->valid = true;
+   return 0;
+}
+
+static int
+bxt_get_memdev_info(struct drm_i915_private *dev_priv)
+{
+   struct memdev_info *memdev_info = _priv->memdev_info;
+   uint32_t dram_channels;
+   uint32_t mem_freq_khz, val;
+   uint8_t num_active_channels;
+   int i;
+
+   val = I915_READ(BXT_P_CR_MC_BIOS_REQ_0_0_0);
+   mem_freq_khz = DIV_ROUND_UP((val & BXT_REQ_DATA_MASK) *
+   BXT_MEMORY_FREQ_MULTIPLIER_HZ, 1000);
+
+   dram_channels = (val >> BXT_DRAM_CHANNEL_ACTIVE_SHIFT) &
+   BXT_DRAM_CHANNEL_ACTIVE_MASK;
+   num_active_channels = hweight32(dram_channels);
+
+   /* each active bit represents 4-byte channel */
+   memdev_info->bandwidth_kbps = (mem_freq_khz * num_active_channels * 4);
+
+   if (memdev_info->bandwidth_kbps == 0) {
+   DRM_ERROR("Couldn't get system memory bandwidth\n");
+   return -EINVAL;
+   }
+
+   /*
+* Now read each DUNIT8/9/10/11 to check the rank of each dimms.
+*/
+  

[Intel-gfx] [PATCH 3/3] drm/i915/gen9: WM memory bandwidth related workaround

2017-01-31 Thread Mahesh Kumar
This patch enables workarounds related to display arbitrated memory
bandwidth only if it's necessary. WA's are applicable for all GEN9
based platforms.

Changes since v1:
 - Rebase on top of Paulo's patch series
Changes since v2:
 - Address review comments
 - Rebase/rework as per other patch changes in series
Changes since v3:
 - Rebase the patch
 - introduce ww_mutex to protect WM operations
 - Protect system memory bandwidth calculation with ww_mutex

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/i915_drv.c  |   1 +
 drivers/gpu/drm/i915/i915_drv.h  |  15 
 drivers/gpu/drm/i915/intel_display.c |  34 
 drivers/gpu/drm/i915/intel_pm.c  | 163 +++
 4 files changed, 194 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b8d0dd2811a9..a14b2a9d2e6a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -814,6 +814,7 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
mutex_init(_priv->modeset_restore_lock);
mutex_init(_priv->av_mutex);
mutex_init(_priv->wm.wm_mutex);
+   drm_modeset_lock_init(_priv->wm.wm_ww_mutex);
mutex_init(_priv->pps_mutex);
 
intel_uc_init_early(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index df24de2b65f2..6e5cdd6c9dfd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1174,6 +1174,13 @@ enum intel_sbi_destination {
SBI_MPHY,
 };
 
+/* SKL+ Watermark arbitrated display bandwidth Workarounds */
+enum watermark_memory_wa {
+   WATERMARK_WA_NONE,
+   WATERMARK_WA_X_TILED,
+   WATERMARK_WA_Y_TILED,
+};
+
 #define QUIRK_PIPEA_FORCE (1<<0)
 #define QUIRK_LVDS_SSC_DISABLE (1<<1)
 #define QUIRK_INVERT_BRIGHTNESS (1<<2)
@@ -1744,8 +1751,15 @@ struct skl_ddb_allocation {
struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES];
 };
 
+struct skl_mem_bw_attr {
+   enum watermark_memory_wa mem_wa;
+   uint32_t pipe_bw_kbps[I915_MAX_PIPES];
+   bool pipe_y_tiled[I915_MAX_PIPES];
+};
+
 struct skl_wm_values {
unsigned dirty_pipes;
+   struct skl_mem_bw_attr mem_attr;
struct skl_ddb_allocation ddb;
 };
 
@@ -2348,6 +2362,7 @@ struct drm_i915_private {
 * cstate->wm.need_postvbl_update.
 */
struct mutex wm_mutex;
+   struct drm_modeset_lock wm_ww_mutex; /* protect DDB/WM 
redistribution among pipes */
 
/*
 * Set during HW readout of watermarks/DDB.  Some platforms
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 1aa708b6f55e..de512bd8136b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14589,6 +14589,38 @@ static void intel_atomic_track_fbs(struct 
drm_atomic_state *state)
  to_intel_plane(plane)->frontbuffer_bit);
 }
 
+static void
+intel_update_wm_bw_wa(struct drm_atomic_state *state)
+{
+   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+   struct drm_i915_private *dev_priv = to_i915(state->dev);
+   const struct drm_crtc *crtc;
+   const struct drm_crtc_state *cstate;
+   const struct memdev_info *memdev_info = _priv->memdev_info;
+   struct skl_mem_bw_attr *results = _state->wm_results.mem_attr;
+   struct skl_mem_bw_attr *hw_vals = _priv->wm.skl_hw.mem_attr;
+   int i;
+
+   if (!IS_GEN9(dev_priv))
+   return;
+
+   if (!memdev_info->valid)
+   return;
+
+   for_each_crtc_in_state(state, crtc, cstate, i) {
+   hw_vals->pipe_bw_kbps[i] = results->pipe_bw_kbps[i];
+   hw_vals->pipe_y_tiled[i] = results->pipe_y_tiled[i];
+   }
+
+   hw_vals->mem_wa = results->mem_wa;
+
+   /*
+* As we already updated state variables no need to hold the lock,
+* other commits can proceed now with their calculation
+*/
+   drm_modeset_unlock(_priv->wm.wm_ww_mutex);
+}
+
 /**
  * intel_atomic_commit - commit validated state object
  * @dev: DRM device
@@ -14629,6 +14661,8 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_shared_dpll_swap_state(state);
intel_atomic_track_fbs(state);
 
+   intel_update_wm_bw_wa(state);
+
if (intel_state->modeset) {
memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
   sizeof(intel_state->min_pixclk));
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 16e83efa1118..ae43df5cdfd8 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2887,21 +2887,6 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
 
 #define SKL_SAGV_BLOCK_TIME30 /* µs */
 
-/*
- * FIXME: We still don't have the 

[Intel-gfx] [PATCH 0/3] Enable IPC & WM related WA's

2017-01-31 Thread Mahesh Kumar
This series include remaining patches from following series
to enable IPC and Enable/update memory BW related WA's for WM.
https://patchwork.freedesktop.org/series/15562/

Mahesh Kumar (3):
  drm/i915/bxt: Enable IPC support
  drm/i915: Decode system memory bandwidth
  drm/i915/gen9: WM memory bandwidth related workaround

 drivers/gpu/drm/i915/i915_drv.c  | 184 ++-
 drivers/gpu/drm/i915/i915_drv.h  |  27 +
 drivers/gpu/drm/i915/i915_reg.h  |  38 
 drivers/gpu/drm/i915/intel_display.c |  35 +++
 drivers/gpu/drm/i915/intel_drv.h |   1 +
 drivers/gpu/drm/i915/intel_pm.c  | 179 ++
 6 files changed, 444 insertions(+), 20 deletions(-)

-- 
2.11.0

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


Re: [Intel-gfx] [PATCH] tools: rename intel_bios_reader to intel_vbt_decode

2017-01-31 Thread Jani Nikula
On Mon, 30 Jan 2017, Ville Syrjälä  wrote:
> On Mon, Jan 30, 2017 at 10:00:54AM +0200, Jani Nikula wrote:
>> On Tue, 24 Jan 2017, Jani Nikula  wrote:
>> > After all these years intel_bios_reader and intel_bios_dumper still
>> > manage to confuse me. Read or dump, which one decodes. Rename
>> > intel_bios_reader to intel_vbt_decode to be in line with the naming of
>> > all the other tools (particularly the closely related
>> > intel_opregion_decode tool) that decode previously gathered or dumped
>> > information.
>> >
>> > Signed-off-by: Jani Nikula 
>> 
>> Pushed patches 1-5 because they were trivial and I don't expect anyone
>> to care.
>> 
>> How about this one? I don't dare push without acks on the change.
>
> You're not alone in your confusion. I routinely end up trying to use
> the wrong tool. So I for one welcome this change.
>
> Acked-by: Ville Syrjälä 

Thanks, pushed with that and Petri's IRC ack.

BR,
Jani.

>
>> 
>> BR,
>> Jani.
>> 
>> >
>> > ---
>> >
>> > Patch 6/6 with -M option.
>> > ---
>> >  man/Makefile.am |  4 ++--
>> >  man/intel_bios_dumper.rst   |  2 +-
>> >  man/{intel_bios_reader.rst => intel_vbt_decode.rst} | 10 +-
>> >  tools/.gitignore|  2 +-
>> >  tools/Makefile.sources  |  6 +++---
>> >  tools/intel_opregion_decode.c   |  2 +-
>> >  tools/{intel_bios_reader.c => intel_vbt_decode.c}   |  0
>> >  7 files changed, 13 insertions(+), 13 deletions(-)
>> >  rename man/{intel_bios_reader.rst => intel_vbt_decode.rst} (89%)
>> >  rename tools/{intel_bios_reader.c => intel_vbt_decode.c} (100%)
>> >
>> > diff --git a/man/Makefile.am b/man/Makefile.am
>> > index e40e2e931ada..0098fa45a618 100644
>> > --- a/man/Makefile.am
>> > +++ b/man/Makefile.am
>> > @@ -3,7 +3,6 @@ appman_RST =   \
>> >intel_aubdump.rst   \
>> >intel_audio_dump.rst\
>> >intel_bios_dumper.rst   \
>> > -  intel_bios_reader.rst   \
>> >intel_error_decode.rst  \
>> >intel_gpu_frequency.rst \
>> >intel_gpu_top.rst   \
>> > @@ -16,7 +15,8 @@ appman_RST = \
>> >intel_upload_blit_large.rst \
>> >intel_upload_blit_large_gtt.rst \
>> >intel_upload_blit_large_map.rst \
>> > -  intel_upload_blit_small.rst
>> > +  intel_upload_blit_small.rst \
>> > +  intel_vbt_decode.rst
>> >  
>> >  if HAVE_RST2MAN
>> >  appman_DATA = $(appman_RST:rst=$(APP_MAN_SUFFIX))
>> > diff --git a/man/intel_bios_dumper.rst b/man/intel_bios_dumper.rst
>> > index 89e0001a70f7..b271b9b1afef 100644
>> > --- a/man/intel_bios_dumper.rst
>> > +++ b/man/intel_bios_dumper.rst
>> > @@ -33,4 +33,4 @@ Report bugs to https://bugs.freedesktop.org.
>> >  SEE ALSO
>> >  
>> >  
>> > -**intel_bios_reader(1)**
>> > +**intel_vbt_decode(1)**
>> > diff --git a/man/intel_bios_reader.rst b/man/intel_vbt_decode.rst
>> > similarity index 89%
>> > rename from man/intel_bios_reader.rst
>> > rename to man/intel_vbt_decode.rst
>> > index 0e935904bcfb..a8d36d500b6d 100644
>> > --- a/man/intel_bios_reader.rst
>> > +++ b/man/intel_vbt_decode.rst
>> > @@ -1,6 +1,6 @@
>> > -=
>> > -intel_bios_reader
>> > -=
>> > +
>> > +intel_vbt_decode
>> > +
>> >  
>> >  -
>> >  Intel Video BIOS Table parser
>> > @@ -16,12 +16,12 @@ Intel Video BIOS Table parser
>> >  SYNOPSIS
>> >  
>> >  
>> > -**intel_bios_reader** [*OPTIONS*]
>> > +**intel_vbt_decode** [*OPTIONS*]
>> >  
>> >  DESCRIPTION
>> >  ===
>> >  
>> > -**intel_bios_reader** is a tool to parse the Intel Video BIOS Tables 
>> > (VBT) and
>> > +**intel_vbt_decode** is a tool to parse the Intel Video BIOS Tables (VBT) 
>> > and
>> >  present the information in a human readable format.
>> >  
>> >  The preferred ways of getting the binary VBT to parse are:
>> > diff --git a/tools/.gitignore b/tools/.gitignore
>> > index 13825a3c9a74..7f5de26f1d07 100644
>> > --- a/tools/.gitignore
>> > +++ b/tools/.gitignore
>> > @@ -5,7 +5,7 @@ intel_aubdump
>> >  intel_audio_dump
>> >  intel_backlight
>> >  intel_bios_dumper
>> > -intel_bios_reader
>> > +intel_vbt_decode
>> >  intel_display_crc
>> >  intel_display_poller
>> >  intel_dump_decode
>> > diff --git a/tools/Makefile.sources b/tools/Makefile.sources
>> > index e2451ea1272c..2c41afffea39 100644
>> > --- a/tools/Makefile.sources
>> > +++ b/tools/Makefile.sources
>> > @@ -10,7 +10,6 @@ tools_prog_lists =   \
>> >intel_reg   \
>> >intel_backlight \
>> >intel_bios_dumper   \
>> > -  intel_bios_reader   \
>> >intel_display_crc   \
>> >intel_display_poller\
>> >intel_forcewaked\
>> > @@ -28,6 

Re: [Intel-gfx] [PATCH v2] drm/color: un-inline drm_color_lut_extract()

2017-01-31 Thread Jani Nikula
On Fri, 27 Jan 2017, Jani Nikula  wrote:
> The function is not that big, but it's also not used for anything
> performance critical. Make it a normal function.
>
> As a side effect, this apparently makes sparse smarter about what it's
> doing, and gets rid of the warning:
>
> ./include/drm/drm_color_mgmt.h:53:28: warning: shift too big (4294967295) for 
> type unsigned long
> ./include/drm/drm_color_mgmt.h:53:28: warning: cast truncates bits from 
> constant value (8000 becomes 0)
>
> v2: rebased
>
> Cc: Lionel Landwerlin 
> Reviewed-by: Daniel Vetter 
> Reviewed-by: Lionel Landwerlin 
> Signed-off-by: Jani Nikula 

This time, pushed to drm-misc-next. Thanks for the review.

BR,
Jani.

> ---
>  drivers/gpu/drm/drm_color_mgmt.c | 24 
>  include/drm/drm_color_mgmt.h | 27 ++-
>  2 files changed, 26 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 789b4c65cd69..cc23b9a505c0 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -88,6 +88,30 @@
>   */
>  
>  /**
> + * drm_color_lut_extract - clamp and round LUT entries
> + * @user_input: input value
> + * @bit_precision: number of bits the hw LUT supports
> + *
> + * Extract a degamma/gamma LUT value provided by user (in the form of
> + * _color_lut entries) and round it to the precision supported by the
> + * hardware.
> + */
> +uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision)
> +{
> + uint32_t val = user_input;
> + uint32_t max = 0x >> (16 - bit_precision);
> +
> + /* Round only if we're not using full precision. */
> + if (bit_precision < 16) {
> + val += 1UL << (16 - bit_precision - 1);
> + val >>= 16 - bit_precision;
> + }
> +
> + return clamp_val(val, 0, max);
> +}
> +EXPORT_SYMBOL(drm_color_lut_extract);
> +
> +/**
>   * drm_crtc_enable_color_mgmt - enable color management properties
>   * @crtc: DRM CRTC
>   * @degamma_lut_size: the size of the degamma lut (before CSC)
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index d9c2f680f5ae..bce4a532836d 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -25,6 +25,8 @@
>  
>  #include 
>  
> +uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision);
> +
>  void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>   uint degamma_lut_size,
>   bool has_ctm,
> @@ -33,29 +35,4 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>  int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
>int gamma_size);
>  
> -/**
> - * drm_color_lut_extract - clamp and round LUT entries
> - * @user_input: input value
> - * @bit_precision: number of bits the hw LUT supports
> - *
> - * Extract a degamma/gamma LUT value provided by user (in the form of
> - * _color_lut entries) and round it to the precision supported by the
> - * hardware.
> - */
> -static inline uint32_t drm_color_lut_extract(uint32_t user_input,
> -  uint32_t bit_precision)
> -{
> - uint32_t val = user_input;
> - uint32_t max = 0x >> (16 - bit_precision);
> -
> - /* Round only if we're not using full precision. */
> - if (bit_precision < 16) {
> - val += 1UL << (16 - bit_precision - 1);
> - val >>= 16 - bit_precision;
> - }
> -
> - return clamp_val(val, 0, max);
> -}
> -
> -
>  #endif

-- 
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 00/10] do_execbuffer tidy

2017-01-31 Thread Chris Wilson
On Tue, Jan 31, 2017 at 01:15:36PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> I've noticed a few opportunities to improve the readability of this functions
> and then kept spotting more and more which can be removed or compacted.
> 
> Eventually ended up with removing i915_execbuffer_params completely. But I 
> think
> it's OK since the plan between when it was added to now changed.

Most of it looks like churn duplicating patches I've already sent. :(
We have an open performance regression bug (that has only gotten worse
with multiple timelines) that I really would like to see some progress
on.
-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 02/10] drm/i915: Drop some unused fields from i915_execbuffer_params

2017-01-31 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

dev, file and ctx are unused.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index ee7b7bd17e29..2991751516f8 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -50,13 +50,10 @@
 #define BATCH_OFFSET_BIAS (256*1024)
 
 struct i915_execbuffer_params {
-   struct drm_device   *dev;
-   struct drm_file *file;
struct i915_vma *batch;
u32 dispatch_flags;
u32 batch_start;
struct intel_engine_cs  *engine;
-   struct i915_gem_context *ctx;
struct drm_i915_gem_request *request;
 };
 
@@ -1834,11 +1831,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
*data,
 * kept around beyond the duration of the IOCTL once the GPU
 * scheduler arrives.
 */
-   params.dev= dev;
-   params.file   = file;
params.engine = engine;
params.dispatch_flags = dispatch_flags;
-   params.ctx= ctx;
params.batch  = batch;
params.batch_start= batch_start_offset;
params.request= req;
-- 
2.7.4

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


[Intel-gfx] [PATCH 07/10] drm/i915: Drop unused engine parameter from i915_gem_validate_context

2017-01-31 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

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

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 57ae6573a37b..51cf3ff3e21d 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1222,7 +1222,7 @@ validate_exec_list(struct drm_device *dev,
 
 static struct i915_gem_context *
 i915_gem_validate_context(struct drm_device *dev, struct drm_file *file,
- struct intel_engine_cs *engine, const u32 ctx_id)
+ const u32 ctx_id)
 {
struct i915_gem_context *ctx;
 
@@ -1656,7 +1656,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
if (ret)
goto pre_mutex_err;
 
-   ctx = i915_gem_validate_context(dev, file, engine,
+   ctx = i915_gem_validate_context(dev, file,
i915_execbuffer2_get_context_id(*args));
if (IS_ERR(ctx)) {
mutex_unlock(>struct_mutex);
-- 
2.7.4

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


[Intel-gfx] [PATCH 06/10] drm/i915: Remove some single use locals i915_gem_do_execbuffer

2017-01-31 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Remove ctx_id, ggtt and vm since they are single use.

 textdata bss dec hex filename
  1085338   263982628 1114364  1100fc i915.ko.0
  1085290   263982628 1114316  1100cc i915.ko.1

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 82e74db5923b..57ae6573a37b 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1573,16 +1573,13 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
*data,
   struct drm_i915_gem_exec_object2 *exec)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct i915_ggtt *ggtt = _priv->ggtt;
struct eb_vmas *eb;
struct drm_i915_gem_exec_object2 shadow_exec_entry;
struct intel_engine_cs *engine;
struct i915_gem_context *ctx;
-   struct i915_address_space *vm;
struct drm_i915_gem_request *req;
struct i915_vma *batch;
u32 batch_start;
-   const u32 ctx_id = i915_execbuffer2_get_context_id(*args);
u32 dispatch_flags;
struct dma_fence *in_fence = NULL;
struct sync_file *out_fence = NULL;
@@ -1659,7 +1656,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
if (ret)
goto pre_mutex_err;
 
-   ctx = i915_gem_validate_context(dev, file, engine, ctx_id);
+   ctx = i915_gem_validate_context(dev, file, engine,
+   i915_execbuffer2_get_context_id(*args));
if (IS_ERR(ctx)) {
mutex_unlock(>struct_mutex);
ret = PTR_ERR(ctx);
@@ -1668,11 +1666,6 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
*data,
 
i915_gem_context_get(ctx);
 
-   if (ctx->ppgtt)
-   vm = >ppgtt->base;
-   else
-   vm = >base;
-
eb = eb_create(dev_priv, args);
if (eb == NULL) {
i915_gem_context_put(ctx);
@@ -1682,7 +1675,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
}
 
/* Look up object handles */
-   ret = eb_lookup_vmas(eb, exec, args, vm, file);
+   ret = eb_lookup_vmas(eb, exec, args, ctx->ppgtt ? >ppgtt->base :
+_priv->ggtt.base, file);
if (ret)
goto err;
 
-- 
2.7.4

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


[Intel-gfx] [PATCH 01/10] drm/i915: Tidy i915_gem_do_execbuffer

2017-01-31 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Instead of sprinkling around usage and initialization of
i915_execbuffer_params we can consolidate it just before
execbuf_submit for maintability and readability.

That way we can also drop the memset since it becomes
easy to spot we initialize all the fields.

 textdata bss dec hex filename
  1085466   263982628 1114492  11017c i915.ko.0
  1085402   263982628 1114428  11013c i915.ko.1

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 87 +++---
 1 file changed, 44 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 91c2393199a3..ee7b7bd17e29 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -50,14 +50,14 @@
 #define BATCH_OFFSET_BIAS (256*1024)
 
 struct i915_execbuffer_params {
-   struct drm_device   *dev;
-   struct drm_file *file;
-   struct i915_vma *batch;
-   u32 dispatch_flags;
-   u32 args_batch_start_offset;
-   struct intel_engine_cs  *engine;
-   struct i915_gem_context *ctx;
-   struct drm_i915_gem_request *request;
+   struct drm_device   *dev;
+   struct drm_file *file;
+   struct i915_vma *batch;
+   u32 dispatch_flags;
+   u32 batch_start;
+   struct intel_engine_cs  *engine;
+   struct i915_gem_context *ctx;
+   struct drm_i915_gem_request *request;
 };
 
 struct eb_vmas {
@@ -1484,11 +1484,10 @@ execbuf_submit(struct i915_execbuffer_params *params,
}
 
exec_len   = args->batch_len;
-   exec_start = params->batch->node.start +
-params->args_batch_start_offset;
+   exec_start = params->batch->node.start + params->batch_start;
 
if (exec_len == 0)
-   exec_len = params->batch->size - 
params->args_batch_start_offset;
+   exec_len = params->batch->size - params->batch_start;
 
ret = params->engine->emit_bb_start(params->request,
exec_start, exec_len,
@@ -1592,8 +1591,10 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
*data,
struct intel_engine_cs *engine;
struct i915_gem_context *ctx;
struct i915_address_space *vm;
-   struct i915_execbuffer_params params_master; /* XXX: will be removed 
later */
-   struct i915_execbuffer_params *params = _master;
+   struct drm_i915_gem_request *req;
+   struct i915_vma *batch;
+   u32 batch_start_offset;
+   struct i915_execbuffer_params params;
const u32 ctx_id = i915_execbuffer2_get_context_id(*args);
u32 dispatch_flags;
struct dma_fence *in_fence = NULL;
@@ -1685,8 +1686,6 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
else
vm = >base;
 
-   memset(_master, 0x00, sizeof(params_master));
-
eb = eb_create(dev_priv, args);
if (eb == NULL) {
i915_gem_context_put(ctx);
@@ -1701,7 +1700,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
goto err;
 
/* take note of the batch buffer before we might reorder the lists */
-   params->batch = eb_get_batch(eb);
+   batch = eb_get_batch(eb);
 
/* Move the objects en-masse into the GTT, evicting if necessary. */
need_relocs = (args->flags & I915_EXEC_NO_RELOC) == 0;
@@ -1725,24 +1724,24 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
*data,
}
 
/* Set the pending read domains for the batch buffer to COMMAND */
-   if (params->batch->obj->base.pending_write_domain) {
+   if (batch->obj->base.pending_write_domain) {
DRM_DEBUG("Attempting to use self-modifying batch buffer\n");
ret = -EINVAL;
goto err;
}
-   if (args->batch_start_offset > params->batch->size ||
-   args->batch_len > params->batch->size - args->batch_start_offset) {
+   if (args->batch_start_offset > batch->size ||
+   args->batch_len > batch->size - args->batch_start_offset) {
DRM_DEBUG("Attempting to use out-of-bounds batch\n");
ret = -EINVAL;
goto err;
}
 
-   params->args_batch_start_offset = args->batch_start_offset;
+   batch_start_offset = args->batch_start_offset;
if (engine->needs_cmd_parser && args->batch_len) {
struct i915_vma *vma;
 
vma = i915_gem_execbuffer_parse(engine, _exec_entry,
-   params->batch->obj,
+   batch->obj,

[Intel-gfx] [PATCH 05/10] drm/i915: Nuke i915_execbuffer_params

2017-01-31 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Now that it only contains three parameters we can pass them
directly to execbuf_submit just as well.

No effect on generated binary, just a source reduction.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 39 --
 1 file changed, 10 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index afbb56196162..82e74db5923b 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -49,12 +49,6 @@
 
 #define BATCH_OFFSET_BIAS (256*1024)
 
-struct i915_execbuffer_params {
-   u32 dispatch_flags;
-   u32 batch_start;
-   struct drm_i915_gem_request *request;
-};
-
 struct eb_vmas {
struct drm_i915_private *i915;
struct list_head vmas;
@@ -1404,11 +1398,10 @@ i915_gem_execbuffer_parse(struct intel_engine_cs 
*engine,
 }
 
 static int
-execbuf_submit(struct i915_execbuffer_params *params,
-  struct drm_i915_gem_execbuffer2 *args,
+execbuf_submit(struct drm_i915_gem_request *req, u32 batch_start,
+  u32 dispatch_flags, struct drm_i915_gem_execbuffer2 *args,
   struct list_head *vmas)
 {
-   struct drm_i915_gem_request *req = params->request;
struct drm_i915_private *dev_priv = req->i915;
struct intel_engine_cs *engine = req->engine;
u64 exec_start, exec_len;
@@ -1481,17 +1474,16 @@ execbuf_submit(struct i915_execbuffer_params *params,
}
 
exec_len   = args->batch_len;
-   exec_start = req->batch->node.start + params->batch_start;
+   exec_start = req->batch->node.start + batch_start;
 
if (exec_len == 0)
-   exec_len = req->batch->size - params->batch_start;
+   exec_len = req->batch->size - batch_start;
 
-   ret = engine->emit_bb_start(req, exec_start, exec_len,
-   params->dispatch_flags);
+   ret = engine->emit_bb_start(req, exec_start, exec_len, dispatch_flags);
if (ret)
return ret;
 
-   trace_i915_gem_ring_dispatch(req, params->dispatch_flags);
+   trace_i915_gem_ring_dispatch(req, dispatch_flags);
 
i915_gem_execbuffer_move_to_active(vmas, req);
 
@@ -1589,8 +1581,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct i915_address_space *vm;
struct drm_i915_gem_request *req;
struct i915_vma *batch;
-   u32 batch_start_offset;
-   struct i915_execbuffer_params params;
+   u32 batch_start;
const u32 ctx_id = i915_execbuffer2_get_context_id(*args);
u32 dispatch_flags;
struct dma_fence *in_fence = NULL;
@@ -1732,7 +1723,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
goto err;
}
 
-   batch_start_offset = args->batch_start_offset;
+   batch_start = args->batch_start_offset;
if (engine->needs_cmd_parser && args->batch_len) {
struct i915_vma *vma;
 
@@ -1758,7 +1749,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
 * command parser has accepted.
 */
dispatch_flags |= I915_DISPATCH_SECURE;
-   batch_start_offset = 0;
+   batch_start = 0;
batch = vma;
}
}
@@ -1824,17 +1815,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
*data,
if (ret)
goto err_request;
 
-   /*
-* Save assorted stuff away to pass through to *_submission().
-* NB: This data should be 'persistent' and not local as it will
-* kept around beyond the duration of the IOCTL once the GPU
-* scheduler arrives.
-*/
-   params.dispatch_flags = dispatch_flags;
-   params.batch_start= batch_start_offset;
-   params.request= req;
-
-   ret = execbuf_submit(, args, >vmas);
+   ret = execbuf_submit(req, batch_start, dispatch_flags, args, >vmas);
 err_request:
__i915_add_request(req, ret == 0);
if (out_fence) {
-- 
2.7.4

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


[Intel-gfx] [PATCH 00/10] do_execbuffer tidy

2017-01-31 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

I've noticed a few opportunities to improve the readability of this functions
and then kept spotting more and more which can be removed or compacted.

Eventually ended up with removing i915_execbuffer_params completely. But I think
it's OK since the plan between when it was added to now changed.

Overall reduction in source and binary, hopefully for tidier code.

 textdata bss dec hex filename
  1085466   263982628 1114492  11017c i915.ko.0
  1085290   263982628 1114316  1100cc i915.ko.1

Tvrtko Ursulin (10):
  drm/i915: Tidy i915_gem_do_execbuffer
  drm/i915: Drop some unused fields from i915_execbuffer_params
  drm/i915: Tidy execbuf_submit
  drm/i915: Remove batch field from i915_execbuffer_params
  drm/i915: Nuke i915_execbuffer_params
  drm/i915: Remove some single use locals i915_gem_do_execbuffer
  drm/i915: Drop unused engine parameter from i915_gem_validate_context
  drm/i915: eb_engine_select only needs flags
  drm/i915: Pass file_priv to eb_select_engine
  drm/i915: Remove some unecessary line breaks

 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 159 +++--
 1 file changed, 60 insertions(+), 99 deletions(-)

-- 
2.7.4

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


[Intel-gfx] [PATCH 04/10] drm/i915: Remove batch field from i915_execbuffer_params

2017-01-31 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Also redundant since it is stored in the request.

 textdata bss dec hex filename
  1085354   263982628 1114380  11010c i915.ko.0
  1085338   263982628 1114364  1100fc i915.ko.1

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

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 119322eb9897..afbb56196162 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -50,7 +50,6 @@
 #define BATCH_OFFSET_BIAS (256*1024)
 
 struct i915_execbuffer_params {
-   struct i915_vma *batch;
u32 dispatch_flags;
u32 batch_start;
struct drm_i915_gem_request *request;
@@ -1482,10 +1481,10 @@ execbuf_submit(struct i915_execbuffer_params *params,
}
 
exec_len   = args->batch_len;
-   exec_start = params->batch->node.start + params->batch_start;
+   exec_start = req->batch->node.start + params->batch_start;
 
if (exec_len == 0)
-   exec_len = params->batch->size - params->batch_start;
+   exec_len = req->batch->size - params->batch_start;
 
ret = engine->emit_bb_start(req, exec_start, exec_len,
params->dispatch_flags);
@@ -1832,7 +1831,6 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
 * scheduler arrives.
 */
params.dispatch_flags = dispatch_flags;
-   params.batch  = batch;
params.batch_start= batch_start_offset;
params.request= req;
 
-- 
2.7.4

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


[Intel-gfx] [PATCH 10/10] drm/i915: Remove some unecessary line breaks

2017-01-31 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Just spotted a few lines which fit in 80 chars and were split.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index ff102b39c3b3..18312959f961 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1066,8 +1066,7 @@ i915_gem_execbuffer_relocate_slow(struct drm_device *dev,
goto err;
 
need_relocs = (args->flags & I915_EXEC_NO_RELOC) == 0;
-   ret = i915_gem_execbuffer_reserve(engine, >vmas, ctx,
- _relocs);
+   ret = i915_gem_execbuffer_reserve(engine, >vmas, ctx, _relocs);
if (ret)
goto err;
 
@@ -1682,8 +1681,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
 
/* Move the objects en-masse into the GTT, evicting if necessary. */
need_relocs = (args->flags & I915_EXEC_NO_RELOC) == 0;
-   ret = i915_gem_execbuffer_reserve(engine, >vmas, ctx,
- _relocs);
+   ret = i915_gem_execbuffer_reserve(engine, >vmas, ctx, _relocs);
if (ret)
goto err;
 
@@ -1693,8 +1691,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
if (ret) {
if (ret == -EFAULT) {
ret = i915_gem_execbuffer_relocate_slow(dev, args, file,
-   engine,
-   eb, exec, ctx);
+   engine, eb,
+   exec, ctx);
BUG_ON(!mutex_is_locked(>struct_mutex));
}
if (ret)
@@ -1719,8 +1717,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct i915_vma *vma;
 
vma = i915_gem_execbuffer_parse(engine, _exec_entry,
-   batch->obj,
-   eb,
+   batch->obj, eb,
args->batch_start_offset,
args->batch_len,
drm_is_current_master(file));
-- 
2.7.4

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


[Intel-gfx] [PATCH 08/10] drm/i915: eb_engine_select only needs flags

2017-01-31 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Not the whole args struct needs to be passed in.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 51cf3ff3e21d..ae94cc27c9ba 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1519,11 +1519,10 @@ static const enum intel_engine_id 
user_ring_map[I915_USER_RINGS + 1] = {
 };
 
 static struct intel_engine_cs *
-eb_select_engine(struct drm_i915_private *dev_priv,
-struct drm_file *file,
-struct drm_i915_gem_execbuffer2 *args)
+eb_select_engine(struct drm_i915_private *dev_priv, struct drm_file *file,
+u64 flags)
 {
-   unsigned int user_ring_id = args->flags & I915_EXEC_RING_MASK;
+   unsigned int user_ring_id = flags & I915_EXEC_RING_MASK;
struct intel_engine_cs *engine;
 
if (user_ring_id > I915_USER_RINGS) {
@@ -1532,14 +1531,14 @@ eb_select_engine(struct drm_i915_private *dev_priv,
}
 
if ((user_ring_id != I915_EXEC_BSD) &&
-   ((args->flags & I915_EXEC_BSD_MASK) != 0)) {
+   ((flags & I915_EXEC_BSD_MASK) != 0)) {
DRM_DEBUG("execbuf with non bsd ring but with invalid "
- "bsd dispatch flags: %d\n", (int)(args->flags));
+ "bsd dispatch flags: %d\n", (int)(flags));
return NULL;
}
 
if (user_ring_id == I915_EXEC_BSD && HAS_BSD2(dev_priv)) {
-   unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK;
+   unsigned int bsd_idx = flags & I915_EXEC_BSD_MASK;
 
if (bsd_idx == I915_EXEC_BSD_DEFAULT) {
bsd_idx = gen8_dispatch_bsd_engine(dev_priv, file);
@@ -1604,7 +1603,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
if (args->flags & I915_EXEC_IS_PINNED)
dispatch_flags |= I915_DISPATCH_PINNED;
 
-   engine = eb_select_engine(dev_priv, file, args);
+   engine = eb_select_engine(dev_priv, file, args->flags);
if (!engine)
return -EINVAL;
 
-- 
2.7.4

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


[Intel-gfx] [PATCH 09/10] drm/i915: Pass file_priv to eb_select_engine

2017-01-31 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

file_priv is what it needs to pass on to gen8_dispatch_bsd_engine so
simplify things by passing it straight away.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index ae94cc27c9ba..ff102b39c3b3 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1496,10 +1496,8 @@ execbuf_submit(struct drm_i915_gem_request *req, u32 
batch_start,
  */
 static unsigned int
 gen8_dispatch_bsd_engine(struct drm_i915_private *dev_priv,
-struct drm_file *file)
+struct drm_i915_file_private *file_priv)
 {
-   struct drm_i915_file_private *file_priv = file->driver_priv;
-
/* Check whether the file_priv has already selected one ring. */
if ((int)file_priv->bsd_engine < 0)
file_priv->bsd_engine = atomic_fetch_xor(1,
@@ -1519,8 +1517,8 @@ static const enum intel_engine_id 
user_ring_map[I915_USER_RINGS + 1] = {
 };
 
 static struct intel_engine_cs *
-eb_select_engine(struct drm_i915_private *dev_priv, struct drm_file *file,
-u64 flags)
+eb_select_engine(struct drm_i915_private *dev_priv,
+struct drm_i915_file_private *file_priv, u64 flags)
 {
unsigned int user_ring_id = flags & I915_EXEC_RING_MASK;
struct intel_engine_cs *engine;
@@ -1541,7 +1539,7 @@ eb_select_engine(struct drm_i915_private *dev_priv, 
struct drm_file *file,
unsigned int bsd_idx = flags & I915_EXEC_BSD_MASK;
 
if (bsd_idx == I915_EXEC_BSD_DEFAULT) {
-   bsd_idx = gen8_dispatch_bsd_engine(dev_priv, file);
+   bsd_idx = gen8_dispatch_bsd_engine(dev_priv, file_priv);
} else if (bsd_idx >= I915_EXEC_BSD_RING1 &&
   bsd_idx <= I915_EXEC_BSD_RING2) {
bsd_idx >>= I915_EXEC_BSD_SHIFT;
@@ -1603,7 +1601,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
if (args->flags & I915_EXEC_IS_PINNED)
dispatch_flags |= I915_DISPATCH_PINNED;
 
-   engine = eb_select_engine(dev_priv, file, args->flags);
+   engine = eb_select_engine(dev_priv, file->driver_priv, args->flags);
if (!engine)
return -EINVAL;
 
-- 
2.7.4

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


[Intel-gfx] [PATCH 03/10] drm/i915: Tidy execbuf_submit

2017-01-31 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Use a local variable for storing the request and engine
and at the same time drop the engine field from
i915_execbuffer_params since it is available from the
request.

 textdata bss dec hex filename
  1085402   263982628 1114428  11013c i915.ko.0
  1085354   263982628 1114380  11010c i915.ko.1

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

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 2991751516f8..119322eb9897 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -53,7 +53,6 @@ struct i915_execbuffer_params {
struct i915_vma *batch;
u32 dispatch_flags;
u32 batch_start;
-   struct intel_engine_cs  *engine;
struct drm_i915_gem_request *request;
 };
 
@@ -1410,17 +1409,19 @@ execbuf_submit(struct i915_execbuffer_params *params,
   struct drm_i915_gem_execbuffer2 *args,
   struct list_head *vmas)
 {
-   struct drm_i915_private *dev_priv = params->request->i915;
+   struct drm_i915_gem_request *req = params->request;
+   struct drm_i915_private *dev_priv = req->i915;
+   struct intel_engine_cs *engine = req->engine;
u64 exec_start, exec_len;
int instp_mode;
u32 instp_mask;
int ret;
 
-   ret = i915_gem_execbuffer_move_to_gpu(params->request, vmas);
+   ret = i915_gem_execbuffer_move_to_gpu(req, vmas);
if (ret)
return ret;
 
-   ret = i915_switch_context(params->request);
+   ret = i915_switch_context(req);
if (ret)
return ret;
 
@@ -1430,25 +1431,25 @@ execbuf_submit(struct i915_execbuffer_params *params,
case I915_EXEC_CONSTANTS_REL_GENERAL:
case I915_EXEC_CONSTANTS_ABSOLUTE:
case I915_EXEC_CONSTANTS_REL_SURFACE:
-   if (instp_mode != 0 && params->engine->id != RCS) {
+   if (instp_mode != 0 && engine->id != RCS) {
DRM_DEBUG("non-0 rel constants mode on non-RCS\n");
return -EINVAL;
}
 
if (instp_mode != dev_priv->relative_constants_mode) {
-   if (INTEL_INFO(dev_priv)->gen < 4) {
+   if (INTEL_GEN(dev_priv) < 4) {
DRM_DEBUG("no rel constants on pre-gen4\n");
return -EINVAL;
}
 
-   if (INTEL_INFO(dev_priv)->gen > 5 &&
+   if (INTEL_GEN(dev_priv) > 5 &&
instp_mode == I915_EXEC_CONSTANTS_REL_SURFACE) {
DRM_DEBUG("rel surface constants mode invalid 
on gen5+\n");
return -EINVAL;
}
 
/* The HW changed the meaning on this bit on gen6 */
-   if (INTEL_INFO(dev_priv)->gen >= 6)
+   if (INTEL_GEN(dev_priv) >= 6)
instp_mask &= ~I915_EXEC_CONSTANTS_REL_SURFACE;
}
break;
@@ -1457,11 +1458,11 @@ execbuf_submit(struct i915_execbuffer_params *params,
return -EINVAL;
}
 
-   if (params->engine->id == RCS &&
+   if (engine->id == RCS &&
instp_mode != dev_priv->relative_constants_mode) {
-   struct intel_ring *ring = params->request->ring;
+   struct intel_ring *ring = req->ring;
 
-   ret = intel_ring_begin(params->request, 4);
+   ret = intel_ring_begin(req, 4);
if (ret)
return ret;
 
@@ -1475,7 +1476,7 @@ execbuf_submit(struct i915_execbuffer_params *params,
}
 
if (args->flags & I915_EXEC_GEN7_SOL_RESET) {
-   ret = i915_reset_gen7_sol_offsets(params->request);
+   ret = i915_reset_gen7_sol_offsets(req);
if (ret)
return ret;
}
@@ -1486,15 +1487,14 @@ execbuf_submit(struct i915_execbuffer_params *params,
if (exec_len == 0)
exec_len = params->batch->size - params->batch_start;
 
-   ret = params->engine->emit_bb_start(params->request,
-   exec_start, exec_len,
-   params->dispatch_flags);
+   ret = engine->emit_bb_start(req, exec_start, exec_len,
+   params->dispatch_flags);
if (ret)
return ret;
 
-   trace_i915_gem_ring_dispatch(params->request, params->dispatch_flags);
+   trace_i915_gem_ring_dispatch(req, params->dispatch_flags);
 
- 

Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2017-01-31 Thread Imre Deak
On Tue, Jan 31, 2017 at 01:12:05PM +0100, Rafael J. Wysocki wrote:
> On 1/31/2017 1:02 PM, Imre Deak wrote:
> >On Tue, Jan 31, 2017 at 12:39:35PM +0100, Rafael J. Wysocki wrote:
> >>On 1/31/2017 11:58 AM, Imre Deak wrote:
> >>>Hi Rafael,
> >>Hi,
> >>
> >>>On Mon, Jan 30, 2017 at 11:44:37PM +0100, Rafael J. Wysocki wrote:
> On 1/24/2017 2:33 AM, Sedat Dilek wrote:
> >On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki  
> >wrote:
> >>On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek  
> >>wrote:
> >>>Hi,
> >>>
> >>>I have already reported this issue in [1].
> >>>One of the issue was solved.
> >>>Unfortunately, it looks like there is still a different problem here
> >>>(Ubuntu/precise AMD64).
> >>>
> >>>I tried v4.10-rc1 and latest Linus tree up to...
> >>>
> >>>commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
> >>>"mm/filemap: fix parameters to test_bit()"
> >>>
> >>>Here we go...
> >>>
> >>>[   29.636047] BUG: sleeping function called from invalid context at
> >>>drivers/base/power/runtime.c:1032
> >>>[   29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: 
> >>>Xorg
> >>>[   29.636058] 1 lock held by Xorg/1500:
> >>>[   29.636060]  #0:  (>struct_mutex){+.+.+.}, at:
> >>>[] i915_mutex_lock_interruptible+0x43/0x140 [i915]
> >>>[   29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
> >>>4.10.0-rc1-6-iniza-amd64 #1
> >>>[   29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> >>>530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> >>>[   29.636111] Call Trace:
> >>>[   29.636120]  dump_stack+0x85/0xc2
> >>>[   29.636124]  ___might_sleep+0x196/0x260
> >>>[   29.636127]  __might_sleep+0x53/0xb0
> >>>[   29.636131]  __pm_runtime_resume+0x7a/0x90
> >>>[   29.636159]  intel_runtime_pm_get+0x25/0x90 [i915]
> >>>[   29.636189]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
> >>>[   29.636220]  i915_vma_bind+0xaf/0x1e0 [i915]
> >>>[   29.636248]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
> >>>[   29.636272]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 
> >>>[i915]
> >>>[   29.636275]  ? trace_hardirqs_on+0xd/0x10
> >>>[   29.636294]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 
> >>>[i915]
> >>>[   29.636316]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 
> >>>[i915]
> >>>[   29.636342]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
> >>>[   29.636347]  ? __might_fault+0x4e/0xb0
> >>>[   29.636373]  i915_gem_execbuffer2+0xc5/0x260 [i915]
> >>>[   29.636376]  ? __might_fault+0x4e/0xb0
> >>>[   29.636395]  drm_ioctl+0x206/0x450 [drm]
> >>>[   29.636420]  ? i915_gem_execbuffer+0x340/0x340 [i915]
> >>>[   29.636425]  ? __fget+0x5/0x200
> >>>[   29.636429]  do_vfs_ioctl+0x91/0x6f0
> >>>[   29.636431]  ? __fget+0x111/0x200
> >>>[   29.636433]  ? __fget+0x5/0x200
> >>>[   29.636436]  SyS_ioctl+0x79/0x90
> >>>[   29.636441]  entry_SYSCALL_64_fastpath+0x23/0xc6
> >>>
> >>>On suspend/resume I see the same call trace.
> >>>[2] points to the "BUG" line.
> >>Well, this appears to be an i915 issue, but not a serious one.
> >>
> >>Clearly, a function that may sleep (pm_runtime_get_sync() in
> >>intel_runtime_pm_get()) is called with disabled interrupts.  If I
> >>understand the code correctly, though, it actually is not going to
> >>sleep in this particular case, because pm_runtime_get_sync() has
> >>already been called once for this device in the same code path which
> >>means that this particular instance will return immediately, so this
> >>is a false-positive (most likely).
> >>>Not sure what's the root cause, but thought to clarify the above:
> >>>
> >>>Yes, i915_gem_do_execbuffer() does take an RPM reference to optimize
> >>>things, so the RPM get in aliasing_gtt_bind_vma() won't need to resume
> >>>the device on this path. This isn't a guarantee though,
> >>>aliasing_gtt_bind_vma() could be called from other places without an RPM
> >>>reference. So preemption being disabled at that point is not
> >>>intentional. I also can't see where on the above path it would get
> >>>disabled due to a bug or otherwise.
> >>The i915 code is correct AFAICS, but the core complains about a nested
> >>invocation of pm_runtime_get_sync() with disabled interrupts (which looks OK
> >>though), so the complaint is a false positive.
> >Well, my point was that interrupts (or preemption) doesn't seem to get
> >disabled anywhere on that path.
> 
> But the might_sleep_if() assertion in __pm_runtime_resume() triggers for
> some reason.  I wonder why then?
> 
> Of course, I may be overlooking something in the i915 code.
> 
> In any case, if you do
> 
> pm_runtime_get_sync(dev)
> local_irq_disable()
> pm_runtime_get_sync(dev)
> 
> pm_runtime_put(dev)
> local_irq_enable()
> 

Re: [Intel-gfx] [PATCH] drm/atomic: Fix double free in drm_atomic_state_default_clear

2017-01-31 Thread Daniel Vetter
On Tue, Jan 31, 2017 at 10:04:09AM -0200, Gustavo Padovan wrote:
> Hi Maarten,
> 
> 2017-01-31 Maarten Lankhorst :
> 
> > drm_atomic_helper_page_flip and drm_atomic_ioctl set their own events
> > in crtc_state->event. But when it's set the event is freed in 2 places.
> > 
> > Solve this by only freeing the event in the atomic ioctl when it
> > allocated its own event.
> > 
> > This has been broken twice. The first time when the code was introduced,
> > but only in the corner case when an event is allocated, but more crtc's
> > were included by atomic check and then failing. This can mostly
> > happen when you do an atomic modeset in i915 and the display clock is
> > changed, which forces all crtc's to be included to the state.
> > 
> > This has been broken worse by adding in-fences support, which caused
> > the double free to be done unconditionally.
> > 
> > [IGT] kms_rotation_crc: starting subtest primary-rotation-180
> > =
> > BUG kmalloc-128 (Tainted: G U ): Object already free
> > -
> > 
> > Disabling lock debugging due to kernel taint
> > INFO: Allocated in drm_atomic_helper_setup_commit+0x285/0x2f0 
> > [drm_kms_helper] age=0 cpu=3 pid=1529
> >  ___slab_alloc+0x308/0x3b0
> >  __slab_alloc+0xd/0x20
> >  kmem_cache_alloc_trace+0x92/0x1c0
> >  drm_atomic_helper_setup_commit+0x285/0x2f0 [drm_kms_helper]
> >  intel_atomic_commit+0x35/0x4f0 [i915]
> >  drm_atomic_commit+0x46/0x50 [drm]
> >  drm_mode_atomic_ioctl+0x7d4/0xab0 [drm]
> >  drm_ioctl+0x2b3/0x490 [drm]
> >  do_vfs_ioctl+0x69c/0x700
> >  SyS_ioctl+0x4e/0x80
> >  entry_SYSCALL_64_fastpath+0x13/0x94
> > INFO: Freed in drm_event_cancel_free+0xa3/0xb0 [drm] age=0 cpu=3 pid=1529
> >  __slab_free+0x48/0x2e0
> >  kfree+0x159/0x1a0
> >  drm_event_cancel_free+0xa3/0xb0 [drm]
> >  drm_mode_atomic_ioctl+0x86d/0xab0 [drm]
> >  drm_ioctl+0x2b3/0x490 [drm]
> >  do_vfs_ioctl+0x69c/0x700
> >  SyS_ioctl+0x4e/0x80
> >  entry_SYSCALL_64_fastpath+0x13/0x94
> > INFO: Slab 0xde1f0997b080 objects=17 used=2 fp=0x92fb65ec2578 
> > flags=0x2008101
> > INFO: Object 0x92fb65ec2578 @offset=1400 fp=0x92fb65ec2ae8
> > 
> > Redzone 92fb65ec2570: bb bb bb bb bb bb bb bb  
> > 
> > Object 92fb65ec2578: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> > 
> > Object 92fb65ec2588: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> > 
> > Object 92fb65ec2598: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> > 
> > Object 92fb65ec25a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> > 
> > Object 92fb65ec25b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> > 
> > Object 92fb65ec25c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> > 
> > Object 92fb65ec25d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> > 
> > Object 92fb65ec25e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  
> > kkk.
> > Redzone 92fb65ec25f8: bb bb bb bb bb bb bb bb  
> > 
> > Padding 92fb65ec2738: 5a 5a 5a 5a 5a 5a 5a 5a  
> > 
> > CPU: 3 PID: 180 Comm: kworker/3:2 Tainted: GBU  
> > 4.10.0-rc6-patser+ #5039
> > Hardware name:  /NUC5PPYB, BIOS 
> > PYBSWCEL.86A.0031.2015.0601.1712 06/01/2015
> > Workqueue: events intel_atomic_helper_free_state [i915]
> > Call Trace:
> >  dump_stack+0x4d/0x6d
> >  print_trailer+0x20c/0x220
> >  free_debug_processing+0x1c6/0x330
> >  ? drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
> >  __slab_free+0x48/0x2e0
> >  ? drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
> >  kfree+0x159/0x1a0
> >  drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
> >  ? drm_atomic_state_clear+0x30/0x30 [drm]
> >  intel_atomic_state_clear+0xd/0x20 [i915]
> >  drm_atomic_state_clear+0x1a/0x30 [drm]
> >  __drm_atomic_state_free+0x13/0x60 [drm]
> >  intel_atomic_helper_free_state+0x5d/0x70 [i915]
> >  process_one_work+0x260/0x4a0
> >  worker_thread+0x2d1/0x4f0
> >  kthread+0x127/0x130
> >  ? process_one_work+0x4a0/0x4a0
> >  ? kthread_stop+0x120/0x120
> >  ret_from_fork+0x29/0x40
> > FIX kmalloc-128: Object at 0x92fb65ec2578 not freed
> > 
> > Fixes: 3b24f7d67581 ("drm/atomic: Add struct drm_crtc_commit to track async 
> > updates")
> > Fixes: 9626014258a5 ("drm/fence: add in-fences support")
> > Cc:  # v4.8+
> > Cc: Daniel Vetter 
> > Signed-off-by: Maarten Lankhorst 
> > Reviewed-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 13 -
> >  1 file changed, 8 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c 

Re: [Intel-gfx] [PATCH v2 26/38] drm/i915: Exercise filling the top/bottom portions of the ppgtt

2017-01-31 Thread Joonas Lahtinen
On to, 2017-01-19 at 11:41 +, Chris Wilson wrote:
> Allocate objects with varying number of pages (which should hopefully
> consist of a mixture of contiguous page chunks and so coalesced sg
> lists) and check that the sg walkers in insert_pages cope.
> 
> Signed-off-by: Chris Wilson 



> +static int fill_hole(struct drm_i915_private *i915,
> +  struct i915_address_space *vm,
> +  u64 hole_start, u64 hole_end,
> +  unsigned long end_time)
> +{
> + const u64 hole_size = hole_end - hole_start;
> + struct drm_i915_gem_object *obj;
> + const unsigned long max_pages =
> + min_t(u64, 1 << 20, hole_size/2 >> PAGE_SHIFT);

At least make a comment, why this specific number. It's good to know if
something is a hard limit vs. pulled out of thin air.

> + for_each_prime_number_from(prime, 2, 13) {

SMALL_PRIME_MAX or something similar? Also, what are we targeting with
the selected number, staying below X bytes, N seconds or what?

I think all the tests could be clarified with such comments.



> + GEM_BUG_ON(!full_size);

This could be in huge_gem_object too?

> + obj = huge_gem_object(i915, PAGE_SIZE, full_size);
> + if (IS_ERR(obj))
> + break;
> +
> + list_add(>batch_pool_link, );
> +
> + /* Align differing sized objects against the edges, and
> +  * check we don't walk off into the void when binding
> +  * them into the GTT.
> +  */
> + for (p = phases; p->name; p++) {
> + u64 flags;
> +
> + flags = p->base;

"offset" and "flags" could be separate variables, just for readability
as this is a test.

> + list_for_each_entry(obj, , 
> batch_pool_link) {
> + vma = i915_vma_instance(obj, vm, NULL);
> + if (IS_ERR(vma))
> + continue;
> +
> + err = i915_vma_pin(vma, 0, 0, flags);
> + if (err) {
> + pr_err("Fill %s pin failed with 
> err=%d on size=%lu pages (prime=%lu), flags=%llx\n", p->name, err, npages, 
> prime, flags);
> + goto err;
> + }
> +
> + i915_vma_unpin(vma);
> +
> + flags += p->step;
> + if (flags < hole_start ||
> + flags > hole_end)

This is also why I'd prefer the variables to be separate, you could
check <= and >= .

> + break;

Make a comment for this block, each previous object is smaller, and
that we rely on the list for ordering.

Even when the lack of comments tried to deceive me, I think I
understood it right;

Reviewed-by: Joonas Lahtinen 

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


Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2017-01-31 Thread Rafael J. Wysocki

On 1/31/2017 1:02 PM, Imre Deak wrote:

On Tue, Jan 31, 2017 at 12:39:35PM +0100, Rafael J. Wysocki wrote:

On 1/31/2017 11:58 AM, Imre Deak wrote:

Hi Rafael,

Hi,


On Mon, Jan 30, 2017 at 11:44:37PM +0100, Rafael J. Wysocki wrote:

On 1/24/2017 2:33 AM, Sedat Dilek wrote:

On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki  wrote:

On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek  wrote:

Hi,

I have already reported this issue in [1].
One of the issue was solved.
Unfortunately, it looks like there is still a different problem here
(Ubuntu/precise AMD64).

I tried v4.10-rc1 and latest Linus tree up to...

commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
"mm/filemap: fix parameters to test_bit()"

Here we go...

[   29.636047] BUG: sleeping function called from invalid context at
drivers/base/power/runtime.c:1032
[   29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
[   29.636058] 1 lock held by Xorg/1500:
[   29.636060]  #0:  (>struct_mutex){+.+.+.}, at:
[] i915_mutex_lock_interruptible+0x43/0x140 [i915]
[   29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
4.10.0-rc1-6-iniza-amd64 #1
[   29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
[   29.636111] Call Trace:
[   29.636120]  dump_stack+0x85/0xc2
[   29.636124]  ___might_sleep+0x196/0x260
[   29.636127]  __might_sleep+0x53/0xb0
[   29.636131]  __pm_runtime_resume+0x7a/0x90
[   29.636159]  intel_runtime_pm_get+0x25/0x90 [i915]
[   29.636189]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
[   29.636220]  i915_vma_bind+0xaf/0x1e0 [i915]
[   29.636248]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
[   29.636272]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
[   29.636275]  ? trace_hardirqs_on+0xd/0x10
[   29.636294]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
[   29.636316]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
[   29.636342]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
[   29.636347]  ? __might_fault+0x4e/0xb0
[   29.636373]  i915_gem_execbuffer2+0xc5/0x260 [i915]
[   29.636376]  ? __might_fault+0x4e/0xb0
[   29.636395]  drm_ioctl+0x206/0x450 [drm]
[   29.636420]  ? i915_gem_execbuffer+0x340/0x340 [i915]
[   29.636425]  ? __fget+0x5/0x200
[   29.636429]  do_vfs_ioctl+0x91/0x6f0
[   29.636431]  ? __fget+0x111/0x200
[   29.636433]  ? __fget+0x5/0x200
[   29.636436]  SyS_ioctl+0x79/0x90
[   29.636441]  entry_SYSCALL_64_fastpath+0x23/0xc6

On suspend/resume I see the same call trace.
[2] points to the "BUG" line.

Well, this appears to be an i915 issue, but not a serious one.

Clearly, a function that may sleep (pm_runtime_get_sync() in
intel_runtime_pm_get()) is called with disabled interrupts.  If I
understand the code correctly, though, it actually is not going to
sleep in this particular case, because pm_runtime_get_sync() has
already been called once for this device in the same code path which
means that this particular instance will return immediately, so this
is a false-positive (most likely).

Not sure what's the root cause, but thought to clarify the above:

Yes, i915_gem_do_execbuffer() does take an RPM reference to optimize
things, so the RPM get in aliasing_gtt_bind_vma() won't need to resume
the device on this path. This isn't a guarantee though,
aliasing_gtt_bind_vma() could be called from other places without an RPM
reference. So preemption being disabled at that point is not
intentional. I also can't see where on the above path it would get
disabled due to a bug or otherwise.

The i915 code is correct AFAICS, but the core complains about a nested
invocation of pm_runtime_get_sync() with disabled interrupts (which looks OK
though), so the complaint is a false positive.

Well, my point was that interrupts (or preemption) doesn't seem to get
disabled anywhere on that path.


But the might_sleep_if() assertion in __pm_runtime_resume() triggers for 
some reason.  I wonder why then?


Of course, I may be overlooking something in the i915 code.

In any case, if you do

pm_runtime_get_sync(dev)
local_irq_disable()
pm_runtime_get_sync(dev)

pm_runtime_put(dev)
local_irq_enable()
pm_runtime_put(dev)

that is technically correct, but it will cause the core to complain.

Thanks,
Rafael

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


Re: [Intel-gfx] [PATCH] drm/atomic: Fix double free in drm_atomic_state_default_clear

2017-01-31 Thread Gustavo Padovan
Hi Maarten,

2017-01-31 Maarten Lankhorst :

> drm_atomic_helper_page_flip and drm_atomic_ioctl set their own events
> in crtc_state->event. But when it's set the event is freed in 2 places.
> 
> Solve this by only freeing the event in the atomic ioctl when it
> allocated its own event.
> 
> This has been broken twice. The first time when the code was introduced,
> but only in the corner case when an event is allocated, but more crtc's
> were included by atomic check and then failing. This can mostly
> happen when you do an atomic modeset in i915 and the display clock is
> changed, which forces all crtc's to be included to the state.
> 
> This has been broken worse by adding in-fences support, which caused
> the double free to be done unconditionally.
> 
> [IGT] kms_rotation_crc: starting subtest primary-rotation-180
> =
> BUG kmalloc-128 (Tainted: G U ): Object already free
> -
> 
> Disabling lock debugging due to kernel taint
> INFO: Allocated in drm_atomic_helper_setup_commit+0x285/0x2f0 
> [drm_kms_helper] age=0 cpu=3 pid=1529
>  ___slab_alloc+0x308/0x3b0
>  __slab_alloc+0xd/0x20
>  kmem_cache_alloc_trace+0x92/0x1c0
>  drm_atomic_helper_setup_commit+0x285/0x2f0 [drm_kms_helper]
>  intel_atomic_commit+0x35/0x4f0 [i915]
>  drm_atomic_commit+0x46/0x50 [drm]
>  drm_mode_atomic_ioctl+0x7d4/0xab0 [drm]
>  drm_ioctl+0x2b3/0x490 [drm]
>  do_vfs_ioctl+0x69c/0x700
>  SyS_ioctl+0x4e/0x80
>  entry_SYSCALL_64_fastpath+0x13/0x94
> INFO: Freed in drm_event_cancel_free+0xa3/0xb0 [drm] age=0 cpu=3 pid=1529
>  __slab_free+0x48/0x2e0
>  kfree+0x159/0x1a0
>  drm_event_cancel_free+0xa3/0xb0 [drm]
>  drm_mode_atomic_ioctl+0x86d/0xab0 [drm]
>  drm_ioctl+0x2b3/0x490 [drm]
>  do_vfs_ioctl+0x69c/0x700
>  SyS_ioctl+0x4e/0x80
>  entry_SYSCALL_64_fastpath+0x13/0x94
> INFO: Slab 0xde1f0997b080 objects=17 used=2 fp=0x92fb65ec2578 
> flags=0x2008101
> INFO: Object 0x92fb65ec2578 @offset=1400 fp=0x92fb65ec2ae8
> 
> Redzone 92fb65ec2570: bb bb bb bb bb bb bb bb  
> 
> Object 92fb65ec2578: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 92fb65ec2588: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 92fb65ec2598: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 92fb65ec25a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 92fb65ec25b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 92fb65ec25c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 92fb65ec25d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 92fb65ec25e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  
> kkk.
> Redzone 92fb65ec25f8: bb bb bb bb bb bb bb bb  
> 
> Padding 92fb65ec2738: 5a 5a 5a 5a 5a 5a 5a 5a  
> 
> CPU: 3 PID: 180 Comm: kworker/3:2 Tainted: GBU  
> 4.10.0-rc6-patser+ #5039
> Hardware name:  /NUC5PPYB, BIOS 
> PYBSWCEL.86A.0031.2015.0601.1712 06/01/2015
> Workqueue: events intel_atomic_helper_free_state [i915]
> Call Trace:
>  dump_stack+0x4d/0x6d
>  print_trailer+0x20c/0x220
>  free_debug_processing+0x1c6/0x330
>  ? drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
>  __slab_free+0x48/0x2e0
>  ? drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
>  kfree+0x159/0x1a0
>  drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
>  ? drm_atomic_state_clear+0x30/0x30 [drm]
>  intel_atomic_state_clear+0xd/0x20 [i915]
>  drm_atomic_state_clear+0x1a/0x30 [drm]
>  __drm_atomic_state_free+0x13/0x60 [drm]
>  intel_atomic_helper_free_state+0x5d/0x70 [i915]
>  process_one_work+0x260/0x4a0
>  worker_thread+0x2d1/0x4f0
>  kthread+0x127/0x130
>  ? process_one_work+0x4a0/0x4a0
>  ? kthread_stop+0x120/0x120
>  ret_from_fork+0x29/0x40
> FIX kmalloc-128: Object at 0x92fb65ec2578 not freed
> 
> Fixes: 3b24f7d67581 ("drm/atomic: Add struct drm_crtc_commit to track async 
> updates")
> Fixes: 9626014258a5 ("drm/fence: add in-fences support")
> Cc:  # v4.8+
> Cc: Daniel Vetter 
> Signed-off-by: Maarten Lankhorst 
> Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 50f5cf7b69d1..fdfb1ec17e66 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -2032,13 +2032,16 @@ static void complete_crtc_signaling(struct drm_device 
> *dev,
>   }
>  
>   for_each_crtc_in_state(state, crtc, 

Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2017-01-31 Thread Imre Deak
On Tue, Jan 31, 2017 at 12:39:35PM +0100, Rafael J. Wysocki wrote:
> On 1/31/2017 11:58 AM, Imre Deak wrote:
> >Hi Rafael,
> 
> Hi,
> 
> >On Mon, Jan 30, 2017 at 11:44:37PM +0100, Rafael J. Wysocki wrote:
> >>On 1/24/2017 2:33 AM, Sedat Dilek wrote:
> >>>On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki  
> >>>wrote:
> On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek  
> wrote:
> >Hi,
> >
> >I have already reported this issue in [1].
> >One of the issue was solved.
> >Unfortunately, it looks like there is still a different problem here
> >(Ubuntu/precise AMD64).
> >
> >I tried v4.10-rc1 and latest Linus tree up to...
> >
> >commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
> >"mm/filemap: fix parameters to test_bit()"
> >
> >Here we go...
> >
> >[   29.636047] BUG: sleeping function called from invalid context at
> >drivers/base/power/runtime.c:1032
> >[   29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
> >[   29.636058] 1 lock held by Xorg/1500:
> >[   29.636060]  #0:  (>struct_mutex){+.+.+.}, at:
> >[] i915_mutex_lock_interruptible+0x43/0x140 [i915]
> >[   29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
> >4.10.0-rc1-6-iniza-amd64 #1
> >[   29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> >530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> >[   29.636111] Call Trace:
> >[   29.636120]  dump_stack+0x85/0xc2
> >[   29.636124]  ___might_sleep+0x196/0x260
> >[   29.636127]  __might_sleep+0x53/0xb0
> >[   29.636131]  __pm_runtime_resume+0x7a/0x90
> >[   29.636159]  intel_runtime_pm_get+0x25/0x90 [i915]
> >[   29.636189]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
> >[   29.636220]  i915_vma_bind+0xaf/0x1e0 [i915]
> >[   29.636248]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
> >[   29.636272]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 
> >[i915]
> >[   29.636275]  ? trace_hardirqs_on+0xd/0x10
> >[   29.636294]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 
> >[i915]
> >[   29.636316]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
> >[   29.636342]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
> >[   29.636347]  ? __might_fault+0x4e/0xb0
> >[   29.636373]  i915_gem_execbuffer2+0xc5/0x260 [i915]
> >[   29.636376]  ? __might_fault+0x4e/0xb0
> >[   29.636395]  drm_ioctl+0x206/0x450 [drm]
> >[   29.636420]  ? i915_gem_execbuffer+0x340/0x340 [i915]
> >[   29.636425]  ? __fget+0x5/0x200
> >[   29.636429]  do_vfs_ioctl+0x91/0x6f0
> >[   29.636431]  ? __fget+0x111/0x200
> >[   29.636433]  ? __fget+0x5/0x200
> >[   29.636436]  SyS_ioctl+0x79/0x90
> >[   29.636441]  entry_SYSCALL_64_fastpath+0x23/0xc6
> >
> >On suspend/resume I see the same call trace.
> >[2] points to the "BUG" line.
> Well, this appears to be an i915 issue, but not a serious one.
> 
> Clearly, a function that may sleep (pm_runtime_get_sync() in
> intel_runtime_pm_get()) is called with disabled interrupts.  If I
> understand the code correctly, though, it actually is not going to
> sleep in this particular case, because pm_runtime_get_sync() has
> already been called once for this device in the same code path which
> means that this particular instance will return immediately, so this
> is a false-positive (most likely).
> >Not sure what's the root cause, but thought to clarify the above:
> >
> >Yes, i915_gem_do_execbuffer() does take an RPM reference to optimize
> >things, so the RPM get in aliasing_gtt_bind_vma() won't need to resume
> >the device on this path. This isn't a guarantee though,
> >aliasing_gtt_bind_vma() could be called from other places without an RPM
> >reference. So preemption being disabled at that point is not
> >intentional. I also can't see where on the above path it would get
> >disabled due to a bug or otherwise.
> 
> The i915 code is correct AFAICS, but the core complains about a nested
> invocation of pm_runtime_get_sync() with disabled interrupts (which looks OK
> though), so the complaint is a false positive.

Well, my point was that interrupts (or preemption) doesn't seem to get
disabled anywhere on that path.

--Imre

> 
> As I said, the way to go here appears to be to tweak the core, which I'm
> going to do.
> 
> Thanks,
> Rafael
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 33/38] drm/i915: Test creation of partial VMA

2017-01-31 Thread Joonas Lahtinen
On to, 2017-01-19 at 11:41 +, Chris Wilson wrote:
> Mock testing to ensure we can create and lookup partial VMA.
> 
> Signed-off-by: Chris Wilson 



> +static bool assert_partial(struct drm_i915_gem_object *obj,
> +    struct i915_vma *vma,
> +    unsigned long offset,
> +    unsigned long size)
> +{
> + struct sgt_iter sgt;

Confusing name, could rather be "sgti" or just "i", or "iter".

> +static int igt_vma_partial(void *arg)
> +{
> + struct drm_i915_private *i915 = arg;
> + const unsigned int npages = 1021; /* prime! */

#define THE_MAGIC_PRIME 1021

> + for (loop = 0; loop <= 1; loop++) { /* exercise both create/lookup */

I'd like the phase array/variable more. "loop" variable is kinda
confusing easily.

> + unsigned int count, nvma;
> +

Make a comment here that a whole VMA is also created at the end and it
needs to be accounted. This is why the phase array might be more
readable.

> + nvma = loop;
> + for_each_prime_number_from(sz, 1, npages) {
> + for_each_prime_number_from(offset, 0, npages - sz) {
> + struct i915_address_space *vm =
> + >ggtt.base;

Could be out of the loop, too.



> +
> + /* Create a mapping for the entire object, just for extra fun */
> + vma = i915_vma_instance(obj, >ggtt.base, NULL);

No helper for this block?

With the variable renamed;

Reviewed-by: Joonas Lahtinen 

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


Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2017-01-31 Thread Rafael J. Wysocki

On 1/31/2017 11:58 AM, Imre Deak wrote:

Hi Rafael,


Hi,


On Mon, Jan 30, 2017 at 11:44:37PM +0100, Rafael J. Wysocki wrote:

On 1/24/2017 2:33 AM, Sedat Dilek wrote:

On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki  wrote:

On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek  wrote:

Hi,

I have already reported this issue in [1].
One of the issue was solved.
Unfortunately, it looks like there is still a different problem here
(Ubuntu/precise AMD64).

I tried v4.10-rc1 and latest Linus tree up to...

commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
"mm/filemap: fix parameters to test_bit()"

Here we go...

[   29.636047] BUG: sleeping function called from invalid context at
drivers/base/power/runtime.c:1032
[   29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
[   29.636058] 1 lock held by Xorg/1500:
[   29.636060]  #0:  (>struct_mutex){+.+.+.}, at:
[] i915_mutex_lock_interruptible+0x43/0x140 [i915]
[   29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
4.10.0-rc1-6-iniza-amd64 #1
[   29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
[   29.636111] Call Trace:
[   29.636120]  dump_stack+0x85/0xc2
[   29.636124]  ___might_sleep+0x196/0x260
[   29.636127]  __might_sleep+0x53/0xb0
[   29.636131]  __pm_runtime_resume+0x7a/0x90
[   29.636159]  intel_runtime_pm_get+0x25/0x90 [i915]
[   29.636189]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
[   29.636220]  i915_vma_bind+0xaf/0x1e0 [i915]
[   29.636248]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
[   29.636272]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
[   29.636275]  ? trace_hardirqs_on+0xd/0x10
[   29.636294]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
[   29.636316]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
[   29.636342]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
[   29.636347]  ? __might_fault+0x4e/0xb0
[   29.636373]  i915_gem_execbuffer2+0xc5/0x260 [i915]
[   29.636376]  ? __might_fault+0x4e/0xb0
[   29.636395]  drm_ioctl+0x206/0x450 [drm]
[   29.636420]  ? i915_gem_execbuffer+0x340/0x340 [i915]
[   29.636425]  ? __fget+0x5/0x200
[   29.636429]  do_vfs_ioctl+0x91/0x6f0
[   29.636431]  ? __fget+0x111/0x200
[   29.636433]  ? __fget+0x5/0x200
[   29.636436]  SyS_ioctl+0x79/0x90
[   29.636441]  entry_SYSCALL_64_fastpath+0x23/0xc6

On suspend/resume I see the same call trace.
[2] points to the "BUG" line.

Well, this appears to be an i915 issue, but not a serious one.

Clearly, a function that may sleep (pm_runtime_get_sync() in
intel_runtime_pm_get()) is called with disabled interrupts.  If I
understand the code correctly, though, it actually is not going to
sleep in this particular case, because pm_runtime_get_sync() has
already been called once for this device in the same code path which
means that this particular instance will return immediately, so this
is a false-positive (most likely).

Not sure what's the root cause, but thought to clarify the above:

Yes, i915_gem_do_execbuffer() does take an RPM reference to optimize
things, so the RPM get in aliasing_gtt_bind_vma() won't need to resume
the device on this path. This isn't a guarantee though,
aliasing_gtt_bind_vma() could be called from other places without an RPM
reference. So preemption being disabled at that point is not
intentional. I also can't see where on the above path it would get
disabled due to a bug or otherwise.


The i915 code is correct AFAICS, but the core complains about a nested 
invocation of pm_runtime_get_sync() with disabled interrupts (which 
looks OK though), so the complaint is a false positive.


As I said, the way to go here appears to be to tweak the core, which I'm 
going to do.


Thanks,
Rafael

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


Re: [Intel-gfx] [PATCH igt] intel-ci: Minimal exercise of explicit fencing

2017-01-31 Thread Chris Wilson
On Tue, Jan 31, 2017 at 01:21:15PM +0200, Petri Latvala wrote:
> On Tue, Jan 31, 2017 at 09:54:21AM +, Chris Wilson wrote:
> > Ping? And any feedback from the earlier ringfill-fds?
> > -Chris
> 
> 
> Sent ack on the ringfill test. This one has been queued for a test
> round at farm2.
> 
> For those following along and smelling chances of getting their
> $favoritefeatureoftheday into BAT, I'm being a little more lenient
> than I should with allowing more tests into fast-feedback at this
> time. As soon as we can deploy Ezbench-driven extended testing (not
> far now btw), fast-feedback will go on a diet.

Unless that is accompanied by some coverage based feedback methodology
consider me grumpy. I wish that we had the tools for BAT to be an
automatic selection of the testcases that gave excellent coverage and
sensitivity.
-Chris

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: The return of i915_gpu_info to debugfs

2017-01-31 Thread Patchwork
== Series Details ==

Series: drm/i915: The return of i915_gpu_info to debugfs
URL   : https://patchwork.freedesktop.org/series/18833/
State : failure

== Summary ==

Series 18833v1 drm/i915: The return of i915_gpu_info to debugfs
https://patchwork.freedesktop.org/api/1.0/series/18833/revisions/1/mbox/

Test drv_hangman:
Subgroup error-state-basic:
pass   -> FAIL   (fi-snb-2520m)
pass   -> FAIL   (fi-snb-2600)
pass   -> FAIL   (fi-skl-6700k)
pass   -> FAIL   (fi-bxt-j4205)
pass   -> FAIL   (fi-hsw-4770)
pass   -> FAIL   (fi-skl-6770hq)
pass   -> FAIL   (fi-hsw-4770r)
pass   -> FAIL   (fi-skl-6700hq)
pass   -> FAIL   (fi-byt-n2820)
pass   -> FAIL   (fi-bsw-n3050)
pass   -> FAIL   (fi-bxt-t5700)
pass   -> FAIL   (fi-ivb-3520m)
pass   -> FAIL   (fi-ivb-3770)
pass   -> FAIL   (fi-bdw-5557u)
pass   -> FAIL   (fi-byt-j1900)
pass   -> FAIL   (fi-skl-6260u)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:1   skip:14 
fi-bsw-n3050 total:246  pass:206  dwarn:0   dfail:0   fail:1   skip:39 
fi-bxt-j4205 total:246  pass:223  dwarn:0   dfail:0   fail:1   skip:22 
fi-bxt-t5700 total:78   pass:64   dwarn:0   dfail:0   fail:1   skip:12 
fi-byt-j1900 total:246  pass:218  dwarn:0   dfail:0   fail:1   skip:27 
fi-byt-n2820 total:246  pass:214  dwarn:0   dfail:0   fail:1   skip:31 
fi-hsw-4770  total:246  pass:226  dwarn:0   dfail:0   fail:1   skip:19 
fi-hsw-4770r total:246  pass:226  dwarn:0   dfail:0   fail:1   skip:19 
fi-ivb-3520m total:246  pass:224  dwarn:0   dfail:0   fail:1   skip:21 
fi-ivb-3770  total:246  pass:224  dwarn:0   dfail:0   fail:1   skip:21 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:1   skip:13 
fi-skl-6700hqtotal:246  pass:225  dwarn:0   dfail:0   fail:1   skip:20 
fi-skl-6700k total:246  pass:220  dwarn:4   dfail:0   fail:1   skip:21 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:1   skip:13 
fi-snb-2520m total:246  pass:214  dwarn:0   dfail:0   fail:1   skip:31 
fi-snb-2600  total:246  pass:213  dwarn:0   dfail:0   fail:1   skip:32 

5689d1f0e8e542fc5a89191493fb77188add8807 drm-tip: 2017y-01m-31d-10h-05m-02s UTC 
integration manifest
5e63eb9 drm/i915: The return of i915_gpu_info to debugfs

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/i915: Be defensive when cleaning up i915_gem_internal pages

2017-01-31 Thread Chris Wilson
On Tue, Jan 31, 2017 at 11:04:49AM +, Matthew Auld wrote:
> On 31 January 2017 at 10:46, Chris Wilson  wrote:
> > If we abort the i915_gem_internal get_pages, we mark the failing sg as
> > the last. However, that means we iterate upto and including the failing
> > sg element and results us in trying to free the unallocated sg_page().
> s/us in/in us/

Ta.
-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 igt] intel-ci: Minimal exercise of explicit fencing

2017-01-31 Thread Petri Latvala
On Tue, Jan 31, 2017 at 09:54:21AM +, Chris Wilson wrote:
> Ping? And any feedback from the earlier ringfill-fds?
> -Chris


Sent ack on the ringfill test. This one has been queued for a test
round at farm2.

For those following along and smelling chances of getting their
$favoritefeatureoftheday into BAT, I'm being a little more lenient
than I should with allowing more tests into fast-feedback at this
time. As soon as we can deploy Ezbench-driven extended testing (not
far now btw), fast-feedback will go on a diet.


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


Re: [Intel-gfx] [PATCH igt] intel-ci: Add multiple ringfill for execlists

2017-01-31 Thread Petri Latvala
On Tue, Jan 24, 2017 at 01:02:23PM +0200, Petri Latvala wrote:
> On Tue, Jan 24, 2017 at 09:31:39AM +, Chris Wilson wrote:
> > On Wed, Jan 18, 2017 at 08:54:10PM +, Chris Wilson wrote:
> > > Execlists introduces a new wrinkle to filling rings, in that each
> > > context has an independent set of rings. Add the subtest that exercises
> > > filling multiple execlist rings (for the same engine) to BAT.
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Petri Latvala 
> > 
> > Ping? This provides coverage of some hairy paths on execlists/guc that
> > currently have nothing explicit.
> 
> 
> Sent to farm2 for a test round.

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


Re: [Intel-gfx] [PATCH] drm/i915: Be defensive when cleaning up i915_gem_internal pages

2017-01-31 Thread Matthew Auld
On 31 January 2017 at 10:46, Chris Wilson  wrote:
> If we abort the i915_gem_internal get_pages, we mark the failing sg as
> the last. However, that means we iterate upto and including the failing
> sg element and results us in trying to free the unallocated sg_page().
s/us in/in us/

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


Re: [Intel-gfx] [PATCH] drm/i915: Add MIPI_IO WA and program DSI regulators

2017-01-31 Thread Mika Kahola
Looks ok.

Acked-by: Mika Kahola 

On Wed, 2017-01-25 at 19:43 +0530, Vidya Srinivas wrote:
> From: Uma Shankar 
> 
> Enable MIPI IO WA for BXT DSI as per bspec and
> program the DSI regulators.
> 
> v2: Moved IO enable to pre-enable as per Mika's
> review comments. Also reused the existing register
> definition for BXT_P_CR_GT_DISP_PWRON.
> 
> v3: Added Programming the DSI regulators as per disable/enable
> sequences.
> 
> v4: Restricting regulator changes to BXT as suggested by
> Jani/Mika
> 
> v5: Removed redundant read/modify for regulator register as
> per Jani's comment. Maintain enable/disable symmetry as per spec.
> 
> Signed-off-by: Uma Shankar 
> Signed-off-by: Vidya Srinivas 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  7 +++
>  drivers/gpu/drm/i915/intel_dsi.c | 24 
>  2 files changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 00970aa..0a9ad44 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1553,6 +1553,7 @@ enum skl_disp_power_wells {
>   _MMIO(_BXT_PHY_CH(phy, ch, reg_ch0, reg_ch1))
>  
>  #define BXT_P_CR_GT_DISP_PWRON   _MMIO(0x138090)
> +#define  MIPIO_RST_CTRL  (1 << 2)
>  
>  #define _BXT_PHY_CTL_DDI_A   0x64C00
>  #define _BXT_PHY_CTL_DDI_B   0x64C10
> @@ -8301,6 +8302,12 @@ enum {
>  #define _BXT_MIPIC_PORT_CTRL 0x6B8C0
>  #define BXT_MIPI_PORT_CTRL(tc)   _MMIO_MIPI(tc,
> _BXT_MIPIA_PORT_CTRL, _BXT_MIPIC_PORT_CTRL)
>  
> +#define BXT_P_DSI_REGULATOR_CFG  _MMIO(0x16002
> 0)
> +#define  STAP_SELECT (1 << 0)
> +
> +#define BXT_P_DSI_REGULATOR_TX_CTRL  _MMIO(0x160054)
> +#define  HS_IO_CTRL_SELECT   (1 << 0)
> +
>  #define  DPI_ENABLE  (1 << 31)
> /* A + C */
>  #define  MIPIA_MIPI4DPHY_DELAY_COUNT_SHIFT   27
>  #define  MIPIA_MIPI4DPHY_DELAY_COUNT_MASK(0xf << 27)
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 16732e7..c98234e 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -548,6 +548,7 @@ static void intel_dsi_pre_enable(struct
> intel_encoder *encoder,
>   struct drm_i915_private *dev_priv = to_i915(encoder-
> >base.dev);
>   struct intel_dsi *intel_dsi = enc_to_intel_dsi(
> >base);
>   enum port port;
> + u32 val;
>  
>   DRM_DEBUG_KMS("\n");
>  
> @@ -558,6 +559,17 @@ static void intel_dsi_pre_enable(struct
> intel_encoder *encoder,
>   intel_disable_dsi_pll(encoder);
>   intel_enable_dsi_pll(encoder, pipe_config);
>  
> + if (IS_BROXTON(dev_priv)) {
> + /* Add MIPI IO reset programming for modeset */
> + val = I915_READ(BXT_P_CR_GT_DISP_PWRON);
> + I915_WRITE(BXT_P_CR_GT_DISP_PWRON,
> + val | MIPIO_RST_CTRL);
> +
> + /* Power up DSI regulator */
> + I915_WRITE(BXT_P_DSI_REGULATOR_CFG, STAP_SELECT);
> + I915_WRITE(BXT_P_DSI_REGULATOR_TX_CTRL, 0);
> + }
> +
>   intel_dsi_prepare(encoder, pipe_config);
>  
>   /* Panel Enable over CRC PMIC */
> @@ -707,6 +719,7 @@ static void intel_dsi_post_disable(struct
> intel_encoder *encoder,
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder-
> >base.dev);
>   struct intel_dsi *intel_dsi = enc_to_intel_dsi(
> >base);
> + u32 val;
>  
>   DRM_DEBUG_KMS("\n");
>  
> @@ -714,6 +727,17 @@ static void intel_dsi_post_disable(struct
> intel_encoder *encoder,
>  
>   intel_dsi_clear_device_ready(encoder);
>  
> + if (IS_BROXTON(dev_priv)) {
> + /* Power down DSI regulator to save power */
> + I915_WRITE(BXT_P_DSI_REGULATOR_CFG, STAP_SELECT);
> + I915_WRITE(BXT_P_DSI_REGULATOR_TX_CTRL,
> HS_IO_CTRL_SELECT);
> +
> + /* Add MIPI IO reset programming for modeset */
> + val = I915_READ(BXT_P_CR_GT_DISP_PWRON);
> + I915_WRITE(BXT_P_CR_GT_DISP_PWRON,
> + val & ~MIPIO_RST_CTRL);
> + }
> +
>   intel_disable_dsi_pll(encoder);
>  
>   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
-- 
Mika Kahola - Intel OTC

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


Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2017-01-31 Thread Imre Deak
Hi Rafael,

On Mon, Jan 30, 2017 at 11:44:37PM +0100, Rafael J. Wysocki wrote:
> On 1/24/2017 2:33 AM, Sedat Dilek wrote:
> >On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki  wrote:
> >>On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek  wrote:
> >>>Hi,
> >>>
> >>>I have already reported this issue in [1].
> >>>One of the issue was solved.
> >>>Unfortunately, it looks like there is still a different problem here
> >>>(Ubuntu/precise AMD64).
> >>>
> >>>I tried v4.10-rc1 and latest Linus tree up to...
> >>>
> >>>commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
> >>>"mm/filemap: fix parameters to test_bit()"
> >>>
> >>>Here we go...
> >>>
> >>>[   29.636047] BUG: sleeping function called from invalid context at
> >>>drivers/base/power/runtime.c:1032
> >>>[   29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
> >>>[   29.636058] 1 lock held by Xorg/1500:
> >>>[   29.636060]  #0:  (>struct_mutex){+.+.+.}, at:
> >>>[] i915_mutex_lock_interruptible+0x43/0x140 [i915]
> >>>[   29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
> >>>4.10.0-rc1-6-iniza-amd64 #1
> >>>[   29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> >>>530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> >>>[   29.636111] Call Trace:
> >>>[   29.636120]  dump_stack+0x85/0xc2
> >>>[   29.636124]  ___might_sleep+0x196/0x260
> >>>[   29.636127]  __might_sleep+0x53/0xb0
> >>>[   29.636131]  __pm_runtime_resume+0x7a/0x90
> >>>[   29.636159]  intel_runtime_pm_get+0x25/0x90 [i915]
> >>>[   29.636189]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
> >>>[   29.636220]  i915_vma_bind+0xaf/0x1e0 [i915]
> >>>[   29.636248]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
> >>>[   29.636272]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
> >>>[   29.636275]  ? trace_hardirqs_on+0xd/0x10
> >>>[   29.636294]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 
> >>>[i915]
> >>>[   29.636316]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
> >>>[   29.636342]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
> >>>[   29.636347]  ? __might_fault+0x4e/0xb0
> >>>[   29.636373]  i915_gem_execbuffer2+0xc5/0x260 [i915]
> >>>[   29.636376]  ? __might_fault+0x4e/0xb0
> >>>[   29.636395]  drm_ioctl+0x206/0x450 [drm]
> >>>[   29.636420]  ? i915_gem_execbuffer+0x340/0x340 [i915]
> >>>[   29.636425]  ? __fget+0x5/0x200
> >>>[   29.636429]  do_vfs_ioctl+0x91/0x6f0
> >>>[   29.636431]  ? __fget+0x111/0x200
> >>>[   29.636433]  ? __fget+0x5/0x200
> >>>[   29.636436]  SyS_ioctl+0x79/0x90
> >>>[   29.636441]  entry_SYSCALL_64_fastpath+0x23/0xc6
> >>>
> >>>On suspend/resume I see the same call trace.
> >>>[2] points to the "BUG" line.
> >>Well, this appears to be an i915 issue, but not a serious one.
> >>
> >>Clearly, a function that may sleep (pm_runtime_get_sync() in
> >>intel_runtime_pm_get()) is called with disabled interrupts.  If I
> >>understand the code correctly, though, it actually is not going to
> >>sleep in this particular case, because pm_runtime_get_sync() has
> >>already been called once for this device in the same code path which
> >>means that this particular instance will return immediately, so this
> >>is a false-positive (most likely).

Not sure what's the root cause, but thought to clarify the above:

Yes, i915_gem_do_execbuffer() does take an RPM reference to optimize
things, so the RPM get in aliasing_gtt_bind_vma() won't need to resume
the device on this path. This isn't a guarantee though,
aliasing_gtt_bind_vma() could be called from other places without an RPM
reference. So preemption being disabled at that point is not
intentional. I also can't see where on the above path it would get
disabled due to a bug or otherwise.

--Imre

> >>
> >>Let me see if I the might_sleep_if() assertion in
> >>__pm_runtime_resume(() can be moved to a better place.
> >>
> >Hi Rafael,
> >
> >did you had a chance to look at this?
> >The problem still remains in Linux v4.10-rc5.
> 
> No, I didn't.

> 
> As I said, this is not a serious issue.
> 
> Thanks,
> Rafael
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 30/38] drm/i915: Test creation of VMA

2017-01-31 Thread Joonas Lahtinen
On to, 2017-01-19 at 11:41 +, Chris Wilson wrote:
> Simple test to exercise creation and lookup of VMA within an object.
> 
> Signed-off-by: Chris Wilson 



> +static bool assert_vma(struct i915_vma *vma,
> +    struct drm_i915_gem_object *obj,
> +    struct i915_gem_context *ctx)
> +{
> + if (vma->vm != >ppgtt->base) {
> + pr_err("VMA created with wrong VM\n");
> + return false;
> + }

maybe "bool correct = true;" and list all the errors he VMA has? and
finally return correct;

> + for_each_prime_number(num_obj, ULONG_MAX - 1) {
> + for (; no < num_obj; no++) {
> + obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
> + if (IS_ERR(obj))
> + goto err;
> +
> + list_add(>batch_pool_link, );

See below;

> + }
> +
> + nc = 0;
> + for_each_prime_number(num_ctx, MAX_CONTEXT_HW_ID) {
> + for (; nc < num_ctx; nc++) {
> + ctx = mock_context(i915, "mock");
> + if (!ctx)
> + goto err;
> +
> + list_move(>link, );

Why the difference?

> + }
> +
> + err = create_vmas(i915, , );
> + if (err)
> + goto err;
> +
> + if (igt_timeout(end_time,
> + "%s timed out: after %lu objects\n",
> + __func__, no))

Maybe also context count, because it's available.

Reviewed-by: Joonas Lahtinen 

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


[Intel-gfx] [PATCH] drm/i915: Be defensive when cleaning up i915_gem_internal pages

2017-01-31 Thread Chris Wilson
If we abort the i915_gem_internal get_pages, we mark the failing sg as
the last. However, that means we iterate upto and including the failing
sg element and results us in trying to free the unallocated sg_page().

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

diff --git a/drivers/gpu/drm/i915/i915_gem_internal.c 
b/drivers/gpu/drm/i915/i915_gem_internal.c
index 17ce53d0d092..64d8fb3fd764 100644
--- a/drivers/gpu/drm/i915/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/i915_gem_internal.c
@@ -35,8 +35,10 @@ static void internal_free_pages(struct sg_table *st)
 {
struct scatterlist *sg;
 
-   for (sg = st->sgl; sg; sg = __sg_next(sg))
-   __free_pages(sg_page(sg), get_order(sg->length));
+   for (sg = st->sgl; sg; sg = __sg_next(sg)) {
+   if (sg_page(sg))
+   __free_pages(sg_page(sg), get_order(sg->length));
+   }
 
sg_free_table(st);
kfree(st);
@@ -116,6 +118,7 @@ i915_gem_object_get_pages_internal(struct 
drm_i915_gem_object *obj)
return st;
 
 err:
+   sg_set_page(sg, NULL, 0, 0);
sg_mark_end(sg);
internal_free_pages(st);
return ERR_PTR(-ENOMEM);
-- 
2.11.0

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


[Intel-gfx] [PATCH] drm/i915: The return of i915_gpu_info to debugfs

2017-01-31 Thread Chris Wilson
Once upon a time before we had automated GPU state capture upon hangs,
we had intel_gpu_dump. Now we come almost full circle and reinstate that
view of the current GPU queues and registers by using the error capture
facility to snapshot the GPU state when debugfs/.../i915_gpu_info is
opened - which should provided useful debugging to both the error
capture routines (without having to cause a hang and avoid the error
state being eaten by igt) and generally.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_debugfs.c   | 123 +++---
 drivers/gpu/drm/i915/i915_drv.h   |  26 ---
 drivers/gpu/drm/i915/i915_gpu_error.c |  71 
 drivers/gpu/drm/i915/i915_sysfs.c |  31 +
 4 files changed, 132 insertions(+), 119 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3ae06568df7b..124a184389a8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -954,89 +954,103 @@ static int i915_gem_fence_regs_info(struct seq_file *m, 
void *data)
 }
 
 #if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
-
-static ssize_t
-i915_error_state_write(struct file *filp,
-  const char __user *ubuf,
-  size_t cnt,
-  loff_t *ppos)
+static ssize_t error_state_read(struct file *file, char __user *ubuf,
+   size_t count, loff_t *pos)
 {
-   struct i915_error_state_file_priv *error_priv = filp->private_data;
-
-   DRM_DEBUG_DRIVER("Resetting error state\n");
-   i915_destroy_error_state(error_priv->i915);
-
-   return cnt;
-}
+   struct drm_i915_error_state *error = file->private_data;
+   struct drm_i915_error_state_buf str;
+   ssize_t ret;
+   loff_t tmp;
 
-static int i915_error_state_open(struct inode *inode, struct file *file)
-{
-   struct drm_i915_private *dev_priv = inode->i_private;
-   struct i915_error_state_file_priv *error_priv;
+   if (!error)
+   return 0;
 
-   error_priv = kzalloc(sizeof(*error_priv), GFP_KERNEL);
-   if (!error_priv)
-   return -ENOMEM;
+   ret = i915_error_state_buf_init(, error->i915, count, *pos);
+   if (ret)
+   return ret;
 
-   error_priv->i915 = dev_priv;
+   ret = i915_error_state_to_str(, error);
+   if (ret)
+   goto out;
 
-   i915_error_state_get(_priv->drm, error_priv);
+   tmp = 0;
+   ret = simple_read_from_buffer(ubuf, count, , str.buf, str.bytes);
+   if (ret < 0)
+   goto out;
 
-   file->private_data = error_priv;
+   *pos = str.start + ret;
+out:
+   i915_error_state_buf_release();
+   return ret;
+}
 
+static int error_state_release(struct inode *inode, struct file *file)
+{
+   i915_error_state_put(file->private_data);
return 0;
 }
 
-static int i915_error_state_release(struct inode *inode, struct file *file)
+static int i915_gpu_info_open(struct inode *inode, struct file *file)
 {
-   struct i915_error_state_file_priv *error_priv = file->private_data;
+   struct drm_i915_error_state *error;
 
-   i915_error_state_put(error_priv);
-   kfree(error_priv);
+   error = i915_error_state(inode->i_private);
+   if (!error)
+   return -ENOMEM;
 
+   file->private_data = error;
return 0;
 }
 
-static ssize_t i915_error_state_read(struct file *file, char __user *userbuf,
-size_t count, loff_t *pos)
+static const struct file_operations i915_gpu_info_fops = {
+   .owner = THIS_MODULE,
+   .open = i915_gpu_info_open,
+   .read = error_state_read,
+   .llseek = default_llseek,
+   .release = error_state_release,
+};
+
+static ssize_t
+i915_error_state_write(struct file *filp,
+  const char __user *ubuf,
+  size_t cnt,
+  loff_t *ppos)
 {
-   struct i915_error_state_file_priv *error_priv = file->private_data;
-   struct drm_i915_error_state_buf error_str;
-   loff_t tmp_pos = 0;
-   ssize_t ret_count = 0;
-   int ret;
+   struct drm_i915_error_state *error = filp->private_data;
 
-   ret = i915_error_state_buf_init(_str, error_priv->i915,
-   count, *pos);
-   if (ret)
-   return ret;
+   if (!error)
+   return 0;
 
-   ret = i915_error_state_to_str(_str, error_priv);
-   if (ret)
-   goto out;
+   DRM_DEBUG_DRIVER("Resetting error state\n");
+   i915_destroy_error_state(error->i915);
 
-   ret_count = simple_read_from_buffer(userbuf, count, _pos,
-   error_str.buf,
-   error_str.bytes);
+   return cnt;
+}
 
-   if (ret_count < 0)
- 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/atomic: Fix double free in drm_atomic_state_default_clear

2017-01-31 Thread Patchwork
== Series Details ==

Series: drm/atomic: Fix double free in drm_atomic_state_default_clear
URL   : https://patchwork.freedesktop.org/series/18826/
State : success

== Summary ==

Series 18826v1 drm/atomic: Fix double free in drm_atomic_state_default_clear
https://patchwork.freedesktop.org/api/1.0/series/18826/revisions/1/mbox/

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
dmesg-warn -> PASS   (fi-snb-2520m)
Test kms_force_connector_basic:
Subgroup force-connector-state:
dmesg-warn -> PASS   (fi-snb-2520m)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a:
dmesg-warn -> PASS   (fi-snb-2520m)

fi-bdw-5557u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:246  pass:207  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:78   pass:65   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:246  pass:219  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:246  pass:223  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:246  pass:226  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:246  pass:221  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:246  pass:214  dwarn:0   dfail:0   fail:0   skip:32 

123d798c350471aba7e0625c154c6d9e395756c8 drm-tip: 2017y-01m-30d-21h-14m-37s UTC 
integration manifest
3d83408 drm/atomic: Fix double free in drm_atomic_state_default_clear

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3651/
___
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 00/11] tests/kms_atomic_transition add fence testing

2017-01-31 Thread Chris Wilson
On Mon, Jan 30, 2017 at 08:58:36PM -0500, Robert Foss wrote:
> This series adds in/out fence testing to kms_atomic_transition test and makes 
> some minor cleanups.
> 
> This series is rebased ontop of the dyn_n_planes_v3 series.
> 
> This series can be found here:
> https://git.collabora.com/cgit/user/robertfoss/intel-gpu-tools.git/log/?h=fences_$VER
> 
> 
> Changes since v1:
> 
>   lib/igt_kms:
>- Added gtk-doc for exported symbols
>- Changed integer casting to avoid potential issues
>- Changed out_fence_ptr type to int64_t*
>- Fixed igt_plane_set_fence_fd comment
> 
>   tests/:
>- Rework timeout change in commit_display()
>- Extract plane_invalid_params_fence() out plane_invalid_params()
>- Extract crtc_invalid_params_fence() out crtc_invalid_params()
>- Prevent add igt_require_sw_sync to subtests using sw_sync
> 
> 
> Changes since v2:
>   Rebased on upstream/master
> 
>   lib/igt_kms:
> - Reset plane->fence_fd to -1 during igt_atomic_prepare_plane_commit()
> - Rework out_fencs_ptr to be an int64_t named out_fence
> - Add igt_pipe_request_out_fence()
>   tests/:
> - Switch to using igt_pipe_request_out_fence()
> - Close out_fence fd
> - Change out_fence to int64_t in run_transition_test()
> - Added comments noting that two testcases are not invalid
> - Added igt_pipe_get_last_out_fence() that wraps pipe->fence_out

Looks like this this missing the uabi conversion to s32 (int).
-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 v2] drm/i915: Sanity check the computed size and base of stolen memory

2017-01-31 Thread Joonas Lahtinen
On ma, 2017-01-30 at 13:47 +, Chris Wilson wrote:
> Just do a quick check that the stolen memory address range doesn't
> overflow our chosen integer type.
> 
> v2: Add add_overflows() to utils with the promise that gcc7 can do this
> better than C and then maybe it will have a proper definition in core.
> 
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 

Reviewed-by: Joonas Lahtinen 

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


Re: [Intel-gfx] [PATCH] drm/i915: Add MIPI_IO WA and program DSI regulators

2017-01-31 Thread Srinivas, Vidya
Gentle remainder - could you kindly check the patch please? Thank you.

> -Original Message-
> From: Srinivas, Vidya
> Sent: Wednesday, January 25, 2017 7:43 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma ; Nikula, Jani
> ; Syrjala, Ville ; Kahola,
> Mika ; Srinivas, Vidya 
> Subject: [PATCH] drm/i915: Add MIPI_IO WA and program DSI regulators
> 
> From: Uma Shankar 
> 
> Enable MIPI IO WA for BXT DSI as per bspec and program the DSI regulators.
> 
> v2: Moved IO enable to pre-enable as per Mika's review comments. Also
> reused the existing register definition for BXT_P_CR_GT_DISP_PWRON.
> 
> v3: Added Programming the DSI regulators as per disable/enable sequences.
> 
> v4: Restricting regulator changes to BXT as suggested by Jani/Mika
> 
> v5: Removed redundant read/modify for regulator register as per Jani's
> comment. Maintain enable/disable symmetry as per spec.
> 
> Signed-off-by: Uma Shankar 
> Signed-off-by: Vidya Srinivas 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  7 +++
> drivers/gpu/drm/i915/intel_dsi.c | 24 
>  2 files changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index 00970aa..0a9ad44 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1553,6 +1553,7 @@ enum skl_disp_power_wells {
>   _MMIO(_BXT_PHY_CH(phy, ch, reg_ch0, reg_ch1))
> 
>  #define BXT_P_CR_GT_DISP_PWRON   _MMIO(0x138090)
> +#define  MIPIO_RST_CTRL  (1 << 2)
> 
>  #define _BXT_PHY_CTL_DDI_A   0x64C00
>  #define _BXT_PHY_CTL_DDI_B   0x64C10
> @@ -8301,6 +8302,12 @@ enum {
>  #define _BXT_MIPIC_PORT_CTRL 0x6B8C0
>  #define BXT_MIPI_PORT_CTRL(tc)   _MMIO_MIPI(tc,
> _BXT_MIPIA_PORT_CTRL, _BXT_MIPIC_PORT_CTRL)
> 
> +#define BXT_P_DSI_REGULATOR_CFG  _MMIO(0x160020)
> +#define  STAP_SELECT (1 << 0)
> +
> +#define BXT_P_DSI_REGULATOR_TX_CTRL  _MMIO(0x160054)
> +#define  HS_IO_CTRL_SELECT   (1 << 0)
> +
>  #define  DPI_ENABLE  (1 << 31) /* A + C */
>  #define  MIPIA_MIPI4DPHY_DELAY_COUNT_SHIFT   27
>  #define  MIPIA_MIPI4DPHY_DELAY_COUNT_MASK(0xf << 27)
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 16732e7..c98234e 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -548,6 +548,7 @@ static void intel_dsi_pre_enable(struct
> intel_encoder *encoder,
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
>   enum port port;
> + u32 val;
> 
>   DRM_DEBUG_KMS("\n");
> 
> @@ -558,6 +559,17 @@ static void intel_dsi_pre_enable(struct
> intel_encoder *encoder,
>   intel_disable_dsi_pll(encoder);
>   intel_enable_dsi_pll(encoder, pipe_config);
> 
> + if (IS_BROXTON(dev_priv)) {
> + /* Add MIPI IO reset programming for modeset */
> + val = I915_READ(BXT_P_CR_GT_DISP_PWRON);
> + I915_WRITE(BXT_P_CR_GT_DISP_PWRON,
> + val | MIPIO_RST_CTRL);
> +
> + /* Power up DSI regulator */
> + I915_WRITE(BXT_P_DSI_REGULATOR_CFG, STAP_SELECT);
> + I915_WRITE(BXT_P_DSI_REGULATOR_TX_CTRL, 0);
> + }
> +
>   intel_dsi_prepare(encoder, pipe_config);
> 
>   /* Panel Enable over CRC PMIC */
> @@ -707,6 +719,7 @@ static void intel_dsi_post_disable(struct
> intel_encoder *encoder,  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
> + u32 val;
> 
>   DRM_DEBUG_KMS("\n");
> 
> @@ -714,6 +727,17 @@ static void intel_dsi_post_disable(struct
> intel_encoder *encoder,
> 
>   intel_dsi_clear_device_ready(encoder);
> 
> + if (IS_BROXTON(dev_priv)) {
> + /* Power down DSI regulator to save power */
> + I915_WRITE(BXT_P_DSI_REGULATOR_CFG, STAP_SELECT);
> + I915_WRITE(BXT_P_DSI_REGULATOR_TX_CTRL,
> HS_IO_CTRL_SELECT);
> +
> + /* Add MIPI IO reset programming for modeset */
> + val = I915_READ(BXT_P_CR_GT_DISP_PWRON);
> + I915_WRITE(BXT_P_CR_GT_DISP_PWRON,
> + val & ~MIPIO_RST_CTRL);
> + }
> +
>   intel_disable_dsi_pll(encoder);
> 
>   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> --
> 1.9.1

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


  1   2   >