Re: [Intel-gfx] [PATCH 1/2] drm: Add a new connector property for link status

[Daniel Vetter]

On Tue, Oct 25, 2016 at 06:16:34PM -0700, Manasi Navare wrote:
> A new optional connector property is added for keeping
> track of whether the link is good (link training passed) or
> link is bad (link training  failed). If the link status property
> is Bad, then userspace should fire off a new modeset at the current
> mode even if there have not been any changes in the mode list
> or connector status.
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Cc: Chris Wilson 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/drm_connector.c | 32 
>  include/drm/drm_connector.h |  1 +
>  include/drm/drm_crtc.h  |  6 ++
>  include/uapi/drm/drm_mode.h |  4 
>  4 files changed, 43 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 2db7fb5..b4ce19f 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -588,6 +588,11 @@ int drm_display_info_set_bus_formats(struct 
> drm_display_info *info,
>  DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>drm_tv_subconnector_enum_list)
>  
> +static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
> + { DRM_MODE_LINK_STATUS_GOOD, "Good" },
> + { DRM_MODE_LINK_STATUS_BAD, "Bad" },
> +};
> +
>  int drm_connector_create_standard_properties(struct drm_device *dev)
>  {
>   struct drm_property *prop;
> @@ -845,6 +850,33 @@ int drm_mode_create_suggested_offset_properties(struct 
> drm_device *dev)
>  EXPORT_SYMBOL(drm_mode_create_suggested_offset_properties);
>  
>  /**
> + * drm_mode_create_link_status_property - Create link status property
> + * @dev: DRM device
> + *
> + * Called by a driver the first time it's needed, must be attached to desired
> + * connectors.
> + * This property is used to indicate whether link sttaus is Good or Bad as
> + * a result fo link training
> + */
> +int drm_mode_create_link_status_property(struct drm_device *dev)

I'd go further and just always create this as one of the standard
properties (and always attach it to the connector, like edid), and only
expose helpers to set the link status to good or bad.
-Daniel

> +{
> + struct drm_property *link_status;
> +
> + if (dev->mode_config.link_status_property)
> + return 0;
> +
> + link_status =
> + drm_property_create_enum(dev, 0, "link-status",
> +  drm_link_status_enum_list,
> +  ARRAY_SIZE(drm_link_status_enum_list));
> +
> + dev->mode_config.scaling_mode_property = link_status;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_mode_create_link_status_property);
> +
> +/**
>   * drm_mode_connector_set_path_property - set tile property on connector
>   * @connector: connector to set property on.
>   * @path: path to use for property; must not be NULL.
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index fc9d475..7234c0c 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -759,6 +759,7 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
>  int drm_mode_create_scaling_mode_property(struct drm_device *dev);
>  int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
>  int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
> +int drm_mode_create_link_status_property(struct drm_device *dev);
>  
>  int drm_mode_connector_set_path_property(struct drm_connector *connector,
>const char *path);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index fa1aa21..3e9c833 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1343,6 +1343,12 @@ struct drm_mode_config {
>*/
>   struct drm_property *suggested_y_property;
>  
> + /**
> +  * @link_status_property: Optional connector property for link status
> +  * of the connector as a result of link training.
> +  */
> +  struct drm_property *link_status_property;
> +
>   /* dumb ioctl parameters */
>   uint32_t preferred_depth, prefer_shadow;
>  
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 084b50a..f1b0afd 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -121,6 +121,10 @@
>  #define DRM_MODE_DIRTY_ON   1
>  #define DRM_MODE_DIRTY_ANNOTATE 2
>  
> +/* Link Status options */
> +#define DRM_MODE_LINK_STATUS_GOOD0
> +#define DRM_MODE_LINK_STATUS_BAD 1
> +
>  struct drm_mode_modeinfo {
>   __u32 clock;
>   __u16 hdisplay;
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dp: Debug log MST active links explicitly (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Debug log MST active links explicitly (rev3)
URL   : https://patchwork.freedesktop.org/series/13627/
State : failure

== Summary ==

Series 13627v3 drm/i915/dp: Debug log MST active links explicitly
https://patchwork.freedesktop.org/api/1.0/series/13627/revisions/3/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6770hq)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6770hq)
Test kms_flip:
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (fi-skl-6770hq)
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> FAIL   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b:
pass   -> DMESG-WARN (fi-ivb-3770)
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-skl-6700hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:219  dwarn:1   dfail:0   fail:0   skip:26 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:219  dwarn:4   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:228  dwarn:3   dfail:0   fail:1   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

f746a2112fbb563743acc132304075706551d123 drm-intel-nightly: 
2016y-10m-25d-20h-02m-34s UTC integration manifest
7de0e75 drm/i915/dp: Debug log MST active links explicitly

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2820/

== Logs ==

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

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Debug log MST active links explicitly

[Pandiyan, Dhinakaran]

Jim,
Please let me know if the R-B is still good.

-DK

On Tue, 2016-10-25 at 21:37 -0700, Dhinakaran Pandiyan wrote:
> From: "Pandiyan, Dhinakaran" 
> 
> No functional change. Just printing the number of active links without
> stating what the number means is not very useful. So, add relevant text.
> 
> v2: Included connector info (Chris)
> Signed-off-by: Dhinakaran Pandiyan 
> Reviewed-by: Jim Bride 
> ---
>  drivers/gpu/drm/i915/intel_dp_mst.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 3ffbd69..8f2016b 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -86,8 +86,6 @@ static void intel_mst_disable_dp(struct intel_encoder 
> *encoder,
>   to_intel_connector(old_conn_state->connector);
>   int ret;
>  
> - DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> -
>   drm_dp_mst_reset_vcpi_slots(_dp->mst_mgr, connector->port);
>  
>   ret = drm_dp_update_payload_part1(_dp->mst_mgr);
> @@ -106,8 +104,6 @@ static void intel_mst_post_disable_dp(struct 
> intel_encoder *encoder,
>   struct intel_connector *connector =
>   to_intel_connector(old_conn_state->connector);
>  
> - DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> -
>   /* this can fail */
>   drm_dp_check_act_status(_dp->mst_mgr);
>   /* and this can also fail */
> @@ -124,6 +120,11 @@ static void intel_mst_post_disable_dp(struct 
> intel_encoder *encoder,
>  
>   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
>   }
> +
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] MST link deactivated, total active 
> links: %d\n",
> +   old_conn_state->connector->base.id,
> +   old_conn_state->connector->name,
> +   intel_dp->active_mst_links);
>  }
>  
>  static void intel_mst_pre_enable_dp(struct intel_encoder *encoder,
> @@ -147,8 +148,6 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
> *encoder,
>   connector->encoder = encoder;
>   intel_mst->connector = connector;
>  
> - DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> -
>   if (intel_dp->active_mst_links == 0) {
>   intel_ddi_clk_select(_dig_port->base,
>pipe_config->shared_dpll);
> @@ -175,7 +174,6 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
> *encoder,
>   return;
>   }
>  
> -
>   intel_dp->active_mst_links++;
>   temp = I915_READ(DP_TP_STATUS(port));
>   I915_WRITE(DP_TP_STATUS(port), temp);
> @@ -194,8 +192,6 @@ static void intel_mst_enable_dp(struct intel_encoder 
> *encoder,
>   enum port port = intel_dig_port->port;
>   int ret;
>  
> - DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> -
>   if (intel_wait_for_register(dev_priv,
>   DP_TP_STATUS(port),
>   DP_TP_STATUS_ACT_SENT,
> @@ -206,6 +202,11 @@ static void intel_mst_enable_dp(struct intel_encoder 
> *encoder,
>   ret = drm_dp_check_act_status(_dp->mst_mgr);
>  
>   ret = drm_dp_update_payload_part2(_dp->mst_mgr);
> +
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] MST link activated, total active 
> links: %d\n",
> +   conn_state->connector->base.id,
> +   conn_state->connector->name,
> +   intel_dp->active_mst_links);
>  }
>  
>  static bool intel_dp_mst_enc_get_hw_state(struct intel_encoder *encoder,

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

[Intel-gfx] [PATCH v2] drm/i915/dp: Debug log MST active links explicitly

[Dhinakaran Pandiyan]

From: "Pandiyan, Dhinakaran" 

No functional change. Just printing the number of active links without
stating what the number means is not very useful. So, add relevant text.

v2: Included connector info (Chris)
Signed-off-by: Dhinakaran Pandiyan 
Reviewed-by: Jim Bride 
---
 drivers/gpu/drm/i915/intel_dp_mst.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 3ffbd69..8f2016b 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -86,8 +86,6 @@ static void intel_mst_disable_dp(struct intel_encoder 
*encoder,
to_intel_connector(old_conn_state->connector);
int ret;
 
-   DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
-
drm_dp_mst_reset_vcpi_slots(_dp->mst_mgr, connector->port);
 
ret = drm_dp_update_payload_part1(_dp->mst_mgr);
@@ -106,8 +104,6 @@ static void intel_mst_post_disable_dp(struct intel_encoder 
*encoder,
struct intel_connector *connector =
to_intel_connector(old_conn_state->connector);
 
-   DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
-
/* this can fail */
drm_dp_check_act_status(_dp->mst_mgr);
/* and this can also fail */
@@ -124,6 +120,11 @@ static void intel_mst_post_disable_dp(struct intel_encoder 
*encoder,
 
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
}
+
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] MST link deactivated, total active 
links: %d\n",
+ old_conn_state->connector->base.id,
+ old_conn_state->connector->name,
+ intel_dp->active_mst_links);
 }
 
 static void intel_mst_pre_enable_dp(struct intel_encoder *encoder,
@@ -147,8 +148,6 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
connector->encoder = encoder;
intel_mst->connector = connector;
 
-   DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
-
if (intel_dp->active_mst_links == 0) {
intel_ddi_clk_select(_dig_port->base,
 pipe_config->shared_dpll);
@@ -175,7 +174,6 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
return;
}
 
-
intel_dp->active_mst_links++;
temp = I915_READ(DP_TP_STATUS(port));
I915_WRITE(DP_TP_STATUS(port), temp);
@@ -194,8 +192,6 @@ static void intel_mst_enable_dp(struct intel_encoder 
*encoder,
enum port port = intel_dig_port->port;
int ret;
 
-   DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
-
if (intel_wait_for_register(dev_priv,
DP_TP_STATUS(port),
DP_TP_STATUS_ACT_SENT,
@@ -206,6 +202,11 @@ static void intel_mst_enable_dp(struct intel_encoder 
*encoder,
ret = drm_dp_check_act_status(_dp->mst_mgr);
 
ret = drm_dp_update_payload_part2(_dp->mst_mgr);
+
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] MST link activated, total active 
links: %d\n",
+ conn_state->connector->base.id,
+ conn_state->connector->name,
+ intel_dp->active_mst_links);
 }
 
 static bool intel_dp_mst_enc_get_hw_state(struct intel_encoder *encoder,
-- 
2.7.4

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

[Intel-gfx] [PATCH v3] kms_atomic : Added subtest for Single Pipe DBUF validation

[meghanelogal]

Existing DDB algorithm divide the DDB wrt data rate,
hence the planes with the less height but same width
will be allocated less blocks and watermark are based
on width which requires more DDB. With this data the flip
may fail.

In new DDB algorithm, the DDB is divided based on
watermark requirement.

In this subtest, dividing the htotal/200 will allocate
~2-4 blocks out of total(512/896), flip may fail with the
exisiting algorithm.But with the new algorithm it will pass.

Signed-off-by: Megha Nelogal 
---
 tests/kms_atomic.c | 79 ++
 1 file changed, 79 insertions(+)

diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
index f27ee46..3ab1d3f 100644
--- a/tests/kms_atomic.c
+++ b/tests/kms_atomic.c
@@ -1280,6 +1280,60 @@ static void atomic_invalid_params(struct 
kms_atomic_crtc_state *crtc,
do_ioctl_err(desc->fd, DRM_IOCTL_MODE_ATOMIC, , EFAULT);
 }
 
+static void validate_dbuf(struct kms_atomic_crtc_state *crtc,
+   struct kms_atomic_plane_state **plane_array,
+   int plane_count)
+{
+   int i;
+   struct kms_atomic_desc *desc = crtc->state->desc;
+
+   /* for active crtc do modeset on the native resolution */
+   drmModeAtomicReq *req = drmModeAtomicAlloc();
+   struct drm_mode_modeinfo *mode = crtc->mode.data;
+   struct kms_atomic_plane_state plane;
+   struct igt_fb fb;
+
+   crtc_populate_req(crtc, req);
+
+   /* Add plane data to the structure...*/
+   uint32_t crtc_x = 0;
+   uint32_t crtc_y = 0;
+
+   for (i = 0; i < plane_count; i++) {
+   plane = *plane_array[i];
+   uint32_t format = plane_get_igt_format();
+
+   igt_require(format != 0);
+   plane.src_x = 0;
+   plane.src_y = 0;
+   plane.src_w = (mode->hdisplay / (1)) << 16;
+   plane.crtc_x = crtc_x;
+   plane.crtc_y = crtc_y;
+   plane.crtc_w = (mode->hdisplay) / (1);
+   plane.crtc_h = (mode->vdisplay) / (i + 1);
+
+   plane.crtc_id = crtc->obj;
+
+   if (i%2 == 0) {
+   plane.src_h = (mode->vdisplay / (1)) << 16;
+   plane.crtc_h = (mode->vdisplay) / (1);
+   }
+
+   if (i%2 == 1) {
+   plane.src_h = ceil((mode->vdisplay / 200) << 16);
+   plane.crtc_h = ceil((mode->vdisplay / 200));
+   }
+
+   plane.fb_id = igt_create_fb(plane.state->desc->fd,
+   plane.crtc_w, plane.crtc_h,
+   format, I915_TILING_NONE, );
+   plane_populate_req(, req);
+   }
+   do_atomic_commit(desc->fd, req, ATOMIC_RELAX_NONE);
+   drmModeAtomicFree(req);
+}
+
+
 igt_main
 {
struct kms_atomic_desc desc;
@@ -1373,6 +1427,31 @@ igt_main
atomic_state_free(scratch);
}
 
+   igt_subtest("validate_dbuf") {
+   int gen;
+
+   gen = intel_gen(intel_get_drm_devid(desc.fd));
+   igt_require(gen >= 9);
+
+   struct kms_atomic_state *scratch = atomic_state_dup(current);
+   struct kms_atomic_crtc_state *crtc;
+   struct kms_atomic_plane_state *planes[2];
+
+   crtc = find_crtc(scratch, true);
+   igt_require(crtc);
+
+   igt_require(find_connector(scratch, crtc));
+
+   planes[0] = find_plane(scratch, PLANE_TYPE_PRIMARY, crtc);
+   igt_require(planes[0]);
+
+   planes[1] = find_plane(scratch, PLANE_TYPE_OVERLAY, crtc);
+   igt_require(planes[1]);
+
+   validate_dbuf(crtc, planes, 2);
+   atomic_state_free(scratch);
+   }
+
atomic_state_free(current);
 
igt_fixture
-- 
1.9.1

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm: Add a new connector property for link status

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm: Add a new connector property for link 
status
URL   : https://patchwork.freedesktop.org/series/14374/
State : failure

== Summary ==

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

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-skl-6700hq)
Test kms_busy:
Subgroup basic-flip-default-a:
pass   -> INCOMPLETE (fi-skl-6260u)
pass   -> INCOMPLETE (fi-bxt-t5700)
pass   -> INCOMPLETE (fi-skl-6770hq)
skip   -> INCOMPLETE (fi-bsw-n3050)
pass   -> INCOMPLETE (fi-ilk-650)
pass   -> INCOMPLETE (fi-hsw-4770)
pass   -> INCOMPLETE (fi-byt-j1900)
pass   -> INCOMPLETE (fi-snb-2520m)
pass   -> INCOMPLETE (fi-hsw-4770r)
pass   -> INCOMPLETE (fi-kbl-7200u)
pass   -> INCOMPLETE (fi-bdw-5557u)
pass   -> INCOMPLETE (fi-skl-6700k)
pass   -> INCOMPLETE (fi-skl-6700hq)
pass   -> INCOMPLETE (fi-snb-2600)
pass   -> INCOMPLETE (fi-ivb-3770)
pass   -> INCOMPLETE (fi-byt-n2820)
pass   -> INCOMPLETE (fi-ivb-3520m)

fi-bdw-5557u total:168  pass:161  dwarn:0   dfail:0   fail:0   skip:6  
fi-bsw-n3050 total:168  pass:149  dwarn:0   dfail:0   fail:0   skip:18 
fi-bxt-t5700 total:168  pass:149  dwarn:0   dfail:0   fail:0   skip:18 
fi-byt-j1900 total:168  pass:148  dwarn:0   dfail:0   fail:0   skip:19 
fi-byt-n2820 total:168  pass:148  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770  total:168  pass:154  dwarn:0   dfail:0   fail:0   skip:13 
fi-hsw-4770r total:168  pass:154  dwarn:0   dfail:0   fail:0   skip:13 
fi-ilk-650   total:168  pass:127  dwarn:0   dfail:0   fail:0   skip:40 
fi-ivb-3520m total:168  pass:149  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:168  pass:149  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7200u total:168  pass:152  dwarn:0   dfail:0   fail:0   skip:15 
fi-skl-6260u total:168  pass:162  dwarn:0   dfail:0   fail:0   skip:5  
fi-skl-6700hqtotal:168  pass:151  dwarn:1   dfail:0   fail:0   skip:15 
fi-skl-6700k total:168  pass:151  dwarn:1   dfail:0   fail:0   skip:15 
fi-skl-6770hqtotal:168  pass:162  dwarn:0   dfail:0   fail:0   skip:5  
fi-snb-2520m total:168  pass:144  dwarn:0   dfail:0   fail:0   skip:23 
fi-snb-2600  total:168  pass:144  dwarn:0   dfail:0   fail:0   skip:23 

f746a2112fbb563743acc132304075706551d123 drm-intel-nightly: 
2016y-10m-25d-20h-02m-34s UTC integration manifest
9181ffc drm/i915: Set link status property for DP connector
59ae3f6 drm: Add a new connector property for link status

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2819/

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/2] drm: Add a new connector property for link status

[Manasi Navare]

Chris,

Would you be able to make the necessary changes in the suerspace
driver so I can do some testing tomorrow?

Manasi

On Tue, Oct 25, 2016 at 06:16:34PM -0700, Manasi Navare wrote:
> A new optional connector property is added for keeping
> track of whether the link is good (link training passed) or
> link is bad (link training  failed). If the link status property
> is Bad, then userspace should fire off a new modeset at the current
> mode even if there have not been any changes in the mode list
> or connector status.
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Cc: Chris Wilson 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/drm_connector.c | 32 
>  include/drm/drm_connector.h |  1 +
>  include/drm/drm_crtc.h  |  6 ++
>  include/uapi/drm/drm_mode.h |  4 
>  4 files changed, 43 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 2db7fb5..b4ce19f 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -588,6 +588,11 @@ int drm_display_info_set_bus_formats(struct 
> drm_display_info *info,
>  DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>drm_tv_subconnector_enum_list)
>  
> +static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
> + { DRM_MODE_LINK_STATUS_GOOD, "Good" },
> + { DRM_MODE_LINK_STATUS_BAD, "Bad" },
> +};
> +
>  int drm_connector_create_standard_properties(struct drm_device *dev)
>  {
>   struct drm_property *prop;
> @@ -845,6 +850,33 @@ int drm_mode_create_suggested_offset_properties(struct 
> drm_device *dev)
>  EXPORT_SYMBOL(drm_mode_create_suggested_offset_properties);
>  
>  /**
> + * drm_mode_create_link_status_property - Create link status property
> + * @dev: DRM device
> + *
> + * Called by a driver the first time it's needed, must be attached to desired
> + * connectors.
> + * This property is used to indicate whether link sttaus is Good or Bad as
> + * a result fo link training
> + */
> +int drm_mode_create_link_status_property(struct drm_device *dev)
> +{
> + struct drm_property *link_status;
> +
> + if (dev->mode_config.link_status_property)
> + return 0;
> +
> + link_status =
> + drm_property_create_enum(dev, 0, "link-status",
> +  drm_link_status_enum_list,
> +  ARRAY_SIZE(drm_link_status_enum_list));
> +
> + dev->mode_config.scaling_mode_property = link_status;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_mode_create_link_status_property);
> +
> +/**
>   * drm_mode_connector_set_path_property - set tile property on connector
>   * @connector: connector to set property on.
>   * @path: path to use for property; must not be NULL.
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index fc9d475..7234c0c 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -759,6 +759,7 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
>  int drm_mode_create_scaling_mode_property(struct drm_device *dev);
>  int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
>  int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
> +int drm_mode_create_link_status_property(struct drm_device *dev);
>  
>  int drm_mode_connector_set_path_property(struct drm_connector *connector,
>const char *path);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index fa1aa21..3e9c833 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1343,6 +1343,12 @@ struct drm_mode_config {
>*/
>   struct drm_property *suggested_y_property;
>  
> + /**
> +  * @link_status_property: Optional connector property for link status
> +  * of the connector as a result of link training.
> +  */
> +  struct drm_property *link_status_property;
> +
>   /* dumb ioctl parameters */
>   uint32_t preferred_depth, prefer_shadow;
>  
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 084b50a..f1b0afd 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -121,6 +121,10 @@
>  #define DRM_MODE_DIRTY_ON   1
>  #define DRM_MODE_DIRTY_ANNOTATE 2
>  
> +/* Link Status options */
> +#define DRM_MODE_LINK_STATUS_GOOD0
> +#define DRM_MODE_LINK_STATUS_BAD 1
> +
>  struct drm_mode_modeinfo {
>   __u32 clock;
>   __u16 hdisplay;
> -- 
> 1.9.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915: Set link status property for DP connector

[Manasi Navare]

The link status connector property is attached to the drm
object in DP initialization.
This also defines a helper function to set the property value.
This will be used to set the link sttaus to Bad in case
of link training failures.

Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Chris Wilson 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3c2293b..dd0d372 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4674,6 +4674,22 @@ static int intel_dp_get_modes(struct drm_connector 
*connector)
 }
 
 static int
+intel_dp_set_link_status_property(struct drm_connector *connector,
+ uint64_t val)
+{
+   struct drm_device *dev = connector->dev;
+   int ret = 0;
+
+   ret = drm_object_property_set_value(>base,
+   
dev->mode_config.link_status_property,
+   val);
+   if (ret)
+   return ret;
+
+   return ret;
+}
+
+static int
 intel_dp_connector_register(struct drm_connector *connector)
 {
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -4940,6 +4956,11 @@ bool intel_dp_is_edp(struct drm_device *dev, enum port 
port)
connector->dev->mode_config.scaling_mode_property,
DRM_MODE_SCALE_ASPECT);
intel_connector->panel.fitting_mode = DRM_MODE_SCALE_ASPECT;
+   } else {
+   drm_mode_create_link_status_property(connector->dev);
+   drm_object_attach_property(>base,
+  
connector->dev->mode_config.link_status_property,
+  DRM_MODE_LINK_STATUS_GOOD);
}
 }
 
-- 
1.9.1

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

[Intel-gfx] [PATCH 1/2] drm: Add a new connector property for link status

[Manasi Navare]

A new optional connector property is added for keeping
track of whether the link is good (link training passed) or
link is bad (link training  failed). If the link status property
is Bad, then userspace should fire off a new modeset at the current
mode even if there have not been any changes in the mode list
or connector status.

Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Chris Wilson 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/drm_connector.c | 32 
 include/drm/drm_connector.h |  1 +
 include/drm/drm_crtc.h  |  6 ++
 include/uapi/drm/drm_mode.h |  4 
 4 files changed, 43 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2db7fb5..b4ce19f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -588,6 +588,11 @@ int drm_display_info_set_bus_formats(struct 
drm_display_info *info,
 DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
 drm_tv_subconnector_enum_list)
 
+static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
+   { DRM_MODE_LINK_STATUS_GOOD, "Good" },
+   { DRM_MODE_LINK_STATUS_BAD, "Bad" },
+};
+
 int drm_connector_create_standard_properties(struct drm_device *dev)
 {
struct drm_property *prop;
@@ -845,6 +850,33 @@ int drm_mode_create_suggested_offset_properties(struct 
drm_device *dev)
 EXPORT_SYMBOL(drm_mode_create_suggested_offset_properties);
 
 /**
+ * drm_mode_create_link_status_property - Create link status property
+ * @dev: DRM device
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * connectors.
+ * This property is used to indicate whether link sttaus is Good or Bad as
+ * a result fo link training
+ */
+int drm_mode_create_link_status_property(struct drm_device *dev)
+{
+   struct drm_property *link_status;
+
+   if (dev->mode_config.link_status_property)
+   return 0;
+
+   link_status =
+   drm_property_create_enum(dev, 0, "link-status",
+drm_link_status_enum_list,
+ARRAY_SIZE(drm_link_status_enum_list));
+
+   dev->mode_config.scaling_mode_property = link_status;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_link_status_property);
+
+/**
  * drm_mode_connector_set_path_property - set tile property on connector
  * @connector: connector to set property on.
  * @path: path to use for property; must not be NULL.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fc9d475..7234c0c 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -759,6 +759,7 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
 int drm_mode_create_scaling_mode_property(struct drm_device *dev);
 int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
 int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
+int drm_mode_create_link_status_property(struct drm_device *dev);
 
 int drm_mode_connector_set_path_property(struct drm_connector *connector,
 const char *path);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index fa1aa21..3e9c833 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1343,6 +1343,12 @@ struct drm_mode_config {
 */
struct drm_property *suggested_y_property;
 
+   /**
+* @link_status_property: Optional connector property for link status
+* of the connector as a result of link training.
+*/
+struct drm_property *link_status_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
 
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 084b50a..f1b0afd 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -121,6 +121,10 @@
 #define DRM_MODE_DIRTY_ON   1
 #define DRM_MODE_DIRTY_ANNOTATE 2
 
+/* Link Status options */
+#define DRM_MODE_LINK_STATUS_GOOD  0
+#define DRM_MODE_LINK_STATUS_BAD   1
+
 struct drm_mode_modeinfo {
__u32 clock;
__u16 hdisplay;
-- 
1.9.1

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

[Intel-gfx] fail to build on 32-bit x86 report

[Dave Airlie]

http://kisskb.ellerman.id.au/kisskb/buildresult/12840554/

Since the GVT stuff it looks like some divide should be a do_div.

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

Re: [Intel-gfx] [PATCH 5/8] drm/i915/huc: Support HuC authentication

[Carlos Santa]

On Mon, 2016-10-03 at 11:42 -0700, Anusha Srivatsa wrote:
> From: Peter Antoine 
> 
> The HuC authentication is done by host2guc call. The HuC RSA keys
> are sent to GuC for authentication.
> 
> v2: rebased on top of drm-intel-nightly.
> changed name format and upped version 1.7.
> v3: rebased on top of drm-intel-nightly.
> v4: changed wait_for_automic to wait_for
> v5: rebased.
> v7: rebased.
> v8: rebased.
> 
> Tested-by: Xiang Haihao 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Alex Dai 
> Signed-off-by: Peter Antoine 
> Reviewed-by: Dave Gordon 
> ---
>  drivers/gpu/drm/i915/i915_guc_submission.c | 65
> ++
>  drivers/gpu/drm/i915/intel_guc_fwif.h  |  1 +
>  drivers/gpu/drm/i915/intel_guc_loader.c|  2 +
>  3 files changed, 68 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index 4b92943..984b529 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include "i915_drv.h"
>  #include "intel_guc.h"
> +#include "intel_huc.h"
>  
>  /**
>   * DOC: GuC-based command submission
> @@ -1110,3 +,67 @@ int intel_guc_resume(struct drm_device *dev)
>  
>   return host2guc_action(guc, data, ARRAY_SIZE(data));
>  }
> +
> +/**
> + * intel_huc_auth() - authenticate ucode
> + * @dev: the drm device
> + *
> + * Triggers a HuC fw authentication request to the GuC via host-2-
> guc
> + * interface.
> + */
> +void intel_huc_auth(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_guc *guc = _priv->guc;
> + struct intel_huc *huc = _priv->huc;
> + struct i915_vma *vma;
> + int ret;
> + u32 data[2];
> +
> + /* Bypass the case where there is no HuC firmware */
> + if (huc->huc_fw.fetch_status == UC_FIRMWARE_NONE ||
> + huc->huc_fw.load_status == UC_FIRMWARE_NONE)
> + return;
> +
> + if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS) {
> + DRM_ERROR("HuC: GuC fw wasn't loaded. Can't
> authenticate");
> + return;
> + }
> +
> + if (huc->huc_fw.load_status != UC_FIRMWARE_SUCCESS) {
> + DRM_ERROR("HuC: fw wasn't loaded. Nothing to
> authenticate");
> + return;
> + }
> +
> + vma = i915_gem_object_ggtt_pin(huc->huc_fw.uc_fw_obj, NULL,
> 0, 0, 0);
> + if (IS_ERR(vma)) {
> + DRM_DEBUG_DRIVER("pin failed %d\n",
> (int)PTR_ERR(vma));
> + return;
> + }
> +
> +
> + /* Invalidate GuC TLB to let GuC take the latest updates to
> GTT. */
> + I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
> +
> + /* Specify auth action and where public signature is. It's
> stored
> +  * at the beginning of the gem object, before the fw bits
> +  */
> + data[0] = HOST2GUC_ACTION_AUTHENTICATE_HUC;
> + data[1] = i915_ggtt_offset(vma) + huc->huc_fw.rsa_offset;
> +
> + ret = host2guc_action(guc, data, ARRAY_SIZE(data));
> + if (ret) {
> + DRM_ERROR("HuC: GuC did not ack Auth request\n");
> + goto out;
> + }
> +
> + /* Check authentication status, it should be done by now */
> + ret = wait_for((I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED) >
> 0, 50);
> + if (ret) {
> + DRM_ERROR("HuC: Authentication failed\n");
> + goto out;
> + }
> +
> +out:
> + i915_vma_unpin(vma);
> +}
> diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h
> b/drivers/gpu/drm/i915/intel_guc_fwif.h
> index b38b6b4..57e6466 100644
> --- a/drivers/gpu/drm/i915/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
> @@ -438,6 +438,7 @@ enum host2guc_action {
>   HOST2GUC_ACTION_ENTER_S_STATE = 0x501,
>   HOST2GUC_ACTION_EXIT_S_STATE = 0x502,
>   HOST2GUC_ACTION_SLPC_REQUEST = 0x3003,
> + HOST2GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
>   HOST2GUC_ACTION_LIMIT
>  };
>  
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
> b/drivers/gpu/drm/i915/intel_guc_loader.c
> index 0d214b4..31a2b0a 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -527,6 +527,8 @@ int intel_guc_setup(struct drm_device *dev)
>   intel_uc_fw_status_repr(guc_fw->fetch_status),
>   intel_uc_fw_status_repr(guc_fw->load_status));
>  
> + intel_huc_auth(dev);
> +

Shouldn't intel_huc_auth() be returning a meaningful error value
instead of void?

Carlos
>   if (i915.enable_guc_submission) {
>   err = i915_guc_submission_enable(dev_priv);
>   if (err)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/dp: Enable DP audio stall fix for gen9 platforms

[Pandiyan, Dhinakaran]

Mixing up git rebase and reset was not a good idea, will send the
corrected patch. Please ignore this.

On Tue, 2016-10-25 at 16:42 -0700, Dhinakaran Pandiyan wrote:
> Enabling DP audio stall fix is necessary to play audio over DP HBR2. So,
> let's set this bit right before enabling the audio codec. Playing audio
> without setting this bit results in pipe FIFO underruns.
> 
> This workaround is applicable only for audio sample rates up to 96kHz. For
> frequencies above 96kHz, this is insufficient and cdclk should be increased
> to at least 432 MHz, just like BDW. Since, the audio driver does not
> support sample rates < 48 kHz, we are safe with this fix for now.
> 
> v2: Inlined the code change within hsw_audio_codec_enable() (Jani)
> Fixed the port clock typo
> Added TODO comment
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/i915_reg.h|  5 +++
>  drivers/gpu/drm/i915/intel_audio.c | 62 
> +++---
>  2 files changed, 62 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 00efaa1..76dac48 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6236,6 +6236,11 @@ enum {
>  #define SLICE_ECO_CHICKEN0   _MMIO(0x7308)
>  #define   PIXEL_MASK_CAMMING_DISABLE (1 << 14)
>  
> +#define _CHICKEN_TRANS_A 0x420C0
> +#define _CHICKEN_TRANS_B 0x420C4
> +#define CHICKEN_TRANS(tran) _MMIO_TRANS(tran, _CHICKEN_TRANS_A, 
> _CHICKEN_TRANS_B)
> +#define SPARE_13 (1<<13)
> +
>  /* WaCatErrorRejectionIssue */
>  #define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG   _MMIO(0x9030)
>  #define  GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB(1<<11)
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 7093cfb..413dd50 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -283,6 +283,8 @@ static void hsw_audio_codec_disable(struct intel_encoder 
> *encoder)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> + struct intel_crtc_state *crtc_config =  intel_crtc->config;
> + enum transcoder cpu_transcoder = crtc_config->cpu_transcoder;
>   enum pipe pipe = intel_crtc->pipe;
>   uint32_t tmp;
>  
> @@ -290,13 +292,21 @@ static void hsw_audio_codec_disable(struct 
> intel_encoder *encoder)
>  
>   mutex_lock(_priv->av_mutex);
>  
> + /*Disable DP audio stall fix for HBR2*/
> + if (IS_GEN9(dev_priv) && intel_crtc_has_dp_encoder(crtc_config) &&
> + crtc_config->port_clock >= 54) {
> + tmp = I915_READ(CHICKEN_TRANS(cpu_transcoder));
> + tmp &= ~SPARE_13;
> + I915_WRITE(CHICKEN_TRANS(cpu_transcoder), tmp);
> + }
> +
>   /* Disable timestamps */
>   tmp = I915_READ(HSW_AUD_CFG(pipe));
>   tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
>   tmp |= AUD_CONFIG_N_PROG_ENABLE;
>   tmp &= ~AUD_CONFIG_UPPER_N_MASK;
>   tmp &= ~AUD_CONFIG_LOWER_N_MASK;
> - if (intel_crtc_has_dp_encoder(intel_crtc->config))
> + if (intel_crtc_has_dp_encoder(crtc_config))
>   tmp |= AUD_CONFIG_N_VALUE_INDEX;
>   I915_WRITE(HSW_AUD_CFG(pipe), tmp);
>  
> @@ -315,6 +325,8 @@ static void hsw_audio_codec_enable(struct drm_connector 
> *connector,
>  {
>   struct drm_i915_private *dev_priv = to_i915(connector->dev);
>   struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder->base.crtc);
> + struct intel_crtc_state *crtc_config =  intel_crtc->config;
> + enum transcoder cpu_transcoder = crtc_config->cpu_transcoder;
>   enum pipe pipe = intel_crtc->pipe;
>   enum port port = intel_encoder->port;
>   const uint8_t *eld = connector->eld;
> @@ -326,6 +338,22 @@ static void hsw_audio_codec_enable(struct drm_connector 
> *connector,
>  
>   mutex_lock(_priv->av_mutex);
>  
> + /* Enable DP audio stall fix for HBR2
> +  *
> +  * TODO: This workaround is applicable only for audio sample rates up
> +  * to 96kHz. For frequencies above 96kHz, this is insufficient and
> +  * cdclk should be increased to at least 432 MHz, just like BDW. Since,
> +  * the audio driver does not support sample rates < 48 kHz, we are safe
> +  * with this fix for now.
> +  */
> +
> + if (IS_GEN9(dev_priv) && intel_crtc_has_dp_encoder(crtc_config) &&
> + crtc_config->port_clock >= 54) {
> + tmp = I915_READ(CHICKEN_TRANS(cpu_transcoder));
> + tmp |= SPARE_13;
> + I915_WRITE(CHICKEN_TRANS(cpu_transcoder), tmp);
> + }
> +
>   /* Enable audio presence detect, invalidate ELD */
>   tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
>   tmp |= AUDIO_OUTPUT_ENABLE(pipe);
> @@ -642,25 +670,49 @@ static int i915_audio_component_get_cdclk_freq(struct 
> device *kdev)
>   

[Intel-gfx] ✓ Fi.CI.BAT: success for DP audio fixes (rev4)

[Patchwork]

== Series Details ==

Series: DP audio fixes (rev4)
URL   : https://patchwork.freedesktop.org/series/14314/
State : success

== Summary ==

Series 14314v4 DP audio fixes
https://patchwork.freedesktop.org/api/1.0/series/14314/revisions/4/mbox/


fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

f746a2112fbb563743acc132304075706551d123 drm-intel-nightly: 
2016y-10m-25d-20h-02m-34s UTC integration manifest
e90ef85 drm/i915/dp: BDW cdclk fix for DP audio
9eb8630 drm/i915/dp: Enable DP audio stall fix for gen9 platforms

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2818/

== Logs ==

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

Re: [Intel-gfx] [PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

[Robert Bragg]

On Tue, Oct 25, 2016 at 10:35 PM, Matthew Auld <
matthew.william.a...@gmail.com> wrote:

> On 25 October 2016 at 00:19, Robert Bragg  wrote:



>
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> > index 3448d05..ea24814 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1764,6 +1764,11 @@ struct intel_wm_config {
>
> >
> >  struct drm_i915_private {
> > @@ -2149,16 +2164,46 @@ struct drm_i915_private {
> >
> > struct {
> > bool initialized;
> > +
> > struct mutex lock;
> > struct list_head streams;
> >
> > +   spinlock_t hook_lock;
> > +
> > struct {
> > -   u32 metrics_set;
> > +   struct i915_perf_stream *exclusive_stream;
> > +
> > +   u32 specific_ctx_id;
> Can we just get rid of this, now that the vma remains pinned we can
> simply get the ggtt address at the time of configuring the OA_CONTROL
> register ?
>

I considered that, but would ideally prefer to keep it considering the
gen8+ patches to come. For gen8+ (with execlists) the context ID isn't a
gtt offset.


>
> > +
> > +   struct hrtimer poll_check_timer;
> > +   wait_queue_head_t poll_wq;
> > +   atomic_t pollin;
> > +
>
>

> > +/* The maximum exponent the hardware accepts is 63 (essentially it
> selects one
> > + * of the 64bit timestamp bits to trigger reports from) but there's
> currently
> > + * no known use case for sampling as infrequently as once per 47
> thousand years.
> > + *
> > + * Since the timestamps included in OA reports are only 32bits it seems
> > + * reasonable to limit the OA exponent where it's still possible to
> account for
> > + * overflow in OA report timestamps.
> > + */
> > +#define OA_EXPONENT_MAX 31
> > +
> > +#define INVALID_CTX_ID 0x
> We shouldn't need this anymore.
>

yeah I removed it and then added it back, just for the sake of explicitly
setting the specific_ctx_id to an invalid ID when closing the exclusive
stream - though resetting the value isn't strictly necessary.

also maybe your comment is assuming specific_ctx_id can be removed, while
I'd prefer to keep it.


> > +
> > +static int claim_specific_ctx(struct i915_perf_stream *stream)
> > +{
> pin_oa_specific_ctx, or something? Also would it not make more sense
> to operate on the context, not the stream.
>

Yeah, I avoided a name like that mainly because it's also initializing
specific_ctx_id, which seemed to me like it would become an unexpected side
effect with that more specific name.

The other consideration is that in my gen8+ patches the pinning code is
conditional depending on whether execlists are enabled, while the function
still initializes specific_ctx_id.

Certainly not attached to the names though.

Chris has some feedback with the code, so maybe that will affect this too.


> > +   struct drm_i915_private *dev_priv = stream->dev_priv;
> > +   struct i915_vma *vma;
> > +   int ret;
> > +
> > +   ret = i915_mutex_lock_interruptible(_priv->drm);
> > +   if (ret)
> > +   return ret;
> > +
> > +   /* So that we don't have to worry about updating the context ID
> > +* in OACONTOL on the fly we make sure to pin the context
> > +* upfront for the lifetime of the stream...
> > +*/
> > +   vma = stream->ctx->engine[RCS].state;
> > +   ret = i915_vma_pin(vma, 0, stream->ctx->ggtt_alignment,
> > +  PIN_GLOBAL | PIN_HIGH);
> > +   if (ret)
> > +   return ret;
> > +
> > +   dev_priv->perf.oa.specific_ctx_id = i915_ggtt_offset(vma);
> > +
> > +   mutex_unlock(_priv->drm.struct_mutex);
> > +
> > +   return 0;
> > +}
>


I'll also follow up on the other notes; thanks!

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

[Intel-gfx] [PATCH v3 1/2] drm/i915/dp: Enable DP audio stall fix for gen9 platforms

[Dhinakaran Pandiyan]

Enabling DP audio stall fix is necessary to play audio over DP HBR2. So,
let's set this bit right before enabling the audio codec. Playing audio
without setting this bit results in pipe FIFO underruns.

This workaround is applicable only for audio sample rates up to 96kHz. For
frequencies above 96kHz, this is insufficient and cdclk should be increased
to at least 432 MHz, just like BDW. Since, the audio driver does not
support sample rates < 48 kHz, we are safe with this fix for now.

v2: Inlined the code change within hsw_audio_codec_enable() (Jani)
Fixed the port clock typo
Added TODO comment
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_reg.h|  5 +++
 drivers/gpu/drm/i915/intel_audio.c | 62 +++---
 2 files changed, 62 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 00efaa1..76dac48 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6236,6 +6236,11 @@ enum {
 #define SLICE_ECO_CHICKEN0 _MMIO(0x7308)
 #define   PIXEL_MASK_CAMMING_DISABLE   (1 << 14)
 
+#define _CHICKEN_TRANS_A   0x420C0
+#define _CHICKEN_TRANS_B   0x420C4
+#define CHICKEN_TRANS(tran) _MMIO_TRANS(tran, _CHICKEN_TRANS_A, 
_CHICKEN_TRANS_B)
+#define SPARE_13   (1<<13)
+
 /* WaCatErrorRejectionIssue */
 #define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG _MMIO(0x9030)
 #define  GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB  (1<<11)
diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index 7093cfb..413dd50 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -283,6 +283,8 @@ static void hsw_audio_codec_disable(struct intel_encoder 
*encoder)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
+   struct intel_crtc_state *crtc_config =  intel_crtc->config;
+   enum transcoder cpu_transcoder = crtc_config->cpu_transcoder;
enum pipe pipe = intel_crtc->pipe;
uint32_t tmp;
 
@@ -290,13 +292,21 @@ static void hsw_audio_codec_disable(struct intel_encoder 
*encoder)
 
mutex_lock(_priv->av_mutex);
 
+   /*Disable DP audio stall fix for HBR2*/
+   if (IS_GEN9(dev_priv) && intel_crtc_has_dp_encoder(crtc_config) &&
+   crtc_config->port_clock >= 54) {
+   tmp = I915_READ(CHICKEN_TRANS(cpu_transcoder));
+   tmp &= ~SPARE_13;
+   I915_WRITE(CHICKEN_TRANS(cpu_transcoder), tmp);
+   }
+
/* Disable timestamps */
tmp = I915_READ(HSW_AUD_CFG(pipe));
tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
tmp |= AUD_CONFIG_N_PROG_ENABLE;
tmp &= ~AUD_CONFIG_UPPER_N_MASK;
tmp &= ~AUD_CONFIG_LOWER_N_MASK;
-   if (intel_crtc_has_dp_encoder(intel_crtc->config))
+   if (intel_crtc_has_dp_encoder(crtc_config))
tmp |= AUD_CONFIG_N_VALUE_INDEX;
I915_WRITE(HSW_AUD_CFG(pipe), tmp);
 
@@ -315,6 +325,8 @@ static void hsw_audio_codec_enable(struct drm_connector 
*connector,
 {
struct drm_i915_private *dev_priv = to_i915(connector->dev);
struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder->base.crtc);
+   struct intel_crtc_state *crtc_config =  intel_crtc->config;
+   enum transcoder cpu_transcoder = crtc_config->cpu_transcoder;
enum pipe pipe = intel_crtc->pipe;
enum port port = intel_encoder->port;
const uint8_t *eld = connector->eld;
@@ -326,6 +338,22 @@ static void hsw_audio_codec_enable(struct drm_connector 
*connector,
 
mutex_lock(_priv->av_mutex);
 
+   /* Enable DP audio stall fix for HBR2
+*
+* TODO: This workaround is applicable only for audio sample rates up
+* to 96kHz. For frequencies above 96kHz, this is insufficient and
+* cdclk should be increased to at least 432 MHz, just like BDW. Since,
+* the audio driver does not support sample rates < 48 kHz, we are safe
+* with this fix for now.
+*/
+
+   if (IS_GEN9(dev_priv) && intel_crtc_has_dp_encoder(crtc_config) &&
+   crtc_config->port_clock >= 54) {
+   tmp = I915_READ(CHICKEN_TRANS(cpu_transcoder));
+   tmp |= SPARE_13;
+   I915_WRITE(CHICKEN_TRANS(cpu_transcoder), tmp);
+   }
+
/* Enable audio presence detect, invalidate ELD */
tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
tmp |= AUDIO_OUTPUT_ENABLE(pipe);
@@ -642,25 +670,49 @@ static int i915_audio_component_get_cdclk_freq(struct 
device *kdev)
return dev_priv->cdclk_freq;
 }
 
+/*
+ * get the intel_encoder according to the parameter port and pipe
+ * intel_encoder is saved by the index of pipe
+ * MST & (pipe >= 0): return the av_enc_map[pipe],
+ *   when port is matched
+ * MST & (pipe < 0): this is invalid
+ * 

[Intel-gfx] [PATCH v3 2/2] drm/i915/dp: BDW cdclk fix for DP audio

[Dhinakaran Pandiyan]

According to BSpec, cdclk has to be not less than 432 MHz with DP audio
enabled, port width x4, and link rate HBR2 (5.4 GHz)

Having a lower cdclk triggers pipe underruns, which then lead to displays
continuously cycling off and on. This is essential for DP MST audio as the
link is trained at HBR2 and 4 lanes by default.

v3: Combine BDW pixel rate adjustments into a function (Jani)
v2: Restrict fix to BDW
Retain the set cdclk across modesets (Ville)
Cc: sta...@vger.kernel.org
Signed-off-by: Dhinakaran Pandiyan 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 27 ---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a94f7d1..efe46b4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10260,6 +10260,27 @@ static void bxt_modeset_commit_cdclk(struct 
drm_atomic_state *old_state)
bxt_set_cdclk(to_i915(dev), req_cdclk);
 }
 
+static int bdw_adjust_min_pipe_pixel_rate(struct intel_crtc_state *crtc_state,
+ int pixel_rate)
+{
+   /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
+   if (crtc_state->ips_enabled)
+   pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
+
+   /* BSpec says "Do not use DisplayPort with CDCLK less than
+* 432 MHz, audio enabled, port width x4, and link rate
+* HBR2 (5.4 GHz), or else there may be audio corruption or
+* screen corruption."
+*/
+   if (intel_crtc_has_dp_encoder(crtc_state) &&
+   crtc_state->has_audio &&
+   crtc_state->port_clock >= 54 &&
+   crtc_state->lane_count == 4)
+   pixel_rate = max(432000, pixel_rate);
+
+   return pixel_rate;
+}
+
 /* compute the max rate for new configuration */
 static int ilk_max_pixel_rate(struct drm_atomic_state *state)
 {
@@ -10285,9 +10306,9 @@ static int ilk_max_pixel_rate(struct drm_atomic_state 
*state)
 
pixel_rate = ilk_pipe_pixel_rate(crtc_state);
 
-   /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
-   if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
-   pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
+   if (IS_BROADWELL(dev_priv))
+   pixel_rate = bdw_adjust_min_pipe_pixel_rate(crtc_state,
+   pixel_rate);
 
intel_state->min_pixclk[i] = pixel_rate;
}
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/dp: BDW cdclk fix for DP audio

[Pandiyan, Dhinakaran]

On Tue, 2016-10-25 at 18:19 +, Pandiyan, Dhinakaran wrote:
> On Tue, 2016-10-25 at 12:14 +0300, Jani Nikula wrote:
> > On Tue, 25 Oct 2016, Jani Nikula  wrote:
> > > On Tue, 25 Oct 2016, Dhinakaran Pandiyan  
> > > wrote:
> > >> According to BSpec, cdclk has to be not less than 432 MHz with DP audio
> > >> enabled, port width x4, and link rate HBR2 (5.4 GHz)
> > >>
> > >> Having a lower cdclk triggers pipe underruns, which then lead to displays
> > >> continuously cycling off and on. This is essential for DP MST audio as 
> > >> the
> > >> link is trained at HBR2 and 4 lanes by default.
> > >>
> > >> v2: Restrict fix to BDW
> > >> Retain the set cdclk across modesets (Ville)
> > >
> > > Cc: sta...@vger.kernel.org
> > >
> > >>
> > >> Signed-off-by: Dhinakaran Pandiyan 
> > >> ---
> > >>  drivers/gpu/drm/i915/intel_display.c | 28 +---
> > >>  1 file changed, 25 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > >> b/drivers/gpu/drm/i915/intel_display.c
> > >> index a94f7d1..8c59651 100644
> > >> --- a/drivers/gpu/drm/i915/intel_display.c
> > >> +++ b/drivers/gpu/drm/i915/intel_display.c
> > >> @@ -10260,6 +10260,18 @@ static void bxt_modeset_commit_cdclk(struct 
> > >> drm_atomic_state *old_state)
> > >>  bxt_set_cdclk(to_i915(dev), req_cdclk);
> > >>  }
> > >>  
> > >> +static unsigned int bdw_dp_audio_cdclk(struct intel_crtc_state 
> > >> *crtc_state)
> > >> +{
> > >> +
> > >> +if (intel_crtc_has_dp_encoder(crtc_state) &&
> > >> +crtc_state->has_audio &&
> > >> +crtc_state->port_clock >= 54 &&
> > >> +crtc_state->lane_count == 4)
> > >> +return 432000;
> > >
> > > Where does 432000 come from? 45 or even (337500 + 1). See below.
> > >
> > >> +
> > >> +return 0;
> > >> +}
> > >> +
> > >>  /* compute the max rate for new configuration */
> > >>  static int ilk_max_pixel_rate(struct drm_atomic_state *state)
> > >>  {
> > >> @@ -10275,7 +10287,7 @@ static int ilk_max_pixel_rate(struct 
> > >> drm_atomic_state *state)
> > >> sizeof(intel_state->min_pixclk));
> > >>  
> > >>  for_each_crtc_in_state(state, crtc, cstate, i) {
> > >> -int pixel_rate;
> > >> +unsigned int pixel_rate;
> > >>  
> > >>  crtc_state = to_intel_crtc_state(cstate);
> > >>  if (!crtc_state->base.enable) {
> > >> @@ -10285,9 +10297,19 @@ static int ilk_max_pixel_rate(struct 
> > >> drm_atomic_state *state)
> > >>  
> > >>  pixel_rate = ilk_pipe_pixel_rate(crtc_state);
> > >>  
> > >> +if (IS_BROADWELL(dev_priv)) {
> > >>  /* pixel rate mustn't exceed 95% of cdclk with IPS on 
> > >> BDW */
> > >> -if (IS_BROADWELL(dev_priv) && 
> > >> crtc_state->ips_enabled)432
> > >> -pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
> > >> +if (crtc_state->ips_enabled)
> > >> +pixel_rate = DIV_ROUND_UP(pixel_rate * 
> > >> 100, 95);
> > >> +
> > >> +/* BSpec says "Do not use DisplayPort with CDCLK less 
> > >> than
> > >> + * 432 MHz, audio enabled, port width x4, and link rate
> > >
> > > For me the spec says "Do not use DisplayPort with CDCLK 337.5 MHz", not
> > > "less than 432 MHz".
> > 
> > Right, so the spec for *Skylake* mentions 432 MHz. Now, we need this fix
> > for both Broadwell and Skylake, where's the Skylake part?
> > 
> > BR,
> > Jani.
> > 
> > 
> 
> I believe you are looking at CDCLK_CTL that refers to pre-production SKL
> SKU's. See the description for DP_TP_CTL instead. The information seems
> to be scattered a bit
> 
> 
> > >
> > >> + * HBR2 (5.4 GHz), or else there may be audio 
> > >> corruption or
> > >> + * screen corruption."
> > >> + */
> > >> +pixel_rate = max(pixel_rate,
> > >> + 
> > >> bdw_dp_audio_cdclk(crtc_state));
> > >> +}
> > >
> > > I'd add a new function
> > >
> > > static int bwd_adjust_min_pipe_pixel_rate(struct intel_crtc_state 
> > > *crtc_state,
> > > int pixel_rate)
> > >
> > > and do both the IPS adjustment and the audio adjustment there, returning
> > > the original pixel_rate if adjustment is not needed. Move the comments
> > > there as well.
> > >
> > > It would be called as
> > >
> > >   if (IS_BROADWELL(dev_priv))
> > >   pixel_rate = bwd_adjust_min_pipe_pixel_rate(crtc_state, 
> > > pixel_rate);
> > >
> > > here.
> > >
> > >
> > > BR,
> > > Jani.
> > >
> 
> Will do.
> 
> -DK
> > >>  
> > >>  intel_state->min_pixclk[i] = pixel_rate;
> > >>  }
> > 
> 
> ___
> Intel-gfx 

Re: [Intel-gfx] [PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

[Chris Wilson]

On Tue, Oct 25, 2016 at 12:19:29AM +0100, Robert Bragg wrote:
> +static int claim_specific_ctx(struct i915_perf_stream *stream)
> +{
> + struct drm_i915_private *dev_priv = stream->dev_priv;
> + struct i915_vma *vma;
> + int ret;
> +
> + ret = i915_mutex_lock_interruptible(_priv->drm);

Looking forward to the day these don't need struct_mutex.

> + if (ret)
> + return ret;
> +
> + /* So that we don't have to worry about updating the context ID
> +  * in OACONTOL on the fly we make sure to pin the context
> +  * upfront for the lifetime of the stream...
> +  */
> + vma = stream->ctx->engine[RCS].state;

There's a caveat here that suggests I had better wrap up this into its
own function. (We need to flush dirty cachelines to memory on first
binding of the context.)

> + ret = i915_vma_pin(vma, 0, stream->ctx->ggtt_alignment,
> +PIN_GLOBAL | PIN_HIGH);
> + if (ret)
> + return ret;

Oops.

> +
> + dev_priv->perf.oa.specific_ctx_id = i915_ggtt_offset(vma);
> +
> + mutex_unlock(_priv->drm.struct_mutex);
> +
> + return 0;
> +}


> +static int alloc_oa_buffer(struct drm_i915_private *dev_priv)
> +{
> + struct drm_i915_gem_object *bo;
> + struct i915_vma *vma;
> + int ret;
> +
> + BUG_ON(dev_priv->perf.oa.oa_buffer.vma);
> +
> + ret = i915_mutex_lock_interruptible(_priv->drm);
> + if (ret)
> + return ret;
> +
> + BUILD_BUG_ON_NOT_POWER_OF_2(OA_BUFFER_SIZE);
> + BUILD_BUG_ON(OA_BUFFER_SIZE < SZ_128K || OA_BUFFER_SIZE > SZ_16M);
> +
> + bo = i915_gem_object_create(_priv->drm, OA_BUFFER_SIZE);
> + if (IS_ERR(bo)) {
> + DRM_ERROR("Failed to allocate OA buffer\n");
> + ret = PTR_ERR(bo);
> + goto unlock;
> + }
> +
> + ret = i915_gem_object_set_cache_level(bo, I915_CACHE_LLC);
> + if (ret)
> + goto err_unref;
> +
> + /* PreHSW required 512K alignment, HSW requires 16M */
> + vma = i915_gem_object_ggtt_pin(bo, NULL, 0, SZ_16M, PIN_MAPPABLE);

Does this need mappable aperture space for OA? You aren't accessing it
via the aperture, but is the hw limited to it?

> + if (IS_ERR(vma)) {
> + ret = PTR_ERR(vma);
> + goto err_unref;
> + }
> + dev_priv->perf.oa.oa_buffer.vma = vma;
> +
> + dev_priv->perf.oa.oa_buffer.vaddr =
> + i915_gem_object_pin_map(bo, I915_MAP_WB);
> + if (IS_ERR(dev_priv->perf.oa.oa_buffer.vaddr)) {
> + ret = PTR_ERR(dev_priv->perf.oa.oa_buffer.vaddr);
> + goto err_unpin;
> + }
> +
> + dev_priv->perf.oa.ops.init_oa_buffer(dev_priv);
> +
> + DRM_DEBUG_DRIVER("OA Buffer initialized, gtt offset = 0x%x, vaddr = %p",
> +  i915_ggtt_offset(dev_priv->perf.oa.oa_buffer.vma),
> +  dev_priv->perf.oa.oa_buffer.vaddr);
> +
> + goto unlock;
> +
> +err_unpin:
> + __i915_vma_unpin(vma);
> +
> +err_unref:
> + i915_gem_object_put(bo);
> +
> + dev_priv->perf.oa.oa_buffer.vaddr = NULL;
> + dev_priv->perf.oa.oa_buffer.vma = NULL;
> +
> +unlock:
> + mutex_unlock(_priv->drm.struct_mutex);
> + return ret;
> +}


> + if (ret >= 0) {
> + /* Maybe make ->pollin per-stream state if we support multiple
> +  * concurrent streams in the future. */
> + atomic_set(_priv->perf.oa.pollin, false);
> + }
> +
>   return ret;
>  }
>  
> -static unsigned int i915_perf_poll_locked(struct i915_perf_stream *stream,
> +static enum hrtimer_restart oa_poll_check_timer_cb(struct hrtimer *hrtimer)
> +{
> + struct drm_i915_private *dev_priv =
> + container_of(hrtimer, typeof(*dev_priv),
> +  perf.oa.poll_check_timer);
> +
> + if (!dev_priv->perf.oa.ops.oa_buffer_is_empty(dev_priv)) {
> + atomic_set(_priv->perf.oa.pollin, true);
> + wake_up(_priv->perf.oa.poll_wq);
> + }
> +
> + hrtimer_forward_now(hrtimer, ns_to_ktime(POLL_PERIOD));
> +
> + return HRTIMER_RESTART;
> +}
> +
> +static unsigned int i915_perf_poll_locked(struct drm_i915_private *dev_priv,
> +   struct i915_perf_stream *stream,
> struct file *file,
> poll_table *wait)
>  {
> - unsigned int streams = 0;
> + unsigned int events = 0;
>  
>   stream->ops->poll_wait(stream, file, wait);
>  
> - if (stream->ops->can_read(stream))
> - streams |= POLLIN;
> + /* Note: we don't explicitly check whether there's something to read
> +  * here since this path may be very hot depending on what else
> +  * userspace is polling, or on the timeout in use. We rely solely on
> +  * the hrtimer/oa_poll_check_timer_cb to notify us when there are
> +  * samples to read.
> +  */
> + if (atomic_read(_priv->perf.oa.pollin))
> + 

Re: [Intel-gfx] [PATCH 1/5] drm: Add atomic helper to redo a modeset on current mode

[Rodrigo Vivi]

On Tue, Oct 25, 2016 at 5:09 AM, Jani Nikula
 wrote:
> On Sat, 22 Oct 2016, Manasi Navare  wrote:
>> This function provides a way for the driver to redo a
>> modeset on the current mode and retry the link training
>> at a lower link rate/lane count/bpp. This will get called
>> incase the link training fails during the current modeset.
>
> Based on discussions on #intel-gfx, I would dodge all the problems here
> by having the userspace do the modeset.

This is not like going back to UMS times?

> If we add a connector property to indicate the link status (and this
> does not have to be DP or link training specific, really), we can set
> that to "bad", and fire off the hotplug uevent. Then userspace has the
> information to force a modeset on that connector even if the mode has
> not changed. (Credits to Ville for the idea.)

This would require changes in all user space drivers out there right?
Ok, maybe faster than fix vblank layer for good...

>
> If we find a solution later on that allows us to handle all of this in
> kernel, we can do so, and remove the property or always report
> "good". Drivers can choose different approaches, depending on the
> capabilities of the hardware, for instance.

So, is this temporary then? While we update the vblank layer?

> Deferring this to the userspace does not regress anything now, because
> currently we just completely fail and end up with a black screen. The
> property would allow an enlightened userspace to fix that. And userspace
> can't rely on the property being there, as it's currently not there.

Also this discussion remind me about the PSR where we refused to give control
to userspace or create any property and kmd should control all cases.
Should we revisit that and change userspace to control PSR?

Thanks,
Rodrigo.

>
>
> BR,
> Jani.
>
>
>>
>> Cc: dri-de...@lists.freedesktop.org
>> Cc: Jani Nikula 
>> Cc: Daniel Vetter 
>> Cc: Ville Syrjala 
>> Signed-off-by: Manasi Navare 
>> ---
>>  drivers/gpu/drm/drm_atomic_helper.c | 58 
>> +
>>  include/drm/drm_atomic_helper.h |  1 +
>>  2 files changed, 59 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index f936276..0c1614e 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -2895,6 +2895,64 @@ int drm_atomic_helper_connector_dpms(struct 
>> drm_connector *connector,
>>  EXPORT_SYMBOL(drm_atomic_helper_connector_dpms);
>>
>>  /**
>> + * drm_atomic_helper_connector_modeset - Force a modeset on a connector
>> + * @connector: DRM connector
>> + *
>> + * Provides a way to redo a modeset with the current mode so that it can
>> + * drop the bpp, link rate/lane count and retry the link training.
>> + *
>> + * Returns:
>> + * Returns 0 on success, negative errno numbers on failure.
>> + */
>> +int
>> +drm_atomic_helper_connector_modeset(struct drm_connector *connector)
>> +{
>> + struct drm_device *dev = connector->dev;
>> + struct drm_modeset_acquire_ctx ctx;
>> + struct drm_atomic_state *state;
>> + struct drm_connector_state *connector_state;
>> + struct drm_crtc_state *crtc_state;
>> + int ret = 0;
>> +
>> + drm_modeset_acquire_init(, 0);
>> + state = drm_atomic_state_alloc(dev);
>> + if (!state) {
>> + ret = -ENOMEM;
>> + goto fail;
>> + }
>> + state->acquire_ctx = 
>> +retry:
>> + ret = 0;
>> + connector_state = drm_atomic_get_connector_state(state, connector);
>> + if (IS_ERR(connector_state)) {
>> + ret = PTR_ERR(connector_state);
>> + goto fail;
>> + }
>> + if (!connector_state->crtc)
>> + goto fail;
>> +
>> + crtc_state = drm_atomic_get_existing_crtc_state(state,
>> + connector_state->crtc);
>> + crtc_state->connectors_changed = true;
>> + ret = drm_atomic_commit(state);
>> +fail:
>> + if (ret == -EDEADLK) {
>> + drm_atomic_state_clear(state);
>> + drm_modeset_backoff();
>> + goto retry;
>> + }
>> +
>> + if (state)
>> + drm_atomic_state_put(state);
>> +
>> + drm_modeset_drop_locks();
>> + drm_modeset_acquire_fini();
>> +
>> + return ret;
>> +}
>> +EXPORT_SYMBOL(drm_atomic_helper_connector_modeset);
>> +
>> +/**
>>   * drm_atomic_helper_best_encoder - Helper for _connector_helper_funcs
>>   *  ->best_encoder callback
>>   * @connector: Connector control structure
>> diff --git a/include/drm/drm_atomic_helper.h 
>> b/include/drm/drm_atomic_helper.h
>> index 7ff92b0..8de24dc 100644
>> --- a/include/drm/drm_atomic_helper.h
>> +++ b/include/drm/drm_atomic_helper.h
>> @@ -126,6 +126,7 @@ int 

Re: [Intel-gfx] [PATCH 1/5] drm: Add atomic helper to redo a modeset on current mode

[Manasi Navare]

On Tue, Oct 25, 2016 at 03:09:39PM +0300, Jani Nikula wrote:
> On Sat, 22 Oct 2016, Manasi Navare  wrote:
> > This function provides a way for the driver to redo a
> > modeset on the current mode and retry the link training
> > at a lower link rate/lane count/bpp. This will get called
> > incase the link training fails during the current modeset.
> 
> Based on discussions on #intel-gfx, I would dodge all the problems here
> by having the userspace do the modeset.
> 
> If we add a connector property to indicate the link status (and this
> does not have to be DP or link training specific, really), we can set
> that to "bad", and fire off the hotplug uevent. Then userspace has the
> information to force a modeset on that connector even if the mode has
> not changed. (Credits to Ville for the idea.)
> 
> If we find a solution later on that allows us to handle all of this in
> kernel, we can do so, and remove the property or always report
> "good". Drivers can choose different approaches, depending on the
> capabilities of the hardware, for instance.
> 
> Deferring this to the userspace does not regress anything now, because
> currently we just completely fail and end up with a black screen. The
> property would allow an enlightened userspace to fix that. And userspace
> can't rely on the property being there, as it's currently not there.
> 
> 
> BR,
> Jani.
> 
>

Thanks for your feedback Jani. I will try implementing this, but isn't this 
going
to require changes in all the userspace drivers (modesetting driver, ChromeOS) 
to
make use of this new property to trigger another modeset?
How easy would it be to have all the userspace drivers adopt this change?

Regards
Manasi
 
> >
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: Jani Nikula 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjala 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 58 
> > +
> >  include/drm/drm_atomic_helper.h |  1 +
> >  2 files changed, 59 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index f936276..0c1614e 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -2895,6 +2895,64 @@ int drm_atomic_helper_connector_dpms(struct 
> > drm_connector *connector,
> >  EXPORT_SYMBOL(drm_atomic_helper_connector_dpms);
> >  
> >  /**
> > + * drm_atomic_helper_connector_modeset - Force a modeset on a connector
> > + * @connector: DRM connector
> > + *
> > + * Provides a way to redo a modeset with the current mode so that it can
> > + * drop the bpp, link rate/lane count and retry the link training.
> > + *
> > + * Returns:
> > + * Returns 0 on success, negative errno numbers on failure.
> > + */
> > +int
> > +drm_atomic_helper_connector_modeset(struct drm_connector *connector)
> > +{
> > +   struct drm_device *dev = connector->dev;
> > +   struct drm_modeset_acquire_ctx ctx;
> > +   struct drm_atomic_state *state;
> > +   struct drm_connector_state *connector_state;
> > +   struct drm_crtc_state *crtc_state;
> > +   int ret = 0;
> > +
> > +   drm_modeset_acquire_init(, 0);
> > +   state = drm_atomic_state_alloc(dev);
> > +   if (!state) {
> > +   ret = -ENOMEM;
> > +   goto fail;
> > +   }
> > +   state->acquire_ctx = 
> > +retry:
> > +   ret = 0;
> > +   connector_state = drm_atomic_get_connector_state(state, connector);
> > +   if (IS_ERR(connector_state)) {
> > +   ret = PTR_ERR(connector_state);
> > +   goto fail;
> > +   }
> > +   if (!connector_state->crtc)
> > +   goto fail;
> > +
> > +   crtc_state = drm_atomic_get_existing_crtc_state(state,
> > +   connector_state->crtc);
> > +   crtc_state->connectors_changed = true;
> > +   ret = drm_atomic_commit(state);
> > +fail:
> > +   if (ret == -EDEADLK) {
> > +   drm_atomic_state_clear(state);
> > +   drm_modeset_backoff();
> > +   goto retry;
> > +   }
> > +
> > +   if (state)
> > +   drm_atomic_state_put(state);
> > +
> > +   drm_modeset_drop_locks();
> > +   drm_modeset_acquire_fini();
> > +
> > +   return ret;
> > +}
> > +EXPORT_SYMBOL(drm_atomic_helper_connector_modeset);
> > +
> > +/**
> >   * drm_atomic_helper_best_encoder - Helper for _connector_helper_funcs
> >   *  ->best_encoder callback
> >   * @connector: Connector control structure
> > diff --git a/include/drm/drm_atomic_helper.h 
> > b/include/drm/drm_atomic_helper.h
> > index 7ff92b0..8de24dc 100644
> > --- a/include/drm/drm_atomic_helper.h
> > +++ b/include/drm/drm_atomic_helper.h
> > @@ -126,6 +126,7 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
> > uint32_t flags);
> >  int drm_atomic_helper_connector_dpms(struct 

Re: [Intel-gfx] [PATCH 4/8] drm/i915/huc: Add debugfs for HuC loading status check

[Carlos Santa]

Tested with HuC version 1.07.1398 on SKL.

Reviewed-by: Carlos Santa 
Tested-by: Carlos Santa 

On Mon, 2016-10-03 at 11:42 -0700, Anusha Srivatsa wrote:
> From: Peter Antoine 
> 
> Add debugfs entry for HuC loading status check.
> 
> v2: rebase on-top of drm-intel-nightly.
> v3: rebased again.
> v7: rebased.
> v8: rebased.
> 
> Tested-by: Xiang Haihao 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Alex Dai 
> Signed-off-by: Peter Antoine 
> Reviewed-by: Dave Gordon 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 31
> +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 44258a8..7bd0e23 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2413,6 +2413,36 @@ static int i915_llc(struct seq_file *m, void
> *data)
>   return 0;
>  }
>  
> +static int i915_huc_load_status_info(struct seq_file *m, void *data)
> +{
> + struct drm_i915_private *dev_priv = node_to_i915(m-
> >private);
> + struct intel_uc_fw *huc_fw = _priv->huc.huc_fw;
> +
> + if (!HAS_HUC_UCODE(dev_priv))
> + return 0;
> +
> + seq_puts(m, "HuC firmware status:\n");
> + seq_printf(m, "\tpath: %s\n", huc_fw->uc_fw_path);
> + seq_printf(m, "\tfetch: %s\n",
> + intel_uc_fw_status_repr(huc_fw->fetch_status));
> + seq_printf(m, "\tload: %s\n",
> + intel_uc_fw_status_repr(huc_fw->load_status));
> + seq_printf(m, "\tversion wanted: %d.%d\n",
> + huc_fw->major_ver_wanted, huc_fw->minor_ver_wanted);
> + seq_printf(m, "\tversion found: %d.%d\n",
> + huc_fw->major_ver_found, huc_fw->minor_ver_found);
> + seq_printf(m, "\theader: offset is %d; size = %d\n",
> + huc_fw->header_offset, huc_fw->header_size);
> + seq_printf(m, "\tuCode: offset is %d; size = %d\n",
> + huc_fw->ucode_offset, huc_fw->ucode_size);
> + seq_printf(m, "\tRSA: offset is %d; size = %d\n",
> + huc_fw->rsa_offset, huc_fw->rsa_size);
> +
> + seq_printf(m, "\nHuC status 0x%08x:\n",
> I915_READ(HUC_STATUS2));
> +
> + return 0;
> +}
> +
>  static int i915_guc_load_status_info(struct seq_file *m, void *data)
>  {
>   struct drm_i915_private *dev_priv = node_to_i915(m-
> >private);
> @@ -4427,6 +4457,7 @@ static const struct drm_info_list
> i915_debugfs_list[] = {
>   {"i915_guc_info", i915_guc_info, 0},
>   {"i915_guc_load_status", i915_guc_load_status_info, 0},
>   {"i915_guc_log_dump", i915_guc_log_dump, 0},
> + {"i915_huc_load_status", i915_huc_load_status_info, 0},
>   {"i915_frequency_info", i915_frequency_info, 0},
>   {"i915_hangcheck_info", i915_hangcheck_info, 0},
>   {"i915_drpc_info", i915_drpc_info, 0},
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v7 04/11] drm/i915: don't whitelist oacontrol in cmd parser

[Matthew Auld]

On 25 October 2016 at 00:19, Robert Bragg  wrote:
> Being able to program OACONTROL from a non-privileged batch buffer is
> not sufficient to be able to configure the OA unit. This was originally
> allowed to help enable Mesa to expose OA counters via the
> INTEL_performance_query extension, but the current implementation based
> on programming OACONTROL via a batch buffer isn't able to report useable
> data without a more complete OA unit configuration. Mesa handles the
> possibility that writes to OACONTROL may not be allowed and so only
> advertises the extension after explicitly testing that a write to
> OACONTROL succeeds. Based on this; removing OACONTROL from the whitelist
> should be ok for userspace.
>
> Removing this simplifies adding a new kernel api for configuring the OA
> unit without needing to consider the possibility that userspace might
> trample on OACONTROL state which we'd like to start managing within
> the kernel instead. In particular running any Mesa based GL application
> currently results in clearing OACONTROL when initializing which would
> disable the capturing of metrics.
>
> Signed-off-by: Robert Bragg 
Okay, seems reasonable.

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

Re: [Intel-gfx] [PATCH v7 03/11] drm/i915: return EACCES for check_cmd() failures

[Matthew Auld]

On 25 October 2016 at 00:19, Robert Bragg  wrote:
> check_cmd() is checking whether a command adheres to certain
> restrictions that ensure it's safe to execute within a privileged batch
> buffer. Returning false implies a privilege problem, not that the
> command is invalid.
>
> The distinction makes the difference between allowing the buffer to be
> executed as an unprivileged batch buffer or returning an EINVAL error to
> userspace without executing anything.
>
> In a case where userspace may want to test whether it can successfully
> write to a register that needs privileges the distinction may be
> important and an EINVAL error may be considered fatal.
>
> In particular this is currently true for Mesa, which includes a test for
> whether OACONTROL can be written too, but Mesa treats any error when
> flushing a batch buffer as fatal, calling exit(1).
>
> As it is currently Mesa can gracefully handle a failure to write to
> OACONTROL if the command parser is disabled, but if we were to remove
> OACONTROL from the parser's whitelist then the returned EINVAL would
> break Mesa applications as they attempt an OACONTROL write.
>
> This bumps the command parser version from 7 to 8, as the change is
> visible to userspace.
>
> Signed-off-by: Robert Bragg 
Seems reasonable.

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

Re: [Intel-gfx] [PATCH] drm: Release reference from blob lookup after replacing property

[Chris Wilson]

On Tue, Oct 25, 2016 at 05:27:21PM -0400, Sean Paul wrote:
> On Tue, Oct 25, 2016 at 3:46 PM, Chris Wilson  
> wrote:
> > drm_property_lookup_blob() returns a reference to the returned blob, and
> > drm_atomic_replace_property_blob() takes a references to the blob it
> > stores, so afterwards we are left owning a reference to the new_blob that
> > we never release, and thus leak memory every time we update a property
> > such as during drm_atomic_helper_legacy_gamma_set().
> >
> > Based on a patch by Felix Monninger 
> >
> > Reported-by: Felix Monninger 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=98420
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 11 ---
> >  1 file changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 1b5a32df9a9a..3b35ab793100 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -416,19 +416,24 @@ drm_atomic_replace_property_blob_from_id(struct 
> > drm_crtc *crtc,
> >  ssize_t expected_size,
> >  bool *replaced)
> >  {
> > -   struct drm_device *dev = crtc->dev;
> > struct drm_property_blob *new_blob = NULL;
> >
> > if (blob_id != 0) {
> > -   new_blob = drm_property_lookup_blob(dev, blob_id);
> > +   new_blob = drm_property_lookup_blob(crtc->dev, blob_id);
> 
> I think this could be further simplified by making use of
> drm_property_lookup_blob() returning NULL for blob_id == 0
> 
> Then you could do something like:
> 
> static int
> drm_atomic_replace_property_blob_from_id(struct drm_crtc *crtc,
>  struct drm_property_blob **old_blob,
>  uint64_t blob_id,
>  ssize_t expected_size,
>  bool *replaced)
> {
> struct drm_property_blob *blob = NULL;
> int ret = 0;
> 
> blob = drm_property_lookup_blob(crtc->dev, blob_id);

Not sure. I think the orignal code would have been clearer as

blob = NULL;
if (id) {
blob = drm_property_lookup_blob(dev, id);
if (!blob)
return -ENOENT;

if (blob->length != expected_size)
return -EINVAL;
}

i.e. the code currently reports if the blob_id doesn't match an existing
blob, and only removes the current blob if passed in 0.

Otherwise it becomes like:

struct drm_property_blob *blob;
int ret = -EINVAL;

blob = drm_property_lookup_blob(crtc->dev, blob_id);
if (!blob_id || 
(blob && (expected_size == 0 || expected_size == blob->length))) {
drm_atomic_replace_property_blob(old_blob, blob, replaced);
ret = 0;
}
drm_property_unreference_blob(blob);

for which I'm actually favouring the existing code for the extra whitespace.

If we insisted on a single return path:

struct drm_property_blob *new_blob = NULL;
int ret = -EINVAL;

if (blob_id != 0) {
new_blob = drm_property_lookup_blob(crtc->dev, blob_id);
if (new_blob == NULL)
goto out;

if (expected_size > 0 && expected_size != new_blob->length)
goto out;
}

drm_atomic_replace_property_blob(blob, new_blob, replaced);
ret = 0;

out:
drm_property_unreference_blob(new_blob);
return ret;

-Chris

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

Re: [Intel-gfx] [PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

[Matthew Auld]

On 25 October 2016 at 00:19, Robert Bragg  wrote:
> Gen graphics hardware can be set up to periodically write snapshots of
> performance counters into a circular buffer via its Observation
> Architecture and this patch exposes that capability to userspace via the
> i915 perf interface.
>
> v2:
>Make sure to initialize ->specific_ctx_id when opening, without
>relying on _pin_notify hook, in case ctx already pinned.
> v3:
>Revert back to pinning ctx upfront when opening stream, removing
>need to hook in to pinning and to update OACONTROL on the fly.
>
> Cc: Chris Wilson 
> Signed-off-by: Robert Bragg 
> Signed-off-by: Zhenyu Wang 
>
> fix enable hsw
Random bit of cruft ?

> ---
>  drivers/gpu/drm/i915/i915_drv.h  |   65 ++-
>  drivers/gpu/drm/i915/i915_perf.c | 1000 
> +-
>  drivers/gpu/drm/i915/i915_reg.h  |  338 +
>  include/uapi/drm/i915_drm.h  |   70 ++-
>  4 files changed, 1444 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3448d05..ea24814 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1764,6 +1764,11 @@ struct intel_wm_config {
> bool sprites_scaled;
>  };
>
> +struct i915_oa_format {
> +   u32 format;
> +   int size;
> +};
> +
>  struct i915_oa_reg {
> i915_reg_t addr;
> u32 value;
> @@ -1784,11 +1789,6 @@ struct i915_perf_stream_ops {
>  */
> void (*disable)(struct i915_perf_stream *stream);
>
> -   /* Return: true if any i915 perf records are ready to read()
> -* for this stream.
> -*/
> -   bool (*can_read)(struct i915_perf_stream *stream);
> -
> /* Call poll_wait, passing a wait queue that will be woken
>  * once there is something ready to read() for the stream
>  */
> @@ -1798,9 +1798,7 @@ struct i915_perf_stream_ops {
>
> /* For handling a blocking read, wait until there is something
>  * to ready to read() for the stream. E.g. wait on the same
> -* wait queue that would be passed to poll_wait() until
> -* ->can_read() returns true (if its safe to call ->can_read()
> -* without the i915 perf lock held).
> +* wait queue that would be passed to poll_wait().
>  */
> int (*wait_unlocked)(struct i915_perf_stream *stream);
>
> @@ -1840,11 +1838,28 @@ struct i915_perf_stream {
> struct list_head link;
>
> u32 sample_flags;
> +   int sample_size;
>
> struct i915_gem_context *ctx;
> bool enabled;
>
> -   struct i915_perf_stream_ops *ops;
> +   const struct i915_perf_stream_ops *ops;
> +};
> +
> +struct i915_oa_ops {
> +   void (*init_oa_buffer)(struct drm_i915_private *dev_priv);
> +   int (*enable_metric_set)(struct drm_i915_private *dev_priv);
> +   void (*disable_metric_set)(struct drm_i915_private *dev_priv);
> +   void (*oa_enable)(struct drm_i915_private *dev_priv);
> +   void (*oa_disable)(struct drm_i915_private *dev_priv);
> +   void (*update_oacontrol)(struct drm_i915_private *dev_priv);
> +   void (*update_hw_ctx_id_locked)(struct drm_i915_private *dev_priv,
> +   u32 ctx_id);
> +   int (*read)(struct i915_perf_stream *stream,
> +   char __user *buf,
> +   size_t count,
> +   size_t *offset);
> +   bool (*oa_buffer_is_empty)(struct drm_i915_private *dev_priv);
>  };
>
>  struct drm_i915_private {
> @@ -2149,16 +2164,46 @@ struct drm_i915_private {
>
> struct {
> bool initialized;
> +
> struct mutex lock;
> struct list_head streams;
>
> +   spinlock_t hook_lock;
> +
> struct {
> -   u32 metrics_set;
> +   struct i915_perf_stream *exclusive_stream;
> +
> +   u32 specific_ctx_id;
Can we just get rid of this, now that the vma remains pinned we can
simply get the ggtt address at the time of configuring the OA_CONTROL
register ?

> +
> +   struct hrtimer poll_check_timer;
> +   wait_queue_head_t poll_wq;
> +   atomic_t pollin;
> +
> +   bool periodic;
> +   int period_exponent;
> +   int timestamp_frequency;
> +
> +   int tail_margin;
> +
> +   int metrics_set;
>
> const struct i915_oa_reg *mux_regs;
> int mux_regs_len;
> const struct i915_oa_reg *b_counter_regs;
> int b_counter_regs_len;
> +
> +   struct {
> +   struct i915_vma *vma;
> +

[Intel-gfx] [PATCH v2] drm: Release reference from blob lookup after replacing property

[Chris Wilson]

From: Felix Monninger 

drm_property_lookup_blob() returns a reference to the returned blob, and
drm_atomic_replace_property_blob() takes a references to the blob it
stores, so afterwards we are left owning a reference to the new_blob that
we never release, and thus leak memory every time we update a property
such as during drm_atomic_helper_legacy_gamma_set().

v2: update credentials, drm_property_unreference_blob() is NULL safe and
NULL is passed consistently to it throughout drm_atomic.c so do so here.

Reported-by: Felix Monninger 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98420
Signed-off-by: Felix Monninger 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_atomic.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 1b5a32df9a9a..e0760c138355 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -416,18 +416,21 @@ drm_atomic_replace_property_blob_from_id(struct drm_crtc 
*crtc,
 ssize_t expected_size,
 bool *replaced)
 {
-   struct drm_device *dev = crtc->dev;
struct drm_property_blob *new_blob = NULL;
 
if (blob_id != 0) {
-   new_blob = drm_property_lookup_blob(dev, blob_id);
+   new_blob = drm_property_lookup_blob(crtc->dev, blob_id);
if (new_blob == NULL)
return -EINVAL;
-   if (expected_size > 0 && expected_size != new_blob->length)
+
+   if (expected_size > 0 && expected_size != new_blob->length) {
+   drm_property_unreference_blob(new_blob);
return -EINVAL;
+   }
}
 
drm_atomic_replace_property_blob(blob, new_blob, replaced);
+   drm_property_unreference_blob(new_blob);
 
return 0;
 }
-- 
2.10.1

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

Re: [Intel-gfx] [PATCH] drm: Release reference from blob lookup after replacing property

[Sean Paul]

On Tue, Oct 25, 2016 at 3:46 PM, Chris Wilson  wrote:
> drm_property_lookup_blob() returns a reference to the returned blob, and
> drm_atomic_replace_property_blob() takes a references to the blob it
> stores, so afterwards we are left owning a reference to the new_blob that
> we never release, and thus leak memory every time we update a property
> such as during drm_atomic_helper_legacy_gamma_set().
>
> Based on a patch by Felix Monninger 
>
> Reported-by: Felix Monninger 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=98420
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/drm_atomic.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 1b5a32df9a9a..3b35ab793100 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -416,19 +416,24 @@ drm_atomic_replace_property_blob_from_id(struct 
> drm_crtc *crtc,
>  ssize_t expected_size,
>  bool *replaced)
>  {
> -   struct drm_device *dev = crtc->dev;
> struct drm_property_blob *new_blob = NULL;
>
> if (blob_id != 0) {
> -   new_blob = drm_property_lookup_blob(dev, blob_id);
> +   new_blob = drm_property_lookup_blob(crtc->dev, blob_id);

I think this could be further simplified by making use of
drm_property_lookup_blob() returning NULL for blob_id == 0

Then you could do something like:

static int
drm_atomic_replace_property_blob_from_id(struct drm_crtc *crtc,
 struct drm_property_blob **old_blob,
 uint64_t blob_id,
 ssize_t expected_size,
 bool *replaced)
{
struct drm_property_blob *blob = NULL;
int ret = 0;

blob = drm_property_lookup_blob(crtc->dev, blob_id);
if (blob && expected_size > 0 && expected_size != blob->length) {
ret = -EINVAL;
goto out;
}
}

drm_atomic_replace_property_blob(blob, blob, replaced);
out:
drm_property_unreference_blob(blob);
return 0;
}

> if (new_blob == NULL)
> return -EINVAL;
> -   if (expected_size > 0 && expected_size != new_blob->length)
> +
> +   if (expected_size > 0 && expected_size != new_blob->length) {
> +   drm_property_unreference_blob(new_blob);
> return -EINVAL;
> +   }
> }
>
> drm_atomic_replace_property_blob(blob, new_blob, replaced);
>
> +   if (new_blob)
> +   drm_property_unreference_blob(new_blob);
> +
> return 0;
>  }
>
> --
> 2.10.1
>
> ___
> 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 i-g-t 1/3 v2] lib/{igt_sysfs, igt_aux}: Make available to other users kick_fbcon() (unbind_fbcon()), and added helpers to igt_aux.

[Chris Wilson]

On Tue, Oct 25, 2016 at 11:44:36PM +0300, Marius Vlad wrote:
> +int
> +igt_pkill(int sig, const char *comm)
> +{
> + int err = 0;
> + PROCTAB *proc;
> + proc_t *proc_info;
> +
> + proc = openproc(PROC_FILLCOM | PROC_FILLSTAT | PROC_FILLARG);
> + igt_assert(proc != NULL);
> +
> + while ((proc_info = readproc(proc, NULL))) {
> + if (!strncasecmp(proc_info->cmd, comm, sizeof(proc_info->cmd))) 
> {
> +
> + if (kill(proc_info->tid, sig) < 0)
> + err = -1;

err = -errno;

(we like to keep kernel conventions where nicely applicable)

> +
> + freeproc(proc_info);
> + break;
> + }
> + freeproc(proc_info);
> + }
> +
> + closeproc(proc);
> + return err;
> +}

> +int

bool

> +igt_kmod_is_loaded(const char *mod_name)
> +{
> + struct kmod_list *mod, *list;
> + struct kmod_ctx *ctx;
> + int ret = 0;
> +
> + ctx = kmod_new(NULL, NULL);
> + igt_assert(ctx != NULL);
> +
> + if (kmod_module_new_from_loaded(ctx, ) < 0) {
> + kmod_unref(ctx);
> + return -1;

Too confusing! :)

if (kmod_module_new_from_loaded(ctx, ) < 0)
goto out;

> + }
> +
> + kmod_list_foreach(mod, list) {
> + struct kmod_module *kmod = kmod_module_get_module(mod);
> + const char *kmod_name = kmod_module_get_name(kmod);
> +
> + if (!strncasecmp(kmod_name, mod_name, strlen(kmod_name))) {

strncasecmp? So what happens if we load i915 and I915_bpo ?

> + kmod_module_unref(kmod);
> + ret = 1;
> + break;
> + }
> + kmod_module_unref(kmod);
> + }
> +
> + kmod_module_unref_list(list);

out:
> + kmod_unref(ctx);
> +
> + return ret;
> +}

> +int
> +igt_kmod_load(const char *mod_name, const char *opts)
> +{
> + struct kmod_ctx *ctx;
> + struct kmod_module *kmod;
> + int err = 0;
> +
> + ctx = kmod_new(NULL, NULL);
> + igt_assert(ctx != NULL);
> +
> +
> + err = kmod_module_new_from_name(ctx, mod_name, );
> + if (err < 0) {
> + goto out;
> + }
> +
> + err = kmod_module_insert_module(kmod, 0, opts);
> + if (err < 0) {
> + switch (err) {
> + case -EEXIST:
> + igt_info("Module %s already inserted\n",
> +  kmod_module_get_name(kmod));
> + err = -1;

Don't reduce the information, just return err; (as elsewhere)

Not sure if igt_info() makes sense, it will be noise for those expecting
and handling the error.

> + break;
> + case -ENOENT:
> + igt_info("Unknown symbol in module %s or "
> +  "unknown parameter\n",
> +  kmod_module_get_name(kmod));
> + err = -1;
> + break;
> + default:
> + igt_info("Could not insert %s (%s)\n",
> +  kmod_module_get_name(kmod), strerror(-err));
> + err = -1;
> + break;
> + }
> + }
> +out:
> + kmod_module_unref(kmod);
> + kmod_unref(ctx);
> +
> + return err;
> +}
> +

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

Re: [Intel-gfx] [PATCH v2] drm/i915: fix comment on I915_{READ, WRITE}_FW

[Chris Wilson]

On Tue, Oct 25, 2016 at 02:48:02PM +0200, Arkadiusz Hiler wrote:
> Comment mentioned use of intel_uncore_forcewake_irq{unlock, lock}
> functions which are nonexistent (and never were).
> 
> The description was also incomplete and could cause confusion. Updated
> comment is more elaborate on usage and caveats.
> 
> v2: mention __locked variant of intel_uncore_forcewake_{get,put} instead
> of plain ones
> 
> Cc: Chris Wilson 
> Cc: Matthew Auld 
> Cc: Mika Kuoppala 
> Signed-off-by: Arkadiusz Hiler 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 28 +---
>  1 file changed, 25 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index b4cb1f0..e0f3fa4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3840,11 +3840,33 @@ __raw_write(64, q)
>  #undef __raw_write
>  
>  /* These are untraced mmio-accessors that are only valid to be used inside
> - * critical sections inside IRQ handlers where forcewake is explicitly
> + * critical sections, such as inside IRQ handlers, where forcewake is 
> explicitly
>   * controlled.
> + *
>   * Think twice, and think again, before using these.
> - * Note: Should only be used between intel_uncore_forcewake_irqlock() and
> - * intel_uncore_forcewake_irqunlock().
> + *
> + * As an example, these accessors can possibly be used between:
> + *
> + * spin_lock_irq(_priv->uncore.lock);
> + * intel_uncore_forcewake_get__locked();
> + *
> + * and
> + *
> + * intel_uncore_forcewake_put__locked();
> + * spin_unlock_irq(_priv->uncore.lock);
> + *
> + *
> + * Note: some registers may not need forcewake held, so
> + * intel_uncore_forcewake_{get,put} can be omitted, see
> + * intel_uncore_forcewake_for_reg().
> + *
> + * Certain architectures will die if the same cacheline is concurrently 
> accessed
> + * by different clients (e.g. Ivybridge). Access to registers should 
> therefore

e.g. on Ivybridge

> + * generally be serialised, by either the dev_priv->uncore.lock or a more
> + * localised lock guarding all access to that bank of registers.
> + *
> + * Code may be serialised by different lock, so immediate
> + * spin_{lock,unlock}_irq() may not be necessary.

This last sentence is redundant since the reason why we need some lock
somewhere is given above.

With that,

Reviewed-by: Chris Wilson 
-Chris

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

[Intel-gfx] [PATCH i-g-t 2/3 v2] tests/drv_module_reload: Convert sh script to C version.

[Marius Vlad]

v2:
- embedded gem_alive and gem_exec_store into test (Chris Wilson)
- int main() to igt_main (Chris Wilson)
- moved tests/gem_alive -> tools/gem_info (Chris Wilson)
- added to intel-ci/fast-feedback.testlist (Petri Latvala)
- added hda_dynamic_debug() (Petri Latvala)
- renamed from tests/drv_module_reload_basic to tests/drv_module_reload
(all subtests are basic and have been added to fast-feedback.testlist)

Signed-off-by: Marius Vlad 
---
 tests/Makefile.am |   1 -
 tests/Makefile.sources|   2 +-
 tests/drv_module_reload.c | 394 ++
 tests/drv_module_reload_basic | 105 -
 tests/gem_alive.c |  35 ---
 tests/intel-ci/fast-feedback.testlist |  13 +-
 tools/Makefile.sources|   1 +
 tools/intel_gem_info.c|  35 +++
 8 files changed, 443 insertions(+), 143 deletions(-)
 create mode 100644 tests/drv_module_reload.c
 delete mode 100755 tests/drv_module_reload_basic
 delete mode 100644 tests/gem_alive.c
 create mode 100644 tools/intel_gem_info.c

diff --git a/tests/Makefile.am b/tests/Makefile.am
index a408126..14a41ae 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -26,7 +26,6 @@ noinst_PROGRAMS = \
$(NULL)
 
 pkglibexec_PROGRAMS = \
-   gem_alive \
gem_stress \
$(TESTS_progs) \
$(TESTS_progs_M) \
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 6d081c3..b1511c6 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -211,6 +211,7 @@ TESTS_progs = \
kms_pwrite_crc \
kms_sink_crc_basic \
prime_udl \
+   drv_module_reload \
$(NULL)
 
 # IMPORTANT: The ZZ_ tests need to be run last!
@@ -221,7 +222,6 @@ TESTS_scripts_M = \
 TESTS_scripts = \
debugfs_emon_crash \
drv_debugfs_reader \
-   drv_module_reload_basic \
kms_sysfs_edid_timing \
sysfs_l3_parity \
test_rte_check \
diff --git a/tests/drv_module_reload.c b/tests/drv_module_reload.c
new file mode 100644
index 000..cd03bbf
--- /dev/null
+++ b/tests/drv_module_reload.c
@@ -0,0 +1,394 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * 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_debugfs.h"
+#include "igt_aux.h"
+#include "igt_sysfs.h"
+#include "igt_core.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define LOCAL_I915_EXEC_BSD_SHIFT  (13)
+#define LOCAL_I915_EXEC_BSD_MASK   (3 << LOCAL_I915_EXEC_BSD_SHIFT)
+
+#define ENGINE_MASK  (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
+
+static void store_dword(int fd, unsigned ring)
+{
+   const int gen = intel_gen(intel_get_drm_devid(fd));
+   struct drm_i915_gem_exec_object2 obj[2];
+   struct drm_i915_gem_relocation_entry reloc;
+   struct drm_i915_gem_execbuffer2 execbuf;
+   uint32_t batch[16];
+   int i;
+
+   gem_require_ring(fd, ring);
+   igt_skip_on_f(gen == 6 && (ring & ~(3<<13)) == I915_EXEC_BSD,
+ "MI_STORE_DATA broken on gen6 bsd\n");
+
+   intel_detect_and_clear_missed_interrupts(fd);
+   memset(, 0, sizeof(execbuf));
+   execbuf.buffers_ptr = (uintptr_t)obj;
+   execbuf.buffer_count = 2;
+   execbuf.flags = ring;
+   if (gen < 6)
+   execbuf.flags |= I915_EXEC_SECURE;
+
+   memset(obj, 0, sizeof(obj));
+   obj[0].handle = gem_create(fd, 4096);
+   obj[1].handle = gem_create(fd, 4096);
+
+   memset(, 0, sizeof(reloc));
+   reloc.target_handle = obj[0].handle;
+   reloc.presumed_offset = 0;
+   reloc.offset = sizeof(uint32_t);
+   reloc.delta = 0;
+   reloc.read_domains = I915_GEM_DOMAIN_INSTRUCTION;
+   reloc.write_domain = I915_GEM_DOMAIN_INSTRUCTION;
+   obj[1].relocs_ptr = 

[Intel-gfx] [PATCH i-g-t 3/3 v3] tests/kms_sysfs_edid_timing: Convert sh to C version.

[Marius Vlad]

v2:
- don't read cached values (Chris Wilson)
- warn on per connector, and fail per mean (Chris Wilson)

These are synthetic: 5us per connector, and 600us for all (as
threshold).

Signed-off-by: Marius Vlad 
---
 tests/Makefile.sources|   2 +-
 tests/kms_sysfs_edid_timing   |  25 --
 tests/kms_sysfs_edid_timing.c | 107 ++
 3 files changed, 108 insertions(+), 26 deletions(-)
 delete mode 100755 tests/kms_sysfs_edid_timing
 create mode 100644 tests/kms_sysfs_edid_timing.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index b1511c6..8af455a 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -212,6 +212,7 @@ TESTS_progs = \
kms_sink_crc_basic \
prime_udl \
drv_module_reload \
+   kms_sysfs_edid_timing \
$(NULL)
 
 # IMPORTANT: The ZZ_ tests need to be run last!
@@ -222,7 +223,6 @@ TESTS_scripts_M = \
 TESTS_scripts = \
debugfs_emon_crash \
drv_debugfs_reader \
-   kms_sysfs_edid_timing \
sysfs_l3_parity \
test_rte_check \
tools_test \
diff --git a/tests/kms_sysfs_edid_timing b/tests/kms_sysfs_edid_timing
deleted file mode 100755
index 46ea540..000
--- a/tests/kms_sysfs_edid_timing
+++ /dev/null
@@ -1,25 +0,0 @@
-#!/bin/bash
-#
-# 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
-#
-
-DRM_LIB_ALLOW_NO_MASTER=1
-
-SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
-. $SOURCE_DIR/drm_lib.sh
-
-TIME1=$(date +%s%N)
-cat $(find /sys/devices/|grep drm | grep /status) > /dev/null
-TIME2=$(date +%s%N)
-
-# time in ms
-RES=$(((TIME2 - TIME1) / 100))
-
-if [ $RES -gt 600 ]; then
-   echo "Talking to outputs took ${RES}ms, something is wrong"
-   exit $IGT_EXIT_FAILURE
-fi
-
-exit $IGT_EXIT_SUCCESS
diff --git a/tests/kms_sysfs_edid_timing.c b/tests/kms_sysfs_edid_timing.c
new file mode 100644
index 000..3b8bca0
--- /dev/null
+++ b/tests/kms_sysfs_edid_timing.c
@@ -0,0 +1,107 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * 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_debugfs.h"
+#include "igt_sysfs.h"
+#include "igt_core.h"
+
+#include 
+#include 
+#include 
+#include 
+
+#define USEC_PER_SEC   (1000*1000)
+#define THRESHOLD_PER_CONNECTOR5
+#define THRESHOLD_TOTAL600
+
+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");
+
+static uint64_t
+mean(uint64_t *a, size_t a_len)
+{
+   int p;
+   uint64_t __sum;
+
+   for (p = 0, __sum = 0; p < a_len; p++) {
+   __sum += a[p];
+   }
+
+   return (__sum / a_len);
+}
+
+igt_simple_main
+{
+   int dir = igt_sysfs_open(-1, NULL);
+   DIR *dirp = fdopendir(dir);
+   struct dirent *de;
+
+   int i, fd = 0;
+   int fds[32];
+
+   uint64_t elapsed, elapsed_mean;
+   uint64_t a[32];
+
+   struct stat st;
+   struct timespec start = {};
+
+   memset(fds, -1, sizeof(fds));
+   memset(a, -1, sizeof(a));
+
+   while ((de = readdir(dirp))) {
+
+   if (*de->d_name == '.')
+   continue;
+
+   if (fstatat(dir, de->d_name, , 0))
+   continue;
+
+   if (S_ISDIR(st.st_mode) && !strncmp(de->d_name, "card0-", 6)) {
+   int dfd = openat(dir, 

[Intel-gfx] [PATCH i-g-t 0/3 v2] Convert sh scripts to C variants.

[Marius Vlad]

This series adds some library support to help converting sh scripts to C
version. Based on that I've converted drv_module_reload_basic and
kms_sysfs_edid_timing.  Other tests should follow. drv_module_reload requires
the most boilerplate code.

The reason for so many changes is the fact that some code got moved so other
users can use it. Secondly wrappers around libkmod and procps in igt_aux.
Thirdly drv_module_reload has embedded tools/gem_info and tests/gem_exec_store
in it, with minor modifications to allow running them as subtests. Finally, C
is more verbose than sh.

Changes since v1:
lib/igt_aux: Addressed comments from Chris Wilson
tests/drv_module_reload: Addressed comments from Chris Wilson and Petri Latvala
tests/kms_sysfs_edid_timing: Addressed comments from Chris Wilson
(Hopefully): Addressed comments from Jani Nikula.


Marius Vlad (3):
  lib/{igt_sysfs,igt_aux}: Make available to other users kick_fbcon()
(unbind_fbcon()), and added helpers to igt_aux
(module loading/unloading, pkill)
  tests/drv_module_reload: Convert sh script to C version.
  tests/kms_sysfs_edid_timing: Convert sh to C version.

 configure.ac  |   2 +
 lib/Makefile.am   |   2 +
 lib/igt_aux.c | 185 
 lib/igt_aux.h |   6 +
 lib/igt_gvt.c |  43 +---
 lib/igt_sysfs.c   |  54 +
 lib/igt_sysfs.h   |   2 +
 tests/Makefile.am |   1 -
 tests/Makefile.sources|   4 +-
 tests/drv_module_reload.c | 394 ++
 tests/drv_module_reload_basic | 105 -
 tests/gem_alive.c |  35 ---
 tests/intel-ci/fast-feedback.testlist |  13 +-
 tests/kms_sysfs_edid_timing   |  25 ---
 tests/kms_sysfs_edid_timing.c | 107 +
 tools/Makefile.sources|   1 +
 tools/intel_gem_info.c|  35 +++
 17 files changed, 804 insertions(+), 210 deletions(-)
 create mode 100644 tests/drv_module_reload.c
 delete mode 100755 tests/drv_module_reload_basic
 delete mode 100644 tests/gem_alive.c
 delete mode 100755 tests/kms_sysfs_edid_timing
 create mode 100644 tests/kms_sysfs_edid_timing.c
 create mode 100644 tools/intel_gem_info.c

-- 
2.7.4

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

[Intel-gfx] [PATCH i-g-t 1/3 v2] lib/{igt_sysfs, igt_aux}: Make available to other users kick_fbcon() (unbind_fbcon()), and added helpers to igt_aux.

[Marius Vlad]

Previously under unbind_fbcon(), to disable/enable framebuffer console.

lib/igt_aux: Added helpers to help convert sh scripts to C version. libkmod
and procps interface.

v2:
- Renamed libkmod helpers (Chris Wilson)
- Removed SIGTERM/SIGKILL case where we repeatedly tried to terminate the
process: just call kill(2) once (Chris Wilson)
- Removed redundant check in igt_kmod_unload(), igt_module_in_use() (Chris
Wilson)
- Pass flags to igt_kmod_unload() from the caller (Chris Wilson)
- Removed useless function igt_kill() which acts just as kill(2) (Chris
Wilson)

Signed-off-by: Marius Vlad 
---
 configure.ac|   2 +
 lib/Makefile.am |   2 +
 lib/igt_aux.c   | 185 
 lib/igt_aux.h   |   6 ++
 lib/igt_gvt.c   |  43 +
 lib/igt_sysfs.c |  54 +
 lib/igt_sysfs.h |   2 +
 7 files changed, 253 insertions(+), 41 deletions(-)

diff --git a/configure.ac b/configure.ac
index 735cfd5..2c6e49d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -121,6 +121,8 @@ AC_SUBST(ASSEMBLER_WARN_CFLAGS)
 
 PKG_CHECK_MODULES(DRM, [libdrm])
 PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
+PKG_CHECK_MODULES(KMOD, [libkmod])
+PKG_CHECK_MODULES(PROCPS, [libprocps])
 
 case "$target_cpu" in
x86*|i?86)
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 4c0893d..e1737bd 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -34,6 +34,8 @@ AM_CFLAGS += $(CAIRO_CFLAGS)
 libintel_tools_la_LIBADD = \
$(DRM_LIBS) \
$(PCIACCESS_LIBS) \
+   $(PROCPS_LIBS) \
+   $(KMOD_LIBS) \
$(CAIRO_LIBS) \
$(LIBUDEV_LIBS) \
$(LIBUNWIND_LIBS) \
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 421f6d4..9e94315 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -51,6 +51,9 @@
 #include 
 #include 
 
+#include 
+#include 
+
 #include "drmtest.h"
 #include "i915_drm.h"
 #include "intel_chipset.h"
@@ -1193,6 +1196,188 @@ void igt_set_module_param_int(const char *name, int val)
igt_set_module_param(name, str);
 }
 
+/**
+ * igt_pkill:
+ * @sig: Signal to send
+ * @name: Name of process in the form found in /proc/pid/comm (limited to 15
+ * chars)
+ * @returns: 0 in case the process is not found running or the signal has been
+ * sent successfully or -1 otherwise.
+ *
+ * This function sends the signal @sig for a process found in process table
+ * with name @comm.
+ */
+int
+igt_pkill(int sig, const char *comm)
+{
+   int err = 0;
+   PROCTAB *proc;
+   proc_t *proc_info;
+
+   proc = openproc(PROC_FILLCOM | PROC_FILLSTAT | PROC_FILLARG);
+   igt_assert(proc != NULL);
+
+   while ((proc_info = readproc(proc, NULL))) {
+   if (!strncasecmp(proc_info->cmd, comm, sizeof(proc_info->cmd))) 
{
+
+   if (kill(proc_info->tid, sig) < 0)
+   err = -1;
+
+   freeproc(proc_info);
+   break;
+   }
+   freeproc(proc_info);
+   }
+
+   closeproc(proc);
+   return err;
+}
+
+/**
+ * igt_kmod_is_loaded:
+ * @mod_name: The name of the module.
+ * @returns: True in case the module has been found or false otherwise.
+ *
+ *
+ * Function to check the existance of module @mod_name in list of loaded kernel
+ * modules.
+ *
+ */
+int
+igt_kmod_is_loaded(const char *mod_name)
+{
+   struct kmod_list *mod, *list;
+   struct kmod_ctx *ctx;
+   int ret = 0;
+
+   ctx = kmod_new(NULL, NULL);
+   igt_assert(ctx != NULL);
+
+   if (kmod_module_new_from_loaded(ctx, ) < 0) {
+   kmod_unref(ctx);
+   return -1;
+   }
+
+   kmod_list_foreach(mod, list) {
+   struct kmod_module *kmod = kmod_module_get_module(mod);
+   const char *kmod_name = kmod_module_get_name(kmod);
+
+   if (!strncasecmp(kmod_name, mod_name, strlen(kmod_name))) {
+   kmod_module_unref(kmod);
+   ret = 1;
+   break;
+   }
+   kmod_module_unref(kmod);
+   }
+
+   kmod_module_unref_list(list);
+   kmod_unref(ctx);
+
+   return ret;
+}
+
+/**
+ * igt_kmod_load:
+ * @mod_name: The name of the module
+ * @opts: Parameters for the module. NULL in case no parameters
+ * are to be passed, or a '\0' terminated string otherwise.
+ * @returns: 0 in case of success or -1 in case the module could not
+ * be loaded.
+ *
+ * This function loads a kernel module using the name specified in @mod_name.
+ *
+ * @Note: This functions doesn't automatically resolve other module
+ * dependencies so make make sure you load the dependencies module(s) before
+ * this one.
+ */
+int
+igt_kmod_load(const char *mod_name, const char *opts)
+{
+   struct kmod_ctx *ctx;
+   struct kmod_module *kmod;
+   int err = 0;
+
+   ctx = kmod_new(NULL, NULL);
+   igt_assert(ctx != NULL);
+
+
+   err = kmod_module_new_from_name(ctx, 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Release reference from blob lookup after replacing property

[Patchwork]

== Series Details ==

Series: drm: Release reference from blob lookup after replacing property
URL   : https://patchwork.freedesktop.org/series/14357/
State : success

== Summary ==

Series 14357v1 drm: Release reference from blob lookup after replacing property
https://patchwork.freedesktop.org/api/1.0/series/14357/revisions/1/mbox/


fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:219  dwarn:4   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

9e8e859eec7e29c4ef33413560819617a7f9f6bf drm-intel-nightly: 
2016y-10m-25d-16h-30m-11s UTC integration manifest
315860c drm: Release reference from blob lookup after replacing property

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2816/

== Logs ==

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

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: WA to address the Ringbuffer coherency issue

[Chris Wilson]

On Tue, Oct 25, 2016 at 10:05:23PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel 
> 
> Driver accesses the ringbuffer pages, via GMADR BAR, if the pages are
> pinned in mappable aperture portion of GGTT and for ringbuffer pages
> allocated from Stolen memory, access can only be done through GMADR BAR.
> In case of GuC based submission, updates done in ringbuffer via GMADR
> may not get committed to memory by the time the Command streamer starts
> reading them, resulting in fetching of stale data.
> 
> For Host based submission, such problem is not there as the write to Ring
> Tail or ELSP register happens from the Host side prior to submission.
> Access to any GFX register from CPU side goes to GTTMMADR BAR and Hw already
> enforces the ordering between outstanding GMADR writes & new GTTMADR access.
> MMIO writes from GuC side do not go to GTTMMADR BAR as GuC communication to
> registers within GT is contained within GT, so ordering is not enforced
> resulting in a race, which can manifest in form of a hang.
> 
> To ensure the flush of in-flight GMADR writes, a POSTING READ is done to
> GuC register prior to doorbell ring.
> There is already a similar WA in i915_gem_object_flush_gtt_write_domain(),
> which takes care of GMADR writes from User space to GEM buffers, but not the
> ringbuffer writes from KMD.
> This WA is needed on all recent HW.
> 
> v2:
> - Use POSTING_READ_FW instead of POSTING_READ as GuC register do not lie
>   in any forcewake domain range and so the overhead of spinlock & search
>   in the forcewake table is avoidable. (Chris)
> 
> Cc: Chris Wilson 
> Signed-off-by: Sagar Arun Kamble 
> Signed-off-by: Akash Goel 

Thanks for respinning, reviewed and pushed.
-Chris

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

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Rotated view does not need a fence

[Chris Wilson]

On Tue, Oct 25, 2016 at 05:40:35PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> We do not need to set up a fence for the rotated view.
> 
> Display does not need it and no one can access it.
> 
> v2: Move code to __i915_vma_set_map_and_fenceable. (Chris Wilson)
> 
> Signed-off-by: Tvrtko Ursulin 
> Fixes: 05a20d098db1 ("drm/i915: Move map-and-fenceable tracking to the VMA")
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 9361c7b54a7f..eb524bdf0c35 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3790,7 +3790,12 @@ void __i915_vma_set_map_and_fenceable(struct i915_vma 
> *vma)
>   mappable = (vma->node.start + fence_size <=
>   dev_priv->ggtt.mappable_end);
>  
> - if (mappable && fenceable)
> + /*
> +  * Explicitly disable for rotated VMA since the display does not
> +  * need the fence and the VMA is not accessible to other users.
> +  */
> + if (mappable && fenceable &&
> + vma->ggtt_view.type != I915_GGTT_VIEW_ROTATED)
>   vma->flags |= I915_VMA_CAN_FENCE;
>   else
>   vma->flags &= ~I915_VMA_CAN_FENCE;

Penciled i915_vma_is_rotated() onto the todo list.

Reviewed-by: Chris Wilson 
-Chris

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

[Intel-gfx] [PATCH] drm: Release reference from blob lookup after replacing property

[Chris Wilson]

drm_property_lookup_blob() returns a reference to the returned blob, and
drm_atomic_replace_property_blob() takes a references to the blob it
stores, so afterwards we are left owning a reference to the new_blob that
we never release, and thus leak memory every time we update a property
such as during drm_atomic_helper_legacy_gamma_set().

Based on a patch by Felix Monninger 

Reported-by: Felix Monninger 
References: https://bugs.freedesktop.org/show_bug.cgi?id=98420
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_atomic.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 1b5a32df9a9a..3b35ab793100 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -416,19 +416,24 @@ drm_atomic_replace_property_blob_from_id(struct drm_crtc 
*crtc,
 ssize_t expected_size,
 bool *replaced)
 {
-   struct drm_device *dev = crtc->dev;
struct drm_property_blob *new_blob = NULL;
 
if (blob_id != 0) {
-   new_blob = drm_property_lookup_blob(dev, blob_id);
+   new_blob = drm_property_lookup_blob(crtc->dev, blob_id);
if (new_blob == NULL)
return -EINVAL;
-   if (expected_size > 0 && expected_size != new_blob->length)
+
+   if (expected_size > 0 && expected_size != new_blob->length) {
+   drm_property_unreference_blob(new_blob);
return -EINVAL;
+   }
}
 
drm_atomic_replace_property_blob(blob, new_blob, replaced);
 
+   if (new_blob)
+   drm_property_unreference_blob(new_blob);
+
return 0;
 }
 
-- 
2.10.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix SKL+ 90/270 degree rotated plane coordinate computation

[Paulo Zanoni]

Em Seg, 2016-10-24 às 19:13 +0300, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä 
> 
> Pass the framebuffer size in .16 fixed point coordinates to
> drm_rect_rotate() since that's what the source coordinates are as
> well
> at this stage. We used to do this part of the computation in integer
> coordinates, but that got changed when moving the computation to
> happen in the check phase of the operation. Unfortunately I forgot
> to shift up the fb width and height appropriately.
> 
> With the bogus size we ended up with some negative fb offset, which
> when
> added to the vma offset caused out scanout to start at an offset
> earlier
> than we inteded. Eg. when testing on my SKL I saw a row of incorrect
> tiles at the top of my screen.

I already mentioned this while reviewing another patch from another
author, but let's throw the idea again: how about adding a specific
16.16 type in order to prevent these silent failures when mixing them
with integers?

struct (or union) int_fixed_16_16 {
uint32_t number;
}

And them some nice macros for explicit casting to/from int.

I see include/drm/fixed.h even has a 20_12 type...

I could even volunteer to do this if there's some positive feedback
upfront, but feel free to do this too in case you want.

We're humans and we're going to make the same "mix normal integers with
16.16 integers" mistake again and again and again, while the compiler
could really help us if the types were not plain integers.

Thoughts?

> 
> Cc: Tvrtko Ursulin 
> Cc: Sivakumar Thulasimani 
> Cc: drm-intel-fi...@lists.freedesktop.org
> Fixes: b63a16f6cd89 ("drm/i915: Compute display surface offset in the
> plane check hook for SKL+")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 5a036999487b..c783f884f85d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2985,7 +2985,8 @@ int skl_check_plane_surface(struct
> intel_plane_state *plane_state)
>   /* Rotate src coordinates to match rotated GTT view */
>   if (drm_rotation_90_or_270(rotation))
>   drm_rect_rotate(_state->base.src,
> - fb->width, fb->height,
> DRM_ROTATE_270);
> + fb->width << 16, fb->height << 16,
> + DRM_ROTATE_270);
>  
>   /*
>    * Handle the AUX surface first since
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Link Rate fallback on Link training failure

[Manasi Navare]

On Tue, Oct 25, 2016 at 03:17:47PM +0300, Jani Nikula wrote:
> On Sat, 22 Oct 2016, Manasi Navare  wrote:
> > If link training at a link rate optimal for a particular
> > mode fails during modeset's atomic commit phase, then we
> > let the modeset complete and then retry. We save the link rate
> > value at which link training failed and use a lower link rate
> > to prune the modes. It will redo the modeset on the current mode
> > at lower link rate or if the current mode gets pruned due to lower
> > link constraints then, it will send a hotplug uevent for userspace
> > to handle it.
> >
> > This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
> > 4.3.1.6.
> >
> > Cc: Jani Nikula 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjala 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c  | 15 +-
> >  drivers/gpu/drm/i915/intel_dp.c   | 69 
> > ++-
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 12 +++--
> >  drivers/gpu/drm/i915/intel_drv.h  |  6 ++-
> >  4 files changed, 95 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index fb18d69..451433b 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1712,6 +1712,8 @@ static void intel_ddi_pre_enable_dp(struct 
> > intel_encoder *encoder,
> > struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > enum port port = intel_ddi_get_encoder_port(encoder);
> > +   struct intel_connector *intel_connector = intel_dp->attached_connector;
> > +   struct drm_connector *connector = _connector->base;
> >  
> > intel_dp_set_link_params(intel_dp, link_rate, lane_count,
> >  link_mst);
> > @@ -1722,7 +1724,18 @@ static void intel_ddi_pre_enable_dp(struct 
> > intel_encoder *encoder,
> > intel_prepare_dp_ddi_buffers(encoder);
> > intel_ddi_init_dp_buf_reg(encoder);
> > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > -   intel_dp_start_link_train(intel_dp);
> > +   if (!intel_dp_start_link_train(intel_dp)) {
> > +   DRM_ERROR("Link Training failed at link rate = %d, lane count = 
> > %d\n",
> > + link_rate, lane_count);
> > +   intel_dp->link_train_failed = true;
> > +   intel_dp->link_train_failed_link_rate = link_rate;
> > +   intel_dp->link_train_failed_lane_count = lane_count;
> 
> I think eventually you'll need to store a list (array) of failing link
> rate, lane count pairs, not just the last that failed. Now you restrict
> the link config computation to only reducing the link rate. But
> currently (for whatever reason, it's flip-flopped too many times) we
> start with wide & slow, meaning that in many cases we've already
> exhausted the option to go slower. If optimal fails, maybe we need to
> try narrow & fast instead.
> 
> BR,
> Jani.
> 
>

So the DP 1.2 spec says that we need to first try reducing the link rate
all the way to RBR without reducing the lane count and if that fails then
just fail the link training. DP spec 1.3 also reduces the lane count after
reducing the link rate all the way to RBR, then it should try lower
lane count and highest link rate again. But I havent expanded this to include
spec 1.3 yet, this can be added later. The DP compliance only follows
CTS according tO DP Spec 1.2 and they would be including lane count
reduction later for CTS 1.3.

But in either case I dont think we need an array, at link train failure, we 
just need to know
the failed link rate and lane count based on which the next lower link rate/lane
count value can be decided here during mode validation and be used during
compute config. 

Manasi
> > +   /* Schedule a Hotplug Uevent to userspace to start modeset */
> > +   schedule_work(>i915_modeset_retry_work);
> > +   } else {
> > +   intel_dp->link_train_failed = false;
> > +   }
> > +
> > if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> > intel_dp_stop_link_train(intel_dp);
> >  }
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index c192e18..5d5f4a7 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -313,6 +313,7 @@ static int intel_dp_link_rate_index(struct intel_dp 
> > *intel_dp,
> > int target_clock = mode->clock;
> > int max_rate, mode_rate, max_lanes, max_link_clock;
> > int max_dotclk;
> > +   int common_rates[DP_MAX_SUPPORTED_RATES] = {};
> >  
> > max_dotclk = intel_dp_downstream_max_dotclock(intel_dp);
> >  
> > @@ -326,8 +327,27 @@ static int intel_dp_link_rate_index(struct intel_dp 
> > *intel_dp,
> > target_clock = 

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Link Rate fallback on Link training failure

[Manasi Navare]

On Mon, Oct 24, 2016 at 11:23:39PM -0700, Pandiyan, Dhinakaran wrote:
> On Fri, 2016-10-21 at 16:45 -0700, Manasi Navare wrote:
> > If link training at a link rate optimal for a particular
> > mode fails during modeset's atomic commit phase, then we
> > let the modeset complete and then retry. We save the link rate
> > value at which link training failed and use a lower link rate
> > to prune the modes. It will redo the modeset on the current mode
> > at lower link rate or if the current mode gets pruned due to lower
> > link constraints then, it will send a hotplug uevent for userspace
> > to handle it.
> > 
> > This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
> > 4.3.1.6.
> > 
> > Cc: Jani Nikula 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjala 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c  | 15 +-
> >  drivers/gpu/drm/i915/intel_dp.c   | 69 
> > ++-
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 12 +++--
> >  drivers/gpu/drm/i915/intel_drv.h  |  6 ++-
> >  4 files changed, 95 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index fb18d69..451433b 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1712,6 +1712,8 @@ static void intel_ddi_pre_enable_dp(struct 
> > intel_encoder *encoder,
> > struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > enum port port = intel_ddi_get_encoder_port(encoder);
> > +   struct intel_connector *intel_connector = intel_dp->attached_connector;
> > +   struct drm_connector *connector = _connector->base;
> >  
> > intel_dp_set_link_params(intel_dp, link_rate, lane_count,
> >  link_mst);
> > @@ -1722,7 +1724,18 @@ static void intel_ddi_pre_enable_dp(struct 
> > intel_encoder *encoder,
> > intel_prepare_dp_ddi_buffers(encoder);
> > intel_ddi_init_dp_buf_reg(encoder);
> > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > -   intel_dp_start_link_train(intel_dp);
> > +   if (!intel_dp_start_link_train(intel_dp)) {
> > +   DRM_ERROR("Link Training failed at link rate = %d, lane count = 
> > %d\n",
> > + link_rate, lane_count);
> > +   intel_dp->link_train_failed = true;
> > +   intel_dp->link_train_failed_link_rate = link_rate;
> > +   intel_dp->link_train_failed_lane_count = lane_count;
> > +   /* Schedule a Hotplug Uevent to userspace to start modeset */
> > +   schedule_work(>i915_modeset_retry_work);
> > +   } else {
> > +   intel_dp->link_train_failed = false;
> > +   }
> > +
> > if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> > intel_dp_stop_link_train(intel_dp);
> >  }
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index c192e18..5d5f4a7 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -313,6 +313,7 @@ static int intel_dp_link_rate_index(struct intel_dp 
> > *intel_dp,
> > int target_clock = mode->clock;
> > int max_rate, mode_rate, max_lanes, max_link_clock;
> > int max_dotclk;
> > +   int common_rates[DP_MAX_SUPPORTED_RATES] = {};
> >  
> > max_dotclk = intel_dp_downstream_max_dotclock(intel_dp);
> >  
> > @@ -326,8 +327,27 @@ static int intel_dp_link_rate_index(struct intel_dp 
> > *intel_dp,
> > target_clock = fixed_mode->clock;
> > }
> >  
> > -   max_link_clock = intel_dp_max_link_rate(intel_dp);
> > -   max_lanes = intel_dp_max_lane_count(intel_dp);
> > +   /* Prune the modes based on the link rate that failed */
> > +   if (intel_dp->link_train_failed_link_rate) {
> 
> Shouldn't the bool link_train_failed that you are adding be used here?
> The naming indicates a check like this should use that.

Either that or the link_train_failed_link_rate can be used, both get
initialized and reset the same time. But using link_train_failed would be more
appropriate I guess, I will look at changing that.

Manasi
> 
> 
> > +   intel_dp->link_rate_index = intel_dp_link_rate_index(intel_dp,
> > +
> > common_rates,
> > +
> > intel_dp->link_train_failed_link_rate);
> > +   if (intel_dp->link_rate_index > 0) {
> > +   max_link_clock = common_rates[intel_dp->link_rate_index 
> > - 1];
> > +   max_lanes = intel_dp_max_lane_count(intel_dp);
> > +   } else {
> > +   /* Here we can lower the lane count, but that will be
> > +* added for DP Spec 1.3
> > +*/
> > +   

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/dp: Enable DP audio stall fix for gen9 platforms

[Pandiyan, Dhinakaran]

On Tue, 2016-10-25 at 11:47 +0300, Jani Nikula wrote:
> On Tue, 25 Oct 2016, Dhinakaran Pandiyan  
> wrote:
> > Enabling DP audio stall fix is necessary to play audio over DP HBR2. So,
> > let's set this bit right before enabling the audio codec. Playing audio
> > without setting this bit results in pipe FIFO underruns.
> >
> > Signed-off-by: Dhinakaran Pandiyan 
> 
> The fix itself looks legit, but please move the enable to beginning of
> hsw_audio_codec_enable and disable to end of hsw_audio_codec_disable in
> intel_audio.c. Seems to me you don't have to have separate functions for
> this, just add it inline there.
> 

I thought of it, but I didn't find any instances reading/writing of
non-audio registers in intel_audio.c. So, left these functions outside.



> Is there a W/A name for this?
> 
> 
> BR,
> Jani.
> 
> 

Not yet.

-DK

> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  |  5 +
> >  drivers/gpu/drm/i915/intel_ddi.c | 38 
> > ++
> >  drivers/gpu/drm/i915/intel_drv.h |  2 ++
> >  3 files changed, 45 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 00efaa1..76dac48 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6236,6 +6236,11 @@ enum {
> >  #define SLICE_ECO_CHICKEN0 _MMIO(0x7308)
> >  #define   PIXEL_MASK_CAMMING_DISABLE   (1 << 14)
> >  
> > +#define _CHICKEN_TRANS_A   0x420C0
> > +#define _CHICKEN_TRANS_B   0x420C4
> > +#define CHICKEN_TRANS(tran) _MMIO_TRANS(tran, _CHICKEN_TRANS_A, 
> > _CHICKEN_TRANS_B)
> > +#define SPARE_13   (1<<13)
> > +
> >  /* WaCatErrorRejectionIssue */
> >  #define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG _MMIO(0x9030)
> >  #define  GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB  (1<<11)
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index fb18d69..84c91c1 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1858,6 +1858,38 @@ void intel_ddi_fdi_post_disable(struct intel_encoder 
> > *intel_encoder,
> > I915_WRITE(FDI_RX_CTL(PIPE_A), val);
> >  }
> >  
> > +void gen9_enable_dp_audio_stall_fix(struct intel_crtc_state *pipe_config)
> > +{
> > +   struct drm_i915_private *dev_priv =
> > +   to_i915(pipe_config->base.crtc->dev);
> > +   enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
> > +   uint32_t temp;
> > +
> > +   if (intel_crtc_has_dp_encoder(pipe_config) &&
> > +   pipe_config->port_clock >= 54000) {
> > +
> > +   temp = I915_READ(CHICKEN_TRANS(cpu_transcoder));
> > +   temp |= SPARE_13;
> > +   I915_WRITE(CHICKEN_TRANS(cpu_transcoder), temp);
> > +   }
> > +}
> > +
> > +void gen9_disable_dp_audio_stall_fix(struct intel_crtc_state *pipe_config)
> > +{
> > +   struct drm_i915_private *dev_priv =
> > +   to_i915(pipe_config->base.crtc->dev);
> > +   enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
> > +   uint32_t temp;
> > +
> > +   if (intel_crtc_has_dp_encoder(pipe_config) &&
> > +   pipe_config->port_clock >= 54000) {
> > +
> > +   temp = I915_READ(CHICKEN_TRANS(cpu_transcoder));
> > +   temp &= ~SPARE_13;
> > +   I915_WRITE(CHICKEN_TRANS(cpu_transcoder), temp);
> > +   }
> > +}
> > +
> >  static void intel_enable_ddi(struct intel_encoder *intel_encoder,
> >  struct intel_crtc_state *pipe_config,
> >  struct drm_connector_state *conn_state)
> > @@ -1893,6 +1925,9 @@ static void intel_enable_ddi(struct intel_encoder 
> > *intel_encoder,
> > }
> >  
> > if (intel_crtc->config->has_audio) {
> > +   if (IS_GEN9(dev_priv))
> > +   gen9_enable_dp_audio_stall_fix(pipe_config);
> > +
> > intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
> > intel_audio_codec_enable(intel_encoder);
> > }
> > @@ -1912,6 +1947,9 @@ static void intel_disable_ddi(struct intel_encoder 
> > *intel_encoder,
> > if (intel_crtc->config->has_audio) {
> > intel_audio_codec_disable(intel_encoder);
> > intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO);
> > +
> > +   if (IS_GEN9(dev_priv))
> > +   gen9_disable_dp_audio_stall_fix(old_crtc_state);
> > }
> >  
> > if (type == INTEL_OUTPUT_EDP) {
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 4e90b07..ef02c62 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1189,6 +1189,8 @@ unsigned int intel_fb_align_height(struct drm_device 
> > *dev,
> >uint64_t fb_format_modifier);
> >  u32 intel_fb_stride_alignment(const struct drm_i915_private *dev_priv,
> >   uint64_t fb_modifier, uint32_t pixel_format);
> > 

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/dp: BDW cdclk fix for DP audio

[Pandiyan, Dhinakaran]

On Tue, 2016-10-25 at 11:46 +0300, Ville Syrjälä wrote:
> On Mon, Oct 24, 2016 at 09:18:37PM -0700, Dhinakaran Pandiyan wrote:
> > According to BSpec, cdclk has to be not less than 432 MHz with DP audio
> > enabled, port width x4, and link rate HBR2 (5.4 GHz)
> > 
> > Having a lower cdclk triggers pipe underruns, which then lead to displays
> > continuously cycling off and on. This is essential for DP MST audio as the
> > link is trained at HBR2 and 4 lanes by default.
> > 
> > v2: Restrict fix to BDW
> > Retain the set cdclk across modesets (Ville)
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 28 +---
> >  1 file changed, 25 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index a94f7d1..8c59651 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -10260,6 +10260,18 @@ static void bxt_modeset_commit_cdclk(struct 
> > drm_atomic_state *old_state)
> > bxt_set_cdclk(to_i915(dev), req_cdclk);
> >  }
> >  
> > +static unsigned int bdw_dp_audio_cdclk(struct intel_crtc_state *crtc_state)
> > +{
> > +
> 
> Useless blank line.
> 
> > +   if (intel_crtc_has_dp_encoder(crtc_state) &&
> > +   crtc_state->has_audio &&
> > +   crtc_state->port_clock >= 54 &&
> > +   crtc_state->lane_count == 4)
> > +   return 432000;
> > +
> > +   return 0;
> > +}
> > +
> >  /* compute the max rate for new configuration */
> >  static int ilk_max_pixel_rate(struct drm_atomic_state *state)
> >  {
> > @@ -10275,7 +10287,7 @@ static int ilk_max_pixel_rate(struct 
> > drm_atomic_state *state)
> >sizeof(intel_state->min_pixclk));
> >  
> > for_each_crtc_in_state(state, crtc, cstate, i) {
> > -   int pixel_rate;
> > +   unsigned int pixel_rate;
> >  
> > crtc_state = to_intel_crtc_state(cstate);
> > if (!crtc_state->base.enable) {
> > @@ -10285,9 +10297,19 @@ static int ilk_max_pixel_rate(struct 
> > drm_atomic_state *state)
> >  
> > pixel_rate = ilk_pipe_pixel_rate(crtc_state);
> >  
> > +   if (IS_BROADWELL(dev_priv)) {
> > /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
> > -   if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
> > -   pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
> > +   if (crtc_state->ips_enabled)
> > +   pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
> > +
> > +   /* BSpec says "Do not use DisplayPort with CDCLK less than
> > +* 432 MHz, audio enabled, port width x4, and link rate
> > +* HBR2 (5.4 GHz), or else there may be audio corruption or
> > +* screen corruption."
> > +*/
> 
> Indentation of the comments is wrong.
> 
> > +   pixel_rate = max(pixel_rate,
> > +bdw_dp_audio_cdclk(crtc_state));
> > +   }
> >  
> > intel_state->min_pixclk[i] = pixel_rate;
> 
> Otherwise I suppose this ought to work.
> 
> So with the formatting stuff fixed this is
> Reviewed-by: Ville Syrjälä 
> 
> The whole min_pixclk vs. pixel_rate vs. cdclk thing is a bit of a mess
> though. So it could use a thorough cleaning to make it less confusing.
> I'm tinking we might just want to start tracking a minimum acceptable
> cdclk per pipe. Probably the main thing would be to pull in the
> 5%/10% guardband handling here for all platforms.
> 

Yeah, definitely needs some work. As you wrote in the previous review,
we can get rid of tracking min_pixclk and track min_cdclk instead. I
could not find any other use for min_pixclk other than computing cdclk.
 
Thanks for the review.

-DK

> > }
> > -- 
> > 2.7.4
> 

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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/dp: BDW cdclk fix for DP audio

[Pandiyan, Dhinakaran]

On Tue, 2016-10-25 at 12:14 +0300, Jani Nikula wrote:
> On Tue, 25 Oct 2016, Jani Nikula  wrote:
> > On Tue, 25 Oct 2016, Dhinakaran Pandiyan  
> > wrote:
> >> According to BSpec, cdclk has to be not less than 432 MHz with DP audio
> >> enabled, port width x4, and link rate HBR2 (5.4 GHz)
> >>
> >> Having a lower cdclk triggers pipe underruns, which then lead to displays
> >> continuously cycling off and on. This is essential for DP MST audio as the
> >> link is trained at HBR2 and 4 lanes by default.
> >>
> >> v2: Restrict fix to BDW
> >> Retain the set cdclk across modesets (Ville)
> >
> > Cc: sta...@vger.kernel.org
> >
> >>
> >> Signed-off-by: Dhinakaran Pandiyan 
> >> ---
> >>  drivers/gpu/drm/i915/intel_display.c | 28 +---
> >>  1 file changed, 25 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index a94f7d1..8c59651 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -10260,6 +10260,18 @@ static void bxt_modeset_commit_cdclk(struct 
> >> drm_atomic_state *old_state)
> >>bxt_set_cdclk(to_i915(dev), req_cdclk);
> >>  }
> >>  
> >> +static unsigned int bdw_dp_audio_cdclk(struct intel_crtc_state 
> >> *crtc_state)
> >> +{
> >> +
> >> +  if (intel_crtc_has_dp_encoder(crtc_state) &&
> >> +  crtc_state->has_audio &&
> >> +  crtc_state->port_clock >= 54 &&
> >> +  crtc_state->lane_count == 4)
> >> +  return 432000;
> >
> > Where does 432000 come from? 45 or even (337500 + 1). See below.
> >
> >> +
> >> +  return 0;
> >> +}
> >> +
> >>  /* compute the max rate for new configuration */
> >>  static int ilk_max_pixel_rate(struct drm_atomic_state *state)
> >>  {
> >> @@ -10275,7 +10287,7 @@ static int ilk_max_pixel_rate(struct 
> >> drm_atomic_state *state)
> >>   sizeof(intel_state->min_pixclk));
> >>  
> >>for_each_crtc_in_state(state, crtc, cstate, i) {
> >> -  int pixel_rate;
> >> +  unsigned int pixel_rate;
> >>  
> >>crtc_state = to_intel_crtc_state(cstate);
> >>if (!crtc_state->base.enable) {
> >> @@ -10285,9 +10297,19 @@ static int ilk_max_pixel_rate(struct 
> >> drm_atomic_state *state)
> >>  
> >>pixel_rate = ilk_pipe_pixel_rate(crtc_state);
> >>  
> >> +  if (IS_BROADWELL(dev_priv)) {
> >>/* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
> >> -  if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)432
> >> -  pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
> >> +  if (crtc_state->ips_enabled)
> >> +  pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
> >> +
> >> +  /* BSpec says "Do not use DisplayPort with CDCLK less than
> >> +   * 432 MHz, audio enabled, port width x4, and link rate
> >
> > For me the spec says "Do not use DisplayPort with CDCLK 337.5 MHz", not
> > "less than 432 MHz".
> 
> Right, so the spec for *Skylake* mentions 432 MHz. Now, we need this fix
> for both Broadwell and Skylake, where's the Skylake part?
> 
> BR,
> Jani.
> 
> 

I believe you are looking at CDCLK_CTL that refers to pre-production SKL
SKU's. See the description for DP_TP_CTL instead. The information seems
to be scattered a bit


> >
> >> +   * HBR2 (5.4 GHz), or else there may be audio corruption or
> >> +   * screen corruption."
> >> +   */
> >> +  pixel_rate = max(pixel_rate,
> >> +   bdw_dp_audio_cdclk(crtc_state));
> >> +  }
> >
> > I'd add a new function
> >
> > static int bwd_adjust_min_pipe_pixel_rate(struct intel_crtc_state 
> > *crtc_state,
> >   int pixel_rate)
> >
> > and do both the IPS adjustment and the audio adjustment there, returning
> > the original pixel_rate if adjustment is not needed. Move the comments
> > there as well.
> >
> > It would be called as
> >
> > if (IS_BROADWELL(dev_priv))
> > pixel_rate = bwd_adjust_min_pipe_pixel_rate(crtc_state, 
> > pixel_rate);
> >
> > here.
> >
> >
> > BR,
> > Jani.
> >

Will do.

-DK
> >>  
> >>intel_state->min_pixclk[i] = pixel_rate;
> >>}
> 

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Link Rate fallback on Link training failure

[Jim Bride]

On Tue, Oct 25, 2016 at 03:17:47PM +0300, Jani Nikula wrote:
> On Sat, 22 Oct 2016, Manasi Navare  wrote:
> > If link training at a link rate optimal for a particular
> > mode fails during modeset's atomic commit phase, then we
> > let the modeset complete and then retry. We save the link rate
> > value at which link training failed and use a lower link rate
> > to prune the modes. It will redo the modeset on the current mode
> > at lower link rate or if the current mode gets pruned due to lower
> > link constraints then, it will send a hotplug uevent for userspace
> > to handle it.
> >
> > This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
> > 4.3.1.6.
> >
> > Cc: Jani Nikula 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjala 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c  | 15 +-
> >  drivers/gpu/drm/i915/intel_dp.c   | 69 
> > ++-
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 12 +++--
> >  drivers/gpu/drm/i915/intel_drv.h  |  6 ++-
> >  4 files changed, 95 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index fb18d69..451433b 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1712,6 +1712,8 @@ static void intel_ddi_pre_enable_dp(struct 
> > intel_encoder *encoder,
> > struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > enum port port = intel_ddi_get_encoder_port(encoder);
> > +   struct intel_connector *intel_connector = intel_dp->attached_connector;
> > +   struct drm_connector *connector = _connector->base;
> >  
> > intel_dp_set_link_params(intel_dp, link_rate, lane_count,
> >  link_mst);
> > @@ -1722,7 +1724,18 @@ static void intel_ddi_pre_enable_dp(struct 
> > intel_encoder *encoder,
> > intel_prepare_dp_ddi_buffers(encoder);
> > intel_ddi_init_dp_buf_reg(encoder);
> > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > -   intel_dp_start_link_train(intel_dp);
> > +   if (!intel_dp_start_link_train(intel_dp)) {
> > +   DRM_ERROR("Link Training failed at link rate = %d, lane count = 
> > %d\n",
> > + link_rate, lane_count);
> > +   intel_dp->link_train_failed = true;
> > +   intel_dp->link_train_failed_link_rate = link_rate;
> > +   intel_dp->link_train_failed_lane_count = lane_count;
> 
> I think eventually you'll need to store a list (array) of failing link
> rate, lane count pairs, not just the last that failed. Now you restrict
> the link config computation to only reducing the link rate. But
> currently (for whatever reason, it's flip-flopped too many times) we
> start with wide & slow, meaning that in many cases we've already
> exhausted the option to go slower. If optimal fails, maybe we need to
> try narrow & fast instead.

The DP spec specifically calls out that lane count shouldn't be reduced
until all speeds with the current lane configuration fail.  Even if
we start at an "optimal" configuration I believe we still need to
follow the reduction pattern that the spec calls out.

Jim


> 
> BR,
> Jani.
> 
> 
> > +   /* Schedule a Hotplug Uevent to userspace to start modeset */
> > +   schedule_work(>i915_modeset_retry_work);
> > +   } else {
> > +   intel_dp->link_train_failed = false;
> > +   }
> > +
> > if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> > intel_dp_stop_link_train(intel_dp);
> >  }
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index c192e18..5d5f4a7 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -313,6 +313,7 @@ static int intel_dp_link_rate_index(struct intel_dp 
> > *intel_dp,
> > int target_clock = mode->clock;
> > int max_rate, mode_rate, max_lanes, max_link_clock;
> > int max_dotclk;
> > +   int common_rates[DP_MAX_SUPPORTED_RATES] = {};
> >  
> > max_dotclk = intel_dp_downstream_max_dotclock(intel_dp);
> >  
> > @@ -326,8 +327,27 @@ static int intel_dp_link_rate_index(struct intel_dp 
> > *intel_dp,
> > target_clock = fixed_mode->clock;
> > }
> >  
> > -   max_link_clock = intel_dp_max_link_rate(intel_dp);
> > -   max_lanes = intel_dp_max_lane_count(intel_dp);
> > +   /* Prune the modes based on the link rate that failed */
> > +   if (intel_dp->link_train_failed_link_rate) {
> > +   intel_dp->link_rate_index = intel_dp_link_rate_index(intel_dp,
> > +
> > common_rates,
> > +
> > intel_dp->link_train_failed_link_rate);
> 

Re: [Intel-gfx] [PATCH] drm/i915/DMC/KBL: Load DMC on KBL using the no_stepping_info array

[Vivi, Rodrigo]

Reviewed-by: Rodrigo Vivi 

On Mon, 2016-10-24 at 17:28 -0700, Anusha Srivatsa wrote:
> Currently, for display there is only one DMC image for KBL.
> Remove the stepping_info table for KBL and use the no_stepping_info
> array for loading the firmware.
> 
> v2: Removed the block of code as pointed out by Rodrigo to make the
> loads as generic as possible.
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/intel_csr.c | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> b/drivers/gpu/drm/i915/intel_csr.c
> index 1ea0e1f..d7a04bc 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -168,12 +168,6 @@ struct stepping_info {
>   char substepping;
>  };
>  
> -static const struct stepping_info kbl_stepping_info[] = {
> - {'A', '0'}, {'B', '0'}, {'C', '0'},
> - {'D', '0'}, {'E', '0'}, {'F', '0'},
> - {'G', '0'}, {'H', '0'}, {'I', '0'},
> -};
> -
>  static const struct stepping_info skl_stepping_info[] = {
>   {'A', '0'}, {'B', '0'}, {'C', '0'},
>   {'D', '0'}, {'E', '0'}, {'F', '0'},
> @@ -194,10 +188,7 @@ intel_get_stepping_info(struct drm_i915_private 
> *dev_priv)
>   const struct stepping_info *si;
>   unsigned int size;
>  
> - if (IS_KABYLAKE(dev_priv)) {
> - size = ARRAY_SIZE(kbl_stepping_info);
> - si = kbl_stepping_info;
> - } else if (IS_SKYLAKE(dev_priv)) {
> + if (IS_SKYLAKE(dev_priv)) {
>   size = ARRAY_SIZE(skl_stepping_info);
>   si = skl_stepping_info;
>   } else if (IS_BROXTON(dev_priv)) {

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/i915: Rotated view does not need a fence (rev3)

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915: Rotated view does not need a 
fence (rev3)
URL   : https://patchwork.freedesktop.org/series/14340/
State : failure

== Summary ==

Series 14340v3 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/14340/revisions/3/mbox/

Test drv_module_reload_basic:
pass   -> SKIP   (fi-skl-6700hq)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test gem_ringfill:
Subgroup basic-default-hang:
pass   -> TIMEOUT(fi-ivb-3520m)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test prime_self_import:
Subgroup basic-with_one_bo:
pass   -> INCOMPLETE (fi-ivb-3520m)
Subgroup basic-with_one_bo_two_files:
pass   -> INCOMPLETE (fi-ivb-3520m)
Subgroup basic-with_two_bos:
pass   -> INCOMPLETE (fi-ivb-3520m)
Test prime_vgem:
Subgroup basic-busy-default:
pass   -> INCOMPLETE (fi-ivb-3520m)
Subgroup basic-fence-flip:
skip   -> INCOMPLETE (fi-ivb-3520m)
Subgroup basic-fence-mmap:
pass   -> INCOMPLETE (fi-ivb-3520m)
Subgroup basic-fence-read:
pass   -> INCOMPLETE (fi-ivb-3520m)
Subgroup basic-fence-wait-default:
pass   -> INCOMPLETE (fi-ivb-3520m)
Subgroup basic-gtt:
pass   -> INCOMPLETE (fi-ivb-3520m)
Subgroup basic-read:
pass   -> INCOMPLETE (fi-ivb-3520m)
Subgroup basic-sync-default:
pass   -> INCOMPLETE (fi-ivb-3520m)
Subgroup basic-wait-default:
pass   -> INCOMPLETE (fi-ivb-3520m)
Subgroup basic-write:
pass   -> INCOMPLETE (fi-ivb-3520m)
Test vgem_basic:
Subgroup create:
pass   -> INCOMPLETE (fi-ivb-3520m)
Subgroup debugfs:
pass   -> INCOMPLETE (fi-ivb-3520m)
Subgroup dmabuf-export:
pass   -> INCOMPLETE (fi-ivb-3520m)
Subgroup dmabuf-fence:
pass   -> INCOMPLETE (fi-ivb-3520m)
Subgroup dmabuf-fence-before:
pass   -> INCOMPLETE (fi-ivb-3520m)
Subgroup dmabuf-mmap:
pass   -> INCOMPLETE (fi-ivb-3520m)
Subgroup mmap:
pass   -> INCOMPLETE (fi-ivb-3520m)
Subgroup second-client:
pass   -> INCOMPLETE (fi-ivb-3520m)
Subgroup sysfs:
pass   -> INCOMPLETE (fi-ivb-3520m)
Subgroup unload:
pass   -> INCOMPLETE (fi-ivb-3520m)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:197  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

9e8e859eec7e29c4ef33413560819617a7f9f6bf drm-intel-nightly: 
2016y-10m-25d-16h-30m-11s UTC integration manifest
b116793 drm/i915: Remove two invalid warns
acd3753 drm/i915: Rotated view does not need a fence

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2815/

== Logs ==

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

[Intel-gfx] [PATCH v2 1/2] drm/i915: Rotated view does not need a fence

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

We do not need to set up a fence for the rotated view.

Display does not need it and no one can access it.

v2: Move code to __i915_vma_set_map_and_fenceable. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Fixes: 05a20d098db1 ("drm/i915: Move map-and-fenceable tracking to the VMA")
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9361c7b54a7f..eb524bdf0c35 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3790,7 +3790,12 @@ void __i915_vma_set_map_and_fenceable(struct i915_vma 
*vma)
mappable = (vma->node.start + fence_size <=
dev_priv->ggtt.mappable_end);
 
-   if (mappable && fenceable)
+   /*
+* Explicitly disable for rotated VMA since the display does not
+* need the fence and the VMA is not accessible to other users.
+*/
+   if (mappable && fenceable &&
+   vma->ggtt_view.type != I915_GGTT_VIEW_ROTATED)
vma->flags |= I915_VMA_CAN_FENCE;
else
vma->flags &= ~I915_VMA_CAN_FENCE;
-- 
2.7.4

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

[Intel-gfx] [PATCH v2 2/2] drm/i915: Remove two invalid warns

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Objects can have multiple VMAs used for display in which
case assertion that objects must not be pinned for display
more times than the current VMA is incorrect.

v2: Commit message update. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Fixes: 058d88c4330f ("drm/i915: Track pinned VMA")
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Ville Syrjälä 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index eb524bdf0c35..87018df94d68 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3595,8 +3595,6 @@ i915_gem_object_pin_to_display_plane(struct 
drm_i915_gem_object *obj,
 
vma->display_alignment = max_t(u64, vma->display_alignment, alignment);
 
-   WARN_ON(obj->pin_display > i915_vma_pin_count(vma));
-
i915_gem_object_flush_cpu_write_domain(obj);
 
old_write_domain = obj->base.write_domain;
@@ -3633,7 +3631,6 @@ i915_gem_object_unpin_from_display_plane(struct i915_vma 
*vma)
list_move_tail(>vm_link, >vm->inactive_list);
 
i915_vma_unpin(vma);
-   WARN_ON(vma->obj->pin_display > i915_vma_pin_count(vma));
 }
 
 /**
-- 
2.7.4

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

[Intel-gfx] [PATCH v2] drm/i915/guc: WA to address the Ringbuffer coherency issue

[akash . goel]

From: Akash Goel 

Driver accesses the ringbuffer pages, via GMADR BAR, if the pages are
pinned in mappable aperture portion of GGTT and for ringbuffer pages
allocated from Stolen memory, access can only be done through GMADR BAR.
In case of GuC based submission, updates done in ringbuffer via GMADR
may not get committed to memory by the time the Command streamer starts
reading them, resulting in fetching of stale data.

For Host based submission, such problem is not there as the write to Ring
Tail or ELSP register happens from the Host side prior to submission.
Access to any GFX register from CPU side goes to GTTMMADR BAR and Hw already
enforces the ordering between outstanding GMADR writes & new GTTMADR access.
MMIO writes from GuC side do not go to GTTMMADR BAR as GuC communication to
registers within GT is contained within GT, so ordering is not enforced
resulting in a race, which can manifest in form of a hang.

To ensure the flush of in-flight GMADR writes, a POSTING READ is done to
GuC register prior to doorbell ring.
There is already a similar WA in i915_gem_object_flush_gtt_write_domain(),
which takes care of GMADR writes from User space to GEM buffers, but not the
ringbuffer writes from KMD.
This WA is needed on all recent HW.

v2:
- Use POSTING_READ_FW instead of POSTING_READ as GuC register do not lie
  in any forcewake domain range and so the overhead of spinlock & search
  in the forcewake table is avoidable. (Chris)

Cc: Chris Wilson 
Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index bf65ffa..74235ea 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -634,6 +634,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
  */
 static void i915_guc_submit(struct drm_i915_gem_request *rq)
 {
+   struct drm_i915_private *dev_priv = rq->i915;
unsigned int engine_id = rq->engine->id;
struct intel_guc *guc = >i915->guc;
struct i915_guc_client *client = guc->execbuf_client;
@@ -641,6 +642,11 @@ static void i915_guc_submit(struct drm_i915_gem_request 
*rq)
 
spin_lock(>wq_lock);
guc_wq_item_append(client, rq);
+
+   /* WA to flush out the pending GMADR writes to ring buffer. */
+   if (i915_vma_is_map_and_fenceable(rq->ring->vma))
+   POSTING_READ_FW(GUC_STATUS);
+
b_ret = guc_ring_doorbell(client);
 
client->submissions[engine_id] += 1;
-- 
1.9.2

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/4] drm/i915: Don't try to initialize sprite planes on pre-ilk

[Patchwork]

== Series Details ==

Series: series starting with [1/4] drm/i915: Don't try to initialize sprite 
planes on pre-ilk
URL   : https://patchwork.freedesktop.org/series/14347/
State : warning

== Summary ==

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

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-skl-6770hq)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> SKIP   (fi-byt-n2820)
Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:219  dwarn:4   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

3ce99d02d8f2b7d1414d20d5972f8e277b33693e drm-intel-nightly: 
2016y-10m-25d-13h-55m-46s UTC integration manifest
1d8506a drm/i915: Reorganize sprite init
28f60dd drm/i915: Bail if plane/crtc init fails
df93569 drm/i915: Initialize planes in a reasonable order
59d4786 drm/i915: Don't try to initialize sprite planes on pre-ilk

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2813/

== Logs ==

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

Re: [Intel-gfx] [PATCH v7 01/11] drm/i915: Add i915 perf infrastructure

[Matthew Auld]

> +
> +/* Note we copy the properties from userspace outside of the i915 perf
> + * mutex to avoid an awkward lockdep with mmap_sem.
> + *
> + * Note this function only validates properties in isolation it doesn't
> + * validate that the combination of properties makes sense or that all
> + * properties necessary for a particular kind of stream have been set.
> + */
> +static int read_properties_unlocked(struct drm_i915_private *dev_priv,
> +   u64 __user *uprops,
> +   u32 n_props,
> +   struct perf_open_properties *props)
> +{
> +   u64 __user *uprop = uprops;
> +   int i;
> +
> +   memset(props, 0, sizeof(struct perf_open_properties));
> +
> +   if (!n_props) {
> +   DRM_ERROR("No i915 perf properties given");
> +   return -EINVAL;
> +   }
> +
> +   if (n_props > DRM_I915_PERF_PROP_MAX) {
> +   DRM_ERROR("More i915 perf properties specified than exist");
> +   return -EINVAL;
> +   }
> +
> +   for (i = 0; i < n_props; i++) {
> +   u64 id, value;
> +   int ret;
> +
> +   ret = get_user(id, (u64 __user *)uprop);
> +   if (ret)
> +   return ret;
> +
> +   ret = get_user(value, (u64 __user *)uprop + 1);
> +   if (ret)
> +   return ret;
Do we really need all of these __user casts, they seem redundant, no?

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

[Intel-gfx] [PATCH 3/4] drm/i915: Bail if plane/crtc init fails

[ville . syrjala]

From: Ville Syrjälä 

Due to the plane->index not getting readjusted in drm_plane_cleanup(),
we can't continue initialization of some plane/crtc init fails.
Well, we sort of could I suppose if we left all initialized planes on
the list, but that would expose those planes to userspace as well.

But for crtcs the situation is even worse since we assume that
pipe==crtc index occasionally, so we can't really deal with a partially
initialize set of crtcs.

So seems safest to just abort the entire thing if anything goes wrong.
All the failure paths here are kmalloc()s anyway, so it seems unlikely
we'd get very far if these start failing.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c  |   4 +-
 drivers/gpu/drm/i915/i915_drv.h  |   2 +-
 drivers/gpu/drm/i915/intel_display.c | 101 ++-
 drivers/gpu/drm/i915/intel_drv.h |   3 +-
 drivers/gpu/drm/i915/intel_sprite.c  |   8 +--
 5 files changed, 75 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index af3559d34328..0e393b5a988a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -592,7 +592,9 @@ static int i915_load_modeset_init(struct drm_device *dev)
 
/* Important: The output setup functions called by modeset_init need
 * working irqs for e.g. gmbus and dp aux transfers. */
-   intel_modeset_init(dev);
+   ret = intel_modeset_init(dev);
+   if (ret)
+   goto cleanup_irq;
 
intel_guc_init(dev);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7a621c74254e..a9308aeb2f1f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3700,7 +3700,7 @@ void intel_device_info_dump(struct drm_i915_private 
*dev_priv);
 
 /* modesetting */
 extern void intel_modeset_init_hw(struct drm_device *dev);
-extern void intel_modeset_init(struct drm_device *dev);
+extern int intel_modeset_init(struct drm_device *dev);
 extern void intel_modeset_gem_init(struct drm_device *dev);
 extern void intel_modeset_cleanup(struct drm_device *dev);
 extern int intel_connector_register(struct drm_connector *);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 244a0f59d8f7..d5a49d12dc88 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14975,9 +14975,6 @@ static void intel_finish_crtc_commit(struct drm_crtc 
*crtc,
  */
 void intel_plane_destroy(struct drm_plane *plane)
 {
-   if (!plane)
-   return;
-
drm_plane_cleanup(plane);
kfree(to_intel_plane(plane));
 }
@@ -14991,11 +14988,10 @@ const struct drm_plane_funcs intel_plane_funcs = {
.atomic_set_property = intel_plane_atomic_set_property,
.atomic_duplicate_state = intel_plane_duplicate_state,
.atomic_destroy_state = intel_plane_destroy_state,
-
 };
 
-static struct drm_plane *intel_primary_plane_create(struct drm_device *dev,
-   int pipe)
+static struct intel_plane *
+intel_primary_plane_create(struct drm_device *dev, enum pipe pipe)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_plane *primary = NULL;
@@ -15006,12 +15002,17 @@ static struct drm_plane 
*intel_primary_plane_create(struct drm_device *dev,
int ret;
 
primary = kzalloc(sizeof(*primary), GFP_KERNEL);
-   if (!primary)
+   if (!primary) {
+   ret = -ENOMEM;
goto fail;
+   }
 
state = intel_create_plane_state(>base);
-   if (!state)
+   if (!state) {
+   ret = -ENOMEM;
goto fail;
+   }
+
primary->base.state = >base;
 
primary->can_scale = false;
@@ -15092,13 +15093,13 @@ static struct drm_plane 
*intel_primary_plane_create(struct drm_device *dev,
 
drm_plane_helper_add(>base, _plane_helper_funcs);
 
-   return >base;
+   return primary;
 
 fail:
kfree(state);
kfree(primary);
 
-   return NULL;
+   return ERR_PTR(ret);
 }
 
 static int
@@ -15194,8 +15195,8 @@ intel_update_cursor_plane(struct drm_plane *plane,
intel_crtc_update_cursor(crtc, state);
 }
 
-static struct drm_plane *intel_cursor_plane_create(struct drm_device *dev,
-  int pipe)
+static struct intel_plane *
+intel_cursor_plane_create(struct drm_device *dev, enum pipe pipe)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_plane *cursor = NULL;
@@ -15203,12 +15204,17 @@ static struct drm_plane 
*intel_cursor_plane_create(struct drm_device *dev,
int ret;
 
cursor = kzalloc(sizeof(*cursor), GFP_KERNEL);
-   if (!cursor)
+   if (!cursor) {
+   ret = -ENOMEM;
goto fail;
+   

[Intel-gfx] [PATCH 1/4] drm/i915: Don't try to initialize sprite planes on pre-ilk

[ville . syrjala]

From: Ville Syrjälä 

We don't currently implement support for sprite planes on pre-ilk
platforms, so let's leave num_sprites at 0 so that we don't get
spurious errors during driver init.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_device_info.c | 5 +++--
 drivers/gpu/drm/i915/intel_sprite.c  | 3 ---
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index d6a8f11813d5..185e3bbc9ec9 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -282,12 +282,13 @@ void intel_device_info_runtime_init(struct 
drm_i915_private *dev_priv)
info->num_sprites[PIPE_A] = 2;
info->num_sprites[PIPE_B] = 2;
info->num_sprites[PIPE_C] = 1;
-   } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+   } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
for_each_pipe(dev_priv, pipe)
info->num_sprites[pipe] = 2;
-   else
+   } else if (INTEL_GEN(dev_priv) >= 5) {
for_each_pipe(dev_priv, pipe)
info->num_sprites[pipe] = 1;
+   }
 
if (i915.disable_display) {
DRM_INFO("Display disabled (module parameter)\n");
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 43d0350856e7..ae1e3d47951b 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1054,9 +1054,6 @@ intel_plane_init(struct drm_device *dev, enum pipe pipe, 
int plane)
int num_plane_formats;
int ret;
 
-   if (INTEL_INFO(dev)->gen < 5)
-   return -ENODEV;
-
intel_plane = kzalloc(sizeof(*intel_plane), GFP_KERNEL);
if (!intel_plane) {
ret = -ENOMEM;
-- 
2.7.4

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

[Intel-gfx] [PATCH 4/4] drm/i915: Reorganize sprite init

[ville . syrjala]

From: Ville Syrjälä 

Kill the switch statement from the sprite init code and replace with a
more straightforward if ladder. Now each significant evolution of the
sprite hardware is in its own neat box.

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

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 41ae7f562eec..70b50a27763e 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1067,25 +1067,25 @@ intel_sprite_plane_create(struct drm_device *dev, enum 
pipe pipe, int plane)
}
intel_plane->base.state = >base;
 
-   switch (INTEL_INFO(dev)->gen) {
-   case 5:
-   case 6:
+   if (INTEL_GEN(dev_priv) >= 9) {
intel_plane->can_scale = true;
-   intel_plane->max_downscale = 16;
-   intel_plane->update_plane = ilk_update_plane;
-   intel_plane->disable_plane = ilk_disable_plane;
+   state->scaler_id = -1;
 
-   if (IS_GEN6(dev_priv)) {
-   plane_formats = snb_plane_formats;
-   num_plane_formats = ARRAY_SIZE(snb_plane_formats);
-   } else {
-   plane_formats = ilk_plane_formats;
-   num_plane_formats = ARRAY_SIZE(ilk_plane_formats);
-   }
-   break;
+   intel_plane->update_plane = skl_update_plane;
+   intel_plane->disable_plane = skl_disable_plane;
+
+   plane_formats = skl_plane_formats;
+   num_plane_formats = ARRAY_SIZE(skl_plane_formats);
+   } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
+   intel_plane->can_scale = false;
+   intel_plane->max_downscale = 1;
+
+   intel_plane->update_plane = vlv_update_plane;
+   intel_plane->disable_plane = vlv_disable_plane;
 
-   case 7:
-   case 8:
+   plane_formats = vlv_plane_formats;
+   num_plane_formats = ARRAY_SIZE(vlv_plane_formats);
+   } else if (INTEL_GEN(dev_priv) >= 7) {
if (IS_IVYBRIDGE(dev_priv)) {
intel_plane->can_scale = true;
intel_plane->max_downscale = 2;
@@ -1094,33 +1094,25 @@ intel_sprite_plane_create(struct drm_device *dev, enum 
pipe pipe, int plane)
intel_plane->max_downscale = 1;
}
 
-   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
-   intel_plane->update_plane = vlv_update_plane;
-   intel_plane->disable_plane = vlv_disable_plane;
+   intel_plane->update_plane = ivb_update_plane;
+   intel_plane->disable_plane = ivb_disable_plane;
 
-   plane_formats = vlv_plane_formats;
-   num_plane_formats = ARRAY_SIZE(vlv_plane_formats);
-   } else {
-   intel_plane->update_plane = ivb_update_plane;
-   intel_plane->disable_plane = ivb_disable_plane;
+   plane_formats = snb_plane_formats;
+   num_plane_formats = ARRAY_SIZE(snb_plane_formats);
+   } else {
+   intel_plane->can_scale = true;
+   intel_plane->max_downscale = 16;
+
+   intel_plane->update_plane = ilk_update_plane;
+   intel_plane->disable_plane = ilk_disable_plane;
 
+   if (IS_GEN6(dev_priv)) {
plane_formats = snb_plane_formats;
num_plane_formats = ARRAY_SIZE(snb_plane_formats);
+   } else {
+   plane_formats = ilk_plane_formats;
+   num_plane_formats = ARRAY_SIZE(ilk_plane_formats);
}
-   break;
-   case 9:
-   intel_plane->can_scale = true;
-   intel_plane->update_plane = skl_update_plane;
-   intel_plane->disable_plane = skl_disable_plane;
-   state->scaler_id = -1;
-
-   plane_formats = skl_plane_formats;
-   num_plane_formats = ARRAY_SIZE(skl_plane_formats);
-   break;
-   default:
-   MISSING_CASE(INTEL_INFO(dev)->gen);
-   ret = -ENODEV;
-   goto fail;
}
 
if (INTEL_GEN(dev_priv) >= 9) {
@@ -1139,7 +1131,7 @@ intel_sprite_plane_create(struct drm_device *dev, enum 
pipe pipe, int plane)
 
possible_crtcs = (1 << pipe);
 
-   if (INTEL_INFO(dev)->gen >= 9)
+   if (INTEL_GEN(dev_priv) >= 9)
ret = drm_universal_plane_init(dev, _plane->base, 
possible_crtcs,
   _plane_funcs,
   plane_formats, 

[Intel-gfx] [PATCH 2/4] drm/i915: Initialize planes in a reasonable order

[ville . syrjala]

From: Ville Syrjälä 

The zpos magic sorting uses the object ID to solve conflicting zpos
values. Let's initialize our planes in an order that makes the object
IDs agree with the normal primary->sprites->cursor z order.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 2a5a7c2868de..244a0f59d8f7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15272,7 +15272,7 @@ static void intel_crtc_init(struct drm_device *dev, int 
pipe)
struct intel_crtc_state *crtc_state = NULL;
struct drm_plane *primary = NULL;
struct drm_plane *cursor = NULL;
-   int ret;
+   int sprite, ret;
 
intel_crtc = kzalloc(sizeof(*intel_crtc), GFP_KERNEL);
if (intel_crtc == NULL)
@@ -15299,6 +15299,13 @@ static void intel_crtc_init(struct drm_device *dev, 
int pipe)
if (!primary)
goto fail;
 
+   for_each_sprite(dev_priv, pipe, sprite) {
+   ret = intel_plane_init(dev, pipe, sprite);
+   if (ret)
+   DRM_DEBUG_KMS("pipe %c sprite %c init failed: %d\n",
+ pipe_name(pipe), sprite_name(pipe, 
sprite), ret);
+   }
+
cursor = intel_cursor_plane_create(dev, pipe);
if (!cursor)
goto fail;
@@ -16423,7 +16430,6 @@ void intel_modeset_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
struct i915_ggtt *ggtt = _priv->ggtt;
-   int sprite, ret;
enum pipe pipe;
struct intel_crtc *crtc;
 
@@ -16494,12 +16500,6 @@ void intel_modeset_init(struct drm_device *dev)
 
for_each_pipe(dev_priv, pipe) {
intel_crtc_init(dev, pipe);
-   for_each_sprite(dev_priv, pipe, sprite) {
-   ret = intel_plane_init(dev, pipe, sprite);
-   if (ret)
-   DRM_DEBUG_KMS("pipe %c sprite %c init failed: 
%d\n",
- pipe_name(pipe), 
sprite_name(pipe, sprite), ret);
-   }
}
 
intel_update_czclk(dev_priv);
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH v2] drm/i915: fix comment on I915_{READ, WRITE}_FW

[Matthew Auld]

On 25 October 2016 at 13:48, Arkadiusz Hiler  wrote:
> Comment mentioned use of intel_uncore_forcewake_irq{unlock, lock}
> functions which are nonexistent (and never were).
>
> The description was also incomplete and could cause confusion. Updated
> comment is more elaborate on usage and caveats.
>
> v2: mention __locked variant of intel_uncore_forcewake_{get,put} instead
> of plain ones
>
> Cc: Chris Wilson 
> Cc: Matthew Auld 
> Cc: Mika Kuoppala 
> Signed-off-by: Arkadiusz Hiler 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915/audio: drop extra crtc clock check from HDMI audio N lookup

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/audio: drop extra crtc clock check 
from HDMI audio N lookup
URL   : https://patchwork.freedesktop.org/series/14342/
State : warning

== Summary ==

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

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-6700hq)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-skl-6770hq)
dmesg-warn -> PASS   (fi-skl-6700hq)
Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (fi-skl-6700hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

3ce99d02d8f2b7d1414d20d5972f8e277b33693e drm-intel-nightly: 
2016y-10m-25d-13h-55m-46s UTC integration manifest
8ee7f93 drm/i915/audio: set proper N/M in modeset
76ec280 drm/i915/audio: drop extra crtc clock check from HDMI audio N lookup

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2812/

== Logs ==

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

Re: [Intel-gfx] drm/i915/audio: m/n value fixes

[Ville Syrjälä]

On Tue, Oct 25, 2016 at 05:54:16PM +0300, Jani Nikula wrote:
> Remaining patch from https://patchwork.freedesktop.org/series/12754/
> plus a cleanup.

I'm not feeling like checking bspec for the nuts and bolts details on
the registers again, but at least the code looks sane to me and the
M/N values what my test application generates (if I double the values
for HBR2). Based on that

Reviewed-by: Ville Syrjälä 

for both patches.

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Rotated view does not need a fence

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Rotated view does not need a fence
URL   : https://patchwork.freedesktop.org/series/14340/
State : warning

== Summary ==

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

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-skl-6770hq)
Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:184  dwarn:1   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:219  dwarn:4   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

3ce99d02d8f2b7d1414d20d5972f8e277b33693e drm-intel-nightly: 
2016y-10m-25d-13h-55m-46s UTC integration manifest
36e261e drm/i915: Remove two invalid warns
ddb7358 drm/i915: Rotated view does not need a fence

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2811/

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 8/8] drm/i915/lspcon: Add workaround for resuming in PCON mode

[Jani Nikula]

On Mon, 24 Oct 2016, Imre Deak  wrote:
> On my APL the LSPCON firmware resumes in PCON mode as opposed to the
> expected LS mode. It also appears to be in a state where AUX DPCD reads
> will succeed but return garbage recovering only after a few hundreds of
> milliseconds. After the recovery time DPCD reads will result in the
> correct values and things will continue to work. If I2C over AUX is
> attempted during this recovery time (implying an AUX write transaction)
> the firmware won't recover and will stay in this broken state.
>
> As a workaround check if the firmware is in PCON state after resume and
> if so wait until the correct DPCD values are returned. For this we
> compare the branch descriptor with the one we cached during init time.
> If the firmware was in the LS state, we skip the w/a and continue as
> before.
>
> v2:
> - Use the DP descriptor value cached in intel_dp. (Jani)
> - Get to intel_dp using container_of(), instead of a cached ptr.
>   (Shashank)
> - Use usleep_range() instead of msleep().
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98353
> Cc: Shashank Sharma 
> Cc: Ville Syrjälä 
> Cc: Jani Nikula 
> Signed-off-by: Imre Deak 

I don't think we properly understand what's going on with the device. In
the mean time, limp on with this if this fixes stuff.

Acked-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/intel_dp.c |  2 +-
>  drivers/gpu/drm/i915/intel_drv.h|  3 +++
>  drivers/gpu/drm/i915/intel_lspcon.c | 37 
> -
>  3 files changed, 40 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 043993f..e9be955 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1451,7 +1451,7 @@ static void intel_dp_print_rates(struct intel_dp 
> *intel_dp)
>   DRM_DEBUG_KMS("common rates: %s\n", str);
>  }
>  
> -static bool
> +bool
>  __intel_dp_read_desc(struct intel_dp *intel_dp, struct intel_dp_desc *desc)
>  {
>   u32 base = drm_dp_is_branch(intel_dp->dpcd) ? DP_BRANCH_OUI :
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 45f55b5..f2b6c59 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -974,6 +974,7 @@ struct intel_dp {
>  struct intel_lspcon {
>   bool active;
>   enum drm_lspcon_mode mode;
> + bool desc_valid;
>  };
>  
>  struct intel_digital_port {
> @@ -1461,6 +1462,8 @@ static inline unsigned int 
> intel_dp_unused_lane_mask(int lane_count)
>  }
>  
>  bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> +bool __intel_dp_read_desc(struct intel_dp *intel_dp,
> +   struct intel_dp_desc *desc);
>  bool intel_dp_read_desc(struct intel_dp *intel_dp);
>  
>  /* intel_dp_aux_backlight.c */
> diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
> b/drivers/gpu/drm/i915/intel_lspcon.c
> index 3dc5a0b..daa5234 100644
> --- a/drivers/gpu/drm/i915/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/intel_lspcon.c
> @@ -97,8 +97,43 @@ static bool lspcon_probe(struct intel_lspcon *lspcon)
>   return true;
>  }
>  
> +static void lspcon_resume_in_pcon_wa(struct intel_lspcon *lspcon)
> +{
> + struct intel_dp *intel_dp = lspcon_to_intel_dp(lspcon);
> + unsigned long start = jiffies;
> +
> + if (!lspcon->desc_valid)
> + return;
> +
> + while (1) {
> + struct intel_dp_desc desc;
> +
> + /*
> +  * The w/a only applies in PCON mode and we don't expect any
> +  * AUX errors.
> +  */
> + if (!__intel_dp_read_desc(intel_dp, ))
> + return;
> +
> + if (!memcmp(_dp->desc, , sizeof(desc))) {
> + DRM_DEBUG_KMS("LSPCON recovering in PCON mode after %u 
> ms\n",
> +   jiffies_to_msecs(jiffies - start));
> + return;
> + }
> +
> + if (time_after(jiffies, start + msecs_to_jiffies(1000)))
> + break;
> +
> + usleep_range(1, 15000);
> + }
> +
> + DRM_DEBUG_KMS("LSPCON DP descriptor mismatch after resume\n");
> +}
> +
>  void lspcon_resume(struct intel_lspcon *lspcon)
>  {
> + lspcon_resume_in_pcon_wa(lspcon);
> +
>   if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON, true))
>   DRM_ERROR("LSPCON resume failed\n");
>   else
> @@ -143,7 +178,7 @@ bool lspcon_init(struct intel_digital_port 
> *intel_dig_port)
>   return false;
>   }
>  
> - intel_dp_read_desc(dp);
> + lspcon->desc_valid = intel_dp_read_desc(dp);
>  
>   DRM_DEBUG_KMS("Success: LSPCON init\n");
>   return true;

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] [PATCH v3 4/8] drm/i915/dp: Print full branch/sink descriptor

[Jani Nikula]

On Tue, 25 Oct 2016, Imre Deak  wrote:
> Extend the branch/sink descriptor info with the missing device ID
> field. While at it also read out all the descriptor registers in one
> transfer and make the debug print more compact.
>
> v2: (Jani)
> - Cache the descriptor in intel_dp.
> - Split out this change into a separate patch.
> v3: (Jani)
> - Fix return value check of __intel_dp_read_desc().
> - Use %pE instead of %s to print the device ID.
>
> Cc: Jani Nikula 
> Signed-off-by: Imre Deak 

Reviewed-by: Jani Nikula 


> ---
>  drivers/gpu/drm/i915/intel_dp.c  | 63 
> ++--
>  drivers/gpu/drm/i915/intel_drv.h | 10 +++
>  2 files changed, 32 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 1991250..57260a2 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1451,34 +1451,35 @@ static void intel_dp_print_rates(struct intel_dp 
> *intel_dp)
>   DRM_DEBUG_KMS("common rates: %s\n", str);
>  }
>  
> -static void intel_dp_print_hw_revision(struct intel_dp *intel_dp)
> +static bool
> +__intel_dp_read_desc(struct intel_dp *intel_dp, struct intel_dp_desc *desc)
>  {
> - uint8_t rev;
> - int len;
> + u32 base = drm_dp_is_branch(intel_dp->dpcd) ? DP_BRANCH_OUI :
> +   DP_SINK_OUI;
>  
> - if (!drm_dp_is_branch(intel_dp->dpcd))
> - return;
> -
> - len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_HW_REV, , 1);
> - if (len < 0)
> - return;
> -
> - DRM_DEBUG_KMS("sink hw revision: %d.%d\n", (rev & 0xf0) >> 4, rev & 
> 0xf);
> + return drm_dp_dpcd_read(_dp->aux, base, desc, sizeof(*desc)) ==
> +sizeof(*desc);
>  }
>  
> -static void intel_dp_print_sw_revision(struct intel_dp *intel_dp)
> +static bool intel_dp_read_desc(struct intel_dp *intel_dp)
>  {
> - uint8_t rev[2];
> - int len;
> + struct intel_dp_desc *desc = _dp->desc;
> + bool oui_sup = intel_dp->dpcd[DP_DOWN_STREAM_PORT_COUNT] &
> +DP_OUI_SUPPORT;
> + int dev_id_len;
>  
> - if (!drm_dp_is_branch(intel_dp->dpcd))
> - return;
> + if (!__intel_dp_read_desc(intel_dp, desc))
> + return false;
>  
> - len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_SW_REV, , 2);
> - if (len < 0)
> - return;
> + dev_id_len = strnlen(desc->device_id, sizeof(desc->device_id));
> + DRM_DEBUG_KMS("DP %s: OUI %*phD%s dev-ID %*pE HW-rev %d.%d SW-rev 
> %d.%d\n",
> +   drm_dp_is_branch(intel_dp->dpcd) ? "branch" : "sink",
> +   (int)sizeof(desc->oui), desc->oui, oui_sup ? "" : "(NS)",
> +   dev_id_len, desc->device_id,
> +   desc->hw_rev >> 4, desc->hw_rev & 0xf,
> +   desc->sw_major_rev, desc->sw_minor_rev);
>  
> - DRM_DEBUG_KMS("sink sw revision: %d.%d\n", rev[0], rev[1]);
> + return true;
>  }
>  
>  static int rate_to_index(int find, const int *rates)
> @@ -3621,23 +3622,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>   return true;
>  }
>  
> -static void
> -intel_dp_probe_oui(struct intel_dp *intel_dp)
> -{
> - bool is_branch = drm_dp_is_branch(intel_dp->dpcd);
> - u8 buf[3];
> -
> - if (!(intel_dp->dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_OUI_SUPPORT))
> - return;
> -
> - if (drm_dp_dpcd_read(_dp->aux,
> -  is_branch ? DP_BRANCH_OUI : DP_SINK_OUI,
> -  buf, 3) == 3)
> - DRM_DEBUG_KMS("%s OUI: %02hx%02hx%02hx\n",
> -   is_branch ? "Branch" : "Sink",
> -   buf[0], buf[1], buf[2]);
> -}
> -
>  static bool
>  intel_dp_can_mst(struct intel_dp *intel_dp)
>  {
> @@ -4416,10 +4400,7 @@ intel_dp_long_pulse(struct intel_connector 
> *intel_connector)
>  
>   intel_dp_print_rates(intel_dp);
>  
> - intel_dp_probe_oui(intel_dp);
> -
> - intel_dp_print_hw_revision(intel_dp);
> - intel_dp_print_sw_revision(intel_dp);
> + intel_dp_read_desc(intel_dp);
>  
>   intel_dp_configure_mst(intel_dp);
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 16b33f5..4c9f953 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -883,6 +883,14 @@ enum link_m_n_set {
>   M2_N2
>  };
>  
> +struct intel_dp_desc {
> + u8 oui[3];
> + u8 device_id[6];
> + u8 hw_rev;
> + u8 sw_major_rev;
> + u8 sw_minor_rev;
> +} __packed;
> +
>  struct intel_dp {
>   i915_reg_t output_reg;
>   i915_reg_t aux_ch_ctl_reg;
> @@ -905,6 +913,8 @@ struct intel_dp {
>   /* sink rates as reported by DP_SUPPORTED_LINK_RATES */
>   uint8_t num_sink_rates;
>   int sink_rates[DP_MAX_SUPPORTED_RATES];
> + /* sink or branch 

Re: [Intel-gfx] [PATCH 1/4] igt_fb: Add Y-tiling support

[Paneri, Praveen]

> So when you say that all Y tiling tests fail without this kernel hack, which 
> tests you are referring to?
If I revert this IGT patch and do not make below kernel change, kms_draw_crc 
(ytiled cases, last patch in this series) fail with following error.

Test assertion failure function igt_assert_crc_equal, file 
hardware/intel/intel-gpu-tools/lib/igt_debugfs.c:266:
Failed assertion: a->crc[i] == b->crc[i]
error: 0x68c96b8b != 0x948e53b

I think, I shall debug it further and try to fix it without making this change.

Regards,
Praveen


-Original Message-
From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] 
Sent: Tuesday, October 25, 2016 6:07 PM
To: Paneri, Praveen ; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/4] igt_fb: Add Y-tiling support


On 25/10/2016 13:06, Paneri, Praveen wrote:
> Hi Tvrtko,
>
> Along with this change I made following change in the kernel side. I was not 
> sure if this is a hack of a legitimate change. Could you please give me a 
> pointer about how to move fwd from here? Without this all Y-tiling tests 
> would fail.
>
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15406,8 +15406,7 @@ static int intel_framebuffer_init(struct drm_device 
> *dev,
> if (obj->tiling_mode == I915_TILING_X)
> mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED;
> else if (obj->tiling_mode == I915_TILING_Y) {
> -   DRM_DEBUG("No Y tiling for legacy addfb\n");
> -   return -EINVAL;
> +   mode_cmd->modifier[0] = 
> + I915_FORMAT_MOD_Y_TILED;
> }
> }

It would be a controversial change, "beyond my pay grade". :)

If you drop this particular IGT patch, you can still create Y tiled 
framebuffers and display them (as the existing tests already do that). 
So when you say that all Y tiling tests fail without this kernel hack, which 
tests you are referring to?

Regards,

Tvrtko

> Regards,
> Praveen
>
>
> -Original Message-
> From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
> Sent: Tuesday, October 25, 2016 1:36 PM
> To: Paneri, Praveen ; 
> intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/4] igt_fb: Add Y-tiling support
>
>
> On 24/10/2016 17:55, Praveen Paneri wrote:
>> This adds Y-tiling check in igt_create_fb_with_bo_size as now we 
>> should also be able to create Y-tiled FBs.
>>
>> Signed-off-by: Praveen Paneri 
>> ---
>>  lib/igt_fb.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/lib/igt_fb.c b/lib/igt_fb.c index 47472f4..bf1d372 
>> 100644
>> --- a/lib/igt_fb.c
>> +++ b/lib/igt_fb.c
>> @@ -608,7 +608,8 @@ igt_create_fb_with_bo_size(int fd, int width, int height,
>>__func__, fb->gem_handle, fb->stride);
>>
>>  if (tiling != LOCAL_DRM_FORMAT_MOD_NONE &&
>> -tiling != LOCAL_I915_FORMAT_MOD_X_TILED) {
>> +tiling != LOCAL_I915_FORMAT_MOD_X_TILED &&
>> +tiling != LOCAL_I915_FORMAT_MOD_Y_TILED) {
>>  do_or_die(__kms_addfb(fd, fb->gem_handle, width, height,
>>fb->stride, format, tiling,
>>LOCAL_DRM_MODE_FB_MODIFIERS, _id));
>>
>
> This works now? Ie. doesn't hit "No Y Tiling for legacy addfb" error in the 
> driver?
>
> Regards,
>
> Tvrtko
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] drm/i915/audio: m/n value fixes

[Jani Nikula]

Remaining patch from https://patchwork.freedesktop.org/series/12754/
plus a cleanup.

BR,
Jani.


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

[Intel-gfx] [PATCH 1/2] drm/i915/audio: drop extra crtc clock check from HDMI audio N lookup

[Jani Nikula]

The array contains the crtc clock, rely on that. While at it, debug log
the HDMI N value or automatic mode.

Cc: Ville Syrjälä 
Cc: "Lin, Mengdong" 
Cc: Libin Yang 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_audio.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index 7093cfbb62b1..1a5c21209446 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -254,16 +254,15 @@ hsw_hdmi_audio_config_update(struct intel_crtc 
*intel_crtc, enum port port,
tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
tmp |= audio_config_hdmi_pixel_clock(adjusted_mode);
 
-   if (adjusted_mode->crtc_clock == TMDS_296M ||
-   adjusted_mode->crtc_clock == TMDS_297M) {
-   n = audio_config_hdmi_get_n(adjusted_mode, rate);
-   if (n != 0) {
-   tmp &= ~AUD_CONFIG_N_MASK;
-   tmp |= AUD_CONFIG_N(n);
-   tmp |= AUD_CONFIG_N_PROG_ENABLE;
-   } else {
-   DRM_DEBUG_KMS("no suitable N value is found\n");
-   }
+   n = audio_config_hdmi_get_n(adjusted_mode, rate);
+   if (n != 0) {
+   DRM_DEBUG_KMS("using N %d\n", n);
+
+   tmp &= ~AUD_CONFIG_N_MASK;
+   tmp |= AUD_CONFIG_N(n);
+   tmp |= AUD_CONFIG_N_PROG_ENABLE;
+   } else {
+   DRM_DEBUG_KMS("using automatic N\n");
}
 
I915_WRITE(HSW_AUD_CFG(pipe), tmp);
-- 
2.1.4

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

[Intel-gfx] [PATCH 2/2] drm/i915/audio: set proper N/M in modeset

[Jani Nikula]

From: Libin Yang 

When modeset occurs and the LS_CLK is set to some special values in DP
mode, the N/M need to be set manually if audio is playing. Otherwise the
first several seconds may be silent in audio playback.

The relationship of Maud and Naud is expressed in the following
equation:

Maud/Naud = 512 * fs / f_LS_Clk

Please refer VESA DisplayPort Standard spec for details.

v2 by Jani:
- organize Maud/Naud table according to DP 1.4 spec
- add 64k and 128k audio rates
- update HSW_AUD_M_CTS_ENABLE register when Maud not found
- remove extra checks for port clock
- simplify Maud/Naud lookup
- reset patch author back to Libin

Cc: "Zhang, Keqiao" 
Cc: Ville Syrjälä 
Cc: "Lin, Mengdong" 
Signed-off-by: Libin Yang 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_reg.h|  7 +++
 drivers/gpu/drm/i915/intel_audio.c | 93 +-
 2 files changed, 99 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index bdc7b3591e1c..542e570b3578 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7370,6 +7370,13 @@ enum {
 #define _HSW_AUD_MISC_CTRL_B   0x65110
 #define HSW_AUD_MISC_CTRL(pipe)_MMIO_PIPE(pipe, 
_HSW_AUD_MISC_CTRL_A, _HSW_AUD_MISC_CTRL_B)
 
+#define _HSW_AUD_M_CTS_ENABLE_A0x65028
+#define _HSW_AUD_M_CTS_ENABLE_B0x65128
+#define HSW_AUD_M_CTS_ENABLE(pipe) _MMIO_PIPE(pipe, 
_HSW_AUD_M_CTS_ENABLE_A, _HSW_AUD_M_CTS_ENABLE_B)
+#define   AUD_M_CTS_M_VALUE_INDEX  (1 << 21)
+#define   AUD_M_CTS_M_PROG_ENABLE  (1 << 20)
+#define   AUD_CONFIG_M_MASK0xf
+
 #define _HSW_AUD_DIP_ELD_CTRL_ST_A 0x650b4
 #define _HSW_AUD_DIP_ELD_CTRL_ST_B 0x651b4
 #define HSW_AUD_DIP_ELD_CTRL(pipe) _MMIO_PIPE(pipe, 
_HSW_AUD_DIP_ELD_CTRL_ST_A, _HSW_AUD_DIP_ELD_CTRL_ST_B)
diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index 1a5c21209446..813fd74d9c8d 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -57,6 +57,63 @@
  * struct _audio_component_audio_ops @audio_ops is called from i915 
driver.
  */
 
+/* DP N/M table */
+#define LC_540M54
+#define LC_270M27
+#define LC_162M162000
+
+struct dp_aud_n_m {
+   int sample_rate;
+   int clock;
+   u16 m;
+   u16 n;
+};
+
+/* Values according to DP 1.4 Table 2-104 */
+static const struct dp_aud_n_m dp_aud_n_m[] = {
+   { 32000, LC_162M, 1024, 10125 },
+   { 44100, LC_162M, 784, 5625 },
+   { 48000, LC_162M, 512, 3375 },
+   { 64000, LC_162M, 2048, 10125 },
+   { 88200, LC_162M, 1568, 5625 },
+   { 96000, LC_162M, 1024, 3375 },
+   { 128000, LC_162M, 4096, 10125 },
+   { 176400, LC_162M, 3136, 5625 },
+   { 192000, LC_162M, 2048, 3375 },
+   { 32000, LC_270M, 1024, 16875 },
+   { 44100, LC_270M, 784, 9375 },
+   { 48000, LC_270M, 512, 5625 },
+   { 64000, LC_270M, 2048, 16875 },
+   { 88200, LC_270M, 1568, 9375 },
+   { 96000, LC_270M, 1024, 5625 },
+   { 128000, LC_270M, 4096, 16875 },
+   { 176400, LC_270M, 3136, 9375 },
+   { 192000, LC_270M, 2048, 5625 },
+   { 32000, LC_540M, 1024, 33750 },
+   { 44100, LC_540M, 784, 18750 },
+   { 48000, LC_540M, 512, 11250 },
+   { 64000, LC_540M, 2048, 33750 },
+   { 88200, LC_540M, 1568, 18750 },
+   { 96000, LC_540M, 1024, 11250 },
+   { 128000, LC_540M, 4096, 33750 },
+   { 176400, LC_540M, 3136, 18750 },
+   { 192000, LC_540M, 2048, 11250 },
+};
+
+static const struct dp_aud_n_m *
+audio_config_dp_get_n_m(struct intel_crtc *intel_crtc, int rate)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(dp_aud_n_m); i++) {
+   if (rate == dp_aud_n_m[i].sample_rate &&
+   intel_crtc->config->port_clock == dp_aud_n_m[i].clock)
+   return _aud_n_m[i];
+   }
+
+   return NULL;
+}
+
 static const struct {
int clock;
u32 config;
@@ -225,16 +282,43 @@ hsw_dp_audio_config_update(struct intel_crtc *intel_crtc, 
enum port port,
   const struct drm_display_mode *adjusted_mode)
 {
struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
+   struct i915_audio_component *acomp = dev_priv->audio_component;
+   int rate = acomp ? acomp->aud_sample_rate[port] : 0;
+   const struct dp_aud_n_m *nm = audio_config_dp_get_n_m(intel_crtc, rate);
enum pipe pipe = intel_crtc->pipe;
u32 tmp;
 
+   if (nm)
+   DRM_DEBUG_KMS("using Maud %u, Naud %u\n", nm->m, nm->n);
+   else
+   DRM_DEBUG_KMS("using automatic Maud, Naud\n");
+
tmp = I915_READ(HSW_AUD_CFG(pipe));
tmp &= 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: fix comment on I915_{READ,WRITE}_FW (rev2)

[Arkadiusz Hiler]

On Tue, Oct 25, 2016 at 04:27:26PM +0200, Saarinen, Jani wrote:
> > == Series Details ==
> > 
> > Series: drm/i915: fix comment on I915_{READ,WRITE}_FW (rev2)
> > URL   : https://patchwork.freedesktop.org/series/14334/
> > State : failure
> > 
> > == Summary ==
> > 
> > Series 14334v2 drm/i915: fix comment on I915_{READ,WRITE}_FW
> > https://patchwork.freedesktop.org/api/1.0/series/14334/revisions/2/mbox/
> > 
> > Test drv_module_reload_basic:
> > pass   -> DMESG-WARN (fi-skl-6700hq)
> > skip   -> PASS   (fi-skl-6260u)
> > Test gem_exec_suspend:
> > Subgroup basic-s3:
> > dmesg-warn -> PASS   (fi-skl-6700hq)
> > Test gem_sync:
> > Subgroup basic-many-each:
> > pass   -> FAIL   (fi-ilk-650)
> All can now see data details on logs link below but here still few times to 
> remind ;)

Thanks! I was figuring out what to do with this error, therefore my
dealy with the reply. I had access to the results even before c;

> Out   
> IGT-Version: 1.16-g1df15af (x86_64) (Linux: 4.9.0-rc2-CI-Patchwork_2809+ 
> x86_64)
> Using Legacy submission 
> render completed 737 cycles
> bsd completed 324 cycles
> Stack trace:
>   #0 [__igt_fail_assert+0x101]
>   #1 [store_many+0x284]
>   #2 [+0x284]
> Subtest basic-many-each: FAIL (5.573s)
> 
> Err   
> (gem_sync:7909) CRITICAL: Test assertion failure function store_many, file 
> gem_sync.c:506:
> (gem_sync:7909) CRITICAL: Failed assertion: 
> intel_detect_and_clear_missed_interrupts(fd) == 0
> (gem_sync:7909) CRITICAL: error: 4 != 0
> Subtest basic-many-each failed.
>  DEBUG 
> (gem_sync:7909) INFO: render completed 737 cycles
> (gem_sync:7909) INFO: bsd completed 324 cycles
> (gem_sync:7909) CRITICAL: Test assertion failure function store_many, file 
> gem_sync.c:506:
> (gem_sync:7909) CRITICAL: Failed assertion: 
> intel_detect_and_clear_missed_interrupts(fd) == 0
> (gem_sync:7909) CRITICAL: error: 4 != 0
>   END  

That's definately not caused by this change as only one comment in the
code is affected.

Should I put bugzilla on it? (I haven't found any on the issue already).

> > Test kms_pipe_crc_basic:
> > Subgroup suspend-read-crc-pipe-a:
> > dmesg-warn -> PASS   (fi-skl-6700hq)
> > Subgroup suspend-read-crc-pipe-b:
> > pass   -> DMESG-WARN (fi-skl-6770hq)
> > dmesg-warn -> PASS   (fi-skl-6700hq)
> > Subgroup suspend-read-crc-pipe-c:
> > dmesg-warn -> PASS   (fi-skl-6700hq)
> > 
> > 
> > cd1dba8d045ce0d59029226108f0ad7b35a9d061 drm-intel-nightly: 2016y-10m-
> > 25d-09h-26m-24s UTC integration manifest
> > 98dec85 drm/i915: fix comment on I915_{READ, WRITE}_FW
> > 
> > Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2809/
> > 
> > == Logs ==
> > 
> > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2809/

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/lspcon: Work around resume failure (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/lspcon: Work around resume failure (rev2)
URL   : https://patchwork.freedesktop.org/series/14280/
State : warning

== Summary ==

Series 14280v2 drm/i915/lspcon: Work around resume failure
https://patchwork.freedesktop.org/api/1.0/series/14280/revisions/2/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-6700hq)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-skl-6770hq)
dmesg-warn -> PASS   (fi-skl-6700hq)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> SKIP   (fi-byt-n2820)
Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-skl-6770hq)
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (fi-skl-6700hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:231  dwarn:1   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

3ce99d02d8f2b7d1414d20d5972f8e277b33693e drm-intel-nightly: 
2016y-10m-25d-13h-55m-46s UTC integration manifest
ab50b11 drm/i915/lspcon: Add workaround for resuming in PCON mode
607efb9 drm/i915/lspcon: Get DDC adapter via container_of() instead of cached 
ptr
e281e36 drm/i915/dp: Read DP descriptor for eDP and LSPCON too
742a374 drm/i915/lspcon: Fail LSPCON probe if the start of DPCD can't be read
e3a2cc0 drm/i915/dp: Print full branch/sink descriptor
d6131ca drm/i915/dp: Print only sink or branch specific OUI based on dev type
3c3c2a2 drm/i915/dp: Remove debug dependency of DPCD SW/HW revision read

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2810/

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2810/
___
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: Remove two invalid warns

[Chris Wilson]

On Tue, Oct 25, 2016 at 03:12:51PM +0100, Tvrtko Ursulin wrote:
> 
> On 25/10/2016 15:09, Chris Wilson wrote:
> >On Tue, Oct 25, 2016 at 03:00:24PM +0100, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin 
> >>
> >>Objects can have multiple VMAs used for display in which
> >>case assertion that objects must not be pinned for display
> >>more times than their single display related VMA is incorrect.
> >
> >But each of those vma are pinned, as many times as they are used by
> >display. This explanation doesn't hold.
> 
> We can have a normal and a rotated vma, each pinned once, object
> pinned therefore pinned to display twice.

Oh, vma_pin_count not obj_pin_count. Bleh. Is the warn useful to keep,
and so we need to iterate over all vma? Probably not. Especially as we
then start asking questions like, should we track pin_display on the vma
as well for better accuracy in their assertion

s/their single dislay related/the current/

Ok, I don't have a great idea for replacing it with some other early
warning signal. With the slight tweak to the changelog,

Reviewed-by: Chris Wilson 
-Chris

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Rotated view does not need a fence

[Tvrtko Ursulin]

On 25/10/2016 15:12, Ville Syrjälä wrote:

On Tue, Oct 25, 2016 at 03:00:23PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

We do not need to set up a fence for the rotated view.

Display does not need it and no one can access it.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 


Broken by 05a20d098db1 ("drm/i915: Move map-and-fenceable tracking to
the VMA") ?


Wasn't sure if this is considered a breakage. Will add when you made the 
effort to dig out the commit, thanks!


Regards,

Tvrtko




---
 drivers/gpu/drm/i915/i915_gem_gtt.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index c241d8143255..c79d7ab75003 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -251,7 +251,8 @@ static inline bool i915_vma_is_ggtt(const struct i915_vma 
*vma)

 static inline bool i915_vma_is_map_and_fenceable(const struct i915_vma *vma)
 {
-   return vma->flags & I915_VMA_CAN_FENCE;
+   return vma->flags & I915_VMA_CAN_FENCE &&
+  vma->ggtt_view.type != I915_GGTT_VIEW_ROTATED;
 }

 static inline bool i915_vma_is_closed(const struct i915_vma *vma)
--
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 2/2] drm/i915: Remove two invalid warns

[Tvrtko Ursulin]

On 25/10/2016 15:12, Tvrtko Ursulin wrote:


On 25/10/2016 15:09, Chris Wilson wrote:

On Tue, Oct 25, 2016 at 03:00:24PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Objects can have multiple VMAs used for display in which
case assertion that objects must not be pinned for display
more times than their single display related VMA is incorrect.


But each of those vma are pinned, as many times as they are used by
display. This explanation doesn't hold.


We can have a normal and a rotated vma, each pinned once, object pinned
therefore pinned to display twice.


P.S. I need a fixes tag for this as well. Looking for a suitable 
candidate in the VMA rewrite series.. suggestions welcome. :)


Regards,

Tvrtko

___
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: Remove two invalid warns

[Tvrtko Ursulin]

On 25/10/2016 15:09, Chris Wilson wrote:

On Tue, Oct 25, 2016 at 03:00:24PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Objects can have multiple VMAs used for display in which
case assertion that objects must not be pinned for display
more times than their single display related VMA is incorrect.


But each of those vma are pinned, as many times as they are used by
display. This explanation doesn't hold.


We can have a normal and a rotated vma, each pinned once, object pinned 
therefore pinned to display twice.


Regards,

Tvrtko

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: fix comment on I915_{READ,WRITE}_FW (rev2)

[Saarinen, Jani]

> == Series Details ==
> 
> Series: drm/i915: fix comment on I915_{READ,WRITE}_FW (rev2)
> URL   : https://patchwork.freedesktop.org/series/14334/
> State : failure
> 
> == Summary ==
> 
> Series 14334v2 drm/i915: fix comment on I915_{READ,WRITE}_FW
> https://patchwork.freedesktop.org/api/1.0/series/14334/revisions/2/mbox/
> 
> Test drv_module_reload_basic:
> pass   -> DMESG-WARN (fi-skl-6700hq)
> skip   -> PASS   (fi-skl-6260u)
> Test gem_exec_suspend:
> Subgroup basic-s3:
> dmesg-warn -> PASS   (fi-skl-6700hq)
> Test gem_sync:
> Subgroup basic-many-each:
> pass   -> FAIL   (fi-ilk-650)
All can now see data details on logs link below but here still few times to 
remind ;)

Out 
IGT-Version: 1.16-g1df15af (x86_64) (Linux: 4.9.0-rc2-CI-Patchwork_2809+ x86_64)
Using Legacy submission 
render completed 737 cycles
bsd completed 324 cycles
Stack trace:
  #0 [__igt_fail_assert+0x101]
  #1 [store_many+0x284]
  #2 [+0x284]
Subtest basic-many-each: FAIL (5.573s)

Err 
(gem_sync:7909) CRITICAL: Test assertion failure function store_many, file 
gem_sync.c:506:
(gem_sync:7909) CRITICAL: Failed assertion: 
intel_detect_and_clear_missed_interrupts(fd) == 0
(gem_sync:7909) CRITICAL: error: 4 != 0
Subtest basic-many-each failed.
 DEBUG 
(gem_sync:7909) INFO: render completed 737 cycles
(gem_sync:7909) INFO: bsd completed 324 cycles
(gem_sync:7909) CRITICAL: Test assertion failure function store_many, file 
gem_sync.c:506:
(gem_sync:7909) CRITICAL: Failed assertion: 
intel_detect_and_clear_missed_interrupts(fd) == 0
(gem_sync:7909) CRITICAL: error: 4 != 0
  END  

> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-a:
> dmesg-warn -> PASS   (fi-skl-6700hq)
> Subgroup suspend-read-crc-pipe-b:
> pass   -> DMESG-WARN (fi-skl-6770hq)
> dmesg-warn -> PASS   (fi-skl-6700hq)
> Subgroup suspend-read-crc-pipe-c:
> dmesg-warn -> PASS   (fi-skl-6700hq)
> 
> fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15
> fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42
> fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30
> fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31
> fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36
> fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22
> fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:1   skip:61
> fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26
> fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26
> fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24
> fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14
> fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23
> fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23
> fi-skl-6770hqtotal:246  pass:231  dwarn:1   dfail:0   fail:0   skip:14
> fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37
> fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38
> 
> cd1dba8d045ce0d59029226108f0ad7b35a9d061 drm-intel-nightly: 2016y-10m-
> 25d-09h-26m-24s UTC integration manifest
> 98dec85 drm/i915: fix comment on I915_{READ, WRITE}_FW
> 
> Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2809/
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2809/


Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo


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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Rotated view does not need a fence

[Ville Syrjälä]

On Tue, Oct 25, 2016 at 03:17:09PM +0100, Chris Wilson wrote:
> On Tue, Oct 25, 2016 at 05:12:22PM +0300, Ville Syrjälä wrote:
> > On Tue, Oct 25, 2016 at 03:00:23PM +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin 
> > > 
> > > We do not need to set up a fence for the rotated view.
> > > 
> > > Display does not need it and no one can access it.
> > > 
> > > Signed-off-by: Tvrtko Ursulin 
> > > Cc: Chris Wilson 
> > > Cc: Joonas Lahtinen 
> > 
> > Broken by 05a20d098db1 ("drm/i915: Move map-and-fenceable tracking to
> > the VMA") ?
> 
> Have a bug link? :)
> 
> There shouldn't be any fail other than reserving a fence, right?

I suppose not. But doesn't hurt to toss in a Fixes tag anyway.

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Rotated view does not need a fence

[Chris Wilson]

On Tue, Oct 25, 2016 at 05:12:22PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 25, 2016 at 03:00:23PM +0100, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin 
> > 
> > We do not need to set up a fence for the rotated view.
> > 
> > Display does not need it and no one can access it.
> > 
> > Signed-off-by: Tvrtko Ursulin 
> > Cc: Chris Wilson 
> > Cc: Joonas Lahtinen 
> 
> Broken by 05a20d098db1 ("drm/i915: Move map-and-fenceable tracking to
> the VMA") ?

Have a bug link? :)

There shouldn't be any fail other than reserving a fence, right?
-Chris

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Rotated view does not need a fence

[Ville Syrjälä]

On Tue, Oct 25, 2016 at 03:00:23PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> We do not need to set up a fence for the rotated view.
> 
> Display does not need it and no one can access it.
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 

Broken by 05a20d098db1 ("drm/i915: Move map-and-fenceable tracking to
the VMA") ?

> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index c241d8143255..c79d7ab75003 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -251,7 +251,8 @@ static inline bool i915_vma_is_ggtt(const struct i915_vma 
> *vma)
>  
>  static inline bool i915_vma_is_map_and_fenceable(const struct i915_vma *vma)
>  {
> - return vma->flags & I915_VMA_CAN_FENCE;
> + return vma->flags & I915_VMA_CAN_FENCE &&
> +vma->ggtt_view.type != I915_GGTT_VIEW_ROTATED;
>  }
>  
>  static inline bool i915_vma_is_closed(const struct i915_vma *vma)
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Remove two invalid warns

[Chris Wilson]

On Tue, Oct 25, 2016 at 03:00:24PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Objects can have multiple VMAs used for display in which
> case assertion that objects must not be pinned for display
> more times than their single display related VMA is incorrect.

But each of those vma are pinned, as many times as they are used by
display. This explanation doesn't hold.
-Chris

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Rotated view does not need a fence

[Chris Wilson]

On Tue, Oct 25, 2016 at 03:00:23PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> We do not need to set up a fence for the rotated view.
> 
> Display does not need it and no one can access it.

See __i915_vma_set_map_and_fenceable. Stop the bit at source. And
include the above line as a comment.
-Chris

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix SKL+ 90/270 degree rotated plane coordinate computation

[Tvrtko Ursulin]

On 24/10/2016 17:13, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

Pass the framebuffer size in .16 fixed point coordinates to
drm_rect_rotate() since that's what the source coordinates are as well
at this stage. We used to do this part of the computation in integer
coordinates, but that got changed when moving the computation to
happen in the check phase of the operation. Unfortunately I forgot
to shift up the fb width and height appropriately.

With the bogus size we ended up with some negative fb offset, which when
added to the vma offset caused out scanout to start at an offset earlier
than we inteded. Eg. when testing on my SKL I saw a row of incorrect
tiles at the top of my screen.

Cc: Tvrtko Ursulin 
Cc: Sivakumar Thulasimani 
Cc: drm-intel-fi...@lists.freedesktop.org
Fixes: b63a16f6cd89 ("drm/i915: Compute display surface offset in the plane check 
hook for SKL+")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5a036999487b..c783f884f85d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2985,7 +2985,8 @@ int skl_check_plane_surface(struct intel_plane_state 
*plane_state)
/* Rotate src coordinates to match rotated GTT view */
if (drm_rotation_90_or_270(rotation))
drm_rect_rotate(_state->base.src,
-   fb->width, fb->height, DRM_ROTATE_270);
+   fb->width << 16, fb->height << 16,
+   DRM_ROTATE_270);

/*
 * Handle the AUX surface first since



Tested-by: Tvrtko Ursulin 

Regards,

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

[Intel-gfx] [PATCH 1/2] drm/i915: Rotated view does not need a fence

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

We do not need to set up a fence for the rotated view.

Display does not need it and no one can access it.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_gtt.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index c241d8143255..c79d7ab75003 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -251,7 +251,8 @@ static inline bool i915_vma_is_ggtt(const struct i915_vma 
*vma)
 
 static inline bool i915_vma_is_map_and_fenceable(const struct i915_vma *vma)
 {
-   return vma->flags & I915_VMA_CAN_FENCE;
+   return vma->flags & I915_VMA_CAN_FENCE &&
+  vma->ggtt_view.type != I915_GGTT_VIEW_ROTATED;
 }
 
 static inline bool i915_vma_is_closed(const struct i915_vma *vma)
-- 
2.7.4

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

[Intel-gfx] [PATCH 2/2] drm/i915: Remove two invalid warns

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Objects can have multiple VMAs used for display in which
case assertion that objects must not be pinned for display
more times than their single display related VMA is incorrect.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_gem.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0e26ee96856e..96f48d2c971c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3595,8 +3595,6 @@ i915_gem_object_pin_to_display_plane(struct 
drm_i915_gem_object *obj,
 
vma->display_alignment = max_t(u64, vma->display_alignment, alignment);
 
-   WARN_ON(obj->pin_display > i915_vma_pin_count(vma));
-
i915_gem_object_flush_cpu_write_domain(obj);
 
old_write_domain = obj->base.write_domain;
@@ -3633,7 +3631,6 @@ i915_gem_object_unpin_from_display_plane(struct i915_vma 
*vma)
list_move_tail(>vm_link, >vm->inactive_list);
 
i915_vma_unpin(vma);
-   WARN_ON(vma->obj->pin_display > i915_vma_pin_count(vma));
 }
 
 /**
-- 
2.7.4

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: fix comment on I915_{READ,WRITE}_FW (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: fix comment on I915_{READ,WRITE}_FW (rev2)
URL   : https://patchwork.freedesktop.org/series/14334/
State : failure

== Summary ==

Series 14334v2 drm/i915: fix comment on I915_{READ,WRITE}_FW
https://patchwork.freedesktop.org/api/1.0/series/14334/revisions/2/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-skl-6700hq)
skip   -> PASS   (fi-skl-6260u)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test gem_sync:
Subgroup basic-many-each:
pass   -> FAIL   (fi-ilk-650)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-skl-6770hq)
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (fi-skl-6700hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:1   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:231  dwarn:1   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

cd1dba8d045ce0d59029226108f0ad7b35a9d061 drm-intel-nightly: 
2016y-10m-25d-09h-26m-24s UTC integration manifest
98dec85 drm/i915: fix comment on I915_{READ, WRITE}_FW

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2809/

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2809/
___
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: Include the kernel uptime in the error state (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Include the kernel uptime in the error state (rev2)
URL   : https://patchwork.freedesktop.org/series/14320/
State : success

== Summary ==

Series 14320v2 drm/i915: Include the kernel uptime in the error state
https://patchwork.freedesktop.org/api/1.0/series/14320/revisions/2/mbox/

Test drv_module_reload_basic:
skip   -> PASS   (fi-skl-6260u)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
skip   -> PASS   (fi-byt-n2820)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:219  dwarn:4   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

cd1dba8d045ce0d59029226108f0ad7b35a9d061 drm-intel-nightly: 
2016y-10m-25d-09h-26m-24s UTC integration manifest
a81dd95 drm/i915: Include the kernel uptime in the error state

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2808/

== Logs ==

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

[Intel-gfx] [PATCH v3 4/8] drm/i915/dp: Print full branch/sink descriptor

[Imre Deak]

Extend the branch/sink descriptor info with the missing device ID
field. While at it also read out all the descriptor registers in one
transfer and make the debug print more compact.

v2: (Jani)
- Cache the descriptor in intel_dp.
- Split out this change into a separate patch.
v3: (Jani)
- Fix return value check of __intel_dp_read_desc().
- Use %pE instead of %s to print the device ID.

Cc: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_dp.c  | 63 ++--
 drivers/gpu/drm/i915/intel_drv.h | 10 +++
 2 files changed, 32 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1991250..57260a2 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1451,34 +1451,35 @@ static void intel_dp_print_rates(struct intel_dp 
*intel_dp)
DRM_DEBUG_KMS("common rates: %s\n", str);
 }
 
-static void intel_dp_print_hw_revision(struct intel_dp *intel_dp)
+static bool
+__intel_dp_read_desc(struct intel_dp *intel_dp, struct intel_dp_desc *desc)
 {
-   uint8_t rev;
-   int len;
+   u32 base = drm_dp_is_branch(intel_dp->dpcd) ? DP_BRANCH_OUI :
+ DP_SINK_OUI;
 
-   if (!drm_dp_is_branch(intel_dp->dpcd))
-   return;
-
-   len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_HW_REV, , 1);
-   if (len < 0)
-   return;
-
-   DRM_DEBUG_KMS("sink hw revision: %d.%d\n", (rev & 0xf0) >> 4, rev & 
0xf);
+   return drm_dp_dpcd_read(_dp->aux, base, desc, sizeof(*desc)) ==
+  sizeof(*desc);
 }
 
-static void intel_dp_print_sw_revision(struct intel_dp *intel_dp)
+static bool intel_dp_read_desc(struct intel_dp *intel_dp)
 {
-   uint8_t rev[2];
-   int len;
+   struct intel_dp_desc *desc = _dp->desc;
+   bool oui_sup = intel_dp->dpcd[DP_DOWN_STREAM_PORT_COUNT] &
+  DP_OUI_SUPPORT;
+   int dev_id_len;
 
-   if (!drm_dp_is_branch(intel_dp->dpcd))
-   return;
+   if (!__intel_dp_read_desc(intel_dp, desc))
+   return false;
 
-   len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_SW_REV, , 2);
-   if (len < 0)
-   return;
+   dev_id_len = strnlen(desc->device_id, sizeof(desc->device_id));
+   DRM_DEBUG_KMS("DP %s: OUI %*phD%s dev-ID %*pE HW-rev %d.%d SW-rev 
%d.%d\n",
+ drm_dp_is_branch(intel_dp->dpcd) ? "branch" : "sink",
+ (int)sizeof(desc->oui), desc->oui, oui_sup ? "" : "(NS)",
+ dev_id_len, desc->device_id,
+ desc->hw_rev >> 4, desc->hw_rev & 0xf,
+ desc->sw_major_rev, desc->sw_minor_rev);
 
-   DRM_DEBUG_KMS("sink sw revision: %d.%d\n", rev[0], rev[1]);
+   return true;
 }
 
 static int rate_to_index(int find, const int *rates)
@@ -3621,23 +3622,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
return true;
 }
 
-static void
-intel_dp_probe_oui(struct intel_dp *intel_dp)
-{
-   bool is_branch = drm_dp_is_branch(intel_dp->dpcd);
-   u8 buf[3];
-
-   if (!(intel_dp->dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_OUI_SUPPORT))
-   return;
-
-   if (drm_dp_dpcd_read(_dp->aux,
-is_branch ? DP_BRANCH_OUI : DP_SINK_OUI,
-buf, 3) == 3)
-   DRM_DEBUG_KMS("%s OUI: %02hx%02hx%02hx\n",
- is_branch ? "Branch" : "Sink",
- buf[0], buf[1], buf[2]);
-}
-
 static bool
 intel_dp_can_mst(struct intel_dp *intel_dp)
 {
@@ -4416,10 +4400,7 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
 
intel_dp_print_rates(intel_dp);
 
-   intel_dp_probe_oui(intel_dp);
-
-   intel_dp_print_hw_revision(intel_dp);
-   intel_dp_print_sw_revision(intel_dp);
+   intel_dp_read_desc(intel_dp);
 
intel_dp_configure_mst(intel_dp);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 16b33f5..4c9f953 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -883,6 +883,14 @@ enum link_m_n_set {
M2_N2
 };
 
+struct intel_dp_desc {
+   u8 oui[3];
+   u8 device_id[6];
+   u8 hw_rev;
+   u8 sw_major_rev;
+   u8 sw_minor_rev;
+} __packed;
+
 struct intel_dp {
i915_reg_t output_reg;
i915_reg_t aux_ch_ctl_reg;
@@ -905,6 +913,8 @@ struct intel_dp {
/* sink rates as reported by DP_SUPPORTED_LINK_RATES */
uint8_t num_sink_rates;
int sink_rates[DP_MAX_SUPPORTED_RATES];
+   /* sink or branch descriptor */
+   struct intel_dp_desc desc;
struct drm_dp_aux aux;
uint8_t train_set[4];
int panel_power_up_delay;
-- 
2.5.0

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

[Intel-gfx] [PATCH v2] drm/i915: fix comment on I915_{READ, WRITE}_FW

[Arkadiusz Hiler]

Comment mentioned use of intel_uncore_forcewake_irq{unlock, lock}
functions which are nonexistent (and never were).

The description was also incomplete and could cause confusion. Updated
comment is more elaborate on usage and caveats.

v2: mention __locked variant of intel_uncore_forcewake_{get,put} instead
of plain ones

Cc: Chris Wilson 
Cc: Matthew Auld 
Cc: Mika Kuoppala 
Signed-off-by: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/i915_drv.h | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b4cb1f0..e0f3fa4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3840,11 +3840,33 @@ __raw_write(64, q)
 #undef __raw_write
 
 /* These are untraced mmio-accessors that are only valid to be used inside
- * critical sections inside IRQ handlers where forcewake is explicitly
+ * critical sections, such as inside IRQ handlers, where forcewake is 
explicitly
  * controlled.
+ *
  * Think twice, and think again, before using these.
- * Note: Should only be used between intel_uncore_forcewake_irqlock() and
- * intel_uncore_forcewake_irqunlock().
+ *
+ * As an example, these accessors can possibly be used between:
+ *
+ * spin_lock_irq(_priv->uncore.lock);
+ * intel_uncore_forcewake_get__locked();
+ *
+ * and
+ *
+ * intel_uncore_forcewake_put__locked();
+ * spin_unlock_irq(_priv->uncore.lock);
+ *
+ *
+ * Note: some registers may not need forcewake held, so
+ * intel_uncore_forcewake_{get,put} can be omitted, see
+ * intel_uncore_forcewake_for_reg().
+ *
+ * Certain architectures will die if the same cacheline is concurrently 
accessed
+ * by different clients (e.g. Ivybridge). Access to registers should therefore
+ * generally be serialised, by either the dev_priv->uncore.lock or a more
+ * localised lock guarding all access to that bank of registers.
+ *
+ * Code may be serialised by different lock, so immediate
+ * spin_{lock,unlock}_irq() may not be necessary.
  */
 #define I915_READ_FW(reg__) __raw_i915_read32(dev_priv, (reg__))
 #define I915_WRITE_FW(reg__, val__) __raw_i915_write32(dev_priv, (reg__), 
(val__))
-- 
2.7.4

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for dma-buf: Rename struct fence to dma_fence (rev3)

[Patchwork]

== Series Details ==

Series: dma-buf: Rename struct fence to dma_fence (rev3)
URL   : https://patchwork.freedesktop.org/series/14324/
State : warning

== Summary ==

Series 14324v3 dma-buf: Rename struct fence to dma_fence
https://patchwork.freedesktop.org/api/1.0/series/14324/revisions/3/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-skl-6700hq)
skip   -> PASS   (fi-skl-6260u)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
skip   -> PASS   (fi-byt-n2820)
Test kms_force_connector_basic:
Subgroup force-edid:
pass   -> DMESG-WARN (fi-ivb-3770)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (fi-skl-6700hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:219  dwarn:1   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

cd1dba8d045ce0d59029226108f0ad7b35a9d061 drm-intel-nightly: 
2016y-10m-25d-09h-26m-24s UTC integration manifest
680414e dma-buf: Rename struct fence to dma_fence

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2807/

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/4] igt_fb: Add Y-tiling support

[Tvrtko Ursulin]

On 25/10/2016 13:06, Paneri, Praveen wrote:

Hi Tvrtko,

Along with this change I made following change in the kernel side. I was not 
sure if this is a hack of a legitimate change. Could you please give me a 
pointer about how to move fwd from here? Without this all Y-tiling tests would 
fail.

--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15406,8 +15406,7 @@ static int intel_framebuffer_init(struct drm_device 
*dev,
if (obj->tiling_mode == I915_TILING_X)
mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED;
else if (obj->tiling_mode == I915_TILING_Y) {
-   DRM_DEBUG("No Y tiling for legacy addfb\n");
-   return -EINVAL;
+   mode_cmd->modifier[0] = I915_FORMAT_MOD_Y_TILED;
}
}


It would be a controversial change, "beyond my pay grade". :)

If you drop this particular IGT patch, you can still create Y tiled 
framebuffers and display them (as the existing tests already do that). 
So when you say that all Y tiling tests fail without this kernel hack, 
which tests you are referring to?


Regards,

Tvrtko


Regards,
Praveen


-Original Message-
From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
Sent: Tuesday, October 25, 2016 1:36 PM
To: Paneri, Praveen ; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/4] igt_fb: Add Y-tiling support


On 24/10/2016 17:55, Praveen Paneri wrote:

This adds Y-tiling check in igt_create_fb_with_bo_size as now we
should also be able to create Y-tiled FBs.

Signed-off-by: Praveen Paneri 
---
 lib/igt_fb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/igt_fb.c b/lib/igt_fb.c index 47472f4..bf1d372 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -608,7 +608,8 @@ igt_create_fb_with_bo_size(int fd, int width, int height,
  __func__, fb->gem_handle, fb->stride);

if (tiling != LOCAL_DRM_FORMAT_MOD_NONE &&
-   tiling != LOCAL_I915_FORMAT_MOD_X_TILED) {
+   tiling != LOCAL_I915_FORMAT_MOD_X_TILED &&
+   tiling != LOCAL_I915_FORMAT_MOD_Y_TILED) {
do_or_die(__kms_addfb(fd, fb->gem_handle, width, height,
  fb->stride, format, tiling,
  LOCAL_DRM_MODE_FB_MODIFIERS, _id));



This works now? Ie. doesn't hit "No Y Tiling for legacy addfb" error in the 
driver?

Regards,

Tvrtko


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

Re: [Intel-gfx] [PATCH] drm/i915: fix comment on I915_{READ, WRITE}_FW

[Chris Wilson]

On Tue, Oct 25, 2016 at 02:15:23PM +0200, Arkadiusz Hiler wrote:
> Comment mentioned use of intel_uncore_forcewake_irq{unlock, lock}
> functions which are nonexistent (and never were).
> 
> The description was also incomplete and could cause confusion. Updated
> comment is more elaborate on usage and caveats.
> 
> Cc: Chris Wilson 
> Cc: Matthew Auld 
> Cc: Mika Kuoppala 
> Signed-off-by: Arkadiusz Hiler 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 28 +---
>  1 file changed, 25 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index b4cb1f0..39238fc 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3840,11 +3840,33 @@ __raw_write(64, q)
>  #undef __raw_write
>  
>  /* These are untraced mmio-accessors that are only valid to be used inside
> - * critical sections inside IRQ handlers where forcewake is explicitly
> + * critical sections, such as inside IRQ handlers, where forcewake is 
> explicitly
>   * controlled.
> + *
>   * Think twice, and think again, before using these.
> - * Note: Should only be used between intel_uncore_forcewake_irqlock() and
> - * intel_uncore_forcewake_irqunlock().
> + *
> + * As an example, these accessors can possibly be used between:
> + *
> + * spin_lock_irq(_priv->uncore.lock);
> + * intel_uncore_forcewake_get();

Ugh, intel_uncore_forcewake_get__locked();

> + *
> + * and
> + *
> + * intel_uncore_forcewake_put();

intel_uncore_forcewake_put__locked();

> + * spin_unlock_irq(_priv->uncore.lock);

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Link Rate fallback on Link training failure

[Jani Nikula]

On Sat, 22 Oct 2016, Manasi Navare  wrote:
> If link training at a link rate optimal for a particular
> mode fails during modeset's atomic commit phase, then we
> let the modeset complete and then retry. We save the link rate
> value at which link training failed and use a lower link rate
> to prune the modes. It will redo the modeset on the current mode
> at lower link rate or if the current mode gets pruned due to lower
> link constraints then, it will send a hotplug uevent for userspace
> to handle it.
>
> This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
> 4.3.1.6.
>
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c  | 15 +-
>  drivers/gpu/drm/i915/intel_dp.c   | 69 
> ++-
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 12 +++--
>  drivers/gpu/drm/i915/intel_drv.h  |  6 ++-
>  4 files changed, 95 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index fb18d69..451433b 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1712,6 +1712,8 @@ static void intel_ddi_pre_enable_dp(struct 
> intel_encoder *encoder,
>   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   enum port port = intel_ddi_get_encoder_port(encoder);
> + struct intel_connector *intel_connector = intel_dp->attached_connector;
> + struct drm_connector *connector = _connector->base;
>  
>   intel_dp_set_link_params(intel_dp, link_rate, lane_count,
>link_mst);
> @@ -1722,7 +1724,18 @@ static void intel_ddi_pre_enable_dp(struct 
> intel_encoder *encoder,
>   intel_prepare_dp_ddi_buffers(encoder);
>   intel_ddi_init_dp_buf_reg(encoder);
>   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> - intel_dp_start_link_train(intel_dp);
> + if (!intel_dp_start_link_train(intel_dp)) {
> + DRM_ERROR("Link Training failed at link rate = %d, lane count = 
> %d\n",
> +   link_rate, lane_count);
> + intel_dp->link_train_failed = true;
> + intel_dp->link_train_failed_link_rate = link_rate;
> + intel_dp->link_train_failed_lane_count = lane_count;

I think eventually you'll need to store a list (array) of failing link
rate, lane count pairs, not just the last that failed. Now you restrict
the link config computation to only reducing the link rate. But
currently (for whatever reason, it's flip-flopped too many times) we
start with wide & slow, meaning that in many cases we've already
exhausted the option to go slower. If optimal fails, maybe we need to
try narrow & fast instead.

BR,
Jani.


> + /* Schedule a Hotplug Uevent to userspace to start modeset */
> + schedule_work(>i915_modeset_retry_work);
> + } else {
> + intel_dp->link_train_failed = false;
> + }
> +
>   if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
>   intel_dp_stop_link_train(intel_dp);
>  }
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index c192e18..5d5f4a7 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -313,6 +313,7 @@ static int intel_dp_link_rate_index(struct intel_dp 
> *intel_dp,
>   int target_clock = mode->clock;
>   int max_rate, mode_rate, max_lanes, max_link_clock;
>   int max_dotclk;
> + int common_rates[DP_MAX_SUPPORTED_RATES] = {};
>  
>   max_dotclk = intel_dp_downstream_max_dotclock(intel_dp);
>  
> @@ -326,8 +327,27 @@ static int intel_dp_link_rate_index(struct intel_dp 
> *intel_dp,
>   target_clock = fixed_mode->clock;
>   }
>  
> - max_link_clock = intel_dp_max_link_rate(intel_dp);
> - max_lanes = intel_dp_max_lane_count(intel_dp);
> + /* Prune the modes based on the link rate that failed */
> + if (intel_dp->link_train_failed_link_rate) {
> + intel_dp->link_rate_index = intel_dp_link_rate_index(intel_dp,
> +  
> common_rates,
> +  
> intel_dp->link_train_failed_link_rate);
> + if (intel_dp->link_rate_index > 0) {
> + max_link_clock = common_rates[intel_dp->link_rate_index 
> - 1];
> + max_lanes = intel_dp_max_lane_count(intel_dp);
> + } else {
> + /* Here we can lower the lane count, but that will be
> +  * added for DP Spec 1.3
> +  */
> + DRM_ERROR("No Valid Mode Supported for this 

[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf: Rename struct fence to dma_fence (rev2)

[Patchwork]

== Series Details ==

Series: dma-buf: Rename struct fence to dma_fence (rev2)
URL   : https://patchwork.freedesktop.org/series/14324/
State : success

== Summary ==

Series 14324v2 dma-buf: Rename struct fence to dma_fence
https://patchwork.freedesktop.org/api/1.0/series/14324/revisions/2/mbox/

Test drv_module_reload_basic:
skip   -> PASS   (fi-skl-6260u)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:219  dwarn:4   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

cd1dba8d045ce0d59029226108f0ad7b35a9d061 drm-intel-nightly: 
2016y-10m-25d-09h-26m-24s UTC integration manifest
7fcdc3b dma-buf: Rename struct fence to dma_fence

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2806/

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: fix comment on I915_{READ,WRITE}_FW

[Arkadiusz Hiler]

Comment mentioned use of intel_uncore_forcewake_irq{unlock, lock}
functions which are nonexistent (and never were).

The description was also incomplete and could cause confusion. Updated
comment is more elaborate on usage and caveats.

Cc: Chris Wilson 
Cc: Matthew Auld 
Cc: Mika Kuoppala 
Signed-off-by: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/i915_drv.h | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b4cb1f0..39238fc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3840,11 +3840,33 @@ __raw_write(64, q)
 #undef __raw_write
 
 /* These are untraced mmio-accessors that are only valid to be used inside
- * critical sections inside IRQ handlers where forcewake is explicitly
+ * critical sections, such as inside IRQ handlers, where forcewake is 
explicitly
  * controlled.
+ *
  * Think twice, and think again, before using these.
- * Note: Should only be used between intel_uncore_forcewake_irqlock() and
- * intel_uncore_forcewake_irqunlock().
+ *
+ * As an example, these accessors can possibly be used between:
+ *
+ * spin_lock_irq(_priv->uncore.lock);
+ * intel_uncore_forcewake_get();
+ *
+ * and
+ *
+ * intel_uncore_forcewake_put();
+ * spin_unlock_irq(_priv->uncore.lock);
+ *
+ *
+ * Note: some registers may not need forcewake held, so
+ * intel_uncore_forcewake_{get,put} can be omitted, see
+ * intel_uncore_forcewake_for_reg().
+ *
+ * Certain architectures will die if the same cacheline is concurrently 
accessed
+ * by different clients (e.g. Ivybridge). Access to registers should therefore
+ * generally be serialised, by either the dev_priv->uncore.lock or a more
+ * localised lock guarding all access to that bank of registers.
+ *
+ * Code may be serialised by different lock, so immediate
+ * spin_{lock,unlock}_irq() may not be necessary.
  */
 #define I915_READ_FW(reg__) __raw_i915_read32(dev_priv, (reg__))
 #define I915_WRITE_FW(reg__, val__) __raw_i915_write32(dev_priv, (reg__), 
(val__))
-- 
2.7.4

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

[Intel-gfx] [CI] drm/i915: Include the kernel uptime in the error state

[Chris Wilson]

As well as knowing when the error occurred, it is more interesting to me
to know how long after booting the error occurred, and for good measure
record the time since last hw initialisation.

Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_drv.h   |  4 
 drivers/gpu/drm/i915/i915_gem.c   |  2 ++
 drivers/gpu/drm/i915/i915_gpu_error.c | 12 ++--
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b4cb1f0f0632..7a621c74254e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -746,6 +746,8 @@ struct intel_display_error_state;
 struct drm_i915_error_state {
struct kref ref;
struct timeval time;
+   struct timeval boottime;
+   struct timeval uptime;
 
struct drm_i915_private *i915;
 
@@ -2099,6 +2101,8 @@ struct drm_i915_private {
 * off the idle_work.
 */
struct delayed_work idle_work;
+
+   ktime_t last_init_time;
} gt;
 
/* perform PHY state sanity checks? */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0e26ee96856e..9361c7b54a7f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4470,6 +4470,8 @@ i915_gem_init_hw(struct drm_device *dev)
enum intel_engine_id id;
int ret;
 
+   dev_priv->gt.last_init_time = ktime_get();
+
/* Double layer security blanket, see i915_gem_init() */
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
 
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 48fece3bb7a9..d5feace8de0d 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -546,9 +546,13 @@ int i915_error_state_to_str(struct 
drm_i915_error_state_buf *m,
}
 
err_printf(m, "%s\n", error->error_msg);
-   err_printf(m, "Time: %ld s %ld us\n", error->time.tv_sec,
-  error->time.tv_usec);
err_printf(m, "Kernel: " UTS_RELEASE "\n");
+   err_printf(m, "Time: %ld s %ld us\n",
+  error->time.tv_sec, error->time.tv_usec);
+   err_printf(m, "Boottime: %ld s %ld us\n",
+  error->boottime.tv_sec, error->boottime.tv_usec);
+   err_printf(m, "Uptime: %ld s %ld us\n",
+  error->uptime.tv_sec, error->uptime.tv_usec);
err_print_capabilities(m, >device_info);
max_hangcheck_score = 0;
for (i = 0; i < ARRAY_SIZE(error->engine); i++) {
@@ -1549,6 +1553,10 @@ static int capture(void *data)
i915_gem_capture_guc_log_buffer(error->i915, error);
 
do_gettimeofday(>time);
+   error->boottime = ktime_to_timeval(ktime_get_boottime());
+   error->uptime =
+   ktime_to_timeval(ktime_sub(ktime_get(),
+  error->i915->gt.last_init_time));
 
error->overlay = intel_overlay_capture_error_state(error->i915);
error->display = intel_display_capture_error_state(error->i915);
-- 
2.10.1

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

Re: [Intel-gfx] [PATCH 1/5] drm: Add atomic helper to redo a modeset on current mode

[Jani Nikula]

On Sat, 22 Oct 2016, Manasi Navare  wrote:
> This function provides a way for the driver to redo a
> modeset on the current mode and retry the link training
> at a lower link rate/lane count/bpp. This will get called
> incase the link training fails during the current modeset.

Based on discussions on #intel-gfx, I would dodge all the problems here
by having the userspace do the modeset.

If we add a connector property to indicate the link status (and this
does not have to be DP or link training specific, really), we can set
that to "bad", and fire off the hotplug uevent. Then userspace has the
information to force a modeset on that connector even if the mode has
not changed. (Credits to Ville for the idea.)

If we find a solution later on that allows us to handle all of this in
kernel, we can do so, and remove the property or always report
"good". Drivers can choose different approaches, depending on the
capabilities of the hardware, for instance.

Deferring this to the userspace does not regress anything now, because
currently we just completely fail and end up with a black screen. The
property would allow an enlightened userspace to fix that. And userspace
can't rely on the property being there, as it's currently not there.


BR,
Jani.


>
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 58 
> +
>  include/drm/drm_atomic_helper.h |  1 +
>  2 files changed, 59 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index f936276..0c1614e 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2895,6 +2895,64 @@ int drm_atomic_helper_connector_dpms(struct 
> drm_connector *connector,
>  EXPORT_SYMBOL(drm_atomic_helper_connector_dpms);
>  
>  /**
> + * drm_atomic_helper_connector_modeset - Force a modeset on a connector
> + * @connector: DRM connector
> + *
> + * Provides a way to redo a modeset with the current mode so that it can
> + * drop the bpp, link rate/lane count and retry the link training.
> + *
> + * Returns:
> + * Returns 0 on success, negative errno numbers on failure.
> + */
> +int
> +drm_atomic_helper_connector_modeset(struct drm_connector *connector)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_modeset_acquire_ctx ctx;
> + struct drm_atomic_state *state;
> + struct drm_connector_state *connector_state;
> + struct drm_crtc_state *crtc_state;
> + int ret = 0;
> +
> + drm_modeset_acquire_init(, 0);
> + state = drm_atomic_state_alloc(dev);
> + if (!state) {
> + ret = -ENOMEM;
> + goto fail;
> + }
> + state->acquire_ctx = 
> +retry:
> + ret = 0;
> + connector_state = drm_atomic_get_connector_state(state, connector);
> + if (IS_ERR(connector_state)) {
> + ret = PTR_ERR(connector_state);
> + goto fail;
> + }
> + if (!connector_state->crtc)
> + goto fail;
> +
> + crtc_state = drm_atomic_get_existing_crtc_state(state,
> + connector_state->crtc);
> + crtc_state->connectors_changed = true;
> + ret = drm_atomic_commit(state);
> +fail:
> + if (ret == -EDEADLK) {
> + drm_atomic_state_clear(state);
> + drm_modeset_backoff();
> + goto retry;
> + }
> +
> + if (state)
> + drm_atomic_state_put(state);
> +
> + drm_modeset_drop_locks();
> + drm_modeset_acquire_fini();
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_connector_modeset);
> +
> +/**
>   * drm_atomic_helper_best_encoder - Helper for _connector_helper_funcs
>   *  ->best_encoder callback
>   * @connector: Connector control structure
> diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> index 7ff92b0..8de24dc 100644
> --- a/include/drm/drm_atomic_helper.h
> +++ b/include/drm/drm_atomic_helper.h
> @@ -126,6 +126,7 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
>   uint32_t flags);
>  int drm_atomic_helper_connector_dpms(struct drm_connector *connector,
>int mode);
> +int drm_atomic_helper_connector_modeset(struct drm_connector *connector);
>  struct drm_encoder *
>  drm_atomic_helper_best_encoder(struct drm_connector *connector);

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

Re: [Intel-gfx] [PATCH] drm/i915: fix comment referencing imaginary functions

[Chris Wilson]

On Tue, Oct 25, 2016 at 12:29:41PM +0100, Matthew Auld wrote:
> > These are untraced mmio-accessors that are only valid to be used inside
> > critical sections inside IRQ handlers where forcewake is explicitly
> > controlled.
> >
> > Think twice, and think again, before using these.
> >
> > Those possibly should be used between:
> >
> > spin_lock_irq(_priv->uncore.lock);
> > intel_uncore_forcewake_get();
> >
> > and
> >
> > intel_uncore_forcewake_put();
> > spin_unlock_irq(_priv->uncore.lock);
> >
> >
> > Note: some registers may not need forcewake held, so
> > intel_uncore_forcewake_{get,put} can be omitted.
> >
> > Code may be serialised by different lock, so immediate
> > spin_{lock,unlock}_irq() may not be necessary.
> Maybe roll that up into a new patch? Assuming Chris is happy...
> 

s/inside IRQ handlers/, such as inside IRQ handlers,/

As an example, these accessors can possibly be used between:

can be omitted, see intel_uncore_forcewake_for_reg().

Certain architectures will die if the same cacheline is concurrently
accessed by different clients (e.g. Ivybridge). Access to registers
should therefore generally be serialised, by either the
dev_priv->uncore.lock or a more localised lock guarding all access to
that bank of registers.

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

Re: [Intel-gfx] [PATCH] drm/i915: fix comment referencing imaginary functions

[Matthew Auld]

> These are untraced mmio-accessors that are only valid to be used inside
> critical sections inside IRQ handlers where forcewake is explicitly
> controlled.
>
> Think twice, and think again, before using these.
>
> Those possibly should be used between:
>
> spin_lock_irq(_priv->uncore.lock);
> intel_uncore_forcewake_get();
>
> and
>
> intel_uncore_forcewake_put();
> spin_unlock_irq(_priv->uncore.lock);
>
>
> Note: some registers may not need forcewake held, so
> intel_uncore_forcewake_{get,put} can be omitted.
>
> Code may be serialised by different lock, so immediate
> spin_{lock,unlock}_irq() may not be necessary.
Maybe roll that up into a new patch? Assuming Chris is happy...
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Include the kernel uptime in the error state

[Matthew Auld]

On 25 October 2016 at 09:16, Chris Wilson  wrote:
> As well as knowing when the error occurred, it is more interesting to me
> to know how long after booting the error occurred, and for good measure
> record the time since last hw initialisation.
>
> Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RESEND PATCH 2/6] drm/i915: Pass atomic state to intel_audio_codec_enable

[Maarten Lankhorst]

Op 24-10-16 om 13:41 schreef Ville Syrjälä:
> On Mon, Oct 24, 2016 at 12:47:21PM +0200, Maarten Lankhorst wrote:
>> Op 24-10-16 om 12:17 schreef Ville Syrjälä:
>>> On Mon, Oct 24, 2016 at 12:12:59PM +0200, Maarten Lankhorst wrote:
 Op 24-10-16 om 12:04 schreef Ville Syrjälä:
> On Mon, Oct 24, 2016 at 10:45:36AM +0200, Maarten Lankhorst wrote:
>> Op 21-10-16 om 16:16 schreef Ville Syrjälä:
>>> On Fri, Oct 21, 2016 at 05:04:46PM +0300, Ville Syrjälä wrote:
 On Wed, Oct 19, 2016 at 03:55:35PM +0200, Maarten Lankhorst wrote:
> drm_select_eld requires mode_config.mutex and connection_mutex
> because it looks at the connector list and at the legacy encoders.
>
> This is not required, because when we call audio_codec_enable we know
> which connector it was called for, so pass the state.
>
> This also removes having to look at crtc->config.
>
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_audio.c | 17 ++---
>  drivers/gpu/drm/i915/intel_ddi.c   |  2 +-
>  drivers/gpu/drm/i915/intel_dp.c| 11 ++-
>  drivers/gpu/drm/i915/intel_drv.h   |  4 +++-
>  drivers/gpu/drm/i915/intel_hdmi.c  |  2 +-
>  5 files changed, 21 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 7093cfbb62b1..63ef25893c7e 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -485,23 +485,26 @@ static void ilk_audio_codec_enable(struct 
> drm_connector *connector,
>  /**
>   * intel_audio_codec_enable - Enable the audio codec for HD audio
>   * @intel_encoder: encoder on which to enable audio
> + * @crtc_state: pointer to the current crtc state.
> + * @conn_state: pointer to the current connector state.
>   *
>   * The enable sequences may only be performed after enabling the 
> transcoder and
>   * port, and after completed link training.
>   */
> -void intel_audio_codec_enable(struct intel_encoder *intel_encoder)
> +void intel_audio_codec_enable(struct intel_encoder *intel_encoder,
> +   const struct intel_crtc_state *crtc_state,
> +   const struct drm_connector_state 
> *conn_state)
>  {
>   struct drm_encoder *encoder = _encoder->base;
> - struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> - const struct drm_display_mode *adjusted_mode = 
> >config->base.adjusted_mode;
> + const struct drm_display_mode *adjusted_mode = 
> _state->base.adjusted_mode;
>   struct drm_connector *connector;
>   struct drm_i915_private *dev_priv = to_i915(encoder->dev);
>   struct i915_audio_component *acomp = dev_priv->audio_component;
>   enum port port = intel_encoder->port;
> - enum pipe pipe = crtc->pipe;
> + enum pipe pipe = drm_crtc_index(crtc_state->base.crtc);
 While we may require that to be true, I'm not sure I like this use.
>>> I should say that otherwise I like this.
>> What do you mean with this comment?
> That the rest of the patch makes sense.
>
 Sorry, I meant the first comment you wrote.
>>> I mean that 'enum pipe pipe = drm_crtc_index(crtc_state->base.crtc);'
>>> is not something that's done anywhere else. So it looks totally foreign.
>>>
>> Not directly I guess. Some places already assume that drm_crtc_index == pipe.
>> But it's ok when I change it to to_intel_crtc(crtc)->pipe?
> Yes.
>
> If we wanted to, I guess we could just do
>
> static inline enum pipe intel_crtc_pipe(crtc)
> {
>   return drm_crtc_index(>base);
> }
>
> and just nuke crtc->pipe entirely.
>
> And then we get to hope that the hw people aren't going to allow fusing
> off pipes in some random order (eg. just fuse off pipe B on a three pipe
> platform). That would obviously break this scheme.
>
That would already cause subtle bugs right now. Lets hope it never happens. :)

~Maarten

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

Re: [Intel-gfx] [PATCH v2 4/8] drm/i915/dp: Print full branch/sink descriptor

[Jani Nikula]

On Tue, 25 Oct 2016, Imre Deak  wrote:
> On ti, 2016-10-25 at 12:28 +0300, Jani Nikula wrote:
>> On Mon, 24 Oct 2016, Imre Deak  wrote:
>> > On Mon, 2016-10-24 at 22:10 +0300, Jani Nikula wrote:
>> > > On Mon, 24 Oct 2016, Imre Deak  wrote:
>> > > > On Mon, 2016-10-24 at 21:14 +0300, Jani Nikula wrote:
>> > > > > On Mon, 24 Oct 2016, Imre Deak  wrote:
>> > > > > > Extend the branch/sink descriptor info with the missing device
>> > > > > > ID
>> > > > > > field. While at it also read out all the descriptor registers
>> > > > > > in one
>> > > > > > transfer and make the debug print more compact.
>> > > > > > 
>> > > > > > v2: (Jani)
>> > > > > > - Cache the descriptor in intel_dp.
>> > > > > > - Split out this change into a separate patch.
>> > > > > > 
>> > > > > > Cc: Jani Nikula 
>> > > > > > Signed-off-by: Imre Deak 
>> > > > > > ---
>> > > > > >  drivers/gpu/drm/i915/intel_dp.c  | 61 +---
>> > > > > > 
>> > > > > >  drivers/gpu/drm/i915/intel_drv.h | 10 +++
>> > > > > >  2 files changed, 30 insertions(+), 41 deletions(-)
>> > > > > > 
>> > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> > > > > > b/drivers/gpu/drm/i915/intel_dp.c
>> > > > > > index 1991250..726fdf2 100644
>> > > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
>> > > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
>> > > > > > @@ -1451,34 +1451,33 @@ static void intel_dp_print_rates(struct
>> > > > > > intel_dp *intel_dp)
>> > > > > >    DRM_DEBUG_KMS("common rates: %s\n", str);
>> > > > > >  }
>> > > > > >  
>> > > > > > -static void intel_dp_print_hw_revision(struct intel_dp
>> > > > > > *intel_dp)
>> > > > > > +static bool
>> > > > > > +__intel_dp_read_desc(struct intel_dp *intel_dp, struct
>> > > > > > intel_dp_desc *desc)
>> > > > > >  {
>> > > > > > -  uint8_t rev;
>> > > > > > -  int len;
>> > > > > > +  u32 base = drm_dp_is_branch(intel_dp->dpcd) ?
>> > > > > > DP_BRANCH_OUI :
>> > > > > > +    DP_SINK_
>> > > > > > OUI;
>> > > > > >  
>> > > > > > -  if (!drm_dp_is_branch(intel_dp->dpcd))
>> > > > > > -  return;
>> > > > > > -
>> > > > > > -  len = drm_dp_dpcd_read(_dp->aux,
>> > > > > > DP_BRANCH_HW_REV, , 1);
>> > > > > > -  if (len < 0)
>> > > > > > -  return;
>> > > > > > -
>> > > > > > -  DRM_DEBUG_KMS("sink hw revision: %d.%d\n", (rev &
>> > > > > > 0xf0) >> 4, rev & 0xf);
>> > > > > > +  return drm_dp_dpcd_read(_dp->aux, base, desc,
>> > > > > > sizeof(*desc)) ==
>> > > > > > +     sizeof(*desc);
>> > > > > >  }
>> > > > > >  
>> > > > > > -static void intel_dp_print_sw_revision(struct intel_dp
>> > > > > > *intel_dp)
>> > > > > > +static bool intel_dp_read_desc(struct intel_dp *intel_dp)
>> > > > > >  {
>> > > > > > -  uint8_t rev[2];
>> > > > > > -  int len;
>> > > > > > +  struct intel_dp_desc *desc = _dp->desc;
>> > > > > > +  bool oui_sup = intel_dp-
>> > > > > > > dpcd[DP_DOWN_STREAM_PORT_COUNT] &
>> > > > > > +     DP_OUI_SUPPORT;
>> > > > > >  
>> > > > > > -  if (!drm_dp_is_branch(intel_dp->dpcd))
>> > > > > > -  return;
>> > > > > > +  if (__intel_dp_read_desc(intel_dp, desc) < 0)
>> > > > > 
>> > > > > The bool returned from __intel_dp_read_desc will never be less
>> > > > > than 0...
>> > > > 
>> > > > Yep, that's a typo, will fix it.
>> > > > 
>> > > > > There's no point in reading the desc if oui_sup is false, is
>> > > > > there? All of desc should read all zeros in that case, not just
>> > > > > OUI.
>> > > > 
>> > > > The spec is not too clear about this yes, but as I read it oui_sup
>> > > > applies only to the OUI reg, device ID and the revisions can be
>> > > > still valid.
>> > > 
>> > > For address 7h:
>> > > 
>> > > """
>> > > Bit 7 = OUI Support
>> > > 0 = OUI not supported
>> > > 1 = OUI supported (OUI and Device Identification mandatory for DP
>> > > 1.2)
>> > > 00400h to 00402h for a Sink device, plus 00403h-0040Bh for Device
>> > > Identification
>> > > 00500h to 00502h for a Branch device, plus 00503h-0050Bh for Device
>> > > Identification
>> > > """
>> > > 
>> > > Based on that I'd say the bit covers device id and revisions too. Why
>> > > would the device id and revision offset be mentioned here otherwise?
>> > 
>> > As a reference to what 'Device Identification' above means? In any case
>> > if 'OUI Support' applies to the whole descriptor referring separately
>> > to OUI and Device Identification right afterwards is confusing to me.
>> 
>> What you call "desc" here means DPCD 0x400..0x40b for sinks, or
>> 0x500..0x50b for branches. That's OUI, an ascii device identification
>> string, and hw/sw revisions.
>
> Yes, I was talking about the specification.
>
>> What's the DPCD revision that LSPCON reports? OUI support is mandatory
>> for DPCD 1.2 and 1.4.
>
> 1.2
>
>> > Could we just read it out regardless of the flag and depend on the 

Re: [Intel-gfx] [PATCH v2 4/8] drm/i915/dp: Print full branch/sink descriptor

[Imre Deak]

On ti, 2016-10-25 at 12:28 +0300, Jani Nikula wrote:
> On Mon, 24 Oct 2016, Imre Deak  wrote:
> > On Mon, 2016-10-24 at 22:10 +0300, Jani Nikula wrote:
> > > On Mon, 24 Oct 2016, Imre Deak  wrote:
> > > > On Mon, 2016-10-24 at 21:14 +0300, Jani Nikula wrote:
> > > > > On Mon, 24 Oct 2016, Imre Deak  wrote:
> > > > > > Extend the branch/sink descriptor info with the missing device
> > > > > > ID
> > > > > > field. While at it also read out all the descriptor registers
> > > > > > in one
> > > > > > transfer and make the debug print more compact.
> > > > > > 
> > > > > > v2: (Jani)
> > > > > > - Cache the descriptor in intel_dp.
> > > > > > - Split out this change into a separate patch.
> > > > > > 
> > > > > > Cc: Jani Nikula 
> > > > > > Signed-off-by: Imre Deak 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/intel_dp.c  | 61 +---
> > > > > > 
> > > > > >  drivers/gpu/drm/i915/intel_drv.h | 10 +++
> > > > > >  2 files changed, 30 insertions(+), 41 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > index 1991250..726fdf2 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > @@ -1451,34 +1451,33 @@ static void intel_dp_print_rates(struct
> > > > > > intel_dp *intel_dp)
> > > > > >     DRM_DEBUG_KMS("common rates: %s\n", str);
> > > > > >  }
> > > > > >  
> > > > > > -static void intel_dp_print_hw_revision(struct intel_dp
> > > > > > *intel_dp)
> > > > > > +static bool
> > > > > > +__intel_dp_read_desc(struct intel_dp *intel_dp, struct
> > > > > > intel_dp_desc *desc)
> > > > > >  {
> > > > > > -   uint8_t rev;
> > > > > > -   int len;
> > > > > > +   u32 base = drm_dp_is_branch(intel_dp->dpcd) ?
> > > > > > DP_BRANCH_OUI :
> > > > > > +     DP_SINK_
> > > > > > OUI;
> > > > > >  
> > > > > > -   if (!drm_dp_is_branch(intel_dp->dpcd))
> > > > > > -   return;
> > > > > > -
> > > > > > -   len = drm_dp_dpcd_read(_dp->aux,
> > > > > > DP_BRANCH_HW_REV, , 1);
> > > > > > -   if (len < 0)
> > > > > > -   return;
> > > > > > -
> > > > > > -   DRM_DEBUG_KMS("sink hw revision: %d.%d\n", (rev &
> > > > > > 0xf0) >> 4, rev & 0xf);
> > > > > > +   return drm_dp_dpcd_read(_dp->aux, base, desc,
> > > > > > sizeof(*desc)) ==
> > > > > > +      sizeof(*desc);
> > > > > >  }
> > > > > >  
> > > > > > -static void intel_dp_print_sw_revision(struct intel_dp
> > > > > > *intel_dp)
> > > > > > +static bool intel_dp_read_desc(struct intel_dp *intel_dp)
> > > > > >  {
> > > > > > -   uint8_t rev[2];
> > > > > > -   int len;
> > > > > > +   struct intel_dp_desc *desc = _dp->desc;
> > > > > > +   bool oui_sup = intel_dp-
> > > > > > > dpcd[DP_DOWN_STREAM_PORT_COUNT] &
> > > > > > +      DP_OUI_SUPPORT;
> > > > > >  
> > > > > > -   if (!drm_dp_is_branch(intel_dp->dpcd))
> > > > > > -   return;
> > > > > > +   if (__intel_dp_read_desc(intel_dp, desc) < 0)
> > > > > 
> > > > > The bool returned from __intel_dp_read_desc will never be less
> > > > > than 0...
> > > > 
> > > > Yep, that's a typo, will fix it.
> > > > 
> > > > > There's no point in reading the desc if oui_sup is false, is
> > > > > there? All of desc should read all zeros in that case, not just
> > > > > OUI.
> > > > 
> > > > The spec is not too clear about this yes, but as I read it oui_sup
> > > > applies only to the OUI reg, device ID and the revisions can be
> > > > still valid.
> > > 
> > > For address 7h:
> > > 
> > > """
> > > Bit 7 = OUI Support
> > > 0 = OUI not supported
> > > 1 = OUI supported (OUI and Device Identification mandatory for DP
> > > 1.2)
> > > 00400h to 00402h for a Sink device, plus 00403h-0040Bh for Device
> > > Identification
> > > 00500h to 00502h for a Branch device, plus 00503h-0050Bh for Device
> > > Identification
> > > """
> > > 
> > > Based on that I'd say the bit covers device id and revisions too. Why
> > > would the device id and revision offset be mentioned here otherwise?
> > 
> > As a reference to what 'Device Identification' above means? In any case
> > if 'OUI Support' applies to the whole descriptor referring separately
> > to OUI and Device Identification right afterwards is confusing to me.
> 
> What you call "desc" here means DPCD 0x400..0x40b for sinks, or
> 0x500..0x50b for branches. That's OUI, an ascii device identification
> string, and hw/sw revisions.

Yes, I was talking about the specification.

> What's the DPCD revision that LSPCON reports? OUI support is mandatory
> for DPCD 1.2 and 1.4.

1.2

> > Could we just read it out regardless of the flag and depend on the read
> > failing or the values being zeroed if it's not "supported"?
> 
> Please tell me again why we use the OUI for this purpose instead of just
> intel_dp->dpcd?

[Intel-gfx] External intel-gfx-ci results site http://intel-gfx-ci.01.org/CI/

[Saarinen, Jani]

Sending behalf of Tomi. 

---
Hello all,

History of CI i-g-t runs for drm-intel-nightly is now available at 
https://intel-gfx-ci.01.org/CI/

The full results for Patchwork / Trybot CI runs are also available. Text 
summary will still be uploaded to patchwork for projects 
https://patchwork.freedesktop.org/project/intel-gfx/series/
https://patchwork.freedesktop.org/project/intel-gfx-trybot/series/

Additional link is published, and the first patch series with URL is 
https://patchwork.freedesktop.org/series/14320/ (See full logs) -> 
https://intel-gfx-ci.01.org/CI/Patchwork_2804/

More information on documentation page:
https://01.org/linuxgraphics/documentation/reproducing-patchwork-test-results

Regards,

Tomi
---


Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



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

[Intel-gfx] ✗ Fi.CI.BAT: warning for dma-buf: Rename struct fence to dma_fence

[Patchwork]

== Series Details ==

Series: dma-buf: Rename struct fence to dma_fence
URL   : https://patchwork.freedesktop.org/series/14324/
State : warning

== Summary ==

Series 14324v1 dma-buf: Rename struct fence to dma_fence
https://patchwork.freedesktop.org/api/1.0/series/14324/revisions/1/mbox/

Test drv_module_reload_basic:
skip   -> PASS   (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6700hq)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
skip   -> PASS   (fi-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b:
pass   -> DMESG-WARN (fi-ivb-3770)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (fi-skl-6700hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:219  dwarn:1   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

cd1dba8d045ce0d59029226108f0ad7b35a9d061 drm-intel-nightly: 
2016y-10m-25d-09h-26m-24s UTC integration manifest
73a5a48 dma-buf: Rename struct fence to dma_fence

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2805/

== Logs ==

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