Re: [Intel-gfx] [PATCH] drm/i915/vbt: Assume port A is connected to eDP when there's no VBT

2017-08-09 Thread Navare, Manasi D
We currently assume port A is connected to a DP sink when VBT is absent, 
instead assume it is connected to an eDP sink, which seems like a more common 
configuration. Although I don't have data to back this up, it is still just as 
valid as asumming port A is not eDP. This reverts to the behavior before 
a98d9c1 ("drm/i915/ddi: Rely on VBT DDI port info for eDP detection") except 
only when there is no VBT. Knowing whether a panel is eDP or not from the panel 
itself would have been nicer, but I cannot find any DPCD registers that provide 
this reliably.

Cc: Jani Nikula 
Cc: Imre Deak 
Cc: Rodrigo Vivi 
Cc: Clint Taylor 

Signed-off-by: Dhinakaran Pandiyan 

Is this patch trying to fix a specific bug? Where do you plan to use 
supports_edp flag? 
I guess I am trying to understand the need for this in the vbt missing defaults 
and what this patch is trying to solve here. 

Manasi


---
 drivers/gpu/drm/i915/intel_bios.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 82b144c..89a405e 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1403,6 +1403,7 @@ init_vbt_missing_defaults(struct drm_i915_private 
*dev_priv)
info->supports_dvi = (port != PORT_A && port != PORT_E);
info->supports_hdmi = info->supports_dvi;
info->supports_dp = (port != PORT_E);
+   info->supports_edp = (port == PORT_A);

}
 }
 
--
2.7.4

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


[Intel-gfx] [PATCH i-g-t 4/4] tests/syncobj: Add some wait and reset tests (v5)

2017-08-09 Thread Jason Ekstrand
This adds both trivial error-checking tests as well as more complex
tests which actually test whether or not waits do what they're supposed
to do.  They only currently work on i915 but it should be simple to hook
them up for other drivers by simply implementing the little function
pointer hook provided at the top for triggering a syncobj.

v2:
 - Actually add the reset tests.
v3:
 - Only do one execbuf for trigger
 - Use do_ioctl and do_ioctl_err
 - Better check for syncobj support
 - Add local_/LOCAL_ defines of things
 - Use a timer instead of a pthread
v4:
 - Use ioctl wrappers
 - Use VGEM instead of i915
 - Combine a bunch of the simple tests into one function
v5:
 - Combinatorially generate basic tests
 - Use sw_sync instead of using vgem directly

Signed-off-by: Jason Ekstrand 
---
 tests/Makefile.sources |   1 +
 tests/syncobj_wait.c   | 477 +
 2 files changed, 478 insertions(+)
 create mode 100644 tests/syncobj_wait.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index bb013c7..430b637 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -230,6 +230,7 @@ TESTS_progs = \
prime_vgem \
sw_sync \
syncobj_basic \
+   syncobj_wait \
template \
tools_test \
vgem_basic \
diff --git a/tests/syncobj_wait.c b/tests/syncobj_wait.c
new file mode 100644
index 000..263d530
--- /dev/null
+++ b/tests/syncobj_wait.c
@@ -0,0 +1,477 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "igt.h"
+#include "sw_sync.h"
+#include "igt_syncobj.h"
+#include 
+#include 
+#include 
+#include "drm.h"
+
+IGT_TEST_DESCRIPTION("Tests for the drm sync object wait API");
+
+/* One tenth of a second */
+#define SHORT_TIME_NSEC 1ull
+
+#define NSECS_PER_SEC 10ull
+
+static uint64_t
+gettime_ns(void)
+{
+   struct timespec current;
+   clock_gettime(CLOCK_MONOTONIC, );
+   return (uint64_t)current.tv_sec * NSECS_PER_SEC + current.tv_nsec;
+}
+
+static uint64_t
+short_timeout(void)
+{
+   return gettime_ns() + SHORT_TIME_NSEC;
+}
+
+static int
+syncobj_attach_sw_sync(int fd, uint32_t handle)
+{
+   struct drm_syncobj_handle;
+   int timeline, fence;
+
+   timeline = sw_sync_timeline_create();
+   fence = sw_sync_timeline_create_fence(timeline, 1);
+   syncobj_import_sync_file(fd, handle, fence);
+   close(fence);
+
+   return timeline;
+}
+
+static void
+syncobj_trigger(int fd, uint32_t handle)
+{
+   int timeline = syncobj_attach_sw_sync(fd, handle);
+   sw_sync_timeline_inc(timeline, 1);
+}
+
+struct delayed_trigger {
+   int fd;
+   uint32_t *syncobjs;
+   int count;
+   uint64_t nsec;
+};
+
+static void
+trigger_syncobj_delayed_func(union sigval sigval)
+{
+   struct delayed_trigger *trigger = sigval.sival_ptr;
+   int i;
+
+   for (i = 0; i < trigger->count; i++)
+   syncobj_trigger(trigger->fd, trigger->syncobjs[i]);
+   free(trigger);
+}
+
+static timer_t
+trigger_syncobj_delayed(int fd, uint32_t *syncobjs, int count, uint64_t nsec)
+{
+   struct delayed_trigger *trigger;
+timer_t timer;
+struct sigevent sev;
+struct itimerspec its;
+
+   trigger = malloc(sizeof(*trigger));
+   trigger->fd = fd;
+   trigger->syncobjs = syncobjs;
+   trigger->count = count;
+   trigger->nsec = nsec;
+
+memset(, 0, sizeof(sev));
+sev.sigev_notify = SIGEV_THREAD;
+sev.sigev_value.sival_ptr = trigger;
+sev.sigev_notify_function = trigger_syncobj_delayed_func;
+igt_assert(timer_create(CLOCK_MONOTONIC, , ) == 0);
+
+memset(, 0, sizeof(its));
+its.it_value.tv_sec = nsec / NSEC_PER_SEC;
+its.it_value.tv_nsec = nsec % NSEC_PER_SEC;
+

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Simplify hpd pin to port

2017-08-09 Thread Pandiyan, Dhinakaran
On Wed, 2017-08-02 at 10:20 -0700, Rodrigo Vivi wrote:
> We will soon need to make that pin port association per
> platform, so let's try to simplify it beforehand.
> 
> Also we are moving the backwards port to pin
> here as well so let's use a standardized way.
> 
> One extra possibility here would be to add a
> MISSING_CASE along with PORT_NONE, but I don't want
> to change this behaviour for now.
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  2 +-
>  drivers/gpu/drm/i915/i915_irq.c  |  3 ++-
>  drivers/gpu/drm/i915/intel_dp.c  |  2 +-
>  drivers/gpu/drm/i915/intel_hotplug.c | 31 +--
>  4 files changed, 21 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d63645a521c4..5c2c7a677e96 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3147,7 +3147,7 @@ void intel_hpd_irq_handler(struct drm_i915_private 
> *dev_priv,
>  void intel_hpd_init(struct drm_i915_private *dev_priv);
>  void intel_hpd_init_work(struct drm_i915_private *dev_priv);
>  void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
> -bool intel_hpd_pin_to_port(enum hpd_pin pin, enum port *port);
> +enum port intel_hpd_port(enum hpd_pin pin);

bikeshed: I feel hpd_pin_to_port reads better, conveys the conversion
from enum hpd_pin to enum port. Secondly, I haven't seen any references
to "hpd_port" in the driver.

It is not entirely obvious to me how changing the function signature
will help per-platform mapping, but returning port looks cleaner. 

With the function name left intact
Reviewed-by: Dhinakaran Pandiyan 


>  bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
>  void intel_hpd_enable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
>  
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 196caa463edf..b115ab584b5e 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1501,7 +1501,8 @@ static void intel_get_hpd_pins(u32 *pin_mask, u32 
> *long_mask,
>  
>   *pin_mask |= BIT(i);
>  
> - if (!intel_hpd_pin_to_port(i, ))
> + port = intel_hpd_port(i);
> + if (port == PORT_NONE)
>   continue;
>  
>   if (long_pulse_detect(port, dig_hotplug_reg))
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 2d42d09428c9..d4e6128f3b3a 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4566,7 +4566,7 @@ static bool bxt_digital_port_connected(struct 
> drm_i915_private *dev_priv,
>   enum port port;
>   u32 bit;
>  
> - intel_hpd_pin_to_port(intel_encoder->hpd_pin, );
> + port = intel_hpd_port(intel_encoder->hpd_pin);
>   switch (port) {
>   case PORT_A:
>   bit = BXT_DE_PORT_HP_DDIA;
> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
> b/drivers/gpu/drm/i915/intel_hotplug.c
> index f1200272a699..5982c47586e7 100644
> --- a/drivers/gpu/drm/i915/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> @@ -76,26 +76,28 @@
>   * it will use i915_hotplug_work_func where this logic is handled.
>   */
>  
> -bool intel_hpd_pin_to_port(enum hpd_pin pin, enum port *port)
> +/**
> + * intel_hpd_port - return port hard associated with certain pin.
> + * @pin: the hpd pin to get associated port
> + *
> + * Return port that is associatade with @pin and PORT_NONE if no port is
> + * hard associated with that @pin.
> + */
> +enum port intel_hpd_port(enum hpd_pin pin)
>  {
>   switch (pin) {
>   case HPD_PORT_A:
> - *port = PORT_A;
> - return true;
> + return PORT_A;
>   case HPD_PORT_B:
> - *port = PORT_B;
> - return true;
> + return PORT_B;
>   case HPD_PORT_C:
> - *port = PORT_C;
> - return true;
> + return PORT_C;
>   case HPD_PORT_D:
> - *port = PORT_D;
> - return true;
> + return PORT_D;
>   case HPD_PORT_E:
> - *port = PORT_E;
> - return true;
> + return PORT_E;
>   default:
> - return false;   /* no hpd */
> + return PORT_NONE; /* no port for this pin */
>   }
>  }
>  
> @@ -389,8 +391,9 @@ void intel_hpd_irq_handler(struct drm_i915_private 
> *dev_priv,
>   if (!(BIT(i) & pin_mask))
>   continue;
>  
> - is_dig_port = intel_hpd_pin_to_port(i, ) &&
> -   dev_priv->hotplug.irq_port[port];
> + port = intel_hpd_port(i);
> + is_dig_port = port != PORT_NONE &&
> + dev_priv->hotplug.irq_port[port];

nit: I find
= (port != 

Re: [Intel-gfx] [PATCH i-g-t 8/8] tests/kms_ccs: Test CCS on sprite planes

2017-08-09 Thread Jason Ekstrand
On Tue, Aug 8, 2017 at 9:16 AM, Daniel Stone  wrote:

> Also try to test CCS on available non-primary planes. However, as there
> is not enough bandwidth to scan out both the primary and sprite planes
> when using CCS (or even Y-tiled), fall back to linear for the primary
> plane when using CCS for a sprite/cursor plane.
>
> Signed-off-by: Daniel Stone 
> ---
>  tests/kms_ccs.c | 74 ++
> +--
>  1 file changed, 67 insertions(+), 7 deletions(-)
>
> diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c
> index 79856f97..c544b36f 100644
> --- a/tests/kms_ccs.c
> +++ b/tests/kms_ccs.c
> @@ -37,19 +37,24 @@ enum test_flags {
>
>  enum test_fb_flags {
> FB_COMPRESSED   = 1 << 0,
> +   FB_HAS_PLANE= 1 << 1,
>  };
>
>  typedef struct {
> int drm_fd;
> igt_display_t display;
> struct igt_fb fb;
> +   struct igt_fb fb_sprite;
> igt_output_t *output;
> enum pipe pipe;
> enum test_flags flags;
> +   igt_plane_t *plane;
>  } data_t;
>
>  #define RED0x00ff
>  #define COMPRESSED_RED 0x0fff
> +#define GREEN  0xff00
> +#define COMPRESSED_GREEN   0x000ff00f
>
>  #define CCS_UNCOMPRESSED   0x0
>  #define CCS_COMPRESSED 0x55
> @@ -173,8 +178,10 @@ static void render_fb(data_t *data, uint32_t
> gem_handle, unsigned int size,
>  {
> uint32_t *ptr;
> unsigned int half_height, half_size;
> -   uint32_t uncompressed_color = RED;
> -   uint32_t compressed_color = COMPRESSED_RED;
> +   uint32_t uncompressed_color = data->plane ? GREEN : RED;
> +   uint32_t compressed_color =
> +   data->plane ? COMPRESSED_GREEN : COMPRESSED_RED;
> +   uint32_t bad_color = RED;
> int i;
>
> ptr = gem_mmap__cpu(data->drm_fd, gem_handle, 0, size,
> @@ -200,8 +207,19 @@ static void render_fb(data_t *data, uint32_t
> gem_handle, unsigned int size,
> ptr[i] = compressed_color;
> }
> } else {
> -   for (i = 0; i < size / 4; i++)
> -   ptr[i] = uncompressed_color;
> +   /* When we're displaying the primary plane underneath a
> +* sprite plane, cut out a 128 x 128 area (less than the
> sprite)
> +* plane size which we paint red, so we know easily if it's
> +* bad.
> +*/
> +   for (i = 0; i < size / 4; i++) {
> +   if ((fb_flags & FB_HAS_PLANE) &&
> +i < (stride * 128) && (i % (stride / 4)) < 1)
> {
>

I think this should be:

(i / (stride / 4)) < 128 && (i % (stride / 4)) < 128

Other than that and the other two comments I made on another patch, this
series looks good to me.  Patches 1-5 are

Reviewed-by: Jason Ekstrand 

Patches 6-7 are

Acked-by: Jason Ekstrand 

I don't feel 100% confident reviewing them without lots of reading of IGT
docs.


> +   ptr[i] = bad_color;
> +   } else {
> +   ptr[i] = uncompressed_color;
> +   }
> +   }
> }
>
> munmap(ptr, size);
> @@ -249,10 +267,17 @@ static void generate_fb(data_t *data, struct igt_fb
> *fb,
> uint64_t modifier;
> int ret;
>
> +   /* Use either compressed or Y-tiled to test. However, given the
> lack of
> +* available bandwidth, we use linear for the primary plane when
> +* testing sprites, since we cannot fit two CCS planes into the
> +* available FIFO configurations.
> +*/
> if (fb_flags & FB_COMPRESSED)
> modifier = LOCAL_I915_FORMAT_MOD_Y_TILED_CCS;
> -   else
> +   else if (!(fb_flags & FB_HAS_PLANE))
> modifier = LOCAL_I915_FORMAT_MOD_Y_TILED;
> +   else
> +   modifier = 0;
>
> f.flags = LOCAL_DRM_MODE_FB_MODIFIERS;
> f.width = width;
> @@ -338,8 +363,17 @@ static void try_config(data_t *data, enum
> test_fb_flags fb_flags)
> DRM_PLANE_TYPE_PRIMARY);
> plane_require_ccs(data, primary, DRM_FORMAT_XRGB);
>
> -   generate_fb(data, >fb, drm_mode->hdisplay,
> drm_mode->vdisplay,
> -   fb_flags);
> +   if (data->plane && fb_flags & FB_COMPRESSED) {
> +   plane_require_ccs(data, data->plane, DRM_FORMAT_XRGB);
> +   generate_fb(data, >fb, drm_mode->hdisplay,
> +   drm_mode->vdisplay,
> +   (fb_flags & ~FB_COMPRESSED) | FB_HAS_PLANE);
> +   generate_fb(data, >fb_sprite, 256, 256, fb_flags);
> +   } else {
> +   generate_fb(data, >fb, drm_mode->hdisplay,
> +   

Re: [Intel-gfx] [PATCH i-g-t 6/8] tests/kms_ccs: Test for supported modifier

2017-08-09 Thread Jason Ekstrand
On Tue, Aug 8, 2017 at 9:16 AM, Daniel Stone  wrote:

> Make sure the CCS modifier is supported on our plane, before we try to
> use it on that plane.
>
> Signed-off-by: Daniel Stone 
> ---
>  tests/kms_ccs.c | 117 ++
> +-
>  1 file changed, 116 insertions(+), 1 deletion(-)
>
> diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c
> index 1a5cdcd4..e74a68af 100644
> --- a/tests/kms_ccs.c
> +++ b/tests/kms_ccs.c
> @@ -54,6 +54,118 @@ typedef struct {
>  #define CCS_UNCOMPRESSED   0x0
>  #define CCS_COMPRESSED 0x55
>
> +struct local_drm_format_modifier {
> +   /* Bitmask of formats in get_plane format list this info applies
> to. The
> +   * offset allows a sliding window of which 64 formats (bits).
> +   *
> +   * Some examples:
> +   * In today's world with < 65 formats, and formats 0, and 2 are
> +   * supported
> +   * 0x0005
> +   * ^-offset = 0, formats = 5
> +   *
> +   * If the number formats grew to 128, and formats 98-102 are
> +   * supported with the modifier:
> +   *
> +   * 0x003c 
> +   * ^
> +   * |__offset = 64, formats = 0x3c
> +   *
> +   */
> +   uint64_t formats;
> +   uint32_t offset;
> +   uint32_t pad;
> +
> +   /* This modifier can be used with the format for this plane. */
> +   uint64_t modifier;
> +};
> +
> +struct local_drm_format_modifier_blob {
> +#define LOCAL_FORMAT_BLOB_CURRENT 1
> +   /* Version of this blob format */
> +   uint32_t version;
> +
> +   /* Flags */
> +   uint32_t flags;
> +
> +   /* Number of fourcc formats supported */
> +   uint32_t count_formats;
> +
> +   /* Where in this blob the formats exist (in bytes) */
> +   uint32_t formats_offset;
> +
> +   /* Number of drm_format_modifiers */
> +   uint32_t count_modifiers;
> +
> +   /* Where in this blob the modifiers exist (in bytes) */
> +   uint32_t modifiers_offset;
> +
> +   /* u32 formats[] */
> +   /* struct drm_format_modifier modifiers[] */
> +};
> +
> +static inline uint32_t *
> +formats_ptr(struct local_drm_format_modifier_blob *blob)
> +{
> +   return (uint32_t *)(((char *)blob) + blob->formats_offset);
> +}
> +
> +static inline struct local_drm_format_modifier *
> +modifiers_ptr(struct local_drm_format_modifier_blob *blob)
> +{
> +   return (struct local_drm_format_modifier *)(((char *)blob) +
> blob->modifiers_offset);
> +}
> +
> +static void plane_require_ccs(data_t *data, igt_plane_t *plane, uint32_t
> format)
> +{
> +   drmModePropertyBlobPtr blob;
> +   struct local_drm_format_modifier_blob *blob_data;
> +   struct local_drm_format_modifier *modifiers;
> +   uint32_t *formats;
> +   uint64_t blob_id;
> +   bool ret;
> +   int fmt_idx = -1;
> +
> +   ret = kmstest_get_property(data->drm_fd,
> plane->drm_plane->plane_id,
> +  DRM_MODE_OBJECT_PLANE, "IN_FORMATS",
> +  NULL, _id, NULL);
> +   igt_skip_on_f(ret == false, "IN_FORMATS not supported by
> kernel\n");
> +   igt_skip_on_f(blob_id == 0, "IN_FORMATS not supported by plane\n");
> +   blob = drmModeGetPropertyBlob(data->drm_fd, blob_id);
> +   igt_assert(blob);
> +   igt_assert_lte(sizeof(struct local_drm_format_modifier_blob),
> +  blob->length);
> +
> +   blob_data = (struct local_drm_format_modifier_blob *) blob->data;
> +   formats = formats_ptr(blob_data);
>

might consider an assert:

igt_assert(formats + blob_data->count_formats <= blob->length)


> +   for (int i = 0; i < blob_data->count_formats; i++) {
> +   if (formats[i] == format) {
> +   fmt_idx = i;
> +   break;
> +   }
> +   }
> +
> +   igt_skip_on_f(fmt_idx == -1,
> + "Format 0x%x not supported by plane\n", format);
> +
> +   modifiers = modifiers_ptr(blob_data);
>

igt_assert(modifiers + blob_data->count_modifiers <= blob->length)


> +   for (int i = 0; i < blob_data->count_modifiers; i++) {
> +   if (modifiers[i].modifier != LOCAL_I915_FORMAT_MOD_Y_TILED_
> CCS)
> +   continue;
> +
> +   if (modifiers[i].offset > fmt_idx ||
> +   fmt_idx > modifiers[i].offset + 63)
> +   continue;
> +
> +   if (modifiers[i].formats &
> +   (1UL << (fmt_idx - modifiers[i].offset)))
> +   return;
> +
> +   igt_skip("i915 CCS modifier not supported for format\n");
> +   }
> +
> +   igt_skip("i915 CCS modifier not supported by kernel for plane\n");
> +}
>
>  static void render_fb(data_t *data, uint32_t gem_handle, unsigned int
> size,
>   

Re: [Intel-gfx] [PATCH] drm/i915: Introduce intel_hdp_pin.

2017-08-09 Thread Pandiyan, Dhinakaran
On Wed, 2017-08-02 at 12:26 -0700, Rodrigo Vivi wrote:
> The idea is to have an unique place to decide the pin-port
> per platform.
> 
> So let's create this function now without any functional
> change. 

This seems to change the behavior when port A is not eDP.

> Just adding together code from hdmi and dp together.
> 
> v2: Add missing pin for port A.
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/intel_dp.c  |  8 ++--
>  drivers/gpu/drm/i915/intel_hdmi.c| 19 +--
>  drivers/gpu/drm/i915/intel_hotplug.c | 26 ++
>  4 files changed, 30 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5c2c7a677e96..c038717ad739 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3148,6 +3148,7 @@ void intel_hpd_init(struct drm_i915_private *dev_priv);
>  void intel_hpd_init_work(struct drm_i915_private *dev_priv);
>  void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
>  enum port intel_hpd_port(enum hpd_pin pin);
> +enum hpd_pin intel_hpd_pin(enum port port);
>  bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
>  void intel_hpd_enable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index d4e6128f3b3a..126783752c6d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5906,26 +5906,22 @@ intel_dp_init_connector_port_info(struct 
> intel_digital_port *intel_dig_port)
>   struct intel_encoder *encoder = _dig_port->base;
>   struct intel_dp *intel_dp = _dig_port->dp;
>  
> + encoder->hpd_pin = intel_hpd_pin(intel_dig_port->port);
> +
>   switch (intel_dig_port->port) {
>   case PORT_A:
> - encoder->hpd_pin = HPD_PORT_A;
>   intel_dp->aux_power_domain = POWER_DOMAIN_AUX_A;
>   break;
>   case PORT_B:
> - encoder->hpd_pin = HPD_PORT_B;
>   intel_dp->aux_power_domain = POWER_DOMAIN_AUX_B;
>   break;
>   case PORT_C:
> - encoder->hpd_pin = HPD_PORT_C;
>   intel_dp->aux_power_domain = POWER_DOMAIN_AUX_C;
>   break;
>   case PORT_D:
> - encoder->hpd_pin = HPD_PORT_D;
>   intel_dp->aux_power_domain = POWER_DOMAIN_AUX_D;
>   break;
>   case PORT_E:
> - encoder->hpd_pin = HPD_PORT_E;
> -
>   /* FIXME: Check VBT for actual wiring of PORT E */
>   intel_dp->aux_power_domain = POWER_DOMAIN_AUX_D;
>   break;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 5609976539bf..dcd14c71a989 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1921,24 +1921,7 @@ void intel_hdmi_init_connector(struct 
> intel_digital_port *intel_dig_port,
>   connector->ycbcr_420_allowed = true;
>  
>   intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
> -
> - switch (port) {
> - case PORT_B:
> - intel_encoder->hpd_pin = HPD_PORT_B;
> - break;
> - case PORT_C:
> - intel_encoder->hpd_pin = HPD_PORT_C;
> - break;
> - case PORT_D:
> - intel_encoder->hpd_pin = HPD_PORT_D;
> - break;
> - case PORT_E:
> - intel_encoder->hpd_pin = HPD_PORT_E;
> - break;
> - default:
> - MISSING_CASE(port);
> - return;
> - }
> + intel_encoder->hpd_pin = intel_hpd_pin(port);

Instead of returning early for port A, this will go ahead and attach the
HDMI encoder to the connector. However, I don't know likely  we'll have
a vbt that says port A supports both DP and HDMI but not eDP. 

>  
>   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
>   intel_hdmi->write_infoframe = vlv_write_infoframe;
> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
> b/drivers/gpu/drm/i915/intel_hotplug.c
> index 5982c47586e7..7b1cf30a3e9b 100644
> --- a/drivers/gpu/drm/i915/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> @@ -101,6 +101,32 @@ enum port intel_hpd_port(enum hpd_pin pin)
>   }
>  }
>  
> +/**
> + * intel_hpd_pin - return pin hard associated with certain port.
> + * @port: the hpd port to get associated pin
> + *
> + * Return pin that is associatade with @port and HDP_NONE if no pin is
> + * hard associated with that @port.
> + */
> +enum hpd_pin intel_hpd_pin(enum port port)
> +{
> + switch (port) {
> + case PORT_A:
> + return HPD_PORT_A;
> + case PORT_B:
> + return HPD_PORT_B;
> + case PORT_C:
> + return HPD_PORT_C;
> + case PORT_D:
> +   

Re: [Intel-gfx] [PATCH] drm/i915/vbt: Assume port A is connected to eDP when there's no VBT

2017-08-09 Thread rodrigo . vivi


> On Aug 9, 2017, at 8:20 PM, Dhinakaran Pandiyan  wrote:
> 
> We currently assume port A is connected to a DP sink when VBT is absent,
> instead assume it is connected to an eDP sink, which seems like a more
> common configuration. Although I don't have data to back this up,
> it is still just as valid as asumming port A is not eDP.

I also don't have enough data, but it is the most common configuration on the 
rvp boards that I see around...
Also the missing vbt case is more for dev platforms anyways right?!


> This reverts to
> the behavior before a98d9c1 ("drm/i915/ddi: Rely on VBT DDI port info for
> eDP detection") except only when there is no VBT. Knowing whether a panel
> is eDP or not from the panel itself would have been nicer, but I cannot
> find any DPCD registers that provide this reliably.
> 
> Cc: Jani Nikula 
> Cc: Imre Deak 
> Cc: Rodrigo Vivi 
> Cc: Clint Taylor 

+Joe
Does this fix the issue Joe has on his GLK B0?

> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
> drivers/gpu/drm/i915/intel_bios.c | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 82b144c..89a405e 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1403,6 +1403,7 @@ init_vbt_missing_defaults(struct drm_i915_private 
> *dev_priv)
>info->supports_dvi = (port != PORT_A && port != PORT_E);
>info->supports_hdmi = info->supports_dvi;
>info->supports_dp = (port != PORT_E);
> +info->supports_edp = (port == PORT_A);

>}
> }
> 
> -- 
> 2.7.4
> 
> ___
> 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] drm/i915: add register macro definition style guide

2017-08-09 Thread Pandiyan, Dhinakaran
On Fri, 2017-08-04 at 13:38 +0300, Jani Nikula wrote:
> This is not to try to force a new style; this is my interpretation of
> what the most common existing style is.
> 
> With hopes I don't need to answer so many questions about style going
> forward.
> 
> Cc: Daniel Vetter 
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> N.b. only the *interpretation* of the existing style is up for debate
> here. Proposals to *change* the style going forward can be done in other
> patches changing this description. However, I doubt the usefulness of
> such changes, with the possible exception of promoting the use of BIT().
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 77 
> +
>  1 file changed, 77 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index b2546ade2c45..324cf04d6bfe 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -25,6 +25,83 @@
>  #ifndef _I915_REG_H_
>  #define _I915_REG_H_
>  
> +/*
> + * The i915 register macro definition style guide.
> + *
> + * Follow the style described here for new macros, and while changing 
> existing
> + * macros. Do not mass change existing definitions just to update the style.
> + *
> + * LAYOUT
> + *
> + * Keep helper macros near the top. For example, _PIPE() and friends.
> + *
> + * Prefix macros that generally should not be used outside of this file with
> + * underscore '_'. For example, _PIPE() and friends, single instances of
> + * registers that are defined solely for the use by function-like macros.
> + *
> + * Avoid using the underscore prefixed macros outside of this file. There are
> + * exceptions, but keep them to a minimum.
> + *
> + * There are two basic types of register definitions: Single registers and
> + * register groups. Register groups are registers which have two or more
> + * instances, for example one per pipe, port, transcoder, etc. Register 
> groups
> + * should be defined using function-like macros.
> + *
> + * For single registers, define the register offset first, followed by 
> register
> + * contents.
> + *
> + * For register groups, define the register instance offsets first, prefixed
> + * with underscore, followed by a function-like macro choosing the right
> + * instance based on the parameter, followed by register contents.
> + *
> + * Define the register contents from most significant to least significant
> + * bit. Indent the bit and bit field macros using two extra spaces between
> + * #define and the macro name.
> + *
> + * For bit fields, define a _MASK and a _SHIFT macro. Define bit field 
> contents
> + * so that they are already shifted in place, and can be directly OR'd. For
> + * convenience, function-like macros may be used to define bit fields, but do
> + * note that the macros may be needed to read as well as write the register
> + * contents.

Thanks for writing this!

Do you mind including an example for defining bit-fields using
function-like macros?

With or without that, since this guide agrees with most of the existing
definitions in i915_reg.h
Reviewed-by: Dhinakaran Pandiyan 

> + *
> + * Define bits using (1 << N) instead of BIT(N). We may change this in the
> + * future, but this is the prevailing style.
> + *
> + * Group the register and its contents together without blank lines, separate
> + * from other registers and their contents with one blank line.
> + *
> + * Indent macro values from macro names using TABs. Use braces in macro 
> values
> + * as needed to avoid unintended precedence after macro substitution. Use 
> spaces
> + * in macro values according to kernel coding style. Use lower case in
> + * hexadecimal values.
> + *
> + * NAMING
> + *
> + * Try to name registers according to the specs. If the register name 
> changes in
> + * the specs from platform to another, stick to the original name.
> + *
> + * Try to re-use existing register macro definitions. Only add new macros for
> + * new register offsets, or when the register contents have changed enough to
> + * warrant a full redefinition.
> + *
> + * When a register or a bit (field) changes for a new platform, prefix the 
> new
> + * macro using the platform acronym or generation. For example, SKL_ or
> + * GEN8_. The prefix signifies the start platform/generation of the register.
> + *
> + * EXAMPLE
> + *
> + * #define _FOO_A0xf000
> + * #define _FOO_B0xf001
> + * #define FOO(pipe) _MMIO_PIPE(pipe, _FOO_A, _FOO_B)
> + * #define   FOO_ENABLE  (1 << 31)
> + * #define   FOO_MODE_MASK   (0xf << 16)
> + * #define   FOO_MODE_SHIFT  16
> + * #define   FOO_MODE_BAR(0 << 16)
> + * #define   FOO_MODE_BAZ(1 << 16)
> + * #define   GEN6_FOO_MODE_QUX   (2 << 16)
> + *
> + */
> +
>  typedef struct {
>   uint32_t reg;
>  } 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/vbt: Assume port A is connected to eDP when there's no VBT

2017-08-09 Thread Patchwork
== Series Details ==

Series: drm/i915/vbt: Assume port A is connected to eDP when there's no VBT
URL   : https://patchwork.freedesktop.org/series/28597/
State : success

== Summary ==

Series 28597v1 drm/i915/vbt: Assume port A is connected to eDP when there's no 
VBT
https://patchwork.freedesktop.org/api/1.0/series/28597/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-n2820) fdo#101705

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

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:433s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:420s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:353s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:497s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:486s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:524s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:586s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:429s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:409s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:416s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:511s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:477s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:457s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:567s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:589s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:528s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:450s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:643s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:460s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:427s
fi-skl-x1585ltotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:484s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:548s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:407s

2d0288b5b28c0d67460f0258a41bb4f78b812f29 drm-tip: 2017y-08m-09d-18h-09m-54s UTC 
integration manifest
03ce4244fb9f drm/i915/vbt: Assume port A is connected to eDP when there's no VBT

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5362/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915/vbt: Assume port A is connected to eDP when there's no VBT

2017-08-09 Thread Dhinakaran Pandiyan
We currently assume port A is connected to a DP sink when VBT is absent,
instead assume it is connected to an eDP sink, which seems like a more
common configuration. Although I don't have data to back this up,
it is still just as valid as asumming port A is not eDP. This reverts to
the behavior before a98d9c1 ("drm/i915/ddi: Rely on VBT DDI port info for
eDP detection") except only when there is no VBT. Knowing whether a panel
is eDP or not from the panel itself would have been nicer, but I cannot
find any DPCD registers that provide this reliably.

Cc: Jani Nikula 
Cc: Imre Deak 
Cc: Rodrigo Vivi 
Cc: Clint Taylor 

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_bios.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 82b144c..89a405e 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1403,6 +1403,7 @@ init_vbt_missing_defaults(struct drm_i915_private 
*dev_priv)
info->supports_dvi = (port != PORT_A && port != PORT_E);
info->supports_hdmi = info->supports_dvi;
info->supports_dp = (port != PORT_E);
+   info->supports_edp = (port == PORT_A);
}
 }
 
-- 
2.7.4

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


Re: [Intel-gfx] [PATCH v9 0/3] drm/i915/gvt: Enable guest i915 48bit full ppgtt support

2017-08-09 Thread Zhenyu Wang
On 2017.08.10 07:41:35 +0800, Tina Zhang wrote:
> This patch set is used to enable guest i915 48bit full ppgtt support.
> 
> Kechen Lu (1):
>   drm/i915/gvt: Add shadow context descriptor updating
> 
> Tina Zhang (2):
>   drm/i915: Enable guest i915 full ppgtt functionality
>   drm/i915/gvt: Fix guest i915 full ppgtt blocking issue
> 
>  drivers/gpu/drm/i915/gvt/execlist.c  |  2 ++
>  drivers/gpu/drm/i915/gvt/gtt.c   | 45 
> ++--
>  drivers/gpu/drm/i915/gvt/gvt.h   |  1 +
>  drivers/gpu/drm/i915/gvt/scheduler.c | 23 ++
>  drivers/gpu/drm/i915/gvt/vgpu.c  |  1 +
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/i915_gem_gtt.c  | 13 +++
>  drivers/gpu/drm/i915/i915_pvinfo.h   |  8 ++-
>  drivers/gpu/drm/i915/i915_vgpu.c |  7 ++
>  drivers/gpu/drm/i915/i915_vgpu.h |  3 +++
>  10 files changed, 82 insertions(+), 22 deletions(-)
> 

As agreed before and need to apply this series in order, i915 change
for this will be merged through gvt pull.

Applied this to gvt-next. Thanks!

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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


Re: [Intel-gfx] linux-next: manual merge of the drm-misc tree with Linus' tree

2017-08-09 Thread Stephen Rothwell
Hi Dave,

On Wed, 2 Aug 2017 12:23:06 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
> 
>   drivers/gpu/drm/nouveau/nv50_display.c
> 
> between commit:
> 
>   4a5431af19bc ("drm/nouveau/kms/nv50: update vblank state in response to 
> modeset actions")
> 
> from Linus' tree and commit:
> 
>   3c847d6cdadb ("drm/nouveau: Convert nouveau to use new iterator macros, 
> v2.")
> 
> from the drm-misc tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary.
> This is now fixed as far as linux-next is concerned, but any non
> trivial conflicts should be mentioned to your upstream maintainer when
> your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/gpu/drm/nouveau/nv50_display.c
> index 9d40b2a8be4d,bd1199b67eb4..
> --- a/drivers/gpu/drm/nouveau/nv50_display.c
> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
> @@@ -3941,8 -3933,6 +3942,8 @@@ nv50_disp_atomic_commit_tail(struct drm
>   
>   NV_ATOMIC(drm, "%s: clr %04x (set %04x)\n", crtc->name,
> asyh->clr.mask, asyh->set.mask);
> - if (crtc_state->active && !asyh->state.active)
> ++if (new_crtc_state->active && !asyh->state.active)
>  +drm_crtc_vblank_off(crtc);
>   
>   if (asyh->clr.mask) {
>   nv50_head_flush_clr(head, asyh, atom->flush_disable);
> @@@ -4028,13 -4018,11 +4029,13 @@@
>   nv50_head_flush_set(head, asyh);
>   interlock_core = 1;
>   }
>  -}
>   
>  -for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
>  -if (new_crtc_state->event)
>  -drm_crtc_vblank_get(crtc);
>  +if (asyh->state.active) {
> - if (!crtc_state->active)
> ++if (!new_crtc_state->active)
>  +drm_crtc_vblank_on(crtc);
>  +if (asyh->state.event)
>  +drm_crtc_vblank_get(crtc);
>  +}
>   }
>   
>   /* Update plane(s). */
> @@@ -4077,18 -4065,16 +4078,18 @@@
>   NV_ERROR(drm, "%s: timeout\n", plane->name);
>   }
>   
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - if (crtc->state->event) {
> + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->event) {
>   unsigned long flags;
>   /* Get correct count/ts if racing with vblank irq */
>  -drm_crtc_accurate_vblank_count(crtc);
>  +if (crtc->state->active)
>  +drm_crtc_accurate_vblank_count(crtc);
>   spin_lock_irqsave(>dev->event_lock, flags);
> - drm_crtc_send_vblank_event(crtc, crtc->state->event);
> + drm_crtc_send_vblank_event(crtc, new_crtc_state->event);
>   spin_unlock_irqrestore(>dev->event_lock, flags);
> - crtc->state->event = NULL;
> + new_crtc_state->event = NULL;
>  -drm_crtc_vblank_put(crtc);
>  +if (crtc->state->active)
>  +drm_crtc_vblank_put(crtc);
>   }
>   }
>   

This conflict is now between the drm tree and Linus' tree.

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


Re: [Intel-gfx] [PATCH] drm/vgem: Couple in drm_syncobj support

2017-08-09 Thread Jason Ekstrand
On Wed, Aug 9, 2017 at 6:23 PM, Chris Wilson 
wrote:

> Quoting Jason Ekstrand (2017-08-10 02:02:43)
> > On Wed, Aug 9, 2017 at 12:03 PM, Chris Wilson 
> wrote:
> >
> > To further facilitate GEM testing, allow testing of drm_syncobj by
> > attaching them to vgem fences. These fences are already employed by
> igt
> > for testing inter-driver fence handling (across dmabuf and
> sync_file).
> >
> > An igt example use would be like:
> >
> >int vgem = drm_driver_open(DRIVER_VGEM);
> >uint32_t handle = vgem_create_dummy(vgem);
> >
> >
> > This is a bit nasty... Why do we need a BO?  Why can't we just create and
> > attach a fence without the BO?
>
> Attach a fence to what? vgem is a wrapper around memory with the fences
> for coordinating exclusive/shared access to that memory. If you remove
> that memory, you remove the only functionality vgem has.
>
> You would be left with just some fences each on their own abstract
> timeline. At that point, you might as well use sw_sync, at least that
> exports a notion of a timeline (which may or may not be useful).
>

Then maybe sw_sync is a better tool for testing syncobj.  I had one version
of my i-g-t patches which used it and it worked out quite well.  Maybe I
should just go back to that.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 2/4] tests/syncobj: Convert the basic test over to the helpers

2017-08-09 Thread Jason Ekstrand
Signed-off-by: Jason Ekstrand 
---
 tests/syncobj_basic.c | 77 +--
 1 file changed, 19 insertions(+), 58 deletions(-)

diff --git a/tests/syncobj_basic.c b/tests/syncobj_basic.c
index a7a6742..b08dd2d 100644
--- a/tests/syncobj_basic.c
+++ b/tests/syncobj_basic.c
@@ -22,6 +22,7 @@
  */
 
 #include "igt.h"
+#include "igt_syncobj.h"
 #include 
 #include 
 #include "drm.h"
@@ -48,14 +49,11 @@ static void
 test_bad_handle_to_fd(int fd)
 {
struct drm_syncobj_handle handle;
-   int ret;
 
handle.handle = 0xdeadbeef;
handle.flags = 0;
 
-   ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, );
-
-   igt_assert(ret == -1 && errno == EINVAL);
+   igt_assert_eq(__syncobj_handle_to_fd(fd, ), -EINVAL);
 }
 
 /* fd to handle a bad fd */
@@ -63,14 +61,11 @@ static void
 test_bad_fd_to_handle(int fd)
 {
struct drm_syncobj_handle handle;
-   int ret;
 
handle.fd = -1;
handle.flags = 0;
 
-   ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, );
-
-   igt_assert(ret == -1 && errno == EINVAL);
+   igt_assert_eq(__syncobj_fd_to_handle(fd, ), -EINVAL);
 }
 
 /* fd to handle an fd but not a sync file one */
@@ -78,58 +73,47 @@ static void
 test_illegal_fd_to_handle(int fd)
 {
struct drm_syncobj_handle handle;
-   int ret;
 
handle.fd = fd;
handle.flags = 0;
 
-   ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, );
-
-   igt_assert(ret == -1 && errno == EINVAL);
+   igt_assert_eq(__syncobj_fd_to_handle(fd, ), -EINVAL);
 }
 
 static void
 test_bad_flags_fd_to_handle(int fd)
 {
struct drm_syncobj_handle handle = { 0 };
-   int ret;
 
handle.flags = 0xdeadbeef;
-   ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, );
-   igt_assert(ret == -1 && errno == EINVAL);
+   igt_assert_eq(__syncobj_fd_to_handle(fd, ), -EINVAL);
 }
 
 static void
 test_bad_flags_handle_to_fd(int fd)
 {
struct drm_syncobj_handle handle = { 0 };
-   int ret;
 
handle.flags = 0xdeadbeef;
-   ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, );
-   igt_assert(ret == -1 && errno == EINVAL);
+   igt_assert_eq(__syncobj_handle_to_fd(fd, ), -EINVAL);
 }
 
 static void
 test_bad_pad_handle_to_fd(int fd)
 {
struct drm_syncobj_handle handle = { 0 };
-   int ret;
 
handle.pad = 0xdeadbeef;
-   ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, );
-   igt_assert(ret == -1 && errno == EINVAL);
+   igt_assert_eq(__syncobj_handle_to_fd(fd, ), -EINVAL);
 }
 
 static void
 test_bad_pad_fd_to_handle(int fd)
 {
struct drm_syncobj_handle handle = { 0 };
-   int ret;
 
handle.pad = 0xdeadbeef;
-   ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, );
-   igt_assert(ret == -1 && errno == EINVAL);
+   igt_assert_eq(__syncobj_fd_to_handle(fd, ), -EINVAL);
 }
 
 
@@ -138,24 +122,17 @@ test_bad_pad_fd_to_handle(int fd)
 static void
 test_bad_destroy_pad(int fd)
 {
-   struct drm_syncobj_create create = { 0 };
struct drm_syncobj_destroy destroy;
int ret;
 
-   ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_CREATE, );
-
-   destroy.handle = create.handle;
+   destroy.handle = syncobj_create(fd);
destroy.pad = 0xdeadbeef;
 
ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_DESTROY, );
 
igt_assert(ret == -1 && errno == EINVAL);
 
-   destroy.handle = create.handle;
-   destroy.pad = 0;
-
-   ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_DESTROY, );
-   igt_assert(ret == 0);
+   syncobj_destroy(fd, destroy.handle);
 }
 
 static void
@@ -176,34 +153,18 @@ test_bad_create_flags(int fd)
 static void
 test_valid_cycle(int fd)
 {
-   int ret;
-   struct drm_syncobj_create create = { 0 };
-   struct drm_syncobj_handle handle = { 0 };
-   struct drm_syncobj_destroy destroy = { 0 };
-   uint32_t first_handle;
-
-   ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_CREATE, );
-   igt_assert(ret == 0);
+   uint32_t first_handle, second_handle;
+   int syncobj_fd;
 
-   first_handle = create.handle;
+   first_handle = syncobj_create(fd);
+   syncobj_fd = syncobj_handle_to_fd(fd, first_handle, 0);
+   second_handle = syncobj_fd_to_handle(fd, syncobj_fd, 0);
+   close(syncobj_fd);
 
-   handle.handle = create.handle;
-   ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, );
-   igt_assert(ret == 0);
-   handle.handle = 0;
-   ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, );
-   close(handle.fd);
-   igt_assert(ret == 0);
+   igt_assert(first_handle != second_handle);
 
-   igt_assert(handle.handle != first_handle);
-
-   destroy.handle = handle.handle;
-   ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_DESTROY, );
-   igt_assert(ret == 0);
-
-   destroy.handle = first_handle;
-   ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_DESTROY, );
-   igt_assert(ret == 0);
+   syncobj_destroy(fd, 

[Intel-gfx] [PATCH 3/4] lib/igt_vgem: Add a syncobj attach helper

2017-08-09 Thread Jason Ekstrand
Signed-off-by: Jason Ekstrand 
---
 lib/igt_vgem.c | 25 -
 lib/igt_vgem.h |  1 +
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/lib/igt_vgem.c b/lib/igt_vgem.c
index 21cccb3..069c6dd 100644
--- a/lib/igt_vgem.c
+++ b/lib/igt_vgem.c
@@ -101,8 +101,9 @@ void *vgem_mmap(int fd, struct vgem_bo *bo, unsigned prot)
 struct local_vgem_fence_attach {
uint32_t handle;
uint32_t flags;
+#define LOCAL_VGEM_FENCE_SYNCOBJ   0x2
uint32_t out_fence;
-   uint32_t pad;
+   uint32_t syncobj;
 };
 
 struct local_vgem_fence_signal {
@@ -167,6 +168,28 @@ uint32_t vgem_fence_attach(int fd, struct vgem_bo *bo, 
unsigned flags)
return arg.out_fence;
 }
 
+uint32_t vgem_fence_attach_syncobj(int fd, uint32_t syncobj)
+{
+   struct local_vgem_fence_attach arg;
+   struct vgem_bo bo;
+
+   /* Create a dummy BO so the import works */
+   bo.width = 1;
+   bo.height = 1;
+   bo.bpp = 4;
+   vgem_create(fd, );
+
+   memset(, 0, sizeof(arg));
+   arg.handle = bo.handle;
+   arg.syncobj = syncobj;
+   arg.flags = LOCAL_VGEM_FENCE_SYNCOBJ;
+   igt_assert_eq(__vgem_fence_attach(fd, ), 0);
+
+   gem_close(fd, bo.handle);
+
+   return arg.out_fence;
+}
+
 static int ioctl_vgem_fence_signal(int fd, struct local_vgem_fence_signal *arg)
 {
int err = 0;
diff --git a/lib/igt_vgem.h b/lib/igt_vgem.h
index 002ad7f..555674b 100644
--- a/lib/igt_vgem.h
+++ b/lib/igt_vgem.h
@@ -44,6 +44,7 @@ bool vgem_fence_has_flag(int fd, unsigned flags);
 uint32_t vgem_fence_attach(int fd, struct vgem_bo *bo, unsigned flags);
 #define VGEM_FENCE_WRITE 0x1
 #define WIP_VGEM_FENCE_NOTIMEOUT 0x2
+uint32_t vgem_fence_attach_syncobj(int fd, uint32_t syncobj);
 int __vgem_fence_signal(int fd, uint32_t fence);
 void vgem_fence_signal(int fd, uint32_t fence);
 
-- 
2.5.0.400.gff86faf

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


[Intel-gfx] [PATCH 1/4] lib: Add some syncobj helpers

2017-08-09 Thread Jason Ekstrand
Signed-off-by: Jason Ekstrand 
---
 lib/Makefile.sources |   2 +
 lib/igt_syncobj.c| 176 +++
 lib/igt_syncobj.h|  65 +++
 3 files changed, 243 insertions(+)
 create mode 100644 lib/igt_syncobj.c
 create mode 100644 lib/igt_syncobj.h

diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 53fdb54..692fe30 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -83,6 +83,8 @@ lib_source_list = \
uwildmat/uwildmat.c \
igt_kmod.c  \
igt_kmod.h  \
+   igt_syncobj.c   \
+   igt_syncobj.h   \
$(NULL)
 
 .PHONY: version.h.tmp
diff --git a/lib/igt_syncobj.c b/lib/igt_syncobj.c
new file mode 100644
index 000..ce9c1e2
--- /dev/null
+++ b/lib/igt_syncobj.c
@@ -0,0 +1,176 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+
+#include "igt.h"
+#include "igt_syncobj.h"
+
+static int
+__syncobj_create(int fd, uint32_t *handle)
+{
+   struct drm_syncobj_create create = { 0 };
+   int err = 0;
+
+   if (drmIoctl(fd, DRM_IOCTL_SYNCOBJ_CREATE, ))
+   err = -errno;
+   *handle = create.handle;
+   return err;
+}
+
+uint32_t
+syncobj_create(int fd)
+{
+   uint32_t handle;
+   igt_assert_eq(__syncobj_create(fd, ), 0);
+   igt_assert(handle);
+   return handle;
+}
+
+static int
+__syncobj_destroy(int fd, uint32_t handle)
+{
+   struct drm_syncobj_destroy destroy = { 0 };
+   int err = 0;
+
+   destroy.handle = handle;
+   if (drmIoctl(fd, DRM_IOCTL_SYNCOBJ_DESTROY, ))
+   err = -errno;
+   return err;
+}
+
+void
+syncobj_destroy(int fd, uint32_t handle)
+{
+   igt_assert_eq(__syncobj_destroy(fd, handle), 0);
+}
+
+int
+__syncobj_handle_to_fd(int fd, struct drm_syncobj_handle *args)
+{
+   int err = 0;
+   if (drmIoctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, args))
+   err = -errno;
+   return err;
+}
+
+int
+syncobj_handle_to_fd(int fd, uint32_t handle, uint32_t flags)
+{
+   struct drm_syncobj_handle args = { 0 };
+   args.handle = handle;
+   args.flags = flags;
+   igt_assert_eq(__syncobj_handle_to_fd(fd, ), 0);
+   igt_assert(args.fd >= 0);
+   return args.fd;
+}
+
+int
+__syncobj_fd_to_handle(int fd, struct drm_syncobj_handle *args)
+{
+   int err = 0;
+   if (drmIoctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, args))
+   err = -errno;
+   return err;
+}
+
+uint32_t
+syncobj_fd_to_handle(int fd, int syncobj_fd, uint32_t flags)
+{
+   struct drm_syncobj_handle args = { 0 };
+   args.fd = syncobj_fd;
+   args.flags = flags;
+   igt_assert_eq(__syncobj_fd_to_handle(fd, ), 0);
+   igt_assert(args.handle > 0);
+   return args.handle;
+}
+
+int
+__syncobj_wait(int fd, struct local_syncobj_wait *args)
+{
+   int err = 0;
+   if (drmIoctl(fd, LOCAL_IOCTL_SYNCOBJ_WAIT, args))
+   err = -errno;
+   return err;
+}
+
+int
+syncobj_wait_err(int fd, uint32_t *handles, uint32_t count,
+uint64_t abs_timeout_nsec, uint32_t flags)
+{
+   struct local_syncobj_wait wait;
+
+   wait.handles = to_user_pointer(handles);
+   wait.timeout_nsec = abs_timeout_nsec;
+   wait.count_handles = count;
+   wait.flags = flags;
+   wait.first_signaled = 0;
+   wait.pad = 0;
+
+   return __syncobj_wait(fd, );
+}
+
+bool
+syncobj_wait(int fd, uint32_t *handles, uint32_t count,
+uint64_t abs_timeout_nsec, uint32_t flags,
+uint32_t *first_signaled)
+{
+   struct local_syncobj_wait wait;
+   int ret;
+
+   wait.handles = to_user_pointer(handles);
+   wait.timeout_nsec = abs_timeout_nsec;
+   wait.count_handles = count;
+   wait.flags = flags;

[Intel-gfx] [PATCH 4/4] tests/syncobj: Add some wait and reset tests (v4)

2017-08-09 Thread Jason Ekstrand
This adds both trivial error-checking tests as well as more complex
tests which actually test whether or not waits do what they're supposed
to do.  They only currently work on i915 but it should be simple to hook
them up for other drivers by simply implementing the little function
pointer hook provided at the top for triggering a syncobj.

v2:
 - Actually add the reset tests.
v3:
 - Only do one execbuf for trigger
 - Use do_ioctl and do_ioctl_err
 - Better check for syncobj support
 - Add local_/LOCAL_ defines of things
 - Use a timer instead of a pthread
v4:
 - Use ioctl wrappers
 - Use VGEM instead of i915
 - Combine a bunch of the simple tests into one function

Signed-off-by: Jason Ekstrand 
---
 tests/Makefile.sources |   1 +
 tests/syncobj_wait.c   | 624 +
 2 files changed, 625 insertions(+)
 create mode 100644 tests/syncobj_wait.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index bb013c7..430b637 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -230,6 +230,7 @@ TESTS_progs = \
prime_vgem \
sw_sync \
syncobj_basic \
+   syncobj_wait \
template \
tools_test \
vgem_basic \
diff --git a/tests/syncobj_wait.c b/tests/syncobj_wait.c
new file mode 100644
index 000..0607a1a
--- /dev/null
+++ b/tests/syncobj_wait.c
@@ -0,0 +1,624 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "igt.h"
+#include "igt_vgem.h"
+#include "sw_sync.h"
+#include "igt_syncobj.h"
+#include 
+#include 
+#include 
+#include "drm.h"
+
+IGT_TEST_DESCRIPTION("Tests for the drm sync object wait API");
+
+/* One tenth of a second */
+#define SHORT_TIME_NSEC 1ull
+
+#define NSECS_PER_SEC 10ull
+
+static uint64_t
+gettime_ns(void)
+{
+   struct timespec current;
+   clock_gettime(CLOCK_MONOTONIC, );
+   return (uint64_t)current.tv_sec * NSECS_PER_SEC + current.tv_nsec;
+}
+
+static uint64_t
+short_timeout(void)
+{
+   return gettime_ns() + SHORT_TIME_NSEC;
+}
+
+static void
+syncobj_trigger(int fd, uint32_t handle)
+{
+   uint32_t fence = vgem_fence_attach_syncobj(fd, handle);
+   vgem_fence_signal(fd, fence);
+}
+
+struct delayed_trigger {
+   int fd;
+   uint32_t *syncobjs;
+   int count;
+   uint64_t nsec;
+};
+
+static void
+trigger_syncobj_delayed_func(union sigval sigval)
+{
+   struct delayed_trigger *trigger = sigval.sival_ptr;
+   int i;
+
+   for (i = 0; i < trigger->count; i++)
+   syncobj_trigger(trigger->fd, trigger->syncobjs[i]);
+   free(trigger);
+}
+
+static timer_t
+trigger_syncobj_delayed(int fd, uint32_t *syncobjs, int count, uint64_t nsec)
+{
+   struct delayed_trigger *trigger;
+timer_t timer;
+struct sigevent sev;
+struct itimerspec its;
+
+   trigger = malloc(sizeof(*trigger));
+   trigger->fd = fd;
+   trigger->syncobjs = syncobjs;
+   trigger->count = count;
+   trigger->nsec = nsec;
+
+memset(, 0, sizeof(sev));
+sev.sigev_notify = SIGEV_THREAD;
+sev.sigev_value.sival_ptr = trigger;
+sev.sigev_notify_function = trigger_syncobj_delayed_func;
+igt_assert(timer_create(CLOCK_MONOTONIC, , ) == 0);
+
+memset(, 0, sizeof(its));
+its.it_value.tv_sec = nsec / NSEC_PER_SEC;
+its.it_value.tv_nsec = nsec % NSEC_PER_SEC;
+igt_assert(timer_settime(timer, 0, , NULL) == 0);
+
+   return timer;
+}
+
+static void
+test_wait_bad_flags(int fd)
+{
+   struct local_syncobj_wait wait = { 0 };
+   wait.flags = 0xdeadbeef;
+   igt_assert_eq(__syncobj_wait(fd, ), -EINVAL);
+}
+
+static void
+test_wait_zero_handles(int fd)
+{
+   struct local_syncobj_wait wait = { 0 };
+   igt_assert_eq(__syncobj_wait(fd, ), -EINVAL);
+}
+
+static void

Re: [Intel-gfx] [PATCH] drm/vgem: Couple in drm_syncobj support

2017-08-09 Thread Chris Wilson
Quoting Jason Ekstrand (2017-08-10 02:02:43)
> On Wed, Aug 9, 2017 at 12:03 PM, Chris Wilson  
> wrote:
> 
> To further facilitate GEM testing, allow testing of drm_syncobj by
> attaching them to vgem fences. These fences are already employed by igt
> for testing inter-driver fence handling (across dmabuf and sync_file).
> 
> An igt example use would be like:
> 
>    int vgem = drm_driver_open(DRIVER_VGEM);
>    uint32_t handle = vgem_create_dummy(vgem);
> 
> 
> This is a bit nasty... Why do we need a BO?  Why can't we just create and
> attach a fence without the BO?

Attach a fence to what? vgem is a wrapper around memory with the fences
for coordinating exclusive/shared access to that memory. If you remove
that memory, you remove the only functionality vgem has.

You would be left with just some fences each on their own abstract
timeline. At that point, you might as well use sw_sync, at least that
exports a notion of a timeline (which may or may not be useful).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/vgem: Couple in drm_syncobj support

2017-08-09 Thread Jason Ekstrand
On Wed, Aug 9, 2017 at 12:03 PM, Chris Wilson 
wrote:

> To further facilitate GEM testing, allow testing of drm_syncobj by
> attaching them to vgem fences. These fences are already employed by igt
> for testing inter-driver fence handling (across dmabuf and sync_file).
>
> An igt example use would be like:
>
>int vgem = drm_driver_open(DRIVER_VGEM);
>uint32_t handle = vgem_create_dummy(vgem);
>

This is a bit nasty... Why do we need a BO?  Why can't we just create and
attach a fence without the BO?


>uint32_t syncobj = drm_syncobj_create(vgem);
>uint32_t fence = drmIoctl(vgem,
>  DRM_IOCTL_VGEM_FENCE_ATTACH,
>  &(struct vgem_fence_attach){
> .handle = handle,
> .flags = VGEM_FENCE_SYNCOBJ,
> .syncobj = syncobj,
>  });
>
>/* ... use syncobj for profit ... */
>
>vgem_fence_signal(vgem, fence);
>
> For wider use though, there is little immediate benefit to syncobj
> over the vgem fence as both are handles in an idr (the fence here is not
> a sync-file fd like in most other drivers). The main benefit for syncobj
> is that it allows to create channels between objects and drivers by
> virtue of its persistence beyond the vgem fence itself.
>
> Signed-off-by: Chris Wilson 
> Cc: Jason Ekstrand 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/vgem/vgem_drv.c   |  4 +++-
>  drivers/gpu/drm/vgem/vgem_fence.c | 26 ++
>  include/drm/drm_syncobj.h |  2 ++
>  include/uapi/drm/vgem_drm.h   |  3 ++-
>  4 files changed, 29 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_
> drv.c
> index 12289673f457..a0202e1eaf6b 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -432,7 +432,9 @@ static void vgem_release(struct drm_device *dev)
>  }
>
>  static struct drm_driver vgem_driver = {
> -   .driver_features= DRIVER_GEM | DRIVER_PRIME,
> +   .driver_features= (DRIVER_GEM |
> +  DRIVER_PRIME |
> +  DRIVER_SYNCOBJ),
> .release= vgem_release,
> .open   = vgem_open,
> .postclose  = vgem_postclose,
> diff --git a/drivers/gpu/drm/vgem/vgem_fence.c
> b/drivers/gpu/drm/vgem/vgem_fence.c
> index 3109c8308eb5..988e860c03d3 100644
> --- a/drivers/gpu/drm/vgem/vgem_fence.c
> +++ b/drivers/gpu/drm/vgem/vgem_fence.c
> @@ -23,6 +23,8 @@
>  #include 
>  #include 
>
> +#include 
> +
>  #include "vgem_drv.h"
>
>  #define VGEM_FENCE_TIMEOUT (10*HZ)
> @@ -156,20 +158,30 @@ int vgem_fence_attach_ioctl(struct drm_device *dev,
> struct drm_vgem_fence_attach *arg = data;
> struct vgem_file *vfile = file->driver_priv;
> struct reservation_object *resv;
> +   struct drm_syncobj *sync = NULL;
> struct drm_gem_object *obj;
> struct dma_fence *fence;
> int ret;
>
> -   if (arg->flags & ~VGEM_FENCE_WRITE)
> -   return -EINVAL;
> -
> -   if (arg->pad)
> +   if (arg->flags & ~(VGEM_FENCE_WRITE | VGEM_FENCE_SYNCOBJ))
> return -EINVAL;
>
> obj = drm_gem_object_lookup(file, arg->handle);
> if (!obj)
> return -ENOENT;
>
> +   if (arg->flags & VGEM_FENCE_SYNCOBJ) {
> +   sync = drm_syncobj_find(file, arg->syncobj);
> +   if (!sync) {
> +   ret = -ENOENT;
> +   goto err;
> +   }
> +
> +   /* We don't check if the current syncobj is busy or not, we
> +* will just replace it with ourselves.
> +*/
> +   }
> +
> ret = attach_dmabuf(dev, obj);
> if (ret)
> goto err;
> @@ -207,12 +219,18 @@ int vgem_fence_attach_ioctl(struct drm_device *dev,
> ret = 0;
> }
> }
> +
> +   if (ret == 0 && sync)
> +   drm_syncobj_replace_fence(sync, fence);
> +
>  err_fence:
> if (ret) {
> dma_fence_signal(fence);
> dma_fence_put(fence);
> }
>  err:
> +   if (sync)
> +   drm_syncobj_put(sync);
> drm_gem_object_unreference_unlocked(obj);
> return ret;
>  }
> diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
> index 89976da542b1..9010ab8343e5 100644
> --- a/include/drm/drm_syncobj.h
> +++ b/include/drm/drm_syncobj.h
> @@ -28,6 +28,8 @@
>
>  #include "linux/dma-fence.h"
>
> +struct drm_file;
> +
>  /**
>   * struct drm_syncobj - sync object.
>   *
> diff --git a/include/uapi/drm/vgem_drm.h b/include/uapi/drm/vgem_drm.h
> 

Re: [Intel-gfx] [PATCH 0/8] Adding NV12 support for SKL display

2017-08-09 Thread Hwang, Dongseong
I tested it on my Kaby Lake chromebook, and it works perfectly.

Best regards,
DS

On Thu, Aug 3, 2017 at 6:23 PM, Hwang, Dongseong
 wrote:
> Thank you for working on NV12 plane support. ChromeOS eagerly wants this
> feature to save power on Youtube. If it's landed soon, I'll really
> appreciate it.
>
> Kristian is working on backporting it to the downstream ChromeOS kernel.
> https://chromium-review.googlesource.com/c/601288
>
> I tested it on my Apollo Lake chromebook, but there is blackscreen
> flickering. NOTE: RGBA, RGBX, BGRA, BGRX, YUYV works without flickering.
> https://goo.gl/photos/tr5VfMiKeyEpDg9K6
>
> Best regards,
> DS
>
>
>
> On Tue, Jul 11, 2017 at 9:18 AM, Ville Syrjälä
>  wrote:
>>
>> On Tue, Jul 11, 2017 at 07:40:48PM +0530, Vidya Srinivas wrote:
>> > This patch series is adding NV12 support for Skylake display after
>> > rebasing on latest drm-intel-nightly. Initial series of the patches
>> > can be found here:
>> > https://lists.freedesktop.org/archives/intel-gfx/2015-May/066786.html
>> >
>> > Feature has been currently tested with custom linux based test tool
>> > IGT test development is under progress. Floating these patches for
>> > initial review. These NV12 patches are dependent on Ville's patches
>> > mentioned below.
>> >
>> > Update from last rev:
>> > Patches were initial reviewed last when floated but
>> > currently there was a design change with respect to
>> > - the way fb offset is handled
>> > - the way rotation is handled
>> > Rebase of the current NV12 patch series has been done as per the
>> > current changes on drm-intel-nightly.
>> > Review comments from Ville (12th June 2017) have been addressed
>> > Review comments from Clinton A Taylor (7th July 2017) have been
>> > addressed
>> > Review comments from Clinton A Taylor (10th July 2017) have been
>> > addressed. Had missed out tested-by/reviewed-by in the patches.
>> > Fixed that error in this series.
>> >
>> > Chandra Konduru (6):
>> >   drm/i915: Set scaler mode for NV12
>> >   drm/i915: Update format_is_yuv() to include NV12
>> >   drm/i915: Upscale scaler max scale for NV12
>> >   drm/i915: Add NV12 as supported format for primary plane
>> >   drm/i915: Add NV12 as supported format for sprite plane
>> >   drm/i915: Add NV12 support to intel_framebuffer_init
>> >
>> > Ville Syrjälä (2):
>> >   drm/i915: Implement .get_format_info() hook for CCS
>> >   drm/i915: Add render decompression support
>>
>> These two are some old stale versions of my CCS patches. I suppose it
>> shouldn't matter too much, as long as no one has based any userspace tests
>> on these since later versions will change how interpret fb->offsets[].
>>
>> >
>> >  drivers/gpu/drm/drm_fourcc.c |   2 +-
>> >  drivers/gpu/drm/i915/i915_reg.h  |  24 +++
>> >  drivers/gpu/drm/i915/intel_atomic.c  |   8 +-
>> >  drivers/gpu/drm/i915/intel_display.c | 313
>> > ---
>> >  drivers/gpu/drm/i915/intel_drv.h |   3 +-
>> >  drivers/gpu/drm/i915/intel_pm.c  |  29 +++-
>> >  drivers/gpu/drm/i915/intel_sprite.c  |  16 +-
>> >  include/drm/drm_mode_config.h|   3 +-
>> >  include/uapi/drm/drm_fourcc.h|   3 +
>> >  9 files changed, 365 insertions(+), 36 deletions(-)
>> >
>> > --
>> > 1.9.1
>> >
>> > ___
>> > Intel-gfx mailing list
>> > Intel-gfx@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>> --
>> Ville Syrjälä
>> Intel OTC
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v9 2/3] drm/i915: Enable guest i915 full ppgtt functionality

2017-08-09 Thread Tina Zhang
Enable the guest i915 full ppgtt functionality when host can provide this
capability. vgt_caps is introduced to guest i915 driver to get the vgpu
capabilities from the device model. VGT_CPAS_FULL_PPGTT is one of the
capabilities type to let guest i915 dirver know that the guest i915 full
ppgtt is supported by device model.

Notice that the minor version of pvinfo isn't bumped because of this
vgt_caps introduction, due to older guest would be broken by simply
increasing the pvinfo version. Although the pvinfo minor version doesn't
increase, the compatibility won't be blocked. The compatibility is ensured
by checking the value of caps field in pvinfo. Zero means no full ppgtt
support and BIT(2) means this feature is provided.

Changes since v1:
- Use u32 instead of uint32_t (Joonas)
- Move VGT_CAPS_FULL_PPGTT introduction to this patch and use #define
  instead of enum (Joonas)
- Rewrite the vgpu full ppgtt capability checking logic. (Joonas)
- Some coding style refine. (Joonas)

Changes since v2:
- Divide the whole patch set into two separate patch series, with one
  patch in i915 side to check guest i915 full ppgtt capability and enable
  it when this capability is supported by the device model, and the other
  one in gvt side which fixs the blocking issue and enables the device
  model to provide the capability to guest. And this patch focuses on guest
  i915 side. (Joonas)
- Change the title from "introduce vgt_caps to pvinfo" to
  "Enable guest i915 full ppgtt functionality". (Tina)

Change since v3:
- Add some comments about pvinfo caps and version. (Joonas)

Change since v4:
- Tested by Tina Zhang.

Change since v5:
- Add limitation about supporting 32bit full ppgtt.

Change since v6:
- Change the fallback to 48bit full ppgtt if i915.ppgtt_enable=2. (Zhenyu)

Change in v9:
- Remove the fixme comment due to no plan for 32bit full ppgtt
  support. (Zhenyu)
- Reorder the patch-set to fix compiling issue with git-bisect. (Zhenyu)
- Add print log when forcing guest 48bit full ppgtt. (Zhenyu)

Reviewed-by: Joonas Lahtinen  in v2
Signed-off-by: Tina Zhang 

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b051122..1b95069 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1879,6 +1879,7 @@ struct i915_workarounds {
 
 struct i915_virtual_gpu {
bool active;
+   u32 caps;
 };
 
 /* used in computing the new watermarks state */
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 10aa776..090ceb7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -141,14 +141,19 @@ int intel_sanitize_enable_ppgtt(struct drm_i915_private 
*dev_priv,
 
has_aliasing_ppgtt = dev_priv->info.has_aliasing_ppgtt;
has_full_ppgtt = dev_priv->info.has_full_ppgtt;
-   has_full_48bit_ppgtt = dev_priv->info.has_full_48bit_ppgtt;
 
if (intel_vgpu_active(dev_priv)) {
-   /* emulation is too hard */
-   has_full_ppgtt = false;
-   has_full_48bit_ppgtt = false;
+   has_full_ppgtt = intel_vgpu_has_full_ppgtt(dev_priv);
+   /* GVT-g has no support for 32bit ppgtt */
+   if (enable_ppgtt == 2 && has_full_ppgtt) {
+   DRM_DEBUG_DRIVER("Force 48bit ppgtt for vGPU\n");
+   enable_ppgtt = 3;
+   }
}
 
+   has_full_48bit_ppgtt = has_full_ppgtt &&
+   dev_priv->info.has_full_48bit_ppgtt;
+
if (!has_aliasing_ppgtt)
return 0;
 
diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h 
b/drivers/gpu/drm/i915/i915_pvinfo.h
index 2cfe96d3..7e958d7 100644
--- a/drivers/gpu/drm/i915/i915_pvinfo.h
+++ b/drivers/gpu/drm/i915/i915_pvinfo.h
@@ -49,12 +49,18 @@ enum vgt_g2v_type {
VGT_G2V_MAX,
 };
 
+/*
+ * VGT capabilities type
+ */
+#define VGT_CAPS_FULL_PPGTT_48BIT  BIT(2)
+
 struct vgt_if {
u64 magic;  /* VGT_MAGIC */
u16 version_major;
u16 version_minor;
u32 vgt_id; /* ID of vGT instance */
-   u32 rsv1[12];   /* pad to offset 0x40 */
+   u32 vgt_caps;   /* VGT capabilities */
+   u32 rsv1[11];   /* pad to offset 0x40 */
/*
 *  Data structure to describe the balooning info of resources.
 *  Each VM can only have one portion of continuous area for now.
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index cf7a958..e85e27c 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -75,10 +75,17 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
return;
}
 
+   dev_priv->vgpu.caps = __raw_i915_read32(dev_priv, vgtif_reg(vgt_caps));
+
dev_priv->vgpu.active = true;
DRM_INFO("Virtual GPU for Intel GVT-g detected.\n");
 }
 

Re: [Intel-gfx] [PATCH i-g-t] tests/kms: increase max threshold time for edid read

2017-08-09 Thread Chris Wilson
Quoting Daniel Vetter (2017-08-07 17:20:27)
> On Fri, Aug 04, 2017 at 11:23:18AM -0700, clinton.a.tay...@intel.com wrote:
> > From: Clint Taylor 
> > 
> > Current 50ms max threshold timing for an EDID read is very close to the
> > actual time for a 2 block HDMI EDID read of 48ms. Any delay like a clock
> > stretch by the EDID eeprom will cause this test to fail. A 4 block HDMI
> > EDID read takes approximately 88ms under nominal conditions, making the max
> > threshold 95ms will allow this test to pass regardless of monitor attached.
> > 
> > Signed-off-by: Clint Taylor 
> 
> Per internal mail, this needs to be runtime adjusted to fit the EDID we're
> reading. Maybe 30ms per edid block.

Those are scary numbers. So please also a kms_flip flip-vs-edid
with timestamp check. Given the number of random probes we do, we must
make sure that we can do those in parallel to driving the display
fluidly. Similarly, some crc testing against edid reading would be in
order to make sure that there are no display glitches during the
transfer.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for tests/kms: increase max threshold time for edid read (rev3)

2017-08-09 Thread Patchwork
== Series Details ==

Series: tests/kms: increase max threshold time for edid read (rev3)
URL   : https://patchwork.freedesktop.org/series/28399/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
c129026622accef6f54c0cfb0dc55e930cfa60b5 igt: add syncobj_basic.

with latest DRM-Tip kernel build CI_DRM_2942
2d0288b5b28c drm-tip: 2017y-08m-09d-18h-09m-54s UTC integration manifest

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> SKIP   (fi-skl-x1585l) fdo#101781
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-n2820) fdo#101705

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

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:445s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:418s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:358s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:499s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:482s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:523s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:585s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:433s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:418s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:419s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:506s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:473s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:461s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:567s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:577s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:523s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:447s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:647s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:463s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:424s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:463s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:544s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:411s

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_50/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/2] drm/i915/perf: Drop lockdep assert for i915_oa_init_reg_state()

2017-08-09 Thread Chris Wilson
Quoting Lionel Landwerlin (2017-08-09 23:47:20)
> On 09/08/17 16:38, Chris Wilson wrote:
> > This is called from execlist context init which we need to be unlocked.
> > Commit f89823c21224 ("drm/i915/perf: Implement
> > I915_PERF_ADD/REMOVE_CONFIG interface") added a lockdep assert to this
> > path for unclear reasons, remove it again!
> >
> > Fixes: 701f8231a2fe ("drm/i915/perf: prune OA configs")
> > Signed-off-by: Chris Wilson 
> > Cc: Lionel Landwerlin 
> > Cc: Matthew Auld 
> > ---
> >   drivers/gpu/drm/i915/i915_perf.c | 2 --
> >   1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> > b/drivers/gpu/drm/i915/i915_perf.c
> > index 1be355d14e8a..3bdf53faae24 100644
> > --- a/drivers/gpu/drm/i915/i915_perf.c
> > +++ b/drivers/gpu/drm/i915/i915_perf.c
> > @@ -2173,8 +2173,6 @@ void i915_oa_init_reg_state(struct intel_engine_cs 
> > *engine,
> >   struct drm_i915_private *dev_priv = engine->i915;
> >   struct i915_perf_stream *stream = dev_priv->perf.oa.exclusive_stream;
> 
> I was trying to avoid adding a new lock for exclusive_stream.
> If we can't rely on dev_priv->drm.struct_mutex to update 
> exclusive_stream, I believe we need to add a new lock.
> Or maybe some other mechanism?

Doesn't changing the exclusive_stream require serialization against the
requests? Therefore we would be safe here for reset as the existence of
the incomplete request that we are altering is the barrier.

Wait... You don't have that barrier anymore? So you never change the
context image for the exclusive stream on setting and force the reload
of the image? I expected to see something like
gen8_configure_all_contexts(), but only needing to change the old/new
exclusive_streams.

At any rate, just wrapping exclusive_stream = bah inside struct_mutex is
not the barrier you intended, or at least not the barrier I think you need
wrt to request construction and concurrent execution thereof.

Longer term, I don't plan for the context allocation/initialisation to
be under the struct_mutex, but we can still expect it to be part of the
request construction, so would still be serialized by a future semaphore
between oa and execbuf.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".

2017-08-09 Thread Joe Kniss
On Wed, Aug 9, 2017 at 12:14 PM, Noralf Trønnes  wrote:
>
> Den 09.08.2017 01.42, skrev Joe Kniss:
>>
>> Because all drivers currently use gem objects for framebuffer planes,
>> the virtual create_handle() is not required.  This change adds a
>> struct drm_gem_object *gems[4] field to drm_framebuffer and removes
>> create_handle() function pointer from drm_framebuffer_funcs.  The
>> corresponding *_create_handle() function is removed from each driver.
>>
>> In many cases this change eliminates a struct *_framebuffer object,
>> as the only need for the derived struct is the addition of the gem
>> object pointer.
>>
>> TESTED: compiled: allyesconfig ARCH=x86,arm platforms:i915, rockchip
>>
>> Signed-off-by: Joe Kniss 
>> ---
>
>
> Hi Joe,
>
> I'm also looking into adding gem objs to drm_framebuffer in this patch:
> [PATCH v2 01/22] drm: Add GEM backed framebuffer library
> https://lists.freedesktop.org/archives/dri-devel/2017-August/149782.html
>

Great.  There's only minimal overlap here.  I'll rebase this change on yours
once it's in.

> [...]
>
>> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
>> b/drivers/gpu/drm/drm_fb_cma_helper.c
>> index ade319d10e70..f5f011b910b1 100644
>> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
>> @@ -31,14 +31,9 @@
>> #define DEFAULT_FBDEFIO_DELAY_MS 50
>>   -struct drm_fb_cma {
>> -   struct drm_framebuffer  fb;
>> -   struct drm_gem_cma_object   *obj[4];
>> -};
>> -
>>   struct drm_fbdev_cma {
>> struct drm_fb_helperfb_helper;
>> -   struct drm_fb_cma   *fb;
>> +   struct drm_framebuffer  *fb;
>
>
> This fb pointer isn't necessary, since fb_helper already has one.
>

I'll remove it... but I am sure when I look deeper there will be more
of these in the various drivers too.

> Noralf.
>
>

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


Re: [Intel-gfx] [maintainer-tools PATCH 5/5] doc: use Sphinx bizstyle builtin html theme

2017-08-09 Thread Rodrigo Vivi
On Wed, Aug 9, 2017 at 2:08 PM, Jani Nikula  wrote:
> Matter of taste, but looks better than the default alabaster,

not sure which one I preferred...
alabaster goes better with 01.org... but it indeed is not very good...

> and is
> less trouble than requiring some external themes (such as the sphinx rtd
> theme used in the kernel).

less trouble is good, but since we are already making changes now and
forcing new packages I believe we could force to use same style as
kernel so we keep in sync...

>
> Signed-off-by: Jani Nikula 
> ---
>  conf.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/conf.py b/conf.py
> index 2e7acb8e76ca..7293d9ddab80 100644
> --- a/conf.py
> +++ b/conf.py
> @@ -119,7 +119,7 @@ todo_include_todos = False
>  # The theme to use for HTML and HTML Help pages.  See the documentation for
>  # a list of builtin themes.
>  #
> -html_theme = 'alabaster'
> +html_theme = 'bizstyle'
>
>  # Theme options are theme-specific and customize the look and feel of a theme
>  # further.  For a list of options available for each theme, see the
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [maintainer-tools PATCH 4/5] doc: build documentation using Sphinx

2017-08-09 Thread Rodrigo Vivi
On Wed, Aug 9, 2017 at 2:08 PM, Jani Nikula  wrote:
> Based on Sphinx-quickstart, with existing and generated Makefiles merged
> together.
>
> This makes the rst2html and Sphinx builds work side by side. Plain
> 'make' continues to use rst2html, and 'make html' and friends use
> Sphinx. The intention is to keep both for a transition period so that we
> can have documentation autobuilders updated.

the one that posts to 01.org or do we have more places pointing here?

>
> Once we're fully converted to Sphinx, we can start looking into using
> the graphviz (Sphinx builtin) and WaveDrom (3rd party) extensions. For
> now, we use the same old clunky methods for including them.

when we know we are fully converted?

>
> Signed-off-by: Jani Nikula 
> ---
>  .gitignore |   1 +
>  Makefile   |  61 +++-
>  conf.py| 236 
> +
>  index.rst  |  17 +
>  4 files changed, 313 insertions(+), 2 deletions(-)
>  create mode 100644 conf.py
>  create mode 100644 index.rst
>
> diff --git a/.gitignore b/.gitignore
> index 35ed071ca482..a176bd76eef5 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -1,3 +1,4 @@
> +_build
>  drm-intel-flow.svg
>  drm-misc-commit-flow.svg
>  *.html
> diff --git a/Makefile b/Makefile
> index 7059eec42720..40b7ee6e2b32 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -4,6 +4,20 @@
>  # the wavedrom json, copy-pasting to and from 
> http://wavedrom.com/editor.html is
>  # handy as it shows the result live.
>
> +# You can set these variables from the command line.
> +SPHINXOPTS=
> +SPHINXBUILD   = sphinx-build
> +PAPER =
> +BUILDDIR  = _build
> +
> +# Internal variables.
> +PAPEROPT_a4 = -D latex_paper_size=a4
> +PAPEROPT_letter = -D latex_paper_size=letter
> +ALLSPHINXOPTS   = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) 
> .
> +# the i18n builder cannot share the environment and doctrees with the others
> +I18NSPHINXOPTS  = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
> +
> +.PHONY: all
>  all: drm-intel.html dim.html drm-misc.html
>
>  %.svg: %.dot
> @@ -41,7 +55,50 @@ mancheck:
>
>  check: shellcheck mancheck all
>
> +.PHONY: clean
>  clean:
> -   rm -f drm-intel.html drm-intel-flow.svg drm-misc-commit-flow.svg 
> dim.html drm-misc.html
> +   rm -rf drm-intel.html drm-intel-flow.svg drm-misc-commit-flow.svg 
> dim.html drm-misc.html $(BUILDDIR)
> +
> +.PHONY: help
> +help:
> +   @echo "Please use \`make ' where  is one of"
> +   @echo "  html   to make standalone HTML files"
> +   @echo "  dirhtmlto make HTML files named index.html in 
> directories"
> +   @echo "  singlehtml to make a single large HTML file"
> +   @echo "  linkcheck  to check all external links for integrity"
> +   @echo "  doctestto run all doctests embedded in the documentation 
> (if enabled)"
> +
> +# FIXME: This works for the first build, but not for updates. Look into using
> +# Sphinx extensions for both the graphviz and wavedrom parts.
> +html dirhtml singlehtml linkcheck doctest: drm-intel-flow.svg 
> drm-misc-commit-flow.svg
> +
> +.PHONY: html
> +html:
> +   $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
> +   @echo
> +   @echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
> +
> +.PHONY: dirhtml
> +dirhtml:
> +   $(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
> +   @echo
> +   @echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
> +
> +.PHONY: singlehtml
> +singlehtml:
> +   $(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
> +   @echo
> +   @echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
> +
> +.PHONY: linkcheck
> +linkcheck:
> +   $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
> +   @echo
> +   @echo "Link check complete; look for any errors in the above output " 
> \
> + "or in $(BUILDDIR)/linkcheck/output.txt."
>
> -.PHONY: all clean
> +.PHONY: doctest
> +doctest:
> +   $(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
> +   @echo "Testing of doctests in the sources finished, look at the " \
> + "results in $(BUILDDIR)/doctest/output.txt."
> diff --git a/conf.py b/conf.py
> new file mode 100644
> index ..2e7acb8e76ca
> --- /dev/null
> +++ b/conf.py
> @@ -0,0 +1,236 @@
> +# -*- coding: utf-8 -*-
> +#
> +# DRM Maintainer Tools documentation build configuration file, created by
> +# sphinx-quickstart on Wed Aug  9 17:57:16 2017.
> +#
> +# This file is execfile()d with the current directory set to its
> +# containing dir.
> +#
> +# Note that not all possible configuration values are present in this
> +# autogenerated file.
> +#
> +# All configuration values have a default; values that are commented out
> +# serve to show the default.
> +
> +# If extensions (or modules to document with autodoc) are in another 
> 

[Intel-gfx] [PATCH v3 i-g-t] tests/kms: increase max threshold time for edid read

2017-08-09 Thread clinton . a . taylor
From: Clint Taylor 

Current 50ms max threshold timing for an EDID read is very close to the
actual time for a 2 block HDMI EDID read. Adjust the timings base on
connector type as DP reads are at 1 MBit and HDMI at 100K bit. If an LSPcon
is connected to device under test the -l option should be passed to update
the threshold timing to allow the LSPcon to read the EDID at the HDMI
timing. The -l option should be used when LSPcon is on the motherboard or
if a USB_C->HDMI converter is present

V2: Adjust timings based on connector type, EDID size, and Add an option to
specify if an LSPcon is present.
V3: added bugzilla to commit message

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

Cc: Daniel Vetter 
Cc: Marta Lofstedt 
Signed-off-by: Clint Taylor 
---
 tests/kms_sysfs_edid_timing.c | 76 +++
 1 file changed, 62 insertions(+), 14 deletions(-)

diff --git a/tests/kms_sysfs_edid_timing.c b/tests/kms_sysfs_edid_timing.c
index 1201388..441dfee 100644
--- a/tests/kms_sysfs_edid_timing.c
+++ b/tests/kms_sysfs_edid_timing.c
@@ -26,21 +26,46 @@
 #include 
 #include 
 
-#define THRESHOLD_PER_CONNECTOR10
-#define THRESHOLD_TOTAL50
-#define CHECK_TIMES15
+#define THRESHOLD_FOR_EMPTY_CONNECTOR  10
+#define THRESHOLD_PER_EDID_BLOCK   5
+#define HDMI_THRESHOLD_MULTIPLIER  10
+#define CHECK_TIMES10
 
 IGT_TEST_DESCRIPTION("This check the time we take to read the content of all "
 "the possible connectors. Without the edid -ENXIO patch "
 
"(http://permalink.gmane.org/gmane.comp.video.dri.devel/62083), "
-"we sometimes take a *really* long time. "
-"So let's just check for some reasonable timing here");
+"we sometimes take a *really* long time. So let's check "
+"an approximate time per edid block based on connector "
+"type. The -l option adjusts DP timing to reflect HDMI 
read "
+"timings from LSPcon.");
+
+/* The -l option has been added to correctly handle timings when an LSPcon is
+ * present. This could be on the platform itself or in a USB_C->HDMI converter.
+ * With LSPCon EDID read timing will need to change from the 1 Mbit AUX
+ * bus speed to the 100 Kbit HDMI DDC bus speed
+ */
+bool lspcon_present;
 
+static int opt_handler(int opt, int opt_index, void *data)
+{
+   if (opt == 'l') {
+   lspcon_present = true;
+   igt_info("set LSPcon present on DP ports\n");
+   }
 
-igt_simple_main
+   return 0;
+}
+
+int main(int argc, char **argv)
 {
DIR *dirp;
struct dirent *de;
+   lspcon_present = false;
+
+   igt_simple_init_parse_opts(, argv, "l", NULL, NULL,
+ opt_handler, NULL);
+
+   igt_skip_on_simulation();
 
dirp = opendir("/sys/class/drm");
igt_assert(dirp != NULL);
@@ -49,17 +74,36 @@ igt_simple_main
struct igt_mean mean = {};
struct stat st;
char path[PATH_MAX];
-   int i;
+   char edid_path[PATH_MAX];
+   char edid[512]; /* enough for 4 block edid */
+   unsigned long edid_size = 0;
+   int i, fd_edid;
+   unsigned int threshold = 0;
 
if (*de->d_name == '.')
continue;;
 
snprintf(path, sizeof(path), "/sys/class/drm/%s/status",
de->d_name);
+   snprintf(edid_path, sizeof(edid_path), "/sys/class/drm/%s/edid",
+   de->d_name);
 
if (stat(path, ))
continue;
 
+   fd_edid = open(edid_path, O_RDONLY);
+   if (fd_edid == -1) {
+   igt_warn("Read Error EDID\n");
+   continue;
+   }
+
+   edid_size = read(fd_edid, edid, 512);
+   threshold = THRESHOLD_PER_EDID_BLOCK * (edid_size / 128);
+   if (lspcon_present || (edid_size > 128 &&
+   !strncmp(de->d_name, "card0-HDMI", 10))) {
+   threshold *= HDMI_THRESHOLD_MULTIPLIER;
+   }
+
igt_mean_init();
for (i = 0; i < CHECK_TIMES; i++) {
struct timespec ts = {};
@@ -76,22 +120,26 @@ igt_simple_main
}
 
igt_debug("%s: mean.max %.2fns, %.2fus, %.2fms, "
- "mean.avg %.2fns, %.2fus, %.2fms\n",
+ "mean.avg %.2fns, %.2fus, %.2fms, "
+ "edid_size %lu, threshold %d\n",
  de->d_name,
  mean.max, mean.max / 1e3, mean.max / 

Re: [Intel-gfx] [maintainer-tools PATCH 3/5] doc: use window.onload to call WaveDrom.ProcessAll()

2017-08-09 Thread Rodrigo Vivi
I don't know WaveDrom much... but it works so

Acked-by: Rodrigo Vivi 

On Wed, Aug 9, 2017 at 2:08 PM, Jani Nikula  wrote:
> Simplify the build by doing the WaveDrom processing from the rst file
> (albeit raw html block) instead of post-processing the output html.
>
> Signed-off-by: Jani Nikula 
> ---
>  Makefile   | 6 --
>  drm-intel-timeline.rst | 4 
>  drm-misc-timeline.rst  | 4 
>  3 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 8bbabae56741..7059eec42720 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -12,15 +12,9 @@ all: drm-intel.html dim.html drm-misc.html
>  %.html: %.rst
> rst2html $< > $@
>
> -# the sed bit here is a hack to make wavedrom process the timeline
>  drm-intel.html: drm-intel.rst drm-intel-flow.svg drm-intel-timeline.rst 
> drm-intel-timeline.json
> -   rst2html $< > $@
> -   sed -i 's/
> -# the sed bit here is a hack to make wavedrom process the timeline
>  drm-misc.html: drm-misc.rst drm-misc-timeline.rst drm-misc-timeline.json 
> drm-misc-commit-flow.svg
> -   rst2html $< > $@
> -   sed -i 's/
>  dim.html: dim.rst
>
> diff --git a/drm-intel-timeline.rst b/drm-intel-timeline.rst
> index e1766a5df98b..3ab39afd5788 100644
> --- a/drm-intel-timeline.rst
> +++ b/drm-intel-timeline.rst
> @@ -17,6 +17,10 @@
>
>  .. raw:: html
>
> +   function init() {
> +   WaveDrom.ProcessAll();
> +   }
> +   window.onload = init;
> 
> 
>
> diff --git a/drm-misc-timeline.rst b/drm-misc-timeline.rst
> index 69724362..a9a80d6a4cfb 100644
> --- a/drm-misc-timeline.rst
> +++ b/drm-misc-timeline.rst
> @@ -8,6 +8,10 @@
>
>  .. raw:: html
>
> +   function init() {
> +   WaveDrom.ProcessAll();
> +   }
> +   window.onload = init;
> 
> 

Re: [Intel-gfx] [maintainer-tools PATCH 2/5] build: add drm-misc-commit-flow.svg to clean target

2017-08-09 Thread Rodrigo Vivi
Reviewed-by: Rodrigo Vivi 

On Wed, Aug 9, 2017 at 2:08 PM, Jani Nikula  wrote:
> Signed-off-by: Jani Nikula 
> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 784d986b18cd..8bbabae56741 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -48,6 +48,6 @@ mancheck:
>  check: shellcheck mancheck all
>
>  clean:
> -   rm -f drm-intel.html drm-intel-flow.svg dim.html drm-misc.html
> +   rm -f drm-intel.html drm-intel-flow.svg drm-misc-commit-flow.svg 
> dim.html drm-misc.html
>
>  .PHONY: all clean
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for tests/kms: increase max threshold time for edid read (rev2)

2017-08-09 Thread Patchwork
== Series Details ==

Series: tests/kms: increase max threshold time for edid read (rev2)
URL   : https://patchwork.freedesktop.org/series/28399/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
c129026622accef6f54c0cfb0dc55e930cfa60b5 igt: add syncobj_basic.

with latest DRM-Tip kernel build CI_DRM_2942
2d0288b5b28c drm-tip: 2017y-08m-09d-18h-09m-54s UTC integration manifest

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test gem_ringfill:
Subgroup basic-default-hang:
dmesg-warn -> INCOMPLETE (fi-pnv-d510) fdo#101600
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> SKIP   (fi-skl-x1585l) fdo#101781

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

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:437s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:418s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:362s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:492s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:496s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:522s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:512s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:589s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:434s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:406s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:428s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:514s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:475s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:460s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:563s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:582s
fi-pnv-d510  total:147  pass:113  dwarn:0   dfail:0   fail:0   skip:33 
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:454s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:649s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:458s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:425s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:468s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:551s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:404s

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_49/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 i-g-t] tests/kms: increase max threshold time for edid read

2017-08-09 Thread clinton . a . taylor
From: Clint Taylor 

Current 50ms max threshold timing for an EDID read is very close to the
actual time for a 2 block HDMI EDID read. Adjust the timings base on
connector type as DP reads are at 1 MBit and HDMI at 100K bit. If an LSPcon
is connected to device under test the -l option should be passed to update
the threshold timing to allow the LSPcon to read the EDID at the HDMI
timing. The -l option should be used when LSPcon is on the motherboard or
if a USB_C->HDMI converter is present

V2: Adjust timings based on connector type, EDID size, and Add an option to
specify if an LSPcon is present.

Cc: Daniel Vetter 
Cc: Marta Lofstedt 
Signed-off-by: Clint Taylor 
---
 tests/kms_sysfs_edid_timing.c | 76 +++
 1 file changed, 62 insertions(+), 14 deletions(-)

diff --git a/tests/kms_sysfs_edid_timing.c b/tests/kms_sysfs_edid_timing.c
index 1201388..441dfee 100644
--- a/tests/kms_sysfs_edid_timing.c
+++ b/tests/kms_sysfs_edid_timing.c
@@ -26,21 +26,46 @@
 #include 
 #include 
 
-#define THRESHOLD_PER_CONNECTOR10
-#define THRESHOLD_TOTAL50
-#define CHECK_TIMES15
+#define THRESHOLD_FOR_EMPTY_CONNECTOR  10
+#define THRESHOLD_PER_EDID_BLOCK   5
+#define HDMI_THRESHOLD_MULTIPLIER  10
+#define CHECK_TIMES10
 
 IGT_TEST_DESCRIPTION("This check the time we take to read the content of all "
 "the possible connectors. Without the edid -ENXIO patch "
 
"(http://permalink.gmane.org/gmane.comp.video.dri.devel/62083), "
-"we sometimes take a *really* long time. "
-"So let's just check for some reasonable timing here");
+"we sometimes take a *really* long time. So let's check "
+"an approximate time per edid block based on connector "
+"type. The -l option adjusts DP timing to reflect HDMI 
read "
+"timings from LSPcon.");
+
+/* The -l option has been added to correctly handle timings when an LSPcon is
+ * present. This could be on the platform itself or in a USB_C->HDMI converter.
+ * With LSPCon EDID read timing will need to change from the 1 Mbit AUX
+ * bus speed to the 100 Kbit HDMI DDC bus speed
+ */
+bool lspcon_present;
 
+static int opt_handler(int opt, int opt_index, void *data)
+{
+   if (opt == 'l') {
+   lspcon_present = true;
+   igt_info("set LSPcon present on DP ports\n");
+   }
 
-igt_simple_main
+   return 0;
+}
+
+int main(int argc, char **argv)
 {
DIR *dirp;
struct dirent *de;
+   lspcon_present = false;
+
+   igt_simple_init_parse_opts(, argv, "l", NULL, NULL,
+ opt_handler, NULL);
+
+   igt_skip_on_simulation();
 
dirp = opendir("/sys/class/drm");
igt_assert(dirp != NULL);
@@ -49,17 +74,36 @@ igt_simple_main
struct igt_mean mean = {};
struct stat st;
char path[PATH_MAX];
-   int i;
+   char edid_path[PATH_MAX];
+   char edid[512]; /* enough for 4 block edid */
+   unsigned long edid_size = 0;
+   int i, fd_edid;
+   unsigned int threshold = 0;
 
if (*de->d_name == '.')
continue;;
 
snprintf(path, sizeof(path), "/sys/class/drm/%s/status",
de->d_name);
+   snprintf(edid_path, sizeof(edid_path), "/sys/class/drm/%s/edid",
+   de->d_name);
 
if (stat(path, ))
continue;
 
+   fd_edid = open(edid_path, O_RDONLY);
+   if (fd_edid == -1) {
+   igt_warn("Read Error EDID\n");
+   continue;
+   }
+
+   edid_size = read(fd_edid, edid, 512);
+   threshold = THRESHOLD_PER_EDID_BLOCK * (edid_size / 128);
+   if (lspcon_present || (edid_size > 128 &&
+   !strncmp(de->d_name, "card0-HDMI", 10))) {
+   threshold *= HDMI_THRESHOLD_MULTIPLIER;
+   }
+
igt_mean_init();
for (i = 0; i < CHECK_TIMES; i++) {
struct timespec ts = {};
@@ -76,22 +120,26 @@ igt_simple_main
}
 
igt_debug("%s: mean.max %.2fns, %.2fus, %.2fms, "
- "mean.avg %.2fns, %.2fus, %.2fms\n",
+ "mean.avg %.2fns, %.2fus, %.2fms, "
+ "edid_size %lu, threshold %d\n",
  de->d_name,
  mean.max, mean.max / 1e3, mean.max / 1e6,
- mean.mean, mean.mean / 1e3, mean.mean / 1e6);
+  

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Rename GuC irq trigger function (rev2)

2017-08-09 Thread Patchwork
== Series Details ==

Series: drm/i915/guc: Rename GuC irq trigger function (rev2)
URL   : https://patchwork.freedesktop.org/series/28570/
State : success

== Summary ==

Series 28570v2 drm/i915/guc: Rename GuC irq trigger function
https://patchwork.freedesktop.org/api/1.0/series/28570/revisions/2/mbox/

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

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

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:441s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:418s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:358s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:489s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:496s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:524s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:517s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:587s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:438s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:410s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:419s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:506s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:474s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:457s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:565s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:579s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:525s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:445s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:646s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:461s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:425s
fi-skl-x1585ltotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:488s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:547s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:413s

2d0288b5b28c0d67460f0258a41bb4f78b812f29 drm-tip: 2017y-08m-09d-18h-09m-54s UTC 
integration manifest
7ced1aeacfcc drm/i915/guc: Rename GuC irq trigger function

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5361/
___
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/edp: Be less aggressive about changing link config on eDP

2017-08-09 Thread Patchwork
== Series Details ==

Series: drm/i915/edp: Be less aggressive about changing link config on eDP
URL   : https://patchwork.freedesktop.org/series/28588/
State : success

== Summary ==

Series 28588v1 drm/i915/edp: Be less aggressive about changing link config on 
eDP
https://patchwork.freedesktop.org/api/1.0/series/28588/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> SKIP   (fi-skl-x1585l) fdo#101781
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-n2820) fdo#101705

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

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:439s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:418s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:365s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:495s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:492s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:513s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:514s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:586s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:429s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:404s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:419s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:504s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:477s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:460s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:572s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:581s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:524s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:446s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:642s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:465s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:424s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:467s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:553s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:403s

2d0288b5b28c0d67460f0258a41bb4f78b812f29 drm-tip: 2017y-08m-09d-18h-09m-54s UTC 
integration manifest
7aeadd39ed6c drm/i915/edp: Be less aggressive about changing link config on eDP

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5360/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [maintainer-tools PATCH 6/5] doc: load WaveDrom scripts directly from CDN instead of bundling

2017-08-09 Thread Jani Nikula
Way back when the WaveDrom stuff was added, the scripts could only be
accessed over http. This caused issues with sites served over https and
modern browsers rightly complaining about mixed content. This was worked
around by downloading the WaveDrom scripts over http at build time, and
bundling them inline into the http.

Now that WaveDrom is available over https, simplify the hackery, and let
the user's browser load the scripts directly at page load time.

Signed-off-by: Jani Nikula 
---
 drm-intel-timeline.rst | 20 +++-
 drm-misc-timeline.rst  | 21 +++--
 2 files changed, 6 insertions(+), 35 deletions(-)

diff --git a/drm-intel-timeline.rst b/drm-intel-timeline.rst
index 3ab39afd5788..fe69fd374cf6 100644
--- a/drm-intel-timeline.rst
+++ b/drm-intel-timeline.rst
@@ -1,22 +1,8 @@
 .. raw:: html
 
-   
-   /* Embedded WaveDrom skin from http://wavedrom.com/skins/default.js */
-
-.. raw:: html
-   :url: http://wavedrom.com/skins/default.js
-
-.. raw:: html
-
-   
-   
-   /* Embedded WaveDrom engine from http://wavedrom.com/WaveDrom.js */
-
-.. raw:: html
-   :url: http://wavedrom.com/WaveDrom.js
-
-.. raw:: html
-
+