Re: [Intel-gfx] [PATCH v3 3/9] drm: Add Content Protection property

[Hans Verkuil]

On 12/05/2017 06:15 AM, Sean Paul wrote:
> This patch adds a new optional connector property to allow userspace to enable
> protection over the content it is displaying. This will typically be 
> implemented
> by the driver using HDCP.
> 
> The property is a tri-state with the following values:
> - OFF: Self explanatory, no content protection
> - DESIRED: Userspace requests that the driver enable protection
> - ENABLED: Once the driver has authenticated the link, it sets this value
> 
> The driver is responsible for downgrading ENABLED to DESIRED if the link 
> becomes
> unprotected. The driver should also maintain the desiredness of protection
> across hotplug/dpms/suspend.
> 
> If this looks familiar, I posted [1] this 3 years ago. We have been using this
> in ChromeOS across exynos, mediatek, and rockchip over that time.
> 
> Changes in v2:
>  - Pimp kerneldoc for content_protection_property (Daniel)
>  - Drop sysfs attribute
> Changes in v3:
>  - None
> 
> Cc: Daniel Vetter 
> Signed-off-by: Sean Paul 
> 
> [1] https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.html
> ---
>  drivers/gpu/drm/drm_atomic.c|  8 +
>  drivers/gpu/drm/drm_connector.c | 71 
> +
>  drivers/gpu/drm/drm_sysfs.c |  1 +
>  include/drm/drm_connector.h | 16 ++
>  include/uapi/drm/drm_mode.h |  4 +++
>  5 files changed, 100 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c2da5585e201..676025d755b2 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1196,6 +1196,12 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   state->picture_aspect_ratio = val;
>   } else if (property == connector->scaling_mode_property) {
>   state->scaling_mode = val;
> + } else if (property == connector->content_protection_property) {
> + if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
> + DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
> + return -EINVAL;
> + }
> + state->content_protection = val;
>   } else if (connector->funcs->atomic_set_property) {
>   return connector->funcs->atomic_set_property(connector,
>   state, property, val);
> @@ -1275,6 +1281,8 @@ drm_atomic_connector_get_property(struct drm_connector 
> *connector,
>   *val = state->picture_aspect_ratio;
>   } else if (property == connector->scaling_mode_property) {
>   *val = state->scaling_mode;
> + } else if (property == connector->content_protection_property) {
> + *val = state->content_protection;
>   } else if (connector->funcs->atomic_get_property) {
>   return connector->funcs->atomic_get_property(connector,
>   state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index f14b48e6e839..8626aa8f485e 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -698,6 +698,13 @@ static const struct drm_prop_enum_list 
> drm_tv_subconnector_enum_list[] = {
>  DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>drm_tv_subconnector_enum_list)
>  
> +static struct drm_prop_enum_list drm_cp_enum_list[] = {
> +{ DRM_MODE_CONTENT_PROTECTION_OFF, "Off" },
> +{ DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
> +{ DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
> +};
> +DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
> +
>  /**
>   * DOC: standard connector properties
>   *
> @@ -764,6 +771,34 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>   *  after modeset, the kernel driver may set this to "BAD" and issue a
>   *  hotplug uevent. Drivers should update this value using
>   *  drm_mode_connector_set_link_status_property().
> + * Content Protection:
> + *   This property is used by userspace to request the kernel protect future
> + *   content communicated over the link. When requested, kernel will apply
> + *   the appropriate means of protection (most often HDCP), and use the
> + *   property to tell userspace the protection is active.
> + *
> + *   The value of this property can be one of the following:
> + *
> + *   - DRM_MODE_CONTENT_PROTECTION_OFF = 0
> + *   The link is not protected, content is transmitted in the clear.
> + *   - DRM_MODE_CONTENT_PROTECTION_DESIRED = 1
> + *   Userspace has requested content protection, but the link is not
> + *   currently protected. When in this state, kernel should enable
> + *   Content Protection as soon as possible.
> + *   - DRM_MODE_CONTENT_PROTECTION_ENABLED = 2
> + *   Userspace has requested content protection, and the link is
> + *   protected. Only the driver can set the property to this value.

Re: [Intel-gfx] [PATCH] drm/i915: Fix compilation (panel orientation x enum plane rename).

[Hans de Goede]

Hi,

On 05-12-17 01:58, Rodrigo Vivi wrote:

On Tue, Dec 05, 2017 at 12:09:35AM +, Michel Thierry wrote:

On 12/4/2017 4:04 PM, Rodrigo Vivi wrote:

When commit '82daca297506 ("drm/i915: Add "panel orientation"
property to the panel connector, v6.")' was done and tested
by CI, commit 'ed15030d7ab0 ("drm/i915: s/enum plane/enum
i9xx_plane_id/")' wasn't there already.


Ops, the biggest issue now is that one patch is on drm-misc-next while
the other one is on drm-intel-next-queued.

I would just revert this from drm-misc-next and apply it to dinq
with a new fixed version or with this patch on top. But I'm not taking
any harsh decision without ack from drm-misc maintainers.

I will check to see if I get some ack or better ideas tonight before going
to bed or in a hope that someone in Europe timezone get this in the morning
and fix it.


Ugh, sorry, I tested that I did not break drm-misc-next compilation,
but I did not realize this was going to break drm-tip compilation.

Just reverting the offending commit on drm-misc-next and
adding a fixed version to dinq will not worked because the patch
depends on the new panel-orientation member of struct drm_display_info.

So there are 2 options AFAICT:

Option 1:
-Merge drm-misc-next into dinq
-Add a fixup commit to dinq on top

Option 2:
-Revert the commit from drm-misc-next
-Merge drm-misc-next into dinq
-Add a fixed version of the commit into dinq

Regards,

Hans





On this race the second patch got merged first so the first one
broke i915 compilation. Thanks to Michel this was found quickly.

Cc: Michel Thierry 
Cc: Daniel Vetter 
Cc: Hans de Goede 
Suggested-by: Michel Thierry 
Fixes: 82daca297506 ("drm/i915: Add "panel orientation" property to the panel 
connector, v6.")
Signed-off-by: Rodrigo Vivi 
---
   drivers/gpu/drm/i915/intel_dsi.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 1b60df3c14a0..f67d321376e4 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1670,7 +1670,7 @@ static int intel_dsi_get_panel_orientation(struct 
intel_connector *connector)
   {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
int orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
-   enum plane plane;
+   enum i9xx_plane_id plane;
u32 val;
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {



Reviewed-by: Michel Thierry 

___
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/2] CONTRIBUTING: Fix spelling mistake and line length

[Petri Latvala]

On Tue, Dec 05, 2017 at 12:23:32AM -0500, Sean Paul wrote:
> Noticed while I was reading it. Makes for a good first contribution, I
> guess.
> 
> Signed-off-by: Sean Paul 

Reviewed-by: Petri Latvala 



> ---
>  CONTRIBUTING | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/CONTRIBUTING b/CONTRIBUTING
> index 561c5dd8..ca2ed8a5 100644
> --- a/CONTRIBUTING
> +++ b/CONTRIBUTING
> @@ -18,13 +18,13 @@ A short list of contribution guidelines:
>  
>on its first invocation.
>  
> -- intel-gpu-tools is MIT lincensed and we require contributions to follow the
> +- intel-gpu-tools is MIT licensed and we require contributions to follow the
>developer's certificate of origin: http://developercertificate.org/
>  
>  - When submitting new testcases please follow the naming conventions 
> documented
> -  in the generated documentation. Also please make full use of all the 
> helpers and
> -  convenience macros provided by the igt library. The semantic patch 
> lib/igt.cocci
> -  can help with the more automatic conversions.
> +  in the generated documentation. Also please make full use of all the 
> helpers
> +  and convenience macros provided by the igt library. The semantic patch
> +  lib/igt.cocci can help with the more automatic conversions.
>  
>  - Patches need to be reviewed on the mailing list. Exceptions only apply for
>testcases and tooling for drivers with just a single contributor (e.g. 
> vc4).
> -- 
> 2.15.0.531.g2ccb3012c9-goog
> 
> ___
> 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 2/2] kms_content_protection: Add Content Protection test

[Petri Latvala]

On Tue, Dec 05, 2017 at 12:23:33AM -0500, Sean Paul wrote:
> Pretty simple test:
> - initializes the output
> - clears the content protection property
> - verifies that it clears
> - sets the content protection property to desired
> - verifies that it transitions to enabled
> 
> Does this for both legacy and atomic.
> 
> Signed-off-by: Sean Paul 
> ---
>  lib/igt_kms.c  |   3 +-
>  lib/igt_kms.h  |   1 +
>  tests/Makefile.sources |   1 +
>  tests/kms_content_protection.c | 128 
> +
>  tests/meson.build  |   1 +
>  5 files changed, 133 insertions(+), 1 deletion(-)
>  create mode 100644 tests/kms_content_protection.c
> 
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index 125ecb19..907db694 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -190,7 +190,8 @@ const char 
> *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
>   "scaling mode",
>   "CRTC_ID",
>   "DPMS",
> - "Broadcast RGB"
> + "Broadcast RGB",
> + "Content Protection"
>  };
>  
>  /*
> diff --git a/lib/igt_kms.h b/lib/igt_kms.h
> index 2a480bf3..93e59dc7 100644
> --- a/lib/igt_kms.h
> +++ b/lib/igt_kms.h
> @@ -118,6 +118,7 @@ enum igt_atomic_connector_properties {
> IGT_CONNECTOR_CRTC_ID,
> IGT_CONNECTOR_DPMS,
> IGT_CONNECTOR_BROADCAST_RGB,
> +   IGT_CONNECTOR_CONTENT_PROTECTION,
> IGT_NUM_CONNECTOR_PROPS
>  };
>  
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 34ca71a0..e0466411 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -179,6 +179,7 @@ TESTS_progs = \
>   kms_chv_cursor_fail \
>   kms_color \
>   kms_concurrent \
> + kms_content_protection\
>   kms_crtc_background_color \
>   kms_cursor_crc \
>   kms_cursor_legacy \
> diff --git a/tests/kms_content_protection.c b/tests/kms_content_protection.c
> new file mode 100644
> index ..7bfe9a69
> --- /dev/null
> +++ b/tests/kms_content_protection.c
> @@ -0,0 +1,128 @@
> +/*
> + * Copyright © 2017 Google, Inc.
> + *
> + * 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"
> +
> +IGT_TEST_DESCRIPTION("Test content protection (HDCP)");
> +
> +typedef struct {
> + int drm_fd;
> + igt_display_t display;
> +} data_t;
> +
> +static bool
> +wait_for_prop_value(igt_output_t *output, uint64_t expected)
> +{
> + uint64_t val;
> + int i;
> +
> + for (i = 0; i < 2000; i++) {
> + val = igt_output_get_prop(output,
> +   IGT_CONNECTOR_CONTENT_PROTECTION);
> + if (val == expected)
> + return true;
> + usleep(1000);
> + }
> + igt_info("prop_value mismatch %ld != %ld\n", val, expected);
> + return false;
> +}
> +
> +static void
> +test_pipe_output(igt_display_t *display, const enum pipe pipe,
> +  igt_output_t *output, enum igt_commit_style s)
> +{
> + drmModeModeInfo mode;
> + igt_plane_t *primary;
> + struct igt_fb red;
> + bool ret;
> +
> + igt_assert(kmstest_get_connector_default_mode(
> + display->drm_fd, output->config.connector, &mode));
> +
> + igt_output_override_mode(output, &mode);
> + igt_output_set_pipe(output, pipe);
> +
> + igt_create_color_fb(display->drm_fd, mode.hdisplay, mode.vdisplay,
> + DRM_FORMAT_XRGB, LOCAL_DRM_FORMAT_MOD_NONE,
> + 1.f, 0.f, 0.f, &red);
> + primary = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY);
> + igt_plane_set_fb(primary, &red);
> + igt_display_commit2(display, s);
> +
> + igt_output_set_prop_value(output, IGT_CONNECTOR_CONTENT_PROTECTION, 0);
> + igt_display_commit2(display, s);
> +
> + ret = wait_for_prop_value(output, 0);
> + igt

Re: [Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] CONTRIBUTING: Fix spelling mistake and line length

[Petri Latvala]

On Tue, Dec 05, 2017 at 06:35:20AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [1/2] CONTRIBUTING: Fix spelling mistake and 
> line length
> URL   : https://patchwork.freedesktop.org/series/34881/
> State : warning
> 
> == Summary ==
> 
> Test gem_tiled_swapping:
> Subgroup non-threaded:
> pass   -> INCOMPLETE (shard-hsw) fdo#104009
> Test kms_flip:
> Subgroup flip-vs-modeset-vs-hang-interruptible:
> pass   -> DMESG-WARN (shard-snb)
> Test kms_frontbuffer_tracking:
> Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
> pass   -> FAIL   (shard-snb) fdo#101623 +1
> Test drv_selftest:
> Subgroup mock_sanitycheck:
> pass   -> DMESG-WARN (shard-snb) fdo#102707 +1
> 
> fdo#104009 https://bugs.freedesktop.org/show_bug.cgi?id=104009
> fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
> fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
> 
> shard-hswtotal:2623 pass:1499 dwarn:2   dfail:0   fail:9   skip:1112 
> time:9330s
> shard-snbtotal:2681 pass:1306 dwarn:3   dfail:0   fail:12  skip:1360 
> time:8164s
> Blacklisted hosts:
> shard-apltotal:2659 pass:1657 dwarn:1   dfail:0   fail:23  skip:977 
> time:13252s
> shard-kbltotal:2681 pass:1797 dwarn:1   dfail:0   fail:24  skip:859 
> time:10805s
> 
> == Logs ==
> 
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_596/shards.html

Only the full results at
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_596/shards-all.html
show results for the new tests. For the record, both new tests passed
on shard-kbl and shard-apl, skipped on shard-snb and shard-hsw.



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

Re: [Intel-gfx] [PATCH i-g-t] intel_aubdump: Add ability to simulate execlist submission

[Jordan Justen]

On 2017-11-28 15:51:19, Scott D Phillips wrote:
> Newer devices do not have the legacy ring buffer submission model,
> so aub files generated using that model cannot be handled by some
> internal tools. The execlist submission modeled by this change is
> pretty simplistic, using GGTT only and synchronizing after every
> batch.
> ---
>  tools/aubdump.c | 422 
> 
>  1 file changed, 394 insertions(+), 28 deletions(-)
> 
> diff --git a/tools/aubdump.c b/tools/aubdump.c
> index 6ba3cb66..232371d5 100644
> --- a/tools/aubdump.c
> +++ b/tools/aubdump.c
> @@ -46,6 +46,175 @@
>  #define ARRAY_SIZE(x) (sizeof(x)/sizeof((x)[0]))
>  #endif
>  
> +#ifndef ALIGN
> +#define ALIGN(x, y) (((x) + (y)-1) & ~((y)-1))
> +#endif
> +
> +#ifndef MIN
> +#define MIN(x, y) ((x) < (y) ? (x) : (y))

I notice 'min' is used in a few other places in i-g-t. Mesa uses MIN2.

> +#endif
> +
> +#define HWS_PGA_RCSUNIT0x02080
> +#define HWS_PGA_VCSUNIT0   0x12080
> +#define HWS_PGA_BCSUNIT0x22080
> +
> +#define GFX_MODE_RCSUNIT   0x0229c
> +#define GFX_MODE_VCSUNIT0  0x1229c
> +#define GFX_MODE_BCSUNIT   0x2229c
> +
> +#define EXECLIST_SUBMITPORT_RCSUNIT0x02230
> +#define EXECLIST_SUBMITPORT_VCSUNIT0   0x12230
> +#define EXECLIST_SUBMITPORT_BCSUNIT0x22230
> +
> +#define EXECLIST_STATUS_RCSUNIT0x02234
> +#define EXECLIST_STATUS_VCSUNIT0   0x12234
> +#define EXECLIST_STATUS_BCSUNIT0x22234
> +
> +#define MEMORY_MAP_SIZE (64 /* MiB */ * 1024 * 1024)
> +
> +#define PTE_SIZE 4
> +#define GEN8_PTE_SIZE 8
> +
> +#define NUM_PT_ENTRIES (ALIGN(MEMORY_MAP_SIZE, 4096) / 4096)
> +#define PT_SIZE ALIGN(NUM_PT_ENTRIES * GEN8_PTE_SIZE, 4096)
> +
> +#define RING_SIZE  ( 1 * 4096)
> +#define PPHWSP_SIZE( 1 * 4096)
> +#define GEN10_LR_CONTEXT_RENDER_SIZE   (19 * 4096)
> +#define GEN8_LR_CONTEXT_OTHER_SIZE ( 2 * 4096)
> +
> +#define STATIC_GGTT_MAP_START 0
> +
> +#define RENDER_RING_ADDR STATIC_GGTT_MAP_START
> +#define RENDER_CONTEXT_ADDR (RENDER_RING_ADDR + RING_SIZE)
> +
> +#define BLITTER_RING_ADDR (RENDER_CONTEXT_ADDR + PPHWSP_SIZE + 
> GEN10_LR_CONTEXT_RENDER_SIZE)
> +#define BLITTER_CONTEXT_ADDR (BLITTER_RING_ADDR + RING_SIZE)
> +
> +#define VIDEO_RING_ADDR (BLITTER_CONTEXT_ADDR + PPHWSP_SIZE + 
> GEN8_LR_CONTEXT_OTHER_SIZE)
> +#define VIDEO_CONTEXT_ADDR (VIDEO_RING_ADDR + RING_SIZE)
> +
> +#define STATIC_GGTT_MAP_END (VIDEO_CONTEXT_ADDR + PPHWSP_SIZE + 
> GEN8_LR_CONTEXT_OTHER_SIZE)
> +#define STATIC_GGTT_MAP_SIZE (STATIC_GGTT_MAP_END - STATIC_GGTT_MAP_START)
> +
> +#define CONTEXT_FLAGS (0x229)  /* Normal Priority | L3-LLC Coherency |
> +   Legacy Context with no 64 bit VA support | Valid */
> +
> +#define RENDER_CONTEXT_DESCRIPTOR  ((uint64_t)1 << 32 | RENDER_CONTEXT_ADDR  
> | CONTEXT_FLAGS)
> +#define BLITTER_CONTEXT_DESCRIPTOR ((uint64_t)2 << 32 | BLITTER_CONTEXT_ADDR 
> | CONTEXT_FLAGS)
> +#define VIDEO_CONTEXT_DESCRIPTOR   ((uint64_t)3 << 32 | VIDEO_CONTEXT_ADDR   
> | CONTEXT_FLAGS)
> +
> +static const uint32_t render_context_init[GEN10_LR_CONTEXT_RENDER_SIZE /
> + sizeof(uint32_t)] = {
> +   0 /* MI_NOOP */,
> +   0x1100101B /* MI_LOAD_REGISTER_IMM */,
> +   0x2244 /* CONTEXT_CONTROL */,   0x90009 /* Inhibit 
> Synchronous Context Switch | Engine Context Restore Inhibit */,
> +   0x2034 /* RING_HEAD */, 0,
> +   0x2030 /* RING_TAIL */, 0,
> +   0x2038 /* RING_BUFFER_START */, RENDER_RING_ADDR,
> +   0x203C /* RING_BUFFER_CONTROL */,   (RING_SIZE - 4096) | 1 /* 
> Buffer Length | Ring Buffer Enable */,
> +   0x2168 /* BB_HEAD_U */, 0,
> +   0x2140 /* BB_HEAD_L */, 0,
> +   0x2110 /* BB_STATE */,  0,
> +   0x211C /* SECOND_BB_HEAD_U */,  0,
> +   0x2114 /* SECOND_BB_HEAD_L */,  0,
> +   0x2118 /* SECOND_BB_STATE */,   0,
> +   0x21C0 /* BB_PER_CTX_PTR */,0,
> +   0x21C4 /* RCS_INDIRECT_CTX */,  0,
> +   0x21C8 /* RCS_INDIRECT_CTX_OFFSET */,   0,
> +   /* MI_NOOP */
> +   0, 0,
> +
> +   0 /* MI_NOOP */,
> +   0x11001011 /* MI_LOAD_REGISTER_IMM */,
> +   0x23A8 /* CTX_TIMESTAMP */, 0,
> +   0x228C /* PDP3_UDW */,  0,
> +   0x2288 /* PDP3_LDW */,  0,
> +   0x2284 /* PDP2_UDW */,  0,
> +   0x2280 /* PDP2_LDW */,  0,
> +   0x227C /* PDP1_UDW */,  0,
> +   0x2278 /* PDP1_LDW */,  0,
> +   0x2274 /* PDP0_UDW */,  0,
> +   0x2270 /* PDP0_LDW */,  0,
> +   /* MI_NOOP */
> +   0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> +
> +   0 /* MI_NOOP */,
> +   0x1101 /* MI_LOAD_REGISTER_IMM */,
> +   0x20C8 /* R_PWR_CLK_STATE */, 0x7FFF,
> +   0x0501 /* MI_BATCH_BUFFER_END */
> +};
> 

[Intel-gfx] [PATCH] drm/i915: Disable display crc feature for vgpu

[Xiaolin Zhang]

for vgpu, it doesn't support display crc feature.
this patch is to skip pipe crc create and report ENODEV
during set_crc_source. igt display crc relatated cases will be
failed instead of dead sleep.

Signed-off-by: Xiaolin Zhang 
---
 drivers/gpu/drm/i915/intel_pipe_crc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c 
b/drivers/gpu/drm/i915/intel_pipe_crc.c
index 1f5cd572a7ff..a4885127a0dc 100644
--- a/drivers/gpu/drm/i915/intel_pipe_crc.c
+++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
@@ -899,6 +899,9 @@ int intel_pipe_crc_create(struct drm_minor *minor)
struct dentry *ent;
int i;
 
+   if (dev_priv->vgpu.active)
+   return 0;
+
for (i = 0; i < ARRAY_SIZE(i915_pipe_crc_data); i++) {
struct pipe_crc_info *info = &i915_pipe_crc_data[i];
 
@@ -923,6 +926,9 @@ int intel_crtc_set_crc_source(struct drm_crtc *crtc, const 
char *source_name,
u32 val = 0; /* shut up gcc */
int ret = 0;
 
+   if (dev_priv->vgpu.active)
+   return -ENODEV;
+
if (display_crc_ctl_parse_source(source_name, &source) < 0) {
DRM_DEBUG_DRIVER("unknown source %s\n", source_name);
return -EINVAL;
-- 
2.14.2

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

Re: [Intel-gfx] [PATCH v3 5/9] drm/i915: Add HDCP framework + base implementation

[Ramalingam C]

On Tuesday 05 December 2017 10:45 AM, Sean Paul wrote:

This patch adds the framework required to add HDCP support to intel
connectors. It implements Aksv loading from fuse, and parts 1/2/3
of the HDCP authentication scheme.

Note that without shim implementations, this does not actually implement
HDCP. That will come in subsequent patches.

Changes in v2:
- Don't open code wait_fors (Chris)
- drm_hdcp.c under MIT license (Daniel)
- Move intel_hdcp_disable() call above ddi_disable (Ram)
- Fix // comments (I wore a cone of shame for 12 hours to atone) (Daniel)
- Justify intel_hdcp_shim with comments (Daniel)
- Fixed async locking issues by adding hdcp_mutex (Daniel)
- Don't alter connector_state in enable/disable (Daniel)
Changes in v3:
- Added hdcp_mutex/hdcp_value to make async reasonable
- Added hdcp_prop_work to separate link checking & property setting
- Added new helper for atomic_check state tracking (Daniel)
- Moved enable/disable into atomic_commit with matching helpers
- Moved intel_hdcp_check_link out of all locks when called from dp
- Bumped up ksv_fifo timeout (noticed failure on one of my dongles)

Cc: Chris Wilson 
Cc: Daniel Vetter 
Cc: Ramalingam C 
Signed-off-by: Sean Paul 
---
  drivers/gpu/drm/i915/Makefile|   1 +
  drivers/gpu/drm/i915/i915_reg.h  |  83 
  drivers/gpu/drm/i915/intel_atomic.c  |   2 +
  drivers/gpu/drm/i915/intel_display.c |  14 +
  drivers/gpu/drm/i915/intel_drv.h |  88 +
  drivers/gpu/drm/i915/intel_hdcp.c| 731 +++
  6 files changed, 919 insertions(+)
  create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 42bc8bd4ff06..3facea4eefdb 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -107,6 +107,7 @@ i915-y += intel_audio.o \
  intel_fbc.o \
  intel_fifo_underrun.o \
  intel_frontbuffer.o \
+ intel_hdcp.o \
  intel_hotplug.o \
  intel_modes.o \
  intel_overlay.o \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 09bf043c1c2e..2bd2cc8441d4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8034,6 +8034,7 @@ enum {
  #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT  8
  #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT  16
  #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT  24
+#define   SKL_PCODE_LOAD_HDCP_KEYS 0x5
  #define   SKL_PCODE_CDCLK_CONTROL 0x7
  #define SKL_CDCLK_PREPARE_FOR_CHANGE  0x3
  #define SKL_CDCLK_READY_FOR_CHANGE0x1
@@ -8335,6 +8336,88 @@ enum skl_power_gate {
  #define  SKL_PW_TO_PG(pw) ((pw) - SKL_DISP_PW_1 + SKL_PG1)
  #define  SKL_FUSE_PG_DIST_STATUS(pg)  (1 << (27 - (pg)))
  
+

+/* HDCP Key Registers */
+#define SKL_HDCP_KEY_CONF  _MMIO(0x66c00)
+#define SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
+#define  SKL_HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
+#define SKL_HDCP_KEY_STATUS_MMIO(0x66c04)
+#define  SKL_HDCP_FUSE_IN_PROGRESS BIT(7)
+#define  SKL_HDCP_FUSE_ERROR   BIT(6)
+#define  SKL_HDCP_FUSE_DONEBIT(5)
+#define  SKL_HDCP_KEY_LOAD_STATUS  BIT(1)
+#define  SKL_HDCP_KEY_LOAD_DONEBIT(0)
+#define SKL_HDCP_AKSV_LO   _MMIO(0x66c10)
+#define SKL_HDCP_AKSV_HI   _MMIO(0x66c14)
+
+/* HDCP Repeater Registers */
+#define SKL_HDCP_REP_CTL   _MMIO(0x66d00)
+#define  SKL_HDCP_DDIB_REP_PRESENT BIT(30)
+#define  SKL_HDCP_DDIA_REP_PRESENT BIT(29)
+#define  SKL_HDCP_DDIC_REP_PRESENT BIT(28)
+#define  SKL_HDCP_DDID_REP_PRESENT BIT(27)
+#define  SKL_HDCP_DDIF_REP_PRESENT BIT(26)
+#define  SKL_HDCP_DDIE_REP_PRESENT BIT(25)
+#define  SKL_HDCP_DDIB_SHA1_M0 (1 << 20)
+#define  SKL_HDCP_DDIA_SHA1_M0 (2 << 20)
+#define  SKL_HDCP_DDIC_SHA1_M0 (3 << 20)
+#define  SKL_HDCP_DDID_SHA1_M0 (4 << 20)
+#define  SKL_HDCP_DDIF_SHA1_M0 (5 << 20)
+#define  SKL_HDCP_DDIE_SHA1_M0 (6 << 20) /* Bspec says 5? */
+#define  SKL_HDCP_SHA1_BUSYBIT(16)
+#define  SKL_HDCP_SHA1_READY   BIT(17)
+#define  SKL_HDCP_SHA1_COMPLETEBIT(18)
+#define  SKL_HDCP_SHA1_V_MATCH BIT(19)
+#define  SKL_HDCP_SHA1_TEXT_32 (1 << 1)
+#define  SKL_HDCP_SHA1_COMPLETE_HASH   (2 << 1)
+#define  SKL_HDCP_SHA1_TEXT_24 (4 << 1)
+#define  SKL_HDCP_SHA1_TEXT_16 (5 << 1)
+#define  SKL_HDCP_SHA1_TEXT_8  (6 << 1)
+#define  SKL_HDCP_SHA1_TEXT_0  (7 << 1)
+#define SKL_HDCP_SHA_V_PRIME_H0_MMIO(0x66d04)
+#define SKL_HDCP_SHA_V_PRIME_H1_MMIO(0x66d08)
+#define SKL_HDCP_SHA_V_PRIME_H2_MMIO(0x66d0C)
+#define SKL_HDCP_SHA_V_PRIME_H3_MMIO(0x66d10)
+#define SKL_HDCP_SHA_V_PRIME_H4_MMIO(0x66d14)
+#define SKL_HDCP_SHA_V_PRIME(h)   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Disable display crc feature for vgpu

[Patchwork]

== Series Details ==

Series: drm/i915: Disable display crc feature for vgpu
URL   : https://patchwork.freedesktop.org/series/34889/
State : success

== Summary ==

Series 34889v1 drm/i915: Disable display crc feature for vgpu
https://patchwork.freedesktop.org/api/1.0/series/34889/revisions/1/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_chamelium:
Subgroup dp-crc-fast:
dmesg-fail -> PASS   (fi-kbl-7500u) fdo#103841

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:432s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:439s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:384s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:521s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:500s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:511s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:486s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:472s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:1   dfail:0   fail:0   skip:108 
time:268s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:535s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:383s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:261s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:396s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:474s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:481s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:530s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:474s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:532s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:592s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:543s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:521s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:496s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:440s
fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:551s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:416s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:610s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:618s
fi-glk-dsi   total:22   pass:21   dwarn:0   dfail:0   fail:0   skip:0  

84cd3d972bdd25fd6f7fe3dc2fe92b0617cde2a5 drm-tip: 2017y-12m-05d-08h-41m-59s UTC 
integration manifest
207897453e85 drm/i915: Disable display crc feature for vgpu

== Logs ==

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

Re: [Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] CONTRIBUTING: Fix spelling mistake and line length

[Petri Latvala]

On Tue, Dec 05, 2017 at 10:26:50AM +0200, Petri Latvala wrote:
> On Tue, Dec 05, 2017 at 06:35:20AM +, Patchwork wrote:
> > == Series Details ==
> > 
> > Series: series starting with [1/2] CONTRIBUTING: Fix spelling mistake and 
> > line length
> > URL   : https://patchwork.freedesktop.org/series/34881/
> > State : warning
> > 
> > == Summary ==
> > 
> > Test gem_tiled_swapping:
> > Subgroup non-threaded:
> > pass   -> INCOMPLETE (shard-hsw) fdo#104009
> > Test kms_flip:
> > Subgroup flip-vs-modeset-vs-hang-interruptible:
> > pass   -> DMESG-WARN (shard-snb)
> > Test kms_frontbuffer_tracking:
> > Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
> > pass   -> FAIL   (shard-snb) fdo#101623 +1
> > Test drv_selftest:
> > Subgroup mock_sanitycheck:
> > pass   -> DMESG-WARN (shard-snb) fdo#102707 +1
> > 
> > fdo#104009 https://bugs.freedesktop.org/show_bug.cgi?id=104009
> > fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
> > fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
> > 
> > shard-hswtotal:2623 pass:1499 dwarn:2   dfail:0   fail:9   
> > skip:1112 time:9330s
> > shard-snbtotal:2681 pass:1306 dwarn:3   dfail:0   fail:12  
> > skip:1360 time:8164s
> > Blacklisted hosts:
> > shard-apltotal:2659 pass:1657 dwarn:1   dfail:0   fail:23  skip:977 
> > time:13252s
> > shard-kbltotal:2681 pass:1797 dwarn:1   dfail:0   fail:24  skip:859 
> > time:10805s
> > 
> > == Logs ==
> > 
> > For more details see: 
> > https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_596/shards.html
> 
> Only the full results at
> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_596/shards-all.html
> show results for the new tests. For the record, both new tests passed
> on shard-kbl and shard-apl, skipped on shard-snb and shard-hsw.

And to clarify: The skips seem correct, but since the HDCP code is not
yet in the kernel, the passes are incorrect.


-- 
Petri Latvala
___
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] lib: avoid < in gtkdoc comments

[Joonas Lahtinen]

On Mon, 2017-12-04 at 21:48 +0100, Daniel Vetter wrote:
> For reasons entirely not clear to me meson gtkdoc runs in strict
> xml parsing mode, whereas automake gtkdoc doesn't. And gtkdoc itself
> is to dense to correctly escape this stuff.
> 
> Paper around this.
> 
> v2: {foo} instead of of tripy  (Joonas)
> 
> Cc: Joonas Lahtinen 
> Signed-off-by: Daniel Vetter 



> +++ b/lib/igt_core.c
> @@ -167,10 +167,10 @@
>   *   test logic.
>   *
>   * - When adding a new feature test function which uses igt_skip() 
> internally,
> - *   use the _require_ naming scheme. When you
> + *   use the {prefix}_require_{feature_name} naming scheme. When you
>   *   instead add a feature test function which returns a boolean, because 
> your
>   *   main test logic must take different actions depending upon the feature's
> - *   availability, then instead use the _has_.
> + *   availability, then instead use the {prefix}_has_.

Umm, should've used 'g' option :P

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

Re: [Intel-gfx] [PATCH i-g-t 2/3] meson: gtkdoc support

[Petri Latvala]

On Mon, Dec 04, 2017 at 09:48:36PM +0100, Daniel Vetter wrote:
> Bunch of neat improvements:
> 
> - xml generates correctly depend upon the test binaries
> - no need to re-run autogen.sh when new chapters/functions get added,
>   all handed by meson
> 
> Still one issue:
> 
> - the gtkdoc target doesn't depend upon the custom_target yet, hacked
>   around using build_by_default: true
> 
>   This is an issue known to upstream already:
> 
>   https://github.com/mesonbuild/meson/issues/2148
> 
> v2: Bump meson version to 0.42, since that's the first release which
> adds the build dir when running the gtkdoc tools, and hence allows
> including generated files.
> 
> v2:
> - Undo the bump, it's only needed for generated source files. Other
>   generated files as input should work with 0.40 already.
> 
> - Generate version.xml from version.xml.in, which allows us to keep
>   the &version; entity.
> 
> v3: Add github issue link.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  docs/meson.build   |  1 +
>  .../intel-gpu-tools/generate_description_xml.sh| 44 
>  .../intel-gpu-tools/generate_programs_xml.sh   | 22 ++
>  docs/reference/intel-gpu-tools/meson.build | 80 
> ++
>  docs/reference/meson.build |  1 +
>  meson.build|  3 +
>  meson.sh   |  2 +-
>  tests/meson.build  |  6 +-
>  8 files changed, 157 insertions(+), 2 deletions(-)
>  create mode 100644 docs/meson.build
>  create mode 100644 docs/reference/intel-gpu-tools/generate_description_xml.sh
>  create mode 100755 docs/reference/intel-gpu-tools/generate_programs_xml.sh
>  create mode 100644 docs/reference/intel-gpu-tools/meson.build
>  create mode 100644 docs/reference/meson.build
> 
> diff --git a/docs/meson.build b/docs/meson.build
> new file mode 100644
> index ..ead14c4015d9
> --- /dev/null
> +++ b/docs/meson.build
> @@ -0,0 +1 @@
> +subdir('reference')
> diff --git a/docs/reference/intel-gpu-tools/generate_description_xml.sh 
> b/docs/reference/intel-gpu-tools/generate_description_xml.sh
> new file mode 100644
> index ..8e39e0c4c289
> --- /dev/null
> +++ b/docs/reference/intel-gpu-tools/generate_description_xml.sh
> @@ -0,0 +1,44 @@
> +#!/bin/sh
> +
> +output=$1
> +filter=$2
> +testlist=$3
> +testdir=$(dirname $testlist)
> +
> +echo "" > $output
> +echo "> 
> $output
> +echo "   
> \"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd\""; >> $output
> +echo "[" >> $output
> +echo "   'http://www.w3.org/2003/XInclude'\">" >> $output
> +echo "  " >> $output
> +echo "]>" >> $output
> +echo "" >> $output
> +echo "Description" >> $output
> +for test in `cat $testlist | tr ' ' '\n' | grep "^$filter" | sort`; do
> + echo "" >> $output;
> + echo "$test" | perl -pe 
> 's/(?<=_)$(KEYWORDS)(?=(_|\W))/\1<\/acronym>/g' >> $output;
> + echo "" >> $output;
> + if ./$testprog --list-subtests > /dev/null ; then
> + echo "Subtests" >> $output;
> + subtest_list=`./$testprog --list-subtests`;
> + subtest_count=`echo $subtest_list | wc -w`;
> + if [ $subtest_count -gt 100 ]; then
> + echo "This test has over 100 subtests. " >> 
> $output;
> + echo "Run $test 
> --list-subtests to list them." >> $output;
> + else
> + echo "" >> $output;
> + for subtest in $subtest_list; do
> + echo "" >> $output;
> + echo "$subtest" | perl -pe 
> 's/\b$(KEYWORDS)\b/\1<\/acronym>/g' >> $output;
> + echo "" >> $output;
> + done;
> + echo "" >> $output;
> + fi;
> + echo "" >> $output;
> + fi;
> + echo "" >> $output;
> +done;
> +echo "" >> $output
> diff --git a/docs/reference/intel-gpu-tools/generate_programs_xml.sh 
> b/docs/reference/intel-gpu-tools/generate_programs_xml.sh
> new file mode 100755
> index ..73adc8cc7bfc
> --- /dev/null
> +++ b/docs/reference/intel-gpu-tools/generate_programs_xml.sh
> @@ -0,0 +1,22 @@
> +#!/bin/sh
> +
> +output=$1
> +filter=$2
> +testlist=$3
> +
> +echo "" > $output
> +echo "> 
> $output
> +echo "   
> \"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd\""; >> $output
> +echo "[" >> $output
> +echo "   'http://www.w3.org/2003/XInclude'\">" >> $output
> +echo "  " >> $output
> +echo "]>" >> $output
> +echo "" >> $output
> +echo "Programs" >> $output
> +echo "" 
> >> $output
> +for test in `cat $testlist | tr ' ' '\n' | grep "^$filter" | sort`; do
> + echo "" >> $output;
> + echo "$test" >> $output;
> +done;
> +echo "" >> $output
> +echo "" >> $output
> diff --git a/docs/reference/intel-gpu-tools/meson.build 
> b/docs/reference/intel-gpu-tools/meson.build
> new file mode 

Re: [Intel-gfx] [PATCH] drm: savely free connectors from connector_iter

[Daniel Vetter]

On Mon, Dec 04, 2017 at 09:48:18PM +0100, Daniel Vetter wrote:
> In
> 
> commit 613051dac40da1751ab269572766d3348d45a197
> Author: Daniel Vetter 
> Date:   Wed Dec 14 00:08:06 2016 +0100
> 
> drm: locking&new iterators for connector_list
> 
> we've went to extreme lengths to make sure connector iterations works
> in any context, without introducing any additional locking context.
> This worked, except for a small fumble in the implementation:
> 
> When we actually race with a concurrent connector unplug event, and
> our temporary connector reference turns out to be the final one, then
> everything breaks: We call the connector release function from
> whatever context we happen to be in, which can be an irq/atomic
> context. And connector freeing grabs all kinds of locks and stuff.
> 
> Fix this by creating a specially safe put function for connetor_iter,
> which (in this rare case) punts the cleanup to a worker.
> 
> Reported-by: Ben Widawsky 
> Cc: Ben Widawsky 
> Fixes: 613051dac40d ("drm: locking&new iterators for connector_list")
> Cc: Dave Airlie 
> Cc: Chris Wilson 
> Cc: Sean Paul 
> Cc:  # v4.11+
> Signed-off-by: Daniel Vetter 

s/savely/safely/ in the summary and

Reviewed-by: Dave Airlie 

from irc. CI is also happy, I'll merge as soon as Ben has approved this
too.
-Daniel

> ---
>  drivers/gpu/drm/drm_connector.c   | 28 ++--
>  drivers/gpu/drm/drm_mode_config.c |  2 ++
>  include/drm/drm_connector.h   |  8 
>  3 files changed, 36 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 25f4b2e9a44f..482014137953 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -152,6 +152,16 @@ static void drm_connector_free(struct kref *kref)
>   connector->funcs->destroy(connector);
>  }
>  
> +static void drm_connector_free_work_fn(struct work_struct *work)
> +{
> + struct drm_connector *connector =
> + container_of(work, struct drm_connector, free_work);
> + struct drm_device *dev = connector->dev;
> +
> + drm_mode_object_unregister(dev, &connector->base);
> + connector->funcs->destroy(connector);
> +}
> +
>  /**
>   * drm_connector_init - Init a preallocated connector
>   * @dev: DRM device
> @@ -181,6 +191,8 @@ int drm_connector_init(struct drm_device *dev,
>   if (ret)
>   return ret;
>  
> + INIT_WORK(&connector->free_work, drm_connector_free_work_fn);
> +
>   connector->base.properties = &connector->properties;
>   connector->dev = dev;
>   connector->funcs = funcs;
> @@ -529,6 +541,18 @@ void drm_connector_list_iter_begin(struct drm_device 
> *dev,
>  }
>  EXPORT_SYMBOL(drm_connector_list_iter_begin);
>  
> +/*
> + * Extra-safe connector put function that works in any context. Should only 
> be
> + * used from the connector_iter functions, where we never really expect to
> + * actually release the connector when dropping our final reference.
> + */
> +static void
> +drm_connector_put_safe(struct drm_connector *conn)
> +{
> + if (refcount_dec_and_test(&conn->base.refcount.refcount))
> + schedule_work(&conn->free_work);
> +}
> +
>  /**
>   * drm_connector_list_iter_next - return next connector
>   * @iter: connectr_list iterator
> @@ -561,7 +585,7 @@ drm_connector_list_iter_next(struct 
> drm_connector_list_iter *iter)
>   spin_unlock_irqrestore(&config->connector_list_lock, flags);
>  
>   if (old_conn)
> - drm_connector_put(old_conn);
> + drm_connector_put_safe(old_conn);
>  
>   return iter->conn;
>  }
> @@ -580,7 +604,7 @@ void drm_connector_list_iter_end(struct 
> drm_connector_list_iter *iter)
>  {
>   iter->dev = NULL;
>   if (iter->conn)
> - drm_connector_put(iter->conn);
> + drm_connector_put_safe(iter->conn);
>   lock_release(&connector_list_iter_dep_map, 0, _RET_IP_);
>  }
>  EXPORT_SYMBOL(drm_connector_list_iter_end);
> diff --git a/drivers/gpu/drm/drm_mode_config.c 
> b/drivers/gpu/drm/drm_mode_config.c
> index 7623607c0f1e..346c19c6ce01 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -431,6 +431,8 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>   drm_connector_put(connector);
>   }
>   drm_connector_list_iter_end(&conn_iter);
> + /* connector_iter drops references in a work item. */
> + flush_scheduled_work();
>   if (WARN_ON(!list_empty(&dev->mode_config.connector_list))) {
>   drm_connector_list_iter_begin(dev, &conn_iter);
>   drm_for_each_connector_iter(connector, &conn_iter)
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 66d6c99d15e5..c5c753a1be85 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -926,6 +926,14 @@ struct drm_connector {
>   uint8_t num_h_tile, num_v_tile;
>   uint8_t tile_h_loc, tile_v_lo

Re: [Intel-gfx] [PATCH 3/3] i965: check scratch page in a locked fashion on each ioctl

[Chris Wilson]

Quoting kevin.rogo...@intel.com (2017-12-05 07:48:14)
> From: Kevin Rogovin 
> 
> ---
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 27 
> ++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index 216073129b..53b3eaf49b 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -804,7 +804,8 @@ static int
>  submit_batch(struct brw_context *brw, int in_fence_fd, int *out_fence_fd)
>  {
> const struct gen_device_info *devinfo = &brw->screen->devinfo;
> -   __DRIscreen *dri_screen = brw->screen->driScrnPriv;
> +   struct intel_screen *screen = brw->screen;
> +   __DRIscreen *dri_screen = screen->driScrnPriv;
> struct intel_batchbuffer *batch = &brw->batch;
> int ret = 0;
>  
> @@ -875,10 +876,34 @@ submit_batch(struct brw_context *brw, int in_fence_fd, 
> int *out_fence_fd)
>   batch->validation_list[index] = tmp;
>}
>  
> +  if (unlikely(screen->debug_batchbuffer.enabled)) {
> + simple_mtx_lock(&screen->debug_batchbuffer.mutex);
> +  }

Per context, then you can remove the locking. It's fitting since the
scratch page is per-context anyway.

> +
>ret = execbuffer(dri_screen->fd, batch, hw_ctx,
> 4 * USED_BATCH(*batch),
> in_fence_fd, out_fence_fd, flags);
>  
> +  if (unlikely(screen->debug_batchbuffer.enabled)) {
> + struct drm_i915_scratch_page sc;
> + int ret;

Tie this into INTEL_DEBUG & SYNC, then you can do all the synchronous
operations in one place.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix compilation (panel orientation x enum plane rename).

[Joonas Lahtinen]

On Tue, 2017-12-05 at 09:18 +0100, Hans de Goede wrote:
> Hi,
> 
> On 05-12-17 01:58, Rodrigo Vivi wrote:
> > On Tue, Dec 05, 2017 at 12:09:35AM +, Michel Thierry wrote:
> > > On 12/4/2017 4:04 PM, Rodrigo Vivi wrote:
> > > > When commit '82daca297506 ("drm/i915: Add "panel orientation"
> > > > property to the panel connector, v6.")' was done and tested
> > > > by CI, commit 'ed15030d7ab0 ("drm/i915: s/enum plane/enum
> > > > i9xx_plane_id/")' wasn't there already.
> > 
> > Ops, the biggest issue now is that one patch is on drm-misc-next while
> > the other one is on drm-intel-next-queued.
> > 
> > I would just revert this from drm-misc-next and apply it to dinq
> > with a new fixed version or with this patch on top. But I'm not taking
> > any harsh decision without ack from drm-misc maintainers.
> > 
> > I will check to see if I get some ack or better ideas tonight before going
> > to bed or in a hope that someone in Europe timezone get this in the morning
> > and fix it.
> 
> Ugh, sorry, I tested that I did not break drm-misc-next compilation,
> but I did not realize this was going to break drm-tip compilation.
> 
> Just reverting the offending commit on drm-misc-next and
> adding a fixed version to dinq will not worked because the patch
> depends on the new panel-orientation member of struct drm_display_info.
> 
> So there are 2 options AFAICT:
> 
> Option 1:
> -Merge drm-misc-next into dinq
> -Add a fixup commit to dinq on top
> 
> Option 2:
> -Revert the commit from drm-misc-next
> -Merge drm-misc-next into dinq
> -Add a fixed version of the commit into dinq

Actually, what was needed (a very badly documented, with obscure
automated fixup patch naming :P) Option 3:

- Add a fixup commit to drm-rerere, so that it gets applied when
merging drm-intel-next-queued to drm-tip.

So it's basically like amending a regular GIT merge with --amend, where
the fixup diff resides in drm-rerere as a .patch file.

It's fixed now.

Regards, Joonas

> 
> Regards,
> 
> Hans
> 
> 
> 
> > > > 
> > > > On this race the second patch got merged first so the first one
> > > > broke i915 compilation. Thanks to Michel this was found quickly.
> > > > 
> > > > Cc: Michel Thierry 
> > > > Cc: Daniel Vetter 
> > > > Cc: Hans de Goede 
> > > > Suggested-by: Michel Thierry 
> > > > Fixes: 82daca297506 ("drm/i915: Add "panel orientation" property to the 
> > > > panel connector, v6.")
> > > > Signed-off-by: Rodrigo Vivi 
> > > > ---
> > > >drivers/gpu/drm/i915/intel_dsi.c | 2 +-
> > > >1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> > > > b/drivers/gpu/drm/i915/intel_dsi.c
> > > > index 1b60df3c14a0..f67d321376e4 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > > > @@ -1670,7 +1670,7 @@ static int intel_dsi_get_panel_orientation(struct 
> > > > intel_connector *connector)
> > > >{
> > > > struct drm_i915_private *dev_priv = 
> > > > to_i915(connector->base.dev);
> > > > int orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
> > > > -   enum plane plane;
> > > > +   enum i9xx_plane_id plane;
> > > > u32 val;
> > > > if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> > > > 
> > > 
> > > Reviewed-by: Michel Thierry 
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix compilation (panel orientation x enum plane rename).

[Daniel Vetter]

On Tue, Dec 05, 2017 at 12:12:27PM +0200, Joonas Lahtinen wrote:
> On Tue, 2017-12-05 at 09:18 +0100, Hans de Goede wrote:
> > Hi,
> > 
> > On 05-12-17 01:58, Rodrigo Vivi wrote:
> > > On Tue, Dec 05, 2017 at 12:09:35AM +, Michel Thierry wrote:
> > > > On 12/4/2017 4:04 PM, Rodrigo Vivi wrote:
> > > > > When commit '82daca297506 ("drm/i915: Add "panel orientation"
> > > > > property to the panel connector, v6.")' was done and tested
> > > > > by CI, commit 'ed15030d7ab0 ("drm/i915: s/enum plane/enum
> > > > > i9xx_plane_id/")' wasn't there already.
> > > 
> > > Ops, the biggest issue now is that one patch is on drm-misc-next while
> > > the other one is on drm-intel-next-queued.
> > > 
> > > I would just revert this from drm-misc-next and apply it to dinq
> > > with a new fixed version or with this patch on top. But I'm not taking
> > > any harsh decision without ack from drm-misc maintainers.
> > > 
> > > I will check to see if I get some ack or better ideas tonight before going
> > > to bed or in a hope that someone in Europe timezone get this in the 
> > > morning
> > > and fix it.
> > 
> > Ugh, sorry, I tested that I did not break drm-misc-next compilation,
> > but I did not realize this was going to break drm-tip compilation.
> > 
> > Just reverting the offending commit on drm-misc-next and
> > adding a fixed version to dinq will not worked because the patch
> > depends on the new panel-orientation member of struct drm_display_info.
> > 
> > So there are 2 options AFAICT:
> > 
> > Option 1:
> > -Merge drm-misc-next into dinq
> > -Add a fixup commit to dinq on top
> > 
> > Option 2:
> > -Revert the commit from drm-misc-next
> > -Merge drm-misc-next into dinq
> > -Add a fixed version of the commit into dinq
> 
> Actually, what was needed (a very badly documented, with obscure
> automated fixup patch naming :P) Option 3:
> 
> - Add a fixup commit to drm-rerere, so that it gets applied when
> merging drm-intel-next-queued to drm-tip.
> 
> So it's basically like amending a regular GIT merge with --amend, where
> the fixup diff resides in drm-rerere as a .patch file.
> 
> It's fixed now.

btw the recommended way to prevent this is to develop patches on top of
drm-tip. Then if you apply it to a branch where not all the patches are
included you'll either get a conflict or it wont' compile anymore. Either
way a warning sign telling you to check that drm-tip is still in good
shape. I think we even have that best practice documented in the committer
section of our docs.

Cheers, Daniel
> 
> Regards, Joonas
> 
> > 
> > Regards,
> > 
> > Hans
> > 
> > 
> > 
> > > > > 
> > > > > On this race the second patch got merged first so the first one
> > > > > broke i915 compilation. Thanks to Michel this was found quickly.
> > > > > 
> > > > > Cc: Michel Thierry 
> > > > > Cc: Daniel Vetter 
> > > > > Cc: Hans de Goede 
> > > > > Suggested-by: Michel Thierry 
> > > > > Fixes: 82daca297506 ("drm/i915: Add "panel orientation" property to 
> > > > > the panel connector, v6.")
> > > > > Signed-off-by: Rodrigo Vivi 
> > > > > ---
> > > > >drivers/gpu/drm/i915/intel_dsi.c | 2 +-
> > > > >1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> > > > > b/drivers/gpu/drm/i915/intel_dsi.c
> > > > > index 1b60df3c14a0..f67d321376e4 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > > > > @@ -1670,7 +1670,7 @@ static int 
> > > > > intel_dsi_get_panel_orientation(struct intel_connector *connector)
> > > > >{
> > > > >   struct drm_i915_private *dev_priv = 
> > > > > to_i915(connector->base.dev);
> > > > >   int orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
> > > > > - enum plane plane;
> > > > > + enum i9xx_plane_id plane;
> > > > >   u32 val;
> > > > >   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> > > > > 
> > > > 
> > > > Reviewed-by: Michel Thierry 
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> -- 
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation

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

[Intel-gfx] [PATCH i-g-t 1/1] lib/igt_gt: Add sentinel to intel_execution_engines2

[Petri Latvala]

The for_each_engine_class_instance macro stops at e__->name being
NULL, so add an object that is so.

Signed-off-by: Petri Latvala 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
---
 lib/igt_gt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/igt_gt.c b/lib/igt_gt.c
index 4a8f541f..ad6e6205 100644
--- a/lib/igt_gt.c
+++ b/lib/igt_gt.c
@@ -615,6 +615,7 @@ const struct intel_execution_engine2 
intel_execution_engines2[] = {
{ "vcs0", I915_ENGINE_CLASS_VIDEO, 0 },
{ "vcs1", I915_ENGINE_CLASS_VIDEO, 1 },
{ "vecs0", I915_ENGINE_CLASS_VIDEO_ENHANCE, 0 },
+   { }
 };
 
 unsigned int
-- 
2.14.1

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

[Intel-gfx] [PATCH i-g-t 3/3] meson: build a full dependency for lib_igt_perf

[Daniel Vetter]

meson prefers packages dependencies over passing arount static
libraries, because those also include linker flags, include dirs and
everything else.

While at it pull the special cases out from the common build stanzas
like we do with other special cases.

Just a bit of ocd to keep everything polished.

Cc: Tvrtko Ursulin 
Signed-off-by: Daniel Vetter 
---
 benchmarks/meson.build |  9 +++--
 lib/meson.build|  5 -
 overlay/meson.build|  4 ++--
 tests/meson.build  | 11 +--
 4 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/benchmarks/meson.build b/benchmarks/meson.build
index fa7f07643a97..4afd204f82b2 100644
--- a/benchmarks/meson.build
+++ b/benchmarks/meson.build
@@ -12,7 +12,6 @@ benchmark_progs = [
'gem_prw',
'gem_set_domain',
'gem_syslatency',
-   'gem_wsim',
'kms_vblank',
'prime_lookup',
'vgem_mmap',
@@ -31,11 +30,9 @@ endif
 foreach prog : benchmark_progs
# FIXME meson doesn't like binaries with the same name
# meanwhile just suffix with _bench
-   link = []
-   if prog == 'gem_wsim'
-   link += lib_igt_perf
-   endif
executable(prog + '_bench', prog + '.c',
-  link_with : link,
   dependencies : test_deps)
 endforeach
+
+executable('gem_wsim_bench', 'gem_wsim.c',
+  dependencies : test_deps + [ lib_igt_perf ])
diff --git a/lib/meson.build b/lib/meson.build
index 29d89cf09b58..d06d85b438b2 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -180,8 +180,11 @@ lib_igt = declare_dependency(link_with : lib_igt_build,
 
 igt_deps = [ lib_igt ] + lib_deps
 
-lib_igt_perf = static_library('igt_perf',
+lib_igt_perf_build = static_library('igt_perf',
['igt_perf.c']
 )
 
+lib_igt_perf = declare_dependency(link_with : lib_igt_perf_build,
+ include_directories : inc)
+
 subdir('tests')
diff --git a/overlay/meson.build b/overlay/meson.build
index 6b479eb89890..afacff5ecf60 100644
--- a/overlay/meson.build
+++ b/overlay/meson.build
@@ -21,7 +21,8 @@ dri2proto = dependency('dri2proto', version : '>= 2.6', 
required : false)
 cairo_xlib = dependency('cairo-xlib', required : false)
 xrandr = dependency('xrandr', version : '>=1.3', required : false)
 
-gpu_overlay_deps = [ realtime, math, cairo, pciaccess, libdrm, libdrm_intel ]
+gpu_overlay_deps = [ realtime, math, cairo, pciaccess, libdrm,
+   libdrm_intel, lib_igt_perf ]
 
 both_x11_src = ''
 
@@ -55,6 +56,5 @@ if xrandr.found() and cairo.found()
include_directories : inc,
c_args : gpu_overlay_cflags,
dependencies : gpu_overlay_deps,
-   link_with : lib_igt_perf,
install : true)
 endif
diff --git a/tests/meson.build b/tests/meson.build
index 94cb8bb48cc7..af73af1219df 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -190,7 +190,6 @@ test_progs = [
'kms_vblank',
'meta_test',
'perf',
-   'perf_pmu',
'pm_backlight',
'pm_lpsp',
'pm_rc6_residency',
@@ -260,17 +259,17 @@ libexecdir = join_paths(get_option('prefix'), 
get_option('libexecdir'), 'intel-g
 test_executables = []
 
 foreach prog : test_progs
-   link = []
-   if prog == 'perf_pmu'
-   link += lib_igt_perf
-   endif
test_executables += executable(prog, prog + '.c',
   dependencies : test_deps,
   install_dir : libexecdir,
-  link_with : link,
   install : true)
 endforeach
 
+test_executables += executable('perf_pmu', 'perf_pmu.c',
+  dependencies : test_deps + [ lib_igt_perf ],
+  install_dir : libexecdir,
+  install : true)
+
 executable('testdisplay', ['testdisplay.c', 'testdisplay_hotplug.c'],
   dependencies : test_deps,
   install_dir : libexecdir,
-- 
2.15.0

___
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] meson: gtkdoc support

[Daniel Vetter]

Bunch of neat improvements:

- xml generates correctly depend upon the test binaries
- no need to re-run autogen.sh when new chapters/functions get added,
  all handed by meson

Still one issue:

- the gtkdoc target doesn't depend upon the custom_target yet, hacked
  around using build_by_default: true

  This is an issue known to upstream already:

  https://github.com/mesonbuild/meson/issues/2148

v2: Bump meson version to 0.42, since that's the first release which
adds the build dir when running the gtkdoc tools, and hence allows
including generated files.

v2:
- Undo the bump, it's only needed for generated source files. Other
  generated files as input should work with 0.40 already.

- Generate version.xml from version.xml.in, which allows us to keep
  the &version; entity.

v3: Add github issue link.

v4:
- Resurrect lost KEYWORDS (Petri)
- Fix issue when running with a clean build, files() doesn't work on generate
  files (Petri).

Signed-off-by: Daniel Vetter 
---
 docs/meson.build   |  1 +
 .../intel-gpu-tools/generate_description_xml.sh| 46 +
 .../intel-gpu-tools/generate_programs_xml.sh   | 22 ++
 docs/reference/intel-gpu-tools/meson.build | 80 ++
 docs/reference/meson.build |  1 +
 meson.build|  3 +
 meson.sh   |  2 +-
 tests/meson.build  |  6 +-
 8 files changed, 158 insertions(+), 3 deletions(-)
 create mode 100644 docs/meson.build
 create mode 100644 docs/reference/intel-gpu-tools/generate_description_xml.sh
 create mode 100755 docs/reference/intel-gpu-tools/generate_programs_xml.sh
 create mode 100644 docs/reference/intel-gpu-tools/meson.build
 create mode 100644 docs/reference/meson.build

diff --git a/docs/meson.build b/docs/meson.build
new file mode 100644
index ..ead14c4015d9
--- /dev/null
+++ b/docs/meson.build
@@ -0,0 +1 @@
+subdir('reference')
diff --git a/docs/reference/intel-gpu-tools/generate_description_xml.sh 
b/docs/reference/intel-gpu-tools/generate_description_xml.sh
new file mode 100644
index ..705a7bf3f180
--- /dev/null
+++ b/docs/reference/intel-gpu-tools/generate_description_xml.sh
@@ -0,0 +1,46 @@
+#!/bin/sh
+
+output=$1
+filter=$2
+testlist=$3
+testdir=$(dirname $testlist)
+
+KEYWORDS="(invalid|hang|swap|thrash|crc|tiled|tiling|rte|ctx|render|blt|bsd|vebox|exec|rpm)"
+
+echo "" > $output
+echo "> 
$output
+echo "   
\"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd\""; >> $output
+echo "[" >> $output
+echo "  http://www.w3.org/2003/XInclude'\">" >> $output
+echo "  " >> $output
+echo "]>" >> $output
+echo "" >> $output
+echo "Description" >> $output
+for test in `cat $testlist | tr ' ' '\n' | grep "^$filter" | sort`; do
+   echo "" >> $output;
+   echo "$test" | perl -pe 
"s/(?<=_)$KEYWORDS(?=(_|\\W))/\\1<\\/acronym>/g" >> $output;
+   echo "" >> $output;
+   if ./$testprog --list-subtests > /dev/null ; then
+   echo "Subtests" >> $output;
+   subtest_list=`./$testprog --list-subtests`;
+   subtest_count=`echo $subtest_list | wc -w`;
+   if [ $subtest_count -gt 100 ]; then
+   echo "This test has over 100 subtests. " >> 
$output;
+   echo "Run $test 
--list-subtests to list them." >> $output;
+   else
+   echo "" >> $output;
+   for subtest in $subtest_list; do
+   echo "" >> $output;
+   echo "$subtest" | perl -pe 
"s/\\b$KEYWORDS\\b/\\1<\\/acronym>/g" >> $output;
+   echo "" >> $output;
+   done;
+   echo "" >> $output;
+   fi;
+   echo "" >> $output;
+   fi;
+   echo "" >> $output;
+done;
+echo "" >> $output
diff --git a/docs/reference/intel-gpu-tools/generate_programs_xml.sh 
b/docs/reference/intel-gpu-tools/generate_programs_xml.sh
new file mode 100755
index ..73adc8cc7bfc
--- /dev/null
+++ b/docs/reference/intel-gpu-tools/generate_programs_xml.sh
@@ -0,0 +1,22 @@
+#!/bin/sh
+
+output=$1
+filter=$2
+testlist=$3
+
+echo "" > $output
+echo "> 
$output
+echo "   
\"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd\""; >> $output
+echo "[" >> $output
+echo "  http://www.w3.org/2003/XInclude'\">" >> $output
+echo "  " >> $output
+echo "]>" >> $output
+echo "" >> $output
+echo "Programs" >> $output
+echo "" 
>> $output
+for test in `cat $testlist | tr ' ' '\n' | grep "^$filter" | sort`; do
+   echo "" >> $output;
+   echo "$test" >> $output;
+done;
+echo "" >> $output
+echo "" >> $output
diff --git a/docs/reference/intel-gpu-tools/meson.build 
b/docs/reference/intel-gpu-tools/meson.build
new file mode 100644
index ..1c009229aae2
--- /dev/null
+++ b/docs/refer

[Intel-gfx] [PATCH i-g-t 1/3] lib: avoid < in gtkdoc comments

[Daniel Vetter]

For reasons entirely not clear to me meson gtkdoc runs in strict
xml parsing mode, whereas automake gtkdoc doesn't. And gtkdoc itself
is to dense to correctly escape this stuff.

Paper around this.

v2: {foo} instead of of tripy  (Joonas)

v3: More fixups (Joonas)

Cc: Joonas Lahtinen 
Signed-off-by: Daniel Vetter 
---
 lib/igt_aux.c | 4 ++--
 lib/igt_core.c| 4 ++--
 lib/igt_debugfs.c | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index e2424109ef20..8ca0b60d0925 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -998,7 +998,7 @@ void igt_drop_root(void)
  * @var: var lookup to to enable this wait
  *
  * Waits for a key press when run interactively and when the corresponding 
debug
- * var is set in the --interactive-debug= variable. Multiple keys
+ * var is set in the --interactive-debug=$var variable. Multiple keys
  * can be specified as a comma-separated list or alternatively "all" if a wait
  * should happen for all cases.
  *
@@ -1039,7 +1039,7 @@ void igt_debug_wait_for_keypress(const char *var)
  * @expected: message to be printed as expected behaviour before wait for keys 
Y/n
  *
  * Waits for a key press when run interactively and when the corresponding 
debug
- * var is set in the --interactive-debug= variable. Multiple vars
+ * var is set in the --interactive-debug=$var variable. Multiple vars
  * can be specified as a comma-separated list or alternatively "all" if a wait
  * should happen for all cases.
  *
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 03fa6e4e836b..777687b5f795 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -167,10 +167,10 @@
  *   test logic.
  *
  * - When adding a new feature test function which uses igt_skip() internally,
- *   use the _require_ naming scheme. When you
+ *   use the {prefix}_require_{feature_name} naming scheme. When you
  *   instead add a feature test function which returns a boolean, because your
  *   main test logic must take different actions depending upon the feature's
- *   availability, then instead use the _has_.
+ *   availability, then instead use the {prefix}_has_{feature_name}.
  *
  * - As already mentioned eschew explicit error handling logic as much as
  *   possible. If your test absolutely has to handle the error of some function
diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index 9af8a5933480..49b68dfed0aa 100644
--- a/lib/igt_debugfs.c
+++ b/lib/igt_debugfs.c
@@ -231,7 +231,7 @@ int igt_debugfs_dir(int device)
  * @mode: mode bits as used by open()
  *
  * This opens a debugfs file as a Unix file descriptor. The filename should be
- * relative to the drm device's root, i.e. without "drm/".
+ * relative to the drm device's root, i.e. without "drm/$minor".
  *
  * Returns:
  * The Unix file descriptor for the debugfs file or -1 if that didn't work out.
-- 
2.15.0

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

Re: [Intel-gfx] [PATCH i-g-t 1/1] lib/igt_gt: Add sentinel to intel_execution_engines2

[Tvrtko Ursulin]

On 05/12/2017 10:16, Petri Latvala wrote:

The for_each_engine_class_instance macro stops at e__->name being
NULL, so add an object that is so.

Signed-off-by: Petri Latvala 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
---
  lib/igt_gt.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/lib/igt_gt.c b/lib/igt_gt.c
index 4a8f541f..ad6e6205 100644
--- a/lib/igt_gt.c
+++ b/lib/igt_gt.c
@@ -615,6 +615,7 @@ const struct intel_execution_engine2 
intel_execution_engines2[] = {
{ "vcs0", I915_ENGINE_CLASS_VIDEO, 0 },
{ "vcs1", I915_ENGINE_CLASS_VIDEO, 1 },
{ "vecs0", I915_ENGINE_CLASS_VIDEO_ENHANCE, 0 },
+   { }
  };
  
  unsigned int




Oh dear, well spotted.

Reviewed-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] drm/i915: Generalize definition for crtc mask

[Mika Kahola]

crtc_mask is defined explicitly defined for a certain number of pipes per
platform. Let's generalize this in a way that crtc_mask dependens only on
the number of pipes defined in device info.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_crt.c  |  9 ++---
 drivers/gpu/drm/i915/intel_ddi.c  |  5 -
 drivers/gpu/drm/i915/intel_dp.c   | 12 
 drivers/gpu/drm/i915/intel_hdmi.c |  4 +++-
 drivers/gpu/drm/i915/intel_lvds.c | 12 +++-
 drivers/gpu/drm/i915/intel_sdvo.c |  5 -
 drivers/gpu/drm/i915/intel_tv.c   |  6 +-
 7 files changed, 37 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 9f31aea..34f65b5 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -903,6 +903,7 @@ void intel_crt_init(struct drm_i915_private *dev_priv)
struct intel_connector *intel_connector;
i915_reg_t adpa_reg;
u32 adpa;
+   enum pipe pipe;
 
if (HAS_PCH_SPLIT(dev_priv))
adpa_reg = PCH_ADPA;
@@ -950,10 +951,12 @@ void intel_crt_init(struct drm_i915_private *dev_priv)
 
crt->base.type = INTEL_OUTPUT_ANALOG;
crt->base.cloneable = (1 << INTEL_OUTPUT_DVO) | (1 << 
INTEL_OUTPUT_HDMI);
-   if (IS_I830(dev_priv))
+   if (IS_I830(dev_priv)) {
crt->base.crtc_mask = (1 << 0);
-   else
-   crt->base.crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
+   } else {
+   for_each_pipe(dev_priv, pipe)
+   crt->base.crtc_mask |= (1 << pipe);
+   }
 
if (IS_GEN2(dev_priv))
connector->interlace_allowed = 0;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index eff3b51..9320542 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2766,6 +2766,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
struct drm_encoder *encoder;
bool init_hdmi, init_dp, init_lspcon = false;
int max_lanes;
+   enum pipe pipe;
 
if (I915_READ(DDI_BUF_CTL(PORT_A)) & DDI_A_4_LANES) {
switch (port) {
@@ -2884,9 +2885,11 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
intel_encoder->type = INTEL_OUTPUT_DDI;
intel_encoder->power_domain = intel_port_to_power_domain(port);
intel_encoder->port = port;
-   intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
intel_encoder->cloneable = 0;
 
+   for_each_pipe(dev_priv, pipe)
+   intel_encoder->crtc_mask |= (1 << pipe);
+
intel_infoframe_init(intel_dig_port);
 
if (init_dp) {
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 957735c..37ba90d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6139,6 +6139,7 @@ bool intel_dp_init(struct drm_i915_private *dev_priv,
struct intel_encoder *intel_encoder;
struct drm_encoder *encoder;
struct intel_connector *intel_connector;
+   enum pipe pipe;
 
intel_dig_port = kzalloc(sizeof(*intel_dig_port), GFP_KERNEL);
if (!intel_dig_port)
@@ -6190,12 +6191,15 @@ bool intel_dp_init(struct drm_i915_private *dev_priv,
intel_encoder->type = INTEL_OUTPUT_DP;
intel_encoder->power_domain = intel_port_to_power_domain(port);
if (IS_CHERRYVIEW(dev_priv)) {
-   if (port == PORT_D)
+   if (port == PORT_D) {
intel_encoder->crtc_mask = 1 << 2;
-   else
-   intel_encoder->crtc_mask = (1 << 0) | (1 << 1);
+   } else {
+   for_each_pipe(dev_priv, pipe)
+   intel_encoder->crtc_mask |= (1 << pipe);
+   }
} else {
-   intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
+   for_each_pipe(dev_priv, pipe)
+   intel_encoder->crtc_mask |= (1 << pipe);
}
intel_encoder->cloneable = 0;
intel_encoder->port = port;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index a40f35a..43584d9 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2072,6 +2072,7 @@ void intel_hdmi_init(struct drm_i915_private *dev_priv,
struct intel_digital_port *intel_dig_port;
struct intel_encoder *intel_encoder;
struct intel_connector *intel_connector;
+   enum pipe pipe;
 
intel_dig_port = kzalloc(sizeof(*intel_dig_port), GFP_KERNEL);
if (!intel_dig_port)
@@ -2128,7 +2129,8 @@ void intel_hdmi_init(struct drm_i915_private *dev_priv,
else
intel_encoder->crtc_mask = (1 << 0) | (1 << 1);
} else {
-   intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
+   

Re: [Intel-gfx] [PATCH 3/3] i965: check scratch page in a locked fashion on each ioctl

[Rogovin, Kevin]

Hi,

> Per context, then you can remove the locking. It's fitting since the scratch 
> page is per-context anyway.

 The scratch page is per context? This I did not know, I thought it was per 
PPGTT. If that is the case, then my proposed interface to get/set the scratch 
page contents is wrong because it does not pass the HW context id.

-Kevin 

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Disable display crc feature for vgpu

[Patchwork]

== Series Details ==

Series: drm/i915: Disable display crc feature for vgpu
URL   : https://patchwork.freedesktop.org/series/34889/
State : success

== Summary ==

Test gem_tiled_swapping:
Subgroup non-threaded:
pass   -> INCOMPLETE (shard-snb) fdo#104009
Test gem_eio:
Subgroup in-flight-contexts:
pass   -> DMESG-WARN (shard-snb) fdo#104058
Test kms_flip:
Subgroup plain-flip-ts-check-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623

fdo#104009 https://bugs.freedesktop.org/show_bug.cgi?id=104009
fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-hswtotal:2650 pass:1519 dwarn:1   dfail:0   fail:11  skip:1118 
time:9034s
shard-snbtotal:2650 pass:1293 dwarn:2   dfail:0   fail:11  skip:1343 
time:7824s
Blacklisted hosts:
shard-apltotal:2679 pass:1676 dwarn:3   dfail:0   fail:23  skip:977 
time:13506s
shard-kbltotal:2621 pass:1755 dwarn:3   dfail:0   fail:23  skip:839 
time:10321s

== Logs ==

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

Re: [Intel-gfx] [RFC PATCH 1/6] drm: Add Content Protection property

[Pavel Machek]

On Wed 2017-11-29 22:08:56, Sean Paul wrote:
> This patch adds a new optional connector property to allow userspace to enable
> protection over the content it is displaying. This will typically be 
> implemented
> by the driver using HDCP.
> 
> The property is a tri-state with the following values:
> - OFF: Self explanatory, no content protection
> - DESIRED: Userspace requests that the driver enable protection
> - ENABLED: Once the driver has authenticated the link, it sets this value
> 
> The driver is responsible for downgrading ENABLED to DESIRED if the link 
> becomes
> unprotected. The driver should also maintain the desiredness of protection
> across hotplug/dpms/suspend.

Why would user of the machine want this to be something else than
'OFF'?

If kernel implements this, will it mean hardware vendors will have to
prevent user from updating kernel on machines they own?

If this is merged, does it open kernel developers to DMCA threats if
they try to change it?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/1] lib/igt_gt: Add sentinel to intel_execution_engines2

[Patchwork]

== Series Details ==

Series: series starting with [1/1] lib/igt_gt: Add sentinel to 
intel_execution_engines2
URL   : https://patchwork.freedesktop.org/series/34892/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
ece35d37e6b0afc0ba99f66179279960042c87bc tests/gem_seqno_wrap: Drop 
gem_seqno_wrap.c

with latest DRM-Tip kernel build CI_DRM_3456
84cd3d972bdd drm-tip: 2017y-12m-05d-08h-41m-59s UTC integration manifest

No testlist changes.

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_chamelium:
Subgroup dp-crc-fast:
dmesg-fail -> PASS   (fi-kbl-7500u) fdo#103841

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:440s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:443s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:386s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:518s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:507s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:514s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:492s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:475s
fi-elk-e7500 total:224  pass:163  dwarn:14  dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:1   dfail:0   fail:0   skip:108 
time:272s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:543s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:375s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:261s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:398s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:453s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:485s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:528s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:474s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:531s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:591s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:459s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:544s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:571s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:524s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:502s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:450s
fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:557s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:426s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:611s
fi-cnl-y total:235  pass:210  dwarn:0   dfail:0   fail:0   skip:24 
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:489s

== Logs ==

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

Re: [Intel-gfx] [PATCH 3/3] i965: check scratch page in a locked fashion on each ioctl

[Chris Wilson]

Quoting Rogovin, Kevin (2017-12-05 10:30:04)
> Hi,
> 
> > Per context, then you can remove the locking. It's fitting since the 
> > scratch page is per-context anyway.
> 
>  The scratch page is per context? This I did not know, I thought it was per 
> PPGTT. If that is the case, then my proposed interface to get/set the scratch 
> page contents is wrong because it does not pass the HW context id.

Yes, it per-vm, which is per-ctx on everything you want to investigate
on. gen4-7 it is a global GTT with a global scratch, and just a mutex
inside one process is not going to give you atomicity.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] i965: check scratch page in a locked fashion on each ioctl

[Rogovin, Kevin]

Thanks, I will make a v2 and post it shortly to correct for my terribly 
embarrassing omission caused by even more terribly embarrassing ignorance.

-Kevin

-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] 
Sent: Tuesday, December 5, 2017 12:39 PM
To: Rogovin, Kevin ; intel-gfx@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH 3/3] i965: check scratch page in a locked 
fashion on each ioctl

Quoting Rogovin, Kevin (2017-12-05 10:30:04)
> Hi,
> 
> > Per context, then you can remove the locking. It's fitting since the 
> > scratch page is per-context anyway.
> 
>  The scratch page is per context? This I did not know, I thought it was per 
> PPGTT. If that is the case, then my proposed interface to get/set the scratch 
> page contents is wrong because it does not pass the HW context id.

Yes, it per-vm, which is per-ctx on everything you want to investigate on. 
gen4-7 it is a global GTT with a global scratch, and just a mutex inside one 
process is not going to give you atomicity.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix compilation (panel orientation x enum plane rename).

[Hans de Goede]

Hi,

On 05-12-17 11:14, Daniel Vetter wrote:

On Tue, Dec 05, 2017 at 12:12:27PM +0200, Joonas Lahtinen wrote:

On Tue, 2017-12-05 at 09:18 +0100, Hans de Goede wrote:

Hi,

On 05-12-17 01:58, Rodrigo Vivi wrote:

On Tue, Dec 05, 2017 at 12:09:35AM +, Michel Thierry wrote:

On 12/4/2017 4:04 PM, Rodrigo Vivi wrote:

When commit '82daca297506 ("drm/i915: Add "panel orientation"
property to the panel connector, v6.")' was done and tested
by CI, commit 'ed15030d7ab0 ("drm/i915: s/enum plane/enum
i9xx_plane_id/")' wasn't there already.


Ops, the biggest issue now is that one patch is on drm-misc-next while
the other one is on drm-intel-next-queued.

I would just revert this from drm-misc-next and apply it to dinq
with a new fixed version or with this patch on top. But I'm not taking
any harsh decision without ack from drm-misc maintainers.

I will check to see if I get some ack or better ideas tonight before going
to bed or in a hope that someone in Europe timezone get this in the morning
and fix it.


Ugh, sorry, I tested that I did not break drm-misc-next compilation,
but I did not realize this was going to break drm-tip compilation.

Just reverting the offending commit on drm-misc-next and
adding a fixed version to dinq will not worked because the patch
depends on the new panel-orientation member of struct drm_display_info.

So there are 2 options AFAICT:

Option 1:
-Merge drm-misc-next into dinq
-Add a fixup commit to dinq on top

Option 2:
-Revert the commit from drm-misc-next
-Merge drm-misc-next into dinq
-Add a fixed version of the commit into dinq


Actually, what was needed (a very badly documented, with obscure
automated fixup patch naming :P) Option 3:

- Add a fixup commit to drm-rerere, so that it gets applied when
merging drm-intel-next-queued to drm-tip.

So it's basically like amending a regular GIT merge with --amend, where
the fixup diff resides in drm-rerere as a .patch file.

It's fixed now.


btw the recommended way to prevent this is to develop patches on top of
drm-tip. Then if you apply it to a branch where not all the patches are
included you'll either get a conflict or it wont' compile anymore. Either
way a warning sign telling you to check that drm-tip is still in good
shape. I think we even have that best practice documented in the committer
section of our docs.


Ok, I will remember that for the next time.

Regards,

Hans






On this race the second patch got merged first so the first one
broke i915 compilation. Thanks to Michel this was found quickly.

Cc: Michel Thierry 
Cc: Daniel Vetter 
Cc: Hans de Goede 
Suggested-by: Michel Thierry 
Fixes: 82daca297506 ("drm/i915: Add "panel orientation" property to the panel 
connector, v6.")
Signed-off-by: Rodrigo Vivi 
---
drivers/gpu/drm/i915/intel_dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 1b60df3c14a0..f67d321376e4 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1670,7 +1670,7 @@ static int intel_dsi_get_panel_orientation(struct 
intel_connector *connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
int orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
-   enum plane plane;
+   enum i9xx_plane_id plane;
u32 val;
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {



Reviewed-by: Michel Thierry 


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

--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation



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

Re: [Intel-gfx] [PATCH i-g-t 3/3] meson: build a full dependency for lib_igt_perf

[Petri Latvala]

On Tue, Dec 05, 2017 at 11:16:50AM +0100, Daniel Vetter wrote:
> meson prefers packages dependencies over passing arount static
> libraries, because those also include linker flags, include dirs and
> everything else.
> 
> While at it pull the special cases out from the common build stanzas
> like we do with other special cases.
> 
> Just a bit of ocd to keep everything polished.
> 
> Cc: Tvrtko Ursulin 
> Signed-off-by: Daniel Vetter 
> ---
>  benchmarks/meson.build |  9 +++--
>  lib/meson.build|  5 -
>  overlay/meson.build|  4 ++--
>  tests/meson.build  | 11 +--
>  4 files changed, 14 insertions(+), 15 deletions(-)
> 
> diff --git a/benchmarks/meson.build b/benchmarks/meson.build
> index fa7f07643a97..4afd204f82b2 100644
> --- a/benchmarks/meson.build
> +++ b/benchmarks/meson.build
> @@ -12,7 +12,6 @@ benchmark_progs = [
>   'gem_prw',
>   'gem_set_domain',
>   'gem_syslatency',
> - 'gem_wsim',
>   'kms_vblank',
>   'prime_lookup',
>   'vgem_mmap',
> @@ -31,11 +30,9 @@ endif
>  foreach prog : benchmark_progs
>   # FIXME meson doesn't like binaries with the same name
>   # meanwhile just suffix with _bench
> - link = []
> - if prog == 'gem_wsim'
> - link += lib_igt_perf
> - endif
>   executable(prog + '_bench', prog + '.c',
> -link_with : link,
>  dependencies : test_deps)
>  endforeach
> +
> +executable('gem_wsim_bench', 'gem_wsim.c',
> +dependencies : test_deps + [ lib_igt_perf ])
> diff --git a/lib/meson.build b/lib/meson.build
> index 29d89cf09b58..d06d85b438b2 100644
> --- a/lib/meson.build
> +++ b/lib/meson.build
> @@ -180,8 +180,11 @@ lib_igt = declare_dependency(link_with : lib_igt_build,
>  
>  igt_deps = [ lib_igt ] + lib_deps
>  
> -lib_igt_perf = static_library('igt_perf',
> +lib_igt_perf_build = static_library('igt_perf',
>   ['igt_perf.c']
>  )
>  
> +lib_igt_perf = declare_dependency(link_with : lib_igt_perf_build,
> +   include_directories : inc)
> +
>  subdir('tests')
> diff --git a/overlay/meson.build b/overlay/meson.build
> index 6b479eb89890..afacff5ecf60 100644
> --- a/overlay/meson.build
> +++ b/overlay/meson.build
> @@ -21,7 +21,8 @@ dri2proto = dependency('dri2proto', version : '>= 2.6', 
> required : false)
>  cairo_xlib = dependency('cairo-xlib', required : false)
>  xrandr = dependency('xrandr', version : '>=1.3', required : false)
>  
> -gpu_overlay_deps = [ realtime, math, cairo, pciaccess, libdrm, libdrm_intel ]
> +gpu_overlay_deps = [ realtime, math, cairo, pciaccess, libdrm,
> + libdrm_intel, lib_igt_perf ]
>  
>  both_x11_src = ''
>  
> @@ -55,6 +56,5 @@ if xrandr.found() and cairo.found()
>   include_directories : inc,
>   c_args : gpu_overlay_cflags,
>   dependencies : gpu_overlay_deps,
> - link_with : lib_igt_perf,
>   install : true)
>  endif
> diff --git a/tests/meson.build b/tests/meson.build
> index 94cb8bb48cc7..af73af1219df 100644
> --- a/tests/meson.build
> +++ b/tests/meson.build
> @@ -190,7 +190,6 @@ test_progs = [
>   'kms_vblank',
>   'meta_test',
>   'perf',
> - 'perf_pmu',
>   'pm_backlight',
>   'pm_lpsp',
>   'pm_rc6_residency',
> @@ -260,17 +259,17 @@ libexecdir = join_paths(get_option('prefix'), 
> get_option('libexecdir'), 'intel-g
>  test_executables = []
>  
>  foreach prog : test_progs
> - link = []
> - if prog == 'perf_pmu'
> - link += lib_igt_perf
> - endif
>   test_executables += executable(prog, prog + '.c',
>  dependencies : test_deps,
>  install_dir : libexecdir,
> -link_with : link,
>  install : true)
>  endforeach
>  
> +test_executables += executable('perf_pmu', 'perf_pmu.c',
> +dependencies : test_deps + [ lib_igt_perf ],
> +install_dir : libexecdir,
> +install : true)
> +


I'm fairly sure I had this commit in my earlier tests for this series,
but apparently not.

test_progs += 'perf_pmu'

is needed here, or perf_pmu doesn't get its place in test-list.txt.


-- 
Petri Latvala



>  executable('testdisplay', ['testdisplay.c', 'testdisplay_hotplug.c'],
>  dependencies : test_deps,
>  install_dir : libexecdir,
> -- 
> 2.15.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 1/6] drm: Add Content Protection property

[Daniel Vetter]

On Tue, Dec 05, 2017 at 11:28:40AM +0100, Pavel Machek wrote:
> On Wed 2017-11-29 22:08:56, Sean Paul wrote:
> > This patch adds a new optional connector property to allow userspace to 
> > enable
> > protection over the content it is displaying. This will typically be 
> > implemented
> > by the driver using HDCP.
> > 
> > The property is a tri-state with the following values:
> > - OFF: Self explanatory, no content protection
> > - DESIRED: Userspace requests that the driver enable protection
> > - ENABLED: Once the driver has authenticated the link, it sets this value
> > 
> > The driver is responsible for downgrading ENABLED to DESIRED if the link 
> > becomes
> > unprotected. The driver should also maintain the desiredness of protection
> > across hotplug/dpms/suspend.
> 
> Why would user of the machine want this to be something else than
> 'OFF'?
> 
> If kernel implements this, will it mean hardware vendors will have to
> prevent user from updating kernel on machines they own?
> 
> If this is merged, does it open kernel developers to DMCA threats if
> they try to change it?

Because this just implements one part of the content protection scheme.
This only gives you an option to enable HDCP (aka encryption, it's really
nothing else) on the cable. Just because it has Content Protection in the
name does _not_ mean it is (stand-alone) an effective nor complete content
protection scheme. It's simply encrypting data, that's all.

If you want to actually lock down a machine to implement content
protection, then you need secure boot without unlockable boot-loader and a
pile more bits in userspace.  If you do all that, only then do you have
full content protection. And yes, then you don't really own the machine
fully, and I think users who are concerned with being able to update their
kernels and be able to exercise their software freedoms already know to
avoid such locked down systems.

So yeah it would be better to call this the "HDMI/DP cable encryption
support", but well, it's not what it's called really.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt 1/2] igt/pm_rc6_residency: Replace hard-coded sleep before rc6 with a probe

[Chris Wilson]

Instead of trying to sleep for 2 evaluations intervals and then assuming
that rc6 is working, poll the rc6 residency instead.

References: https://bugs.freedesktop.org/show_bug.cgi?id=104099
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 tests/pm_rc6_residency.c | 33 ++---
 1 file changed, 14 insertions(+), 19 deletions(-)

diff --git a/tests/pm_rc6_residency.c b/tests/pm_rc6_residency.c
index 3f6860199..16f4b1421 100644
--- a/tests/pm_rc6_residency.c
+++ b/tests/pm_rc6_residency.c
@@ -122,9 +122,6 @@ static void measure_residencies(int devid, unsigned int 
mask,
struct residencies end = { };
int retry;
 
-   if (!mask)
-   return;
-
/*
 * Retry in case of counter wrap-around. We simply re-run the
 * measurement, since the valid counter range is different on
@@ -168,17 +165,18 @@ static void measure_residencies(int devid, unsigned int 
mask,
res->rc6 += res->rc6p;
 }
 
-static unsigned long rc6_enable_us(void)
+static bool wait_for_rc6(void)
 {
-   /*
-* To know how long we need to wait for the device to enter rc6 once
-* idle, we need to look at GEN6_RC_EVALUATION_INTERVAL. Currently,
-* this is set to 125000 (12500 * 1280ns or 0.16s) on all platforms.
-* We must complete at least one EI with activity below the
-* per-platform threshold for RC6 to kick. Therefore, we must wait
-* at least 2 EI cycles, before we can expect rc6 to start ticking.
-*/
-   return 2 * 160 * 1000;
+   struct timespec tv = {};
+   unsigned long start, now;
+
+   start = read_rc6_residency("rc6");
+   do {
+   usleep(50);
+   now = read_rc6_residency("rc6");
+   } while (now == start && !igt_seconds_elapsed(&tv));
+
+   return now != start;
 }
 
 igt_main
@@ -198,19 +196,17 @@ igt_main
 
/* Make sure rc6 counters are running */
igt_drop_caches_set(fd, DROP_IDLE);
-   usleep(rc6_enable_us());
+   igt_require(wait_for_rc6());
 
close(fd);
 
rc6_enabled = get_rc6_enabled_mask();
-   igt_require(rc6_enabled);
+   igt_require(rc6_enabled & RC6_ENABLED);
}
 
igt_subtest("rc6-accuracy") {
struct residencies res;
 
-   igt_require(rc6_enabled & RC6_ENABLED);
-
measure_residencies(devid, rc6_enabled, &res);
residency_accuracy(res.rc6, res.duration, "rc6");
}
@@ -218,8 +214,7 @@ igt_main
igt_subtest("media-rc6-accuracy") {
struct residencies res;
 
-   igt_require((rc6_enabled & RC6_ENABLED) &&
-   (IS_VALLEYVIEW(devid) || IS_CHERRYVIEW(devid)));
+   igt_require(IS_VALLEYVIEW(devid) || IS_CHERRYVIEW(devid));
 
measure_residencies(devid, rc6_enabled, &res);
residency_accuracy(res.media_rc6, res.duration, "media_rc6");
-- 
2.15.1

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

[Intel-gfx] [PATCH igt 2/2] igt/perf_pmu: Replace hard-coded sleep before rc6 with a probe

[Chris Wilson]

Instead of trying to sleep for 2 evaluations intervals and then assuming
that rc6 is working, poll the rc6 residency instead.

References: https://bugs.freedesktop.org/show_bug.cgi?id=103929
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 tests/perf_pmu.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index e872f4e55..65bc734da 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -1008,6 +1008,20 @@ static unsigned long rc6_enable_us(void)
return 2 * 160 * 1000;
 }
 
+static bool wait_for_rc6(int fd)
+{
+   struct timespec tv = {};
+   uint64_t start, now;
+
+   start = pmu_read_single(fd);
+   do {
+   usleep(50);
+   now = pmu_read_single(fd);
+   } while (start == now && !igt_seconds_elapsed(&tv));
+
+   return start != now;
+}
+
 static void
 test_rc6(int gem_fd)
 {
@@ -1019,7 +1033,7 @@ test_rc6(int gem_fd)
fd = open_pmu(I915_PMU_RC6_RESIDENCY);
 
gem_quiescent_gpu(gem_fd);
-   usleep(rc6_enable_us()); /* wait for the rc6 cycle counter to kick in */
+   igt_require(wait_for_rc6(fd));
 
/* Go idle and check full RC6. */
prev = pmu_read_single(fd);
-- 
2.15.1

___
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: Generalize definition for crtc mask

[Patchwork]

== Series Details ==

Series: drm/i915: Generalize definition for crtc mask
URL   : https://patchwork.freedesktop.org/series/34894/
State : warning

== Summary ==

Series 34894v1 drm/i915: Generalize definition for crtc mask
https://patchwork.freedesktop.org/api/1.0/series/34894/revisions/1/mbox/

Test gem_exec_reloc:
Subgroup basic-cpu-gtt-active:
pass   -> FAIL   (fi-gdg-551) fdo#102582 +3
Test kms_busy:
Subgroup basic-flip-a:
pass   -> SKIP   (fi-bwr-2160)
Test kms_chamelium:
Subgroup dp-crc-fast:
dmesg-fail -> PASS   (fi-kbl-7500u) fdo#103841
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-hsw-4770) fdo#103375
Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> SKIP   (fi-bwr-2160) fdo#103182

fdo#102582 https://bugs.freedesktop.org/show_bug.cgi?id=102582
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103182 https://bugs.freedesktop.org/show_bug.cgi?id=103182

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:442s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:448s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:390s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:531s
fi-bwr-2160  total:288  pass:181  dwarn:0   dfail:0   fail:0   skip:107 
time:274s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:504s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:513s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:491s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:480s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:174  dwarn:1   dfail:0   fail:5   skip:108 
time:270s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:545s
fi-hsw-4770  total:244  pass:220  dwarn:0   dfail:0   fail:0   skip:23 
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:259s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:399s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:455s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:487s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:526s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:481s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:533s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:543s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:522s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:504s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:447s
fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:549s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:419s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:617s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:628s
fi-glk-dsi   total:103  pass:91   dwarn:0   dfail:0   fail:0   skip:11 

84cd3d972bdd25fd6f7fe3dc2fe92b0617cde2a5 drm-tip: 2017y-12m-05d-08h-41m-59s UTC 
integration manifest
292c13a60aa3 drm/i915: Generalize definition for crtc mask

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t 3/3] meson: build a full dependency for lib_igt_perf

[Petri Latvala]

On Tue, Dec 05, 2017 at 12:44:02PM +0200, Petri Latvala wrote:
> On Tue, Dec 05, 2017 at 11:16:50AM +0100, Daniel Vetter wrote:
> > meson prefers packages dependencies over passing arount static
> > libraries, because those also include linker flags, include dirs and
> > everything else.
> > 
> > While at it pull the special cases out from the common build stanzas
> > like we do with other special cases.
> > 
> > Just a bit of ocd to keep everything polished.
> > 
> > Cc: Tvrtko Ursulin 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  benchmarks/meson.build |  9 +++--
> >  lib/meson.build|  5 -
> >  overlay/meson.build|  4 ++--
> >  tests/meson.build  | 11 +--
> >  4 files changed, 14 insertions(+), 15 deletions(-)
> > 
> > diff --git a/benchmarks/meson.build b/benchmarks/meson.build
> > index fa7f07643a97..4afd204f82b2 100644
> > --- a/benchmarks/meson.build
> > +++ b/benchmarks/meson.build
> > @@ -12,7 +12,6 @@ benchmark_progs = [
> > 'gem_prw',
> > 'gem_set_domain',
> > 'gem_syslatency',
> > -   'gem_wsim',
> > 'kms_vblank',
> > 'prime_lookup',
> > 'vgem_mmap',
> > @@ -31,11 +30,9 @@ endif
> >  foreach prog : benchmark_progs
> > # FIXME meson doesn't like binaries with the same name
> > # meanwhile just suffix with _bench
> > -   link = []
> > -   if prog == 'gem_wsim'
> > -   link += lib_igt_perf
> > -   endif
> > executable(prog + '_bench', prog + '.c',
> > -  link_with : link,
> >dependencies : test_deps)
> >  endforeach
> > +
> > +executable('gem_wsim_bench', 'gem_wsim.c',
> > +  dependencies : test_deps + [ lib_igt_perf ])
> > diff --git a/lib/meson.build b/lib/meson.build
> > index 29d89cf09b58..d06d85b438b2 100644
> > --- a/lib/meson.build
> > +++ b/lib/meson.build
> > @@ -180,8 +180,11 @@ lib_igt = declare_dependency(link_with : lib_igt_build,
> >  
> >  igt_deps = [ lib_igt ] + lib_deps
> >  
> > -lib_igt_perf = static_library('igt_perf',
> > +lib_igt_perf_build = static_library('igt_perf',
> > ['igt_perf.c']
> >  )
> >  
> > +lib_igt_perf = declare_dependency(link_with : lib_igt_perf_build,
> > + include_directories : inc)
> > +
> >  subdir('tests')
> > diff --git a/overlay/meson.build b/overlay/meson.build
> > index 6b479eb89890..afacff5ecf60 100644
> > --- a/overlay/meson.build
> > +++ b/overlay/meson.build
> > @@ -21,7 +21,8 @@ dri2proto = dependency('dri2proto', version : '>= 2.6', 
> > required : false)
> >  cairo_xlib = dependency('cairo-xlib', required : false)
> >  xrandr = dependency('xrandr', version : '>=1.3', required : false)
> >  
> > -gpu_overlay_deps = [ realtime, math, cairo, pciaccess, libdrm, 
> > libdrm_intel ]
> > +gpu_overlay_deps = [ realtime, math, cairo, pciaccess, libdrm,
> > +   libdrm_intel, lib_igt_perf ]
> >  
> >  both_x11_src = ''
> >  
> > @@ -55,6 +56,5 @@ if xrandr.found() and cairo.found()
> > include_directories : inc,
> > c_args : gpu_overlay_cflags,
> > dependencies : gpu_overlay_deps,
> > -   link_with : lib_igt_perf,
> > install : true)
> >  endif
> > diff --git a/tests/meson.build b/tests/meson.build
> > index 94cb8bb48cc7..af73af1219df 100644
> > --- a/tests/meson.build
> > +++ b/tests/meson.build
> > @@ -190,7 +190,6 @@ test_progs = [
> > 'kms_vblank',
> > 'meta_test',
> > 'perf',
> > -   'perf_pmu',
> > 'pm_backlight',
> > 'pm_lpsp',
> > 'pm_rc6_residency',
> > @@ -260,17 +259,17 @@ libexecdir = join_paths(get_option('prefix'), 
> > get_option('libexecdir'), 'intel-g
> >  test_executables = []
> >  
> >  foreach prog : test_progs
> > -   link = []
> > -   if prog == 'perf_pmu'
> > -   link += lib_igt_perf
> > -   endif
> > test_executables += executable(prog, prog + '.c',
> >dependencies : test_deps,
> >install_dir : libexecdir,
> > -  link_with : link,
> >install : true)
> >  endforeach
> >  
> > +test_executables += executable('perf_pmu', 'perf_pmu.c',
> > +  dependencies : test_deps + [ lib_igt_perf ],
> > +  install_dir : libexecdir,
> > +  install : true)
> > +
> 
> 
> I'm fairly sure I had this commit in my earlier tests for this series,
> but apparently not.
> 
> test_progs += 'perf_pmu'
> 
> is needed here, or perf_pmu doesn't get its place in test-list.txt.
> 


With this fixup squashed in, the series is

Reviewed-by: Petri Latvala 


The differences in the generated xml (autotools vs meson) were, let's
say, cosmetic and minor.



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

[Intel-gfx] [PATCH 2/2] drm/i915: Assert GGTT writes were flushed before unbinding a GGTT vma

[Chris Wilson]

As writes through the GTT and GGTT PTE updates do not share the same
path, they are not strictly ordered and so we must explicitly flush the
indirect writes prior to modifying the PTE. However, we track the PTE
using multiple vma, but only a single write_domain on the object, so
before unbinding any GGTT vma we must flush all writes. Provide an
assert that this is so.

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

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index bf6d8d1eaabe..846056cd1eb7 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -790,6 +790,14 @@ int i915_vma_unbind(struct i915_vma *vma)
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
 
if (i915_vma_is_map_and_fenceable(vma)) {
+   /*
+* Check that we have flushed all writes through the GGTT
+* before the unbind. We don't track writes per-vma so assume
+* that we have flushed all writes on the object before each
+* GGTT vma is unbound.
+*/
+   GEM_BUG_ON(obj->base.write_domain & I915_GEM_DOMAIN_GTT);
+
/* release the fence reg _after_ flushing */
ret = i915_vma_put_fence(vma);
if (ret)
-- 
2.15.1

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

[Intel-gfx] [PATCH 1/2] drm/i915: Flush pending GTT writes before unbinding

[Chris Wilson]

From the shrinker paths, we want to relinquish the GPU and GGTT access to
the object, releasing the backing storage back to the system for
swapout. As a part of that process we would unpin the pages, marking
them for access by the CPU (for the swapout/swapin). However, if that
process was interrupted after unbind the vma, we missed a flush of the
inflight GGTT writes before we made that GTT space available again for
reuse, with the prospect that we would redirect them to another page.

The bug dates back to the introduction of multiple GGTT vma, but the
code itself dates to commit 02bef8f98d26 ("drm/i915: Unbind closed vma
for i915_gem_object_unbind()").

Fixes: 02bef8f98d26 ("drm/i915: Unbind closed vma for i915_gem_object_unbind()")
Fixes: c5ad54cf7dd8 ("drm/i915: Use partial view in mmap fault handler")
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: sta...@vger.kernel.org
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e083f242b8dc..80b78fb5daac 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -330,17 +330,10 @@ int i915_gem_object_unbind(struct drm_i915_gem_object 
*obj)
 * must wait for all rendering to complete to the object (as unbinding
 * must anyway), and retire the requests.
 */
-   ret = i915_gem_object_wait(obj,
-  I915_WAIT_INTERRUPTIBLE |
-  I915_WAIT_LOCKED |
-  I915_WAIT_ALL,
-  MAX_SCHEDULE_TIMEOUT,
-  NULL);
+   ret = i915_gem_object_set_to_cpu_domain(obj, false);
if (ret)
return ret;
 
-   i915_gem_retire_requests(to_i915(obj->base.dev));
-
while ((vma = list_first_entry_or_null(&obj->vma_list,
   struct i915_vma,
   obj_link))) {
-- 
2.15.1

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] lib: avoid < in gtkdoc comments

[Patchwork]

== Series Details ==

Series: series starting with [1/3] lib: avoid < in gtkdoc comments
URL   : https://patchwork.freedesktop.org/series/34893/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
ece35d37e6b0afc0ba99f66179279960042c87bc tests/gem_seqno_wrap: Drop 
gem_seqno_wrap.c

with latest DRM-Tip kernel build CI_DRM_3456
84cd3d972bdd drm-tip: 2017y-12m-05d-08h-41m-59s UTC integration manifest

No testlist changes.

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test kms_chamelium:
Subgroup dp-crc-fast:
dmesg-fail -> PASS   (fi-kbl-7500u) fdo#103841
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:437s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:447s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:391s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:526s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:507s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:509s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:491s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:475s
fi-elk-e7500 total:224  pass:163  dwarn:14  dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:274s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:377s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:258s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:399s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:480s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:451s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:484s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:533s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:475s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:533s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:590s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:545s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:524s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:501s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:416s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:613s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:620s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:492s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/1] lib/igt_gt: Add sentinel to intel_execution_engines2

[Patchwork]

== Series Details ==

Series: series starting with [1/1] lib/igt_gt: Add sentinel to 
intel_execution_engines2
URL   : https://patchwork.freedesktop.org/series/34892/
State : failure

== Summary ==

Test drv_module_reload:
Subgroup basic-no-display:
pass   -> DMESG-WARN (shard-hsw) fdo#102707 +1
Test gem_tiled_swapping:
Subgroup non-threaded:
incomplete -> PASS   (shard-hsw) fdo#104009
Test kms_flip:
Subgroup flip-vs-modeset-vs-hang:
pass   -> INCOMPLETE (shard-snb)

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

shard-hswtotal:2679 pass:1535 dwarn:2   dfail:0   fail:10  skip:1132 
time:9431s
shard-snbtotal:2652 pass:1298 dwarn:2   dfail:0   fail:12  skip:1339 
time:7871s
Blacklisted hosts:
shard-apltotal:2679 pass:1680 dwarn:1   dfail:0   fail:21  skip:977 
time:13648s
shard-kbltotal:2679 pass:1789 dwarn:9   dfail:0   fail:24  skip:857 
time:10807s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_597/shards.html
___
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/i915: Flush pending GTT writes before unbinding

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Flush pending GTT writes before 
unbinding
URL   : https://patchwork.freedesktop.org/series/34899/
State : failure

== Summary ==

Series 34899v1 series starting with [1/2] drm/i915: Flush pending GTT writes 
before unbinding
https://patchwork.freedesktop.org/api/1.0/series/34899/revisions/1/mbox/

Test core_auth:
Subgroup basic-auth:
pass   -> INCOMPLETE (fi-bdw-5557u)
pass   -> INCOMPLETE (fi-bsw-n3050)
pass   -> INCOMPLETE (fi-skl-6260u)
pass   -> INCOMPLETE (fi-skl-6600u)
pass   -> INCOMPLETE (fi-skl-6700hq)
pass   -> INCOMPLETE (fi-skl-6700k)
pass   -> INCOMPLETE (fi-skl-6770hq)
pass   -> INCOMPLETE (fi-bxt-dsi)
pass   -> INCOMPLETE (fi-bxt-j4205)
pass   -> INCOMPLETE (fi-kbl-7500u)
pass   -> INCOMPLETE (fi-kbl-7560u)
pass   -> INCOMPLETE (fi-kbl-7567u)
pass   -> INCOMPLETE (fi-kbl-r)
pass   -> INCOMPLETE (fi-glk-1)
Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-bwr-2160)
pass   -> INCOMPLETE (fi-byt-j1900)
pass   -> INCOMPLETE (fi-byt-n2820)
pass   -> INCOMPLETE (fi-skl-gvtdvm)
Test gem_exec_basic:
Subgroup gtt-blt:
pass   -> INCOMPLETE (fi-snb-2520m)
pass   -> INCOMPLETE (fi-snb-2600)
pass   -> INCOMPLETE (fi-ivb-3520m)
pass   -> INCOMPLETE (fi-ivb-3770)
pass   -> INCOMPLETE (fi-hsw-4770)
pass   -> INCOMPLETE (fi-hsw-4770r)
pass   -> INCOMPLETE (fi-bdw-gvtdvm)
Subgroup gtt-bsd:
pass   -> INCOMPLETE (fi-elk-e7500)
pass   -> INCOMPLETE (fi-ilk-650)
Subgroup gtt-default:
pass   -> INCOMPLETE (fi-gdg-551)
pass   -> INCOMPLETE (fi-blb-e6850)
pass   -> INCOMPLETE (fi-pnv-d510)

fi-bdw-5557u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-bdw-gvtdvmtotal:30   pass:29   dwarn:0   dfail:0   fail:0   skip:0  
fi-blb-e6850 total:34   pass:17   dwarn:0   dfail:0   fail:0   skip:16 
fi-bsw-n3050 total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-bwr-2160  total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-bxt-dsi   total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-bxt-j4205 total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-byt-j1900 total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-byt-n2820 total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-elk-e7500 total:31   pass:17   dwarn:1   dfail:0   fail:0   skip:12 
fi-gdg-551   total:34   pass:15   dwarn:0   dfail:0   fail:0   skip:18 
fi-glk-1 total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-hsw-4770  total:30   pass:27   dwarn:0   dfail:0   fail:0   skip:2  
fi-hsw-4770r total:30   pass:27   dwarn:0   dfail:0   fail:0   skip:2  
fi-ilk-650   total:31   pass:18   dwarn:0   dfail:0   fail:0   skip:12 
fi-ivb-3520m total:30   pass:26   dwarn:0   dfail:0   fail:0   skip:3  
fi-ivb-3770  total:30   pass:26   dwarn:0   dfail:0   fail:0   skip:3  
fi-kbl-7500u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-kbl-7560u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-kbl-7567u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-kbl-r total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-pnv-d510  total:34   pass:17   dwarn:0   dfail:0   fail:0   skip:16 
fi-skl-6260u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-6600u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-6700hqtotal:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-6700k total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-6770hqtotal:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-gvtdvmtotal:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2520m total:30   pass:26   dwarn:0   dfail:0   fail:0   skip:3  
fi-snb-2600  total:30   pass:26   dwarn:0   dfail:0   fail:0   skip:3  
Blacklisted hosts:
fi-cfl-s2total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-cnl-y total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-glk-dsi   total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  

84cd3d972bdd25fd6f7fe3dc2fe92b0617cde2a5 drm-tip: 2017y-12m-05d-08h-41m-59s UTC 
integration manifest
88a7c20b7c95 drm/i915: Assert GGTT writes were flushed before unbinding a GGTT 
vma
9673a7c7ace9 drm/i915: Flush pending GTT writes be

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] igt/pm_rc6_residency: Replace hard-coded sleep before rc6 with a probe

[Patchwork]

== Series Details ==

Series: series starting with [1/2] igt/pm_rc6_residency: Replace hard-coded 
sleep before rc6 with a probe
URL   : https://patchwork.freedesktop.org/series/34897/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
ece35d37e6b0afc0ba99f66179279960042c87bc tests/gem_seqno_wrap: Drop 
gem_seqno_wrap.c

with latest DRM-Tip kernel build CI_DRM_3456
84cd3d972bdd drm-tip: 2017y-12m-05d-08h-41m-59s UTC integration manifest

No testlist changes.

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test kms_chamelium:
Subgroup dp-crc-fast:
dmesg-fail -> PASS   (fi-kbl-7500u) fdo#103841
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-hsw-4770) fdo#103375

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:444s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:445s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:389s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:518s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:508s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:509s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:495s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:481s
fi-elk-e7500 total:224  pass:163  dwarn:14  dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:271s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:544s
fi-hsw-4770  total:244  pass:220  dwarn:0   dfail:0   fail:0   skip:23 
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:260s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:395s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:473s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:447s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:491s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:528s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:479s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:529s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:591s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:456s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:538s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:519s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:500s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:447s
fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:562s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:422s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:616s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:620s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:488s

== Logs ==

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

Re: [Intel-gfx] [PATCH igt 2/2] igt/perf_pmu: Replace hard-coded sleep before rc6 with a probe

[Tvrtko Ursulin]

On 05/12/2017 10:56, Chris Wilson wrote:

Instead of trying to sleep for 2 evaluations intervals and then assuming
that rc6 is working, poll the rc6 residency instead.

References: https://bugs.freedesktop.org/show_bug.cgi?id=103929
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  tests/perf_pmu.c | 16 +++-
  1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index e872f4e55..65bc734da 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -1008,6 +1008,20 @@ static unsigned long rc6_enable_us(void)
return 2 * 160 * 1000;
  }
  
+static bool wait_for_rc6(int fd)

+{
+   struct timespec tv = {};
+   uint64_t start, now;
+
+   start = pmu_read_single(fd);
+   do {
+   usleep(50);


Not needlessly fast?


+   now = pmu_read_single(fd);
+   } while (start == now && !igt_seconds_elapsed(&tv));


So up to one second wait.


+
+   return start != now;
+}
+
  static void
  test_rc6(int gem_fd)
  {
@@ -1019,7 +1033,7 @@ test_rc6(int gem_fd)
fd = open_pmu(I915_PMU_RC6_RESIDENCY);
  
  	gem_quiescent_gpu(gem_fd);

-   usleep(rc6_enable_us()); /* wait for the rc6 cycle counter to kick in */
+   igt_require(wait_for_rc6(fd));


Eliminate now unused rc6_enable_us() ?

  
  	/* Go idle and check full RC6. */

prev = pmu_read_single(fd);



With dead-code removed:

Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH igt 1/2] igt/pm_rc6_residency: Replace hard-coded sleep before rc6 with a probe

[Tvrtko Ursulin]

On 05/12/2017 10:56, Chris Wilson wrote:

Instead of trying to sleep for 2 evaluations intervals and then assuming
that rc6 is working, poll the rc6 residency instead.

References: https://bugs.freedesktop.org/show_bug.cgi?id=104099
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  tests/pm_rc6_residency.c | 33 ++---
  1 file changed, 14 insertions(+), 19 deletions(-)

diff --git a/tests/pm_rc6_residency.c b/tests/pm_rc6_residency.c
index 3f6860199..16f4b1421 100644
--- a/tests/pm_rc6_residency.c
+++ b/tests/pm_rc6_residency.c
@@ -122,9 +122,6 @@ static void measure_residencies(int devid, unsigned int 
mask,
struct residencies end = { };
int retry;
  
-	if (!mask)

-   return;
-
/*
 * Retry in case of counter wrap-around. We simply re-run the
 * measurement, since the valid counter range is different on
@@ -168,17 +165,18 @@ static void measure_residencies(int devid, unsigned int 
mask,
res->rc6 += res->rc6p;
  }
  
-static unsigned long rc6_enable_us(void)

+static bool wait_for_rc6(void)
  {
-   /*
-* To know how long we need to wait for the device to enter rc6 once
-* idle, we need to look at GEN6_RC_EVALUATION_INTERVAL. Currently,
-* this is set to 125000 (12500 * 1280ns or 0.16s) on all platforms.
-* We must complete at least one EI with activity below the
-* per-platform threshold for RC6 to kick. Therefore, we must wait
-* at least 2 EI cycles, before we can expect rc6 to start ticking.
-*/
-   return 2 * 160 * 1000;
+   struct timespec tv = {};
+   unsigned long start, now;
+
+   start = read_rc6_residency("rc6");
+   do {
+   usleep(50);
+   now = read_rc6_residency("rc6");
+   } while (now == start && !igt_seconds_elapsed(&tv));
+
+   return now != start;
  }
  
  igt_main

@@ -198,19 +196,17 @@ igt_main
  
  		/* Make sure rc6 counters are running */

igt_drop_caches_set(fd, DROP_IDLE);
-   usleep(rc6_enable_us());
+   igt_require(wait_for_rc6());
  
  		close(fd);
  
  		rc6_enabled = get_rc6_enabled_mask();

-   igt_require(rc6_enabled);
+   igt_require(rc6_enabled & RC6_ENABLED);
}
  
  	igt_subtest("rc6-accuracy") {

struct residencies res;
  
-		igt_require(rc6_enabled & RC6_ENABLED);

-
measure_residencies(devid, rc6_enabled, &res);
residency_accuracy(res.rc6, res.duration, "rc6");
}
@@ -218,8 +214,7 @@ igt_main
igt_subtest("media-rc6-accuracy") {
struct residencies res;
  
-		igt_require((rc6_enabled & RC6_ENABLED) &&

-   (IS_VALLEYVIEW(devid) || IS_CHERRYVIEW(devid)));
+   igt_require(IS_VALLEYVIEW(devid) || IS_CHERRYVIEW(devid));
  
  		measure_residencies(devid, rc6_enabled, &res);

residency_accuracy(res.media_rc6, res.duration, "media_rc6");



Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH igt 2/2] igt/perf_pmu: Replace hard-coded sleep before rc6 with a probe

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-12-05 12:05:14)
> 
> On 05/12/2017 10:56, Chris Wilson wrote:
> > Instead of trying to sleep for 2 evaluations intervals and then assuming
> > that rc6 is working, poll the rc6 residency instead.
> > 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=103929
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > ---
> >   tests/perf_pmu.c | 16 +++-
> >   1 file changed, 15 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
> > index e872f4e55..65bc734da 100644
> > --- a/tests/perf_pmu.c
> > +++ b/tests/perf_pmu.c
> > @@ -1008,6 +1008,20 @@ static unsigned long rc6_enable_us(void)
> >   return 2 * 160 * 1000;
> >   }
> >   
> > +static bool wait_for_rc6(int fd)
> > +{
> > + struct timespec tv = {};
> > + uint64_t start, now;
> > +
> > + start = pmu_read_single(fd);
> > + do {
> > + usleep(50);
> 
> Not needlessly fast?

Since we expect the EI to be 160us, I was erring on the side of
optimism. i.e. if the idling took long enough, rc6 would be close to
starting on our return. However, the code is trying to be safe just in
case, for whatever unknown reason, it takes longer. This pair of tests,
I am assuming are only concerned with the accuracy of the counter rather
than investigating kernel/device behaviour. (We should have some other
pm_rc6 tests that try to check that rc6 kicks off in a timely manner,
but we don't publish the expectations for rc6 behaviour. Not sure?)
 
> > + now = pmu_read_single(fd);
> > + } while (start == now && !igt_seconds_elapsed(&tv));
> 
> So up to one second wait.

Expectation is that it should only take 320us for it to kick off, so 1s
seems a reasonable upper bound. Maybe 2s?
 
> > +
> > + return start != now;
> > +}
> > +
> >   static void
> >   test_rc6(int gem_fd)
> >   {
> > @@ -1019,7 +1033,7 @@ test_rc6(int gem_fd)
> >   fd = open_pmu(I915_PMU_RC6_RESIDENCY);
> >   
> >   gem_quiescent_gpu(gem_fd);
> > - usleep(rc6_enable_us()); /* wait for the rc6 cycle counter to kick in 
> > */
> > + igt_require(wait_for_rc6(fd));
> 
> Eliminate now unused rc6_enable_us() ?

I thought I did, my mistake.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915: Flush pending GTT writes before unbinding

[Chris Wilson]

From the shrinker paths, we want to relinquish the GPU and GGTT access to
the object, releasing the backing storage back to the system for
swapout. As a part of that process we would unpin the pages, marking
them for access by the CPU (for the swapout/swapin). However, if that
process was interrupted after unbind the vma, we missed a flush of the
inflight GGTT writes before we made that GTT space available again for
reuse, with the prospect that we would redirect them to another page.

The bug dates back to the introduction of multiple GGTT vma, but the
code itself dates to commit 02bef8f98d26 ("drm/i915: Unbind closed vma
for i915_gem_object_unbind()").

Fixes: 02bef8f98d26 ("drm/i915: Unbind closed vma for i915_gem_object_unbind()")
Fixes: c5ad54cf7dd8 ("drm/i915: Use partial view in mmap fault handler")
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: sta...@vger.kernel.org
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e083f242b8dc..80b78fb5daac 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -330,17 +330,10 @@ int i915_gem_object_unbind(struct drm_i915_gem_object 
*obj)
 * must wait for all rendering to complete to the object (as unbinding
 * must anyway), and retire the requests.
 */
-   ret = i915_gem_object_wait(obj,
-  I915_WAIT_INTERRUPTIBLE |
-  I915_WAIT_LOCKED |
-  I915_WAIT_ALL,
-  MAX_SCHEDULE_TIMEOUT,
-  NULL);
+   ret = i915_gem_object_set_to_cpu_domain(obj, false);
if (ret)
return ret;
 
-   i915_gem_retire_requests(to_i915(obj->base.dev));
-
while ((vma = list_first_entry_or_null(&obj->vma_list,
   struct i915_vma,
   obj_link))) {
-- 
2.15.1

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] lib: avoid < in gtkdoc comments

[Patchwork]

== Series Details ==

Series: series starting with [1/3] lib: avoid < in gtkdoc comments
URL   : https://patchwork.freedesktop.org/series/34893/
State : failure

== Summary ==

Test kms_flip:
Subgroup plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Test gem_eio:
Subgroup in-flight:
pass   -> DMESG-FAIL (shard-snb)
Test drv_module_reload:
Subgroup basic-reload:
pass   -> DMESG-WARN (shard-hsw) fdo#102707
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623
Test gem_tiled_swapping:
Subgroup non-threaded:
pass   -> INCOMPLETE (shard-snb) fdo#104009

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#104009 https://bugs.freedesktop.org/show_bug.cgi?id=104009

shard-hswtotal:2608 pass:1492 dwarn:2   dfail:0   fail:10  skip:1103 
time:9165s
shard-snbtotal:2608 pass:1271 dwarn:1   dfail:1   fail:10  skip:1324 
time:7881s
Blacklisted hosts:
shard-apltotal:2679 pass:1680 dwarn:1   dfail:0   fail:21  skip:977 
time:13721s
shard-kbltotal:2604 pass:1747 dwarn:4   dfail:0   fail:20  skip:833 
time:10552s

== Logs ==

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

[Intel-gfx] [PATCH 2/2] drm/i915: Track GGTT on the vma

[Chris Wilson]

As writes through the GTT and GGTT PTE updates do not share the same
path, they are not strictly ordered and so we must explicitly flush the
indirect writes prior to modifying the PTE. We do track outstanding GGTT
writes on the object itself, but since the object may have multiple GGTT
vma, that is overly coarse as we can track and flush individual vma as
required.

Whilst here, update the GGTT flushing behaviour for Cannonlake.

References: https://bugs.freedesktop.org/show_bug.cgi?id=104002
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 ++
 drivers/gpu/drm/i915/i915_gem.c | 55 +++--
 drivers/gpu/drm/i915/i915_vma.c | 22 +
 drivers/gpu/drm/i915/i915_vma.h | 19 ++
 4 files changed, 80 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 594fd14e66c5..5cf58e049dbd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3879,6 +3879,8 @@ int __must_check i915_gem_evict_for_node(struct 
i915_address_space *vm,
 unsigned int flags);
 int i915_gem_evict_vm(struct i915_address_space *vm);
 
+void i915_gem_flush_ggtt_writes(struct drm_i915_private *dev_priv);
+
 /* belongs in i915_gem_gtt.h */
 static inline void i915_gem_chipset_flush(struct drm_i915_private *dev_priv)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 80b78fb5daac..cd8f3d847350 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -666,17 +666,13 @@ fb_write_origin(struct drm_i915_gem_object *obj, unsigned 
int domain)
obj->frontbuffer_ggtt_origin : ORIGIN_CPU);
 }
 
-static void
-flush_write_domain(struct drm_i915_gem_object *obj, unsigned int flush_domains)
+void i915_gem_flush_ggtt_writes(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
-
-   if (!(obj->base.write_domain & flush_domains))
-   return;
-
-   /* No actual flushing is required for the GTT write domain.  Writes
-* to it "immediately" go to main memory as far as we know, so there's
-* no chipset flush.  It also doesn't land in render cache.
+   /*
+* No actual flushing is required for the GTT write domain for reads
+* from the GTT domain. Writes to it "immediately" go to main memory
+* as far as we know, so there's no chipset flush. It also doesn't
+* land in the GPU render cache.
 *
 * However, we do have to enforce the order so that all writes through
 * the GTT land before any writes to the device, such as updates to
@@ -687,22 +683,43 @@ flush_write_domain(struct drm_i915_gem_object *obj, 
unsigned int flush_domains)
 * timing. This issue has only been observed when switching quickly
 * between GTT writes and CPU reads from inside the kernel on recent hw,
 * and it appears to only affect discrete GTT blocks (i.e. on LLC
-* system agents we cannot reproduce this behaviour).
+* system agents we cannot reproduce this behaviour, until Cannonlake
+* that was!).
 */
+
wmb();
 
+   intel_runtime_pm_get(dev_priv);
+   spin_lock_irq(&dev_priv->uncore.lock);
+
+   POSTING_READ_FW(RING_HEAD(dev_priv->engine[RCS]->mmio_base));
+
+   spin_unlock_irq(&dev_priv->uncore.lock);
+   intel_runtime_pm_put(dev_priv);
+}
+
+static void
+flush_write_domain(struct drm_i915_gem_object *obj, unsigned int flush_domains)
+{
+   struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
+   struct i915_vma *vma;
+
+   if (!(obj->base.write_domain & flush_domains))
+   return;
+
switch (obj->base.write_domain) {
case I915_GEM_DOMAIN_GTT:
-   if (!HAS_LLC(dev_priv)) {
-   intel_runtime_pm_get(dev_priv);
-   spin_lock_irq(&dev_priv->uncore.lock);
-   
POSTING_READ_FW(RING_HEAD(dev_priv->engine[RCS]->mmio_base));
-   spin_unlock_irq(&dev_priv->uncore.lock);
-   intel_runtime_pm_put(dev_priv);
-   }
+   i915_gem_flush_ggtt_writes(dev_priv);
 
intel_fb_obj_flush(obj,
   fb_write_origin(obj, I915_GEM_DOMAIN_GTT));
+
+   list_for_each_entry(vma, &obj->vma_list, obj_link) {
+   if (!i915_vma_is_ggtt(vma))
+   break;
+
+   i915_vma_unset_ggtt_write(vma);
+   }
break;
 
case I915_GEM_DOMAIN_CPU:
@@ -1965,6 +1982,8 @@ int i915_gem_fault(struct vm_fault *vmf)
list_add(&obj->userfault_link, &dev_priv->mm.userfault_list);
GEM_BUG_ON(!obj->userfault_count);
 
+   i915_vma_set_ggtt_write(vma);
+
 err_fenc

[Intel-gfx] [PATCH igt] lib: Check and report if a subtest triggers a new kernel taint

[Chris Wilson]

Checking for a tainted kernel is a convenient way to see if the test
generated a critical error such as a oops, or machine check.

v2: Docs?

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Radoslaw Szwichtenberg 
Reviewed-by: Joonas Lahtinen 
---
 lib/Makefile.sources   |   2 +
 lib/igt_core.c |  19 +++-
 lib/igt_kernel_taint.c | 120 +
 lib/igt_kernel_taint.h |  34 ++
 4 files changed, 174 insertions(+), 1 deletion(-)
 create mode 100644 lib/igt_kernel_taint.c
 create mode 100644 lib/igt_kernel_taint.h

diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 6e968d9f7..152153908 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -22,6 +22,8 @@ lib_source_list = \
igt_gt.h\
igt_gvt.c   \
igt_gvt.h   \
+   igt_kernel_taint.c  \
+   igt_kernel_taint.h  \
igt_primes.c\
igt_primes.h\
igt_rand.c  \
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 03fa6e4e8..486c5989d 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -63,6 +63,7 @@
 #include "intel_chipset.h"
 #include "intel_io.h"
 #include "igt_debugfs.h"
+#include "igt_kernel_taint.h"
 #include "version.h"
 #include "config.h"
 
@@ -261,6 +262,7 @@ static bool list_subtests = false;
 static char *run_single_subtest = NULL;
 static bool run_single_subtest_found = false;
 static const char *in_subtest = NULL;
+static unsigned long saved_kernel_taint;
 static struct timespec subtest_time;
 static clockid_t igt_clock = (clockid_t)-1;
 static bool in_fixture = false;
@@ -937,6 +939,8 @@ bool __igt_run_subtest(const char *subtest_name)
return false;
}
 
+   saved_kernel_taint = igt_read_kernel_taint();
+
kmsg(KERN_INFO "[IGT] %s: starting subtest %s\n", command_str, 
subtest_name);
igt_debug("Starting subtest: %s\n", subtest_name);
 
@@ -1083,8 +1087,21 @@ void __igt_skip_check(const char *file, const int line,
 void igt_success(void)
 {
succeeded_one = true;
-   if (in_subtest)
+   if (in_subtest) {
+   unsigned long new_kernel_taints =
+   igt_read_kernel_taint() & ~saved_kernel_taint;
+   unsigned int tainted = igt_kernel_tainted(new_kernel_taints);
+
+   if (tainted) {
+   igt_kernel_taint_print(new_kernel_taints);
+   if (tainted & TAINT_ERROR)
+   exit_subtest("FAIL");
+   else
+   exit_subtest("WARN");
+   }
+
exit_subtest("SUCCESS");
+   }
 }
 
 /**
diff --git a/lib/igt_kernel_taint.c b/lib/igt_kernel_taint.c
new file mode 100644
index 0..7f105ead7
--- /dev/null
+++ b/lib/igt_kernel_taint.c
@@ -0,0 +1,120 @@
+/*
+ * Copyright 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+
+#include "igt.h"
+#include "igt_kernel_taint.h"
+#include "igt_sysfs.h"
+
+#define BIT(x) (1ul << (x))
+
+static const struct kernel_taint {
+   const char *msg;
+   unsigned int flags;
+} taints[] = {
+   { "Non-GPL module loaded" },
+   { "Forced module load" },
+   { "Unsafe SMP processor" },
+   { "Forced module unload" },
+   { "Machine Check Exception", TAINT_WARN },
+   { "Bad page detected", TAINT_ERROR },
+   { "Tainted by user request (e.g. modparam_unsafe)" },
+   { "System is on fire", TAINT_ERROR },
+   { "ACPI DSDT has been overridden by user" },
+   { "OOPS", TAINT_ERROR },
+   { "Staging driver loaded; are you mad?" },
+   { "Severe firmware bug workaround active", TAINT_WARN },
+   { "Out-of-tree module loaded" },
+   { "Unsigned module loaded" },
+   { "Soft-lockup detected", 

Re: [Intel-gfx] [PATCH igt] lib: Check and report if a subtest triggers a new kernel taint

[Petri Latvala]

On Tue, Dec 05, 2017 at 12:24:53PM +, Chris Wilson wrote:
> Checking for a tainted kernel is a convenient way to see if the test
> generated a critical error such as a oops, or machine check.
> 
> v2: Docs?
> 
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Radoslaw Szwichtenberg 
> Reviewed-by: Joonas Lahtinen 
> ---
>  lib/Makefile.sources   |   2 +
>  lib/igt_core.c |  19 +++-
>  lib/igt_kernel_taint.c | 120 
> +
>  lib/igt_kernel_taint.h |  34 ++
>  4 files changed, 174 insertions(+), 1 deletion(-)
>  create mode 100644 lib/igt_kernel_taint.c
>  create mode 100644 lib/igt_kernel_taint.h
> 
> diff --git a/lib/Makefile.sources b/lib/Makefile.sources
> index 6e968d9f7..152153908 100644
> --- a/lib/Makefile.sources
> +++ b/lib/Makefile.sources
> @@ -22,6 +22,8 @@ lib_source_list =   \
>   igt_gt.h\
>   igt_gvt.c   \
>   igt_gvt.h   \
> + igt_kernel_taint.c  \
> + igt_kernel_taint.h  \
>   igt_primes.c\
>   igt_primes.h\
>   igt_rand.c  \
> diff --git a/lib/igt_core.c b/lib/igt_core.c
> index 03fa6e4e8..486c5989d 100644
> --- a/lib/igt_core.c
> +++ b/lib/igt_core.c
> @@ -63,6 +63,7 @@
>  #include "intel_chipset.h"
>  #include "intel_io.h"
>  #include "igt_debugfs.h"
> +#include "igt_kernel_taint.h"
>  #include "version.h"
>  #include "config.h"
>  
> @@ -261,6 +262,7 @@ static bool list_subtests = false;
>  static char *run_single_subtest = NULL;
>  static bool run_single_subtest_found = false;
>  static const char *in_subtest = NULL;
> +static unsigned long saved_kernel_taint;
>  static struct timespec subtest_time;
>  static clockid_t igt_clock = (clockid_t)-1;
>  static bool in_fixture = false;
> @@ -937,6 +939,8 @@ bool __igt_run_subtest(const char *subtest_name)
>   return false;
>   }
>  
> + saved_kernel_taint = igt_read_kernel_taint();
> +
>   kmsg(KERN_INFO "[IGT] %s: starting subtest %s\n", command_str, 
> subtest_name);
>   igt_debug("Starting subtest: %s\n", subtest_name);
>  
> @@ -1083,8 +1087,21 @@ void __igt_skip_check(const char *file, const int line,
>  void igt_success(void)
>  {
>   succeeded_one = true;
> - if (in_subtest)
> + if (in_subtest) {
> + unsigned long new_kernel_taints =
> + igt_read_kernel_taint() & ~saved_kernel_taint;
> + unsigned int tainted = igt_kernel_tainted(new_kernel_taints);
> +
> + if (tainted) {
> + igt_kernel_taint_print(new_kernel_taints);
> + if (tainted & TAINT_ERROR)
> + exit_subtest("FAIL");
> + else
> + exit_subtest("WARN");
> + }
> +
>   exit_subtest("SUCCESS");
> + }
>  }


If you change the result to FAIL or WARN here, succeeded_one should not be 
changed.

What of tests that don't have subtests?


-- 
Petri Latvala



>  
>  /**
> diff --git a/lib/igt_kernel_taint.c b/lib/igt_kernel_taint.c
> new file mode 100644
> index 0..7f105ead7
> --- /dev/null
> +++ b/lib/igt_kernel_taint.c
> @@ -0,0 +1,120 @@
> +/*
> + * Copyright 2017 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include 
> +#include 
> +
> +#include "igt.h"
> +#include "igt_kernel_taint.h"
> +#include "igt_sysfs.h"
> +
> +#define BIT(x) (1ul << (x))
> +
> +static const struct kernel_taint {
> + const char *msg;
> + unsigned int flags;
> +} taints[] = {
> + { "Non-GPL module loaded" },
> + { "Forced module load" },
> + { "Unsafe SMP processor" },
> + { "Forced module unload" },
> + { "Machine Check Exception", TAINT_WARN },
> + { "Bad page detected", TAINT_ERROR },
> + { "Tai

Re: [Intel-gfx] [PATCH igt] lib: Check and report if a subtest triggers a new kernel taint

[Chris Wilson]

Quoting Petri Latvala (2017-12-05 12:32:36)
> On Tue, Dec 05, 2017 at 12:24:53PM +, Chris Wilson wrote:
> > Checking for a tainted kernel is a convenient way to see if the test
> > generated a critical error such as a oops, or machine check.
> > 
> > v2: Docs?
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Daniel Vetter 
> > Cc: Radoslaw Szwichtenberg 
> > Reviewed-by: Joonas Lahtinen 
> > ---
> >  lib/Makefile.sources   |   2 +
> >  lib/igt_core.c |  19 +++-
> >  lib/igt_kernel_taint.c | 120 
> > +
> >  lib/igt_kernel_taint.h |  34 ++
> >  4 files changed, 174 insertions(+), 1 deletion(-)
> >  create mode 100644 lib/igt_kernel_taint.c
> >  create mode 100644 lib/igt_kernel_taint.h
> > 
> > diff --git a/lib/Makefile.sources b/lib/Makefile.sources
> > index 6e968d9f7..152153908 100644
> > --- a/lib/Makefile.sources
> > +++ b/lib/Makefile.sources
> > @@ -22,6 +22,8 @@ lib_source_list =   \
> >   igt_gt.h\
> >   igt_gvt.c   \
> >   igt_gvt.h   \
> > + igt_kernel_taint.c  \
> > + igt_kernel_taint.h  \
> >   igt_primes.c\
> >   igt_primes.h\
> >   igt_rand.c  \
> > diff --git a/lib/igt_core.c b/lib/igt_core.c
> > index 03fa6e4e8..486c5989d 100644
> > --- a/lib/igt_core.c
> > +++ b/lib/igt_core.c
> > @@ -63,6 +63,7 @@
> >  #include "intel_chipset.h"
> >  #include "intel_io.h"
> >  #include "igt_debugfs.h"
> > +#include "igt_kernel_taint.h"
> >  #include "version.h"
> >  #include "config.h"
> >  
> > @@ -261,6 +262,7 @@ static bool list_subtests = false;
> >  static char *run_single_subtest = NULL;
> >  static bool run_single_subtest_found = false;
> >  static const char *in_subtest = NULL;
> > +static unsigned long saved_kernel_taint;
> >  static struct timespec subtest_time;
> >  static clockid_t igt_clock = (clockid_t)-1;
> >  static bool in_fixture = false;
> > @@ -937,6 +939,8 @@ bool __igt_run_subtest(const char *subtest_name)
> >   return false;
> >   }
> >  
> > + saved_kernel_taint = igt_read_kernel_taint();
> > +
> >   kmsg(KERN_INFO "[IGT] %s: starting subtest %s\n", command_str, 
> > subtest_name);
> >   igt_debug("Starting subtest: %s\n", subtest_name);
> >  
> > @@ -1083,8 +1087,21 @@ void __igt_skip_check(const char *file, const int 
> > line,
> >  void igt_success(void)
> >  {
> >   succeeded_one = true;
> > - if (in_subtest)
> > + if (in_subtest) {
> > + unsigned long new_kernel_taints =
> > + igt_read_kernel_taint() & ~saved_kernel_taint;
> > + unsigned int tainted = igt_kernel_tainted(new_kernel_taints);
> > +
> > + if (tainted) {
> > + igt_kernel_taint_print(new_kernel_taints);
> > + if (tainted & TAINT_ERROR)
> > + exit_subtest("FAIL");
> > + else
> > + exit_subtest("WARN");
> > + }
> > +
> >   exit_subtest("SUCCESS");
> > + }
> >  }
> 
> 
> If you change the result to FAIL or WARN here, succeeded_one should not be 
> changed.
> 
> What of tests that don't have subtests?

I don't know where they are tracked. If there is a location we can place
such a before/after check. Or even if we do want to change test status
at all, and just make it a warn if the kernel becomes tainted.

The ambition here isn't just to flag oops reliably, but to respond when
we know the HW is broken and requires rebooting.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] igt/pm_rc6_residency: Replace hard-coded sleep before rc6 with a probe

[Patchwork]

== Series Details ==

Series: series starting with [1/2] igt/pm_rc6_residency: Replace hard-coded 
sleep before rc6 with a probe
URL   : https://patchwork.freedesktop.org/series/34897/
State : warning

== Summary ==

Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623
Test kms_chv_cursor_fail:
Subgroup pipe-a-128x128-bottom-edge:
pass   -> SKIP   (shard-hsw)
Test drv_module_reload:
Subgroup basic-reload-inject:
pass   -> DMESG-WARN (shard-snb) fdo#102707
Test kms_flip:
Subgroup plain-flip-ts-check-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368

fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368

shard-hswtotal:2605 pass:1487 dwarn:1   dfail:0   fail:10  skip:1106 
time:9097s
shard-snbtotal:2679 pass:1308 dwarn:2   dfail:0   fail:11  skip:1358 
time:8128s
Blacklisted hosts:
shard-apltotal:2657 pass:1654 dwarn:3   dfail:0   fail:22  skip:977 
time:13324s
shard-kbltotal:2679 pass:1794 dwarn:2   dfail:0   fail:23  skip:860 
time:10853s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_599/shards.html
___
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/i915: Flush pending GTT writes before unbinding

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Flush pending GTT writes before 
unbinding
URL   : https://patchwork.freedesktop.org/series/34900/
State : failure

== Summary ==

Series 34900v1 series starting with [1/2] drm/i915: Flush pending GTT writes 
before unbinding
https://patchwork.freedesktop.org/api/1.0/series/34900/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test drv_module_reload:
Subgroup basic-reload:
pass   -> DMESG-FAIL (fi-ilk-650)
pass   -> INCOMPLETE (fi-snb-2600)
pass   -> INCOMPLETE (fi-ivb-3520m)
pass   -> INCOMPLETE (fi-ivb-3770)
pass   -> INCOMPLETE (fi-byt-j1900)
pass   -> INCOMPLETE (fi-byt-n2820)
pass   -> INCOMPLETE (fi-hsw-4770)
pass   -> INCOMPLETE (fi-hsw-4770r)
pass   -> DMESG-FAIL (fi-bdw-5557u)
pass   -> DMESG-FAIL (fi-bdw-gvtdvm)
pass   -> DMESG-FAIL (fi-bsw-n3050)
pass   -> DMESG-FAIL (fi-skl-6260u)
pass   -> DMESG-FAIL (fi-skl-6600u)
pass   -> DMESG-FAIL (fi-skl-6700hq)
pass   -> DMESG-FAIL (fi-skl-6700k)
pass   -> DMESG-FAIL (fi-skl-6770hq)
pass   -> DMESG-FAIL (fi-skl-gvtdvm)
pass   -> DMESG-FAIL (fi-bxt-dsi)
pass   -> DMESG-FAIL (fi-bxt-j4205)
pass   -> DMESG-FAIL (fi-kbl-7500u)
pass   -> DMESG-FAIL (fi-kbl-7560u)
pass   -> DMESG-FAIL (fi-kbl-7567u)
pass   -> DMESG-FAIL (fi-kbl-r)
pass   -> DMESG-FAIL (fi-glk-1)
Subgroup basic-no-display:
pass   -> FAIL   (fi-ilk-650)
pass   -> FAIL   (fi-bdw-5557u)
pass   -> FAIL   (fi-bdw-gvtdvm)
pass   -> DMESG-FAIL (fi-bsw-n3050)
pass   -> FAIL   (fi-skl-6260u)
pass   -> FAIL   (fi-skl-6600u)
pass   -> FAIL   (fi-skl-6700hq)
pass   -> FAIL   (fi-skl-6700k)
pass   -> FAIL   (fi-skl-6770hq)
pass   -> FAIL   (fi-skl-gvtdvm)
pass   -> FAIL   (fi-bxt-dsi)
pass   -> FAIL   (fi-bxt-j4205)
pass   -> FAIL   (fi-kbl-7500u)
pass   -> FAIL   (fi-kbl-7560u)
pass   -> FAIL   (fi-kbl-7567u)
pass   -> FAIL   (fi-kbl-r)
pass   -> FAIL   (fi-glk-1)
Subgroup basic-reload-inject:
pass   -> FAIL   (fi-ilk-650)
pass   -> FAIL   (fi-bdw-5557u)
pass   -> FAIL   (fi-bdw-gvtdvm)
pass   -> FAIL   (fi-bsw-n3050) fdo#103706 +9
pass   -> FAIL   (fi-skl-6260u)
pass   -> FAIL   (fi-skl-6600u)
pass   -> FAIL   (fi-skl-6700hq)
pass   -> FAIL   (fi-skl-6700k)
pass   -> FAIL   (fi-skl-6770hq)
pass   -> FAIL   (fi-skl-gvtdvm)
pass   -> FAIL   (fi-kbl-7500u)
pass   -> FAIL   (fi-kbl-7567u)
pass   -> FAIL   (fi-kbl-r)
Test gvt_basic:
Subgroup invalid-placeholder-test:
skip   -> INCOMPLETE (fi-ilk-650)
skip   -> INCOMPLETE (fi-bdw-5557u)
skip   -> INCOMPLETE (fi-skl-6260u)
skip   -> INCOMPLETE (fi-skl-6600u)
skip   -> INCOMPLETE (fi-skl-6700hq)
skip   -> INCOMPLETE (fi-skl-6700k)
skip   -> INCOMPLETE (fi-skl-6770hq)
skip   -> INCOMPLETE (fi-kbl-7500u)
skip   -> INCOMPLETE (fi-kbl-7567u)
skip   -> INCOMPLETE (fi-kbl-r)

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

fi-bdw-5557u total:288  pass:264  dwarn:0   dfail:1   fail:2   skip:20 
fi-bdw-gvtdvmtotal:288  pass:261  dwarn:0   dfail:1   fail:2   skip:24  
time:439s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:384s
fi-bsw-n3050 total:288  pass:239  dwarn:0   dfail:2   fail:1   skip:45 
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:255  dwarn:0   dfail:1   fail:2   skip:29 
fi-bxt-j4205 total:288  pass:256  dwarn:0   dfail:1   fail:2   skip:28 
fi-byt-j1900 total:285  pass:250  dwarn:0

Re: [Intel-gfx] [PATCH igt] lib: Check and report if a subtest triggers a new kernel taint

[Petri Latvala]

On Tue, Dec 05, 2017 at 12:38:19PM +, Chris Wilson wrote:
> Quoting Petri Latvala (2017-12-05 12:32:36)
> > On Tue, Dec 05, 2017 at 12:24:53PM +, Chris Wilson wrote:
> > > Checking for a tainted kernel is a convenient way to see if the test
> > > generated a critical error such as a oops, or machine check.
> > > 
> > > v2: Docs?
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Daniel Vetter 
> > > Cc: Radoslaw Szwichtenberg 
> > > Reviewed-by: Joonas Lahtinen 
> > > ---
> > >  lib/Makefile.sources   |   2 +
> > >  lib/igt_core.c |  19 +++-
> > >  lib/igt_kernel_taint.c | 120 
> > > +
> > >  lib/igt_kernel_taint.h |  34 ++
> > >  4 files changed, 174 insertions(+), 1 deletion(-)
> > >  create mode 100644 lib/igt_kernel_taint.c
> > >  create mode 100644 lib/igt_kernel_taint.h
> > > 
> > > diff --git a/lib/Makefile.sources b/lib/Makefile.sources
> > > index 6e968d9f7..152153908 100644
> > > --- a/lib/Makefile.sources
> > > +++ b/lib/Makefile.sources
> > > @@ -22,6 +22,8 @@ lib_source_list =   \
> > >   igt_gt.h\
> > >   igt_gvt.c   \
> > >   igt_gvt.h   \
> > > + igt_kernel_taint.c  \
> > > + igt_kernel_taint.h  \
> > >   igt_primes.c\
> > >   igt_primes.h\
> > >   igt_rand.c  \
> > > diff --git a/lib/igt_core.c b/lib/igt_core.c
> > > index 03fa6e4e8..486c5989d 100644
> > > --- a/lib/igt_core.c
> > > +++ b/lib/igt_core.c
> > > @@ -63,6 +63,7 @@
> > >  #include "intel_chipset.h"
> > >  #include "intel_io.h"
> > >  #include "igt_debugfs.h"
> > > +#include "igt_kernel_taint.h"
> > >  #include "version.h"
> > >  #include "config.h"
> > >  
> > > @@ -261,6 +262,7 @@ static bool list_subtests = false;
> > >  static char *run_single_subtest = NULL;
> > >  static bool run_single_subtest_found = false;
> > >  static const char *in_subtest = NULL;
> > > +static unsigned long saved_kernel_taint;
> > >  static struct timespec subtest_time;
> > >  static clockid_t igt_clock = (clockid_t)-1;
> > >  static bool in_fixture = false;
> > > @@ -937,6 +939,8 @@ bool __igt_run_subtest(const char *subtest_name)
> > >   return false;
> > >   }
> > >  
> > > + saved_kernel_taint = igt_read_kernel_taint();
> > > +
> > >   kmsg(KERN_INFO "[IGT] %s: starting subtest %s\n", command_str, 
> > > subtest_name);
> > >   igt_debug("Starting subtest: %s\n", subtest_name);
> > >  
> > > @@ -1083,8 +1087,21 @@ void __igt_skip_check(const char *file, const int 
> > > line,
> > >  void igt_success(void)
> > >  {
> > >   succeeded_one = true;
> > > - if (in_subtest)
> > > + if (in_subtest) {
> > > + unsigned long new_kernel_taints =
> > > + igt_read_kernel_taint() & ~saved_kernel_taint;
> > > + unsigned int tainted = 
> > > igt_kernel_tainted(new_kernel_taints);
> > > +
> > > + if (tainted) {
> > > + igt_kernel_taint_print(new_kernel_taints);
> > > + if (tainted & TAINT_ERROR)
> > > + exit_subtest("FAIL");
> > > + else
> > > + exit_subtest("WARN");
> > > + }
> > > +
> > >   exit_subtest("SUCCESS");
> > > + }
> > >  }
> > 
> > 
> > If you change the result to FAIL or WARN here, succeeded_one should not be 
> > changed.
> > 
> > What of tests that don't have subtests?
> 
> I don't know where they are tracked. If there is a location we can place
> such a before/after check. Or even if we do want to change test status
> at all, and just make it a warn if the kernel becomes tainted.
> 
> The ambition here isn't just to flag oops reliably, but to respond when
> we know the HW is broken and requires rebooting.

Still, the behaviour should be consistent whether it's a simple_test
or a subtest, right?

igt_simple_init_parse_opts would be a good place for storing the old
taint status, and checking generated taints / remapping the result
could be done in igt_exit, when test_with_subtests == false.


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

Re: [Intel-gfx] [PATCH] drm/i915/skl: DMC firmware for skylake v1.27

[Imre Deak]

On Thu, Nov 09, 2017 at 05:18:32PM -0800, Anusha Srivatsa wrote:
> There is a new version of dmc available for skylake.
> Following additions from ver1.27
> 
> 1. Fix for the issue where DC_STATE was getting enabled even when
> disabled by driver causing data corruption.
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Anusha Srivatsa 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/intel_csr.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> b/drivers/gpu/drm/i915/intel_csr.c
> index 77d8b3d..239b4c6 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -44,9 +44,9 @@
>  MODULE_FIRMWARE(I915_CSR_KBL);
>  #define KBL_CSR_VERSION_REQUIRED CSR_VERSION(1, 1)
>  
> -#define I915_CSR_SKL "i915/skl_dmc_ver1_26.bin"
> +#define I915_CSR_SKL "i915/skl_dmc_ver1_27.bin"
>  MODULE_FIRMWARE(I915_CSR_SKL);
> -#define SKL_CSR_VERSION_REQUIRED CSR_VERSION(1, 26)
> +#define SKL_CSR_VERSION_REQUIRED CSR_VERSION(1, 27)
>  
>  #define I915_CSR_BXT "i915/bxt_dmc_ver1_07.bin"
>  MODULE_FIRMWARE(I915_CSR_BXT);
> -- 
> 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 v5] drm/i915: Restore GT performance in headless mode with DMC loaded

[Imre Deak]

On Sat, Dec 02, 2017 at 01:58:12AM +0200, Rogozhkin, Dmitry V wrote:
> On Thu, 2017-11-30 at 13:19 +0200, Imre Deak wrote:
> > On Thu, Nov 30, 2017 at 09:45:25AM +, Chris Wilson wrote:
> > > Quoting Tvrtko Ursulin (2017-11-30 09:18:20)
> > > > From: Tvrtko Ursulin 
> > > > 
> > > > It seems that the DMC likes to transition between the DC states a lot 
> > > > when
> > > > there are no connected displays (no active power domains) during command
> > > > submission.
> > > > 
> > > > This activity on DC states has a negative impact on the performance of 
> > > > the
> > > > chip with huge latencies observed in the interrupt handlers and 
> > > > elsewhere.
> > > > Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
> > > > eight.
> > > > 
> > > > Work around it by introducing a new power domain named,
> > > > POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
> > > > held for the duration of command submission activity.
> > > > 
> > > > v2:
> > > >  * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
> > > >  * Protect macro body with braces. (Jani Nikula)
> > > > 
> > > > v3:
> > > >  * Add dedicated power domain for clarity. (Chris, Imre)
> > > >  * Commit message and comment text updates.
> > > >  * Apply to all big-core GEN9 parts apart for Skylake which is pending 
> > > > DMC
> > > >firmware release.
> > > > 
> > > > v4:
> > > >  * Power domain should be inner to device runtime pm. (Chris)
> > > >  * Simplify NEEDS_CSR_GT_PERF_WA macro. (Chris)
> > > >  * Handle async DMC loading by moving the GT_IRQ power domain logic into
> > > >intel_runtime_pm. (Daniel, Chris)
> > > >  * Include small core GEN9 as well. (Imre)
> > > > 
> > > > v5
> > > >  * Special handling for async DMC load is not needed since on failure 
> > > > the
> > > >power domain reference is kept permanently taken. (Imre)
> > > > 
> > > > Signed-off-by: Tvrtko Ursulin 
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
> > > > Testcase: igt/gem_exec_nop/headless
> > > > Cc: Imre Deak 
> > > > Acked-by: Chris Wilson  (v2)
> > > > Cc: Chris Wilson 
> > > > Cc: Dmitry Rogozhkin 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h |  4 
> > > >  drivers/gpu/drm/i915/i915_gem.c |  3 +++
> > > >  drivers/gpu/drm/i915/i915_gem_request.c | 14 ++
> > > >  drivers/gpu/drm/i915/intel_runtime_pm.c | 14 ++
> > > >  4 files changed, 35 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index bddd65839f60..59cf11dd5d3b 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -398,6 +398,7 @@ enum intel_display_power_domain {
> > > > POWER_DOMAIN_AUX_D,
> > > > POWER_DOMAIN_GMBUS,
> > > > POWER_DOMAIN_MODESET,
> > > > +   POWER_DOMAIN_GT_IRQ,
> > > > POWER_DOMAIN_INIT,
> > > >  
> > > > POWER_DOMAIN_NUM,
> > > > @@ -3285,6 +3286,9 @@ intel_info(const struct drm_i915_private 
> > > > *dev_priv)
> > > >  #define GT_FREQUENCY_MULTIPLIER 50
> > > >  #define GEN9_FREQ_SCALER 3
> > > >  
> > > > +#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
> > > > +   (HAS_CSR(dev_priv) && IS_GEN9(dev_priv) && 
> > > > !IS_SKYLAKE(dev_priv))
> > 
> > Nitpick: could be just !IS_SKYLAKE(), but works in the above way too.
> > For all other platforms the GT_IRQ domain won't be mapped making
> > display_power_get/put on those just a domain ref inc/dec, otherwise a
> > nop.
> 
> Folks, is my understanding correct that once SKL DMC will be merged we
> just remove !IS_SKYLAKE from the above check to get the performance fix
> for SKL and nothing more changes in the patch? I am asking because there
> is a need to have SKL patch on the plate already to verify the fix
> sooner rather than later. From this perspective, can we have one more
> patch in the series dedicated to fix SKL right now? After all, SKL DMC
> is available in drm-firmware already, those who need can try it.

The fixed SKL firmware is now in linux-firmware.git.

Tvrtko, could you resend the patch without the NEEDS_CSR_GT_PERF_WA()
check?

Thanks,
Imre

> 
> > 
> > > > +
> > > >  #include "i915_trace.h"
> > > >  
> > > >  static inline bool intel_vtd_active(void)
> > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > > > b/drivers/gpu/drm/i915/i915_gem.c
> > > > index 354b0546a191..c6067cba1dca 100644
> > > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > > @@ -3381,6 +3381,9 @@ i915_gem_idle_work_handler(struct work_struct 
> > > > *work)
> > > >  
> > > > if (INTEL_GEN(dev_priv) >= 6)
> > > > gen6_rps_idle(dev_priv);
> > > > +
> > > > +   intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
> > > > +
> > > > intel_runtime_pm_put(dev_priv);
> > > >  out_unlock:
> > > > mutex_unlock(&dev_priv->drm.struct_mutex);
> > > > diff --git

Re: [Intel-gfx] [PATCH v5] drm/i915: Restore GT performance in headless mode with DMC loaded

[Imre Deak]

On Sat, Dec 02, 2017 at 02:05:42AM +0200, Rogozhkin, Dmitry V wrote:
> On Thu, 2017-11-30 at 13:19 +0200, Imre Deak wrote:
> > > > +#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
> > > > +   (HAS_CSR(dev_priv) && IS_GEN9(dev_priv) && !
> > IS_SKYLAKE(dev_priv))
> > 
> > Nitpick: could be just !IS_SKYLAKE(), but works in the above way too.
> > For all other platforms the GT_IRQ domain won't be mapped making
> > display_power_get/put on those just a domain ref inc/dec, otherwise a
> > nop.
> 
> Why not +&& !IS_BROXTON(dev_priv) by the way?

We have the same slow-down problem on APL/BXT (and we don't have the DC6
corruption problem there).

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

[Intel-gfx] [PATCH v2] drm/i915: Track GGTT writes on the vma

[Chris Wilson]

As writes through the GTT and GGTT PTE updates do not share the same
path, they are not strictly ordered and so we must explicitly flush the
indirect writes prior to modifying the PTE. We do track outstanding GGTT
writes on the object itself, but since the object may have multiple GGTT
vma, that is overly coarse as we can track and flush individual vma as
required.

Whilst here, update the GGTT flushing behaviour for Cannonlake.

v2: Hard-code ring offset to allow use during unload (after RCS may have
been freed, or never existed!)

References: https://bugs.freedesktop.org/show_bug.cgi?id=104002
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 ++
 drivers/gpu/drm/i915/i915_gem.c | 55 +++--
 drivers/gpu/drm/i915/i915_vma.c | 22 +
 drivers/gpu/drm/i915/i915_vma.h | 19 ++
 4 files changed, 80 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 594fd14e66c5..5cf58e049dbd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3879,6 +3879,8 @@ int __must_check i915_gem_evict_for_node(struct 
i915_address_space *vm,
 unsigned int flags);
 int i915_gem_evict_vm(struct i915_address_space *vm);
 
+void i915_gem_flush_ggtt_writes(struct drm_i915_private *dev_priv);
+
 /* belongs in i915_gem_gtt.h */
 static inline void i915_gem_chipset_flush(struct drm_i915_private *dev_priv)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 80b78fb5daac..3760bb05 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -666,17 +666,13 @@ fb_write_origin(struct drm_i915_gem_object *obj, unsigned 
int domain)
obj->frontbuffer_ggtt_origin : ORIGIN_CPU);
 }
 
-static void
-flush_write_domain(struct drm_i915_gem_object *obj, unsigned int flush_domains)
+void i915_gem_flush_ggtt_writes(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
-
-   if (!(obj->base.write_domain & flush_domains))
-   return;
-
-   /* No actual flushing is required for the GTT write domain.  Writes
-* to it "immediately" go to main memory as far as we know, so there's
-* no chipset flush.  It also doesn't land in render cache.
+   /*
+* No actual flushing is required for the GTT write domain for reads
+* from the GTT domain. Writes to it "immediately" go to main memory
+* as far as we know, so there's no chipset flush. It also doesn't
+* land in the GPU render cache.
 *
 * However, we do have to enforce the order so that all writes through
 * the GTT land before any writes to the device, such as updates to
@@ -687,22 +683,43 @@ flush_write_domain(struct drm_i915_gem_object *obj, 
unsigned int flush_domains)
 * timing. This issue has only been observed when switching quickly
 * between GTT writes and CPU reads from inside the kernel on recent hw,
 * and it appears to only affect discrete GTT blocks (i.e. on LLC
-* system agents we cannot reproduce this behaviour).
+* system agents we cannot reproduce this behaviour, until Cannonlake
+* that was!).
 */
+
wmb();
 
+   intel_runtime_pm_get(dev_priv);
+   spin_lock_irq(&dev_priv->uncore.lock);
+
+   POSTING_READ_FW(RING_HEAD(RENDER_RING_BASE));
+
+   spin_unlock_irq(&dev_priv->uncore.lock);
+   intel_runtime_pm_put(dev_priv);
+}
+
+static void
+flush_write_domain(struct drm_i915_gem_object *obj, unsigned int flush_domains)
+{
+   struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
+   struct i915_vma *vma;
+
+   if (!(obj->base.write_domain & flush_domains))
+   return;
+
switch (obj->base.write_domain) {
case I915_GEM_DOMAIN_GTT:
-   if (!HAS_LLC(dev_priv)) {
-   intel_runtime_pm_get(dev_priv);
-   spin_lock_irq(&dev_priv->uncore.lock);
-   
POSTING_READ_FW(RING_HEAD(dev_priv->engine[RCS]->mmio_base));
-   spin_unlock_irq(&dev_priv->uncore.lock);
-   intel_runtime_pm_put(dev_priv);
-   }
+   i915_gem_flush_ggtt_writes(dev_priv);
 
intel_fb_obj_flush(obj,
   fb_write_origin(obj, I915_GEM_DOMAIN_GTT));
+
+   list_for_each_entry(vma, &obj->vma_list, obj_link) {
+   if (!i915_vma_is_ggtt(vma))
+   break;
+
+   i915_vma_unset_ggtt_write(vma);
+   }
break;
 
case I915_GEM_DOMAIN_CPU:
@@ -1965,6 +1982,8 @@ int i915_gem_fault(struct vm_fault *vmf)
list_add(&obj->userfault_link, &dev_priv->mm.userfault_list);
 

[Intel-gfx] [PATCH v6] drm/i915: Restore GT performance in headless mode with DMC loaded

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

It seems that the DMC likes to transition between the DC states a lot when
there are no connected displays (no active power domains) during command
submission.

This activity on DC states has a negative impact on the performance of the
chip with huge latencies observed in the interrupt handlers and elsewhere.
Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
eight.

Work around it by introducing a new power domain named,
POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
held for the duration of command submission activity.

v2:
 * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
 * Protect macro body with braces. (Jani Nikula)

v3:
 * Add dedicated power domain for clarity. (Chris, Imre)
 * Commit message and comment text updates.
 * Apply to all big-core GEN9 parts apart for Skylake which is pending DMC
   firmware release.

v4:
 * Power domain should be inner to device runtime pm. (Chris)
 * Simplify NEEDS_CSR_GT_PERF_WA macro. (Chris)
 * Handle async DMC loading by moving the GT_IRQ power domain logic into
   intel_runtime_pm. (Daniel, Chris)
 * Include small core GEN9 as well. (Imre)

v5
 * Special handling for async DMC load is not needed since on failure the
   power domain reference is kept permanently taken. (Imre)

v6:
 * Drop the NEEDS_CSR_GT_PERF_WA macro since all firmwares have now been
   deployed. (Imre, Chris)

Signed-off-by: Tvrtko Ursulin 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
Testcase: igt/gem_exec_nop/headless
Cc: Imre Deak 
Acked-by: Chris Wilson  (v2)
Cc: Chris Wilson 
Cc: Dmitry Rogozhkin 
Reviewed-by: Daniel Vetter  (v5)
Reviewed-by: Chris Wilson  (v5)
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c |  3 +++
 drivers/gpu/drm/i915/i915_gem_request.c | 14 ++
 drivers/gpu/drm/i915/intel_runtime_pm.c |  5 +
 4 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 594fd14e66c5..c56dccdf52e9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -398,6 +398,7 @@ enum intel_display_power_domain {
POWER_DOMAIN_AUX_D,
POWER_DOMAIN_GMBUS,
POWER_DOMAIN_MODESET,
+   POWER_DOMAIN_GT_IRQ,
POWER_DOMAIN_INIT,
 
POWER_DOMAIN_NUM,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e083f242b8dc..a8879854000b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3381,6 +3381,9 @@ i915_gem_idle_work_handler(struct work_struct *work)
 
if (INTEL_GEN(dev_priv) >= 6)
gen6_rps_idle(dev_priv);
+
+   intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
+
intel_runtime_pm_put(dev_priv);
 out_unlock:
mutex_unlock(&dev_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index a90bdd26571f..c28a4ceb016d 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -252,6 +252,20 @@ static void mark_busy(struct drm_i915_private *i915)
GEM_BUG_ON(!i915->gt.active_requests);
 
intel_runtime_pm_get_noresume(i915);
+
+   /*
+* It seems that the DMC likes to transition between the DC states a lot
+* when there are no connected displays (no active power domains) during
+* command submission.
+*
+* This activity has negative impact on the performance of the chip with
+* huge latencies observed in the interrupt handler and elsewhere.
+*
+* Work around it by grabbing a GT IRQ power domain whilst there is any
+* GT activity, preventing any DC state transitions.
+*/
+   intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
+
i915->gt.awake = true;
 
intel_enable_gt_powersave(i915);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 8315499452dc..96ab74f3d101 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -130,6 +130,8 @@ intel_display_power_domain_str(enum 
intel_display_power_domain domain)
return "INIT";
case POWER_DOMAIN_MODESET:
return "MODESET";
+   case POWER_DOMAIN_GT_IRQ:
+   return "GT_IRQ";
default:
MISSING_CASE(domain);
return "?";
@@ -1705,6 +1707,7 @@ void intel_display_power_put(struct drm_i915_private 
*dev_priv,
BIT_ULL(POWER_DOMAIN_INIT))
 #define SKL_DISPLAY_DC_OFF_POWER_DOMAINS ( \
SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
+   BIT_ULL(POWER_DOMAIN_GT_IRQ) |  \
BIT_ULL(POWER_DOMAIN_MODESET) | \
BIT_ULL(POWER_DOMAIN_AUX_A) |   \
BIT_ULL(POWER_DOMAIN_INIT))
@@ -1727,6

Re: [Intel-gfx] [PATCH v6] drm/i915: Restore GT performance in headless mode with DMC loaded

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-12-05 13:28:54)
> From: Tvrtko Ursulin 
> 
> It seems that the DMC likes to transition between the DC states a lot when
> there are no connected displays (no active power domains) during command
> submission.
> 
> This activity on DC states has a negative impact on the performance of the
> chip with huge latencies observed in the interrupt handlers and elsewhere.
> Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
> eight.
> 
> Work around it by introducing a new power domain named,
> POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
> held for the duration of command submission activity.
> 
> v2:
>  * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
>  * Protect macro body with braces. (Jani Nikula)
> 
> v3:
>  * Add dedicated power domain for clarity. (Chris, Imre)
>  * Commit message and comment text updates.
>  * Apply to all big-core GEN9 parts apart for Skylake which is pending DMC
>firmware release.
> 
> v4:
>  * Power domain should be inner to device runtime pm. (Chris)
>  * Simplify NEEDS_CSR_GT_PERF_WA macro. (Chris)
>  * Handle async DMC loading by moving the GT_IRQ power domain logic into
>intel_runtime_pm. (Daniel, Chris)
>  * Include small core GEN9 as well. (Imre)
> 
> v5
>  * Special handling for async DMC load is not needed since on failure the
>power domain reference is kept permanently taken. (Imre)
> 
> v6:
>  * Drop the NEEDS_CSR_GT_PERF_WA macro since all firmwares have now been
>deployed. (Imre, Chris)
> 
> Signed-off-by: Tvrtko Ursulin 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
> Testcase: igt/gem_exec_nop/headless
> Cc: Imre Deak 
> Acked-by: Chris Wilson  (v2)
> Cc: Chris Wilson 
> Cc: Dmitry Rogozhkin 
> Reviewed-by: Daniel Vetter  (v5)
> Reviewed-by: Chris Wilson  (v5)
Reviewed-by: Chris Wilson 

Could we add a note that Cannonlake is excluded and needs to be checked
as to whether it suffers the same?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix compilation (panel orientation x enum plane rename).

[Ville Syrjälä]

On Mon, Dec 04, 2017 at 04:04:15PM -0800, Rodrigo Vivi wrote:
> When commit '82daca297506 ("drm/i915: Add "panel orientation"
> property to the panel connector, v6.")' was done and tested
> by CI, commit 'ed15030d7ab0 ("drm/i915: s/enum plane/enum
> i9xx_plane_id/")' wasn't there already.
> 
> On this race the second patch got merged first so the first one
> broke i915 compilation. Thanks to Michel this was found quickly.
> 
> Cc: Michel Thierry 
> Cc: Daniel Vetter 
> Cc: Hans de Goede 
> Suggested-by: Michel Thierry 
> Fixes: 82daca297506 ("drm/i915: Add "panel orientation" property to the panel 
> connector, v6.")
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_dsi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 1b60df3c14a0..f67d321376e4 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -1670,7 +1670,7 @@ static int intel_dsi_get_panel_orientation(struct 
> intel_connector *connector)
>  {
>   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>   int orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
> - enum plane plane;
> + enum i9xx_plane_id plane;

s/plane/i9xx_plane/ for consistency

Not that I particularly like having this code here in the first
place. Ideally it would be part of proper plane state readout, but since
we don't have that I think it should be in some more central place so
that every connector can use it.

>   u32 val;
>  
>   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> -- 
> 2.13.6
> 
> ___
> 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] [RFC PATCH 0/6] drm/i915: Implement HDCP

[Ville Syrjälä]

On Thu, Nov 30, 2017 at 08:50:38AM +0100, Daniel Vetter wrote:
> On Wed, Nov 29, 2017 at 10:08:55PM -0500, Sean Paul wrote:
> > Here's the RFC for my i915 HDCP patchset. The UABI is based on what we've 
> > been
> > using in Chrome for the past 3 years. I posted the property to the list back
> > then, but never had a mainline driver to implement it. I do now :-)
> > 
> > Things are mostly in place, danvet gave me some feedback that I will
> > incorporate in v1. However, in the interest of gaining more early feedback, 
> > I'm
> > posting this now.
> > 
> > TODO:
> > - Add kerneldoc for property
> 
> The big thing I'd like to see here is clear description of the flows
> between kernel and userspace (since there's no helpers on the kernel side
> to standardize this).
> 
> One thing we discussed in that context is the addition of an uevent (like
> we do for anything else that changes with connectors, link_status is one
> example). But since the hdcp spec explicitly demands that the video player
> must poll the status an event is moot and won't be used. And I'm no fan of
> speculative uapi :-)

Speaking of uapi... Do we have an open source userspace and igts for
this somewhere?

I'm also concerned about debugging this. It will be a real PITA
to do if we can't even test it easily.

> 
> > - Fix '//' comments
> > - Change to MIT license
> > - Rebase on Ville's gmbus fixes (thanks Ville)
> > - Improve documentation on drm_intel_hdcp_shim
> > - Fix async commit locking (ie: don't use connection_mutex)
> > - Don't change connector->state in enable, defer to worker
> 
> Same holds for the disable callback, you can't touch state in there.
> 
> With the link_status prop (which is somewhat similar) we only reset it in
> atomic_check (where we hold the state locks) and in the async worker (same
> applies).
> -Daniel
> 
> > - Add igt coverage for the feature.
> > 
> > Thanks!
> > 
> > Sean
> > 
> > 
> > Sean Paul (6):
> >   drm: Add Content Protection property
> >   drm: Add some HDCP related #defines
> >   drm/i915: Add HDCP framework + base implementation
> >   drm/i915: Add function to output Aksv over GMBUS
> >   drm/i915: Implement HDCP for HDMI
> >   drm/i915: Implement HDCP for DisplayPort
> > 
> >  drivers/gpu/drm/drm_atomic.c|   8 +
> >  drivers/gpu/drm/drm_connector.c |  43 +++
> >  drivers/gpu/drm/drm_sysfs.c |  29 ++
> >  drivers/gpu/drm/i915/Makefile   |   1 +
> >  drivers/gpu/drm/i915/i915_drv.h |   1 +
> >  drivers/gpu/drm/i915/i915_reg.h |  85 +
> >  drivers/gpu/drm/i915/intel_atomic.c |  26 +-
> >  drivers/gpu/drm/i915/intel_ddi.c|  64 
> >  drivers/gpu/drm/i915/intel_dp.c | 243 +-
> >  drivers/gpu/drm/i915/intel_drv.h|  53 +++
> >  drivers/gpu/drm/i915/intel_hdcp.c   | 636 
> > 
> >  drivers/gpu/drm/i915/intel_hdmi.c   | 253 ++
> >  drivers/gpu/drm/i915/intel_i2c.c|  54 ++-
> >  include/drm/drm_connector.h |  16 +
> >  include/drm/drm_dp_helper.h |  17 +
> >  include/drm/drm_hdcp.h  |  44 +++
> >  include/uapi/drm/drm_mode.h |   4 +
> >  17 files changed, 1560 insertions(+), 17 deletions(-)
> >  create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
> >  create mode 100644 include/drm/drm_hdcp.h
> > 
> > -- 
> > 2.15.0.531.g2ccb3012c9-goog
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [Intel-gfx] [RFC 1/4] drm/i915/perf: Add support to correlate GPU timestamp with system time

[Lionel Landwerlin]

On 15/11/17 12:25, Chris Wilson wrote:

Quoting Sagar Arun Kamble (2017-11-15 12:13:51)

  #include 
  #include 
@@ -2149,6 +2150,14 @@ struct i915_perf_stream {
  * @oa_config: The OA configuration used by the stream.
  */
 struct i915_oa_config *oa_config;
+
+   /**
+* System time correlation variables.
+*/
+   struct cyclecounter cc;
+   spinlock_t systime_lock;
+   struct timespec64 start_systime;
+   struct timecounter tc;

This pattern is repeated a lot by struct timecounter users. (I'm still
trying to understand why the common case is not catered for by a
convenience timecounter api.)


  };
  
  /**

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 00be015..72ddc34 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -192,6 +192,7 @@
   */
  
  #include 

+#include 
  #include 
  #include 
  
@@ -2391,6 +2392,56 @@ static unsigned int i915_perf_poll(struct file *file, poll_table *wait)

  }
  
  /**

+ * i915_cyclecounter_read - read raw cycle/timestamp counter
+ * @cc: cyclecounter structure
+ */
+static u64 i915_cyclecounter_read(const struct cyclecounter *cc)
+{
+   struct i915_perf_stream *stream = container_of(cc, typeof(*stream), cc);
+   struct drm_i915_private *dev_priv = stream->dev_priv;
+   u64 ts_count;
+
+   intel_runtime_pm_get(dev_priv);
+   ts_count = I915_READ64_2x32(GEN4_TIMESTAMP,
+   GEN7_TIMESTAMP_UDW);
+   intel_runtime_pm_put(dev_priv);
+
+   return ts_count;
+}
+
+static void i915_perf_init_cyclecounter(struct i915_perf_stream *stream)
+{
+   struct drm_i915_private *dev_priv = stream->dev_priv;
+   int cs_ts_freq = dev_priv->perf.oa.timestamp_frequency;
+   struct cyclecounter *cc = &stream->cc;
+   u32 maxsec;
+
+   cc->read = i915_cyclecounter_read;
+   cc->mask = CYCLECOUNTER_MASK(CS_TIMESTAMP_WIDTH(dev_priv));
+   maxsec = cc->mask / cs_ts_freq;
+
+   clocks_calc_mult_shift(&cc->mult, &cc->shift, cs_ts_freq,
+  NSEC_PER_SEC, maxsec);
+}
+
+static void i915_perf_init_timecounter(struct i915_perf_stream *stream)
+{
+#define SYSTIME_START_OFFSET   35 /* Counter read takes about 350us */
+   unsigned long flags;
+   u64 ns;
+
+   i915_perf_init_cyclecounter(stream);
+   spin_lock_init(&stream->systime_lock);
+
+   getnstimeofday64(&stream->start_systime);
+   ns = timespec64_to_ns(&stream->start_systime) + SYSTIME_START_OFFSET;

Use ktime directly. Or else Arnd will be back with a patch to fix it.
(All non-ktime interfaces are effectively deprecated; obsolete for
drivers.)


+   spin_lock_irqsave(&stream->systime_lock, flags);
+   timecounter_init(&stream->tc, &stream->cc, ns);
+   spin_unlock_irqrestore(&stream->systime_lock, flags);
+}
+
+/**
   * i915_perf_enable_locked - handle `I915_PERF_IOCTL_ENABLE` ioctl
   * @stream: A disabled i915 perf stream
   *
@@ -2408,6 +2459,8 @@ static void i915_perf_enable_locked(struct 
i915_perf_stream *stream)
 /* Allow stream->ops->enable() to refer to this */
 stream->enabled = true;
  
+   i915_perf_init_timecounter(stream);

+
 if (stream->ops->enable)
 stream->ops->enable(stream);
  }
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cfdf4f8..e7e6966 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8882,6 +8882,12 @@ enum skl_power_gate {
  
  /* Gen4+ Timestamp and Pipe Frame time stamp registers */

  #define GEN4_TIMESTAMP _MMIO(0x2358)
+#define GEN7_TIMESTAMP_UDW _MMIO(0x235C)
+#define PRE_GEN7_TIMESTAMP_WIDTH   32
+#define GEN7_TIMESTAMP_WIDTH   36
+#define CS_TIMESTAMP_WIDTH(dev_priv) \
+   (INTEL_GEN(dev_priv) < 7 ? PRE_GEN7_TIMESTAMP_WIDTH : \
+  GEN7_TIMESTAMP_WIDTH)

s/PRE_GEN7/GEN4/ would be consistent.
If you really want to add support for earlier, I9XX_.


Why not use the RING_TIMESTAMP() RING_TIMESTAMP_UDW() ?
There's already used for the reg_read ioctl.



Ok. I can accept the justification, and we are not the only ones who do
the cyclecounter -> timecounter correction like this.
-Chris



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

Re: [Intel-gfx] [PATCH 3/3] i965: check scratch page in a locked fashion on each ioctl

[Joonas Lahtinen]

On Tue, 2017-12-05 at 10:41 +, Rogovin, Kevin wrote:
> Thanks, I will make a v2 and post it shortly to correct for my
> terribly embarrassing omission caused by even more terribly
> embarrassing ignorance.

To avoid v3, do concept the code around suggested existing
I915_GEM_CONTEXT_GETPARAM and I915_GEM_CONTEXT_SETPARAM ioctls. Just
add a new parameter I915_CONTEXT_PARAM_SCRATCH_PAGE. The interface
should become pretty bullet-proof that way.

Regards, Joonas

> 
> -Kevin
> 
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] 
> Sent: Tuesday, December 5, 2017 12:39 PM
> To: Rogovin, Kevin ; intel-gfx@lists.freedes
> ktop.org
> Subject: RE: [Intel-gfx] [PATCH 3/3] i965: check scratch page in a
> locked fashion on each ioctl
> 
> Quoting Rogovin, Kevin (2017-12-05 10:30:04)
> > Hi,
> > 
> > > Per context, then you can remove the locking. It's fitting since
> > > the scratch page is per-context anyway.
> > 
> >  The scratch page is per context? This I did not know, I thought it
> > was per PPGTT. If that is the case, then my proposed interface to
> > get/set the scratch page contents is wrong because it does not pass
> > the HW context id.
> 
> Yes, it per-vm, which is per-ctx on everything you want to
> investigate on. gen4-7 it is a global GTT with a global scratch, and
> just a mutex inside one process is not going to give you atomicity.
> -Chris
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Generalize definition for crtc mask

[Ville Syrjälä]

On Tue, Dec 05, 2017 at 12:15:39PM +0200, Mika Kahola wrote:
> crtc_mask is defined explicitly defined for a certain number of pipes per
> platform. Let's generalize this in a way that crtc_mask dependens only on
> the number of pipes defined in device info.
> 
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/i915/intel_crt.c  |  9 ++---
>  drivers/gpu/drm/i915/intel_ddi.c  |  5 -
>  drivers/gpu/drm/i915/intel_dp.c   | 12 
>  drivers/gpu/drm/i915/intel_hdmi.c |  4 +++-
>  drivers/gpu/drm/i915/intel_lvds.c | 12 +++-
>  drivers/gpu/drm/i915/intel_sdvo.c |  5 -
>  drivers/gpu/drm/i915/intel_tv.c   |  6 +-
>  7 files changed, 37 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_crt.c 
> b/drivers/gpu/drm/i915/intel_crt.c
> index 9f31aea..34f65b5 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -903,6 +903,7 @@ void intel_crt_init(struct drm_i915_private *dev_priv)
>   struct intel_connector *intel_connector;
>   i915_reg_t adpa_reg;
>   u32 adpa;
> + enum pipe pipe;
>  
>   if (HAS_PCH_SPLIT(dev_priv))
>   adpa_reg = PCH_ADPA;
> @@ -950,10 +951,12 @@ void intel_crt_init(struct drm_i915_private *dev_priv)
>  
>   crt->base.type = INTEL_OUTPUT_ANALOG;
>   crt->base.cloneable = (1 << INTEL_OUTPUT_DVO) | (1 << 
> INTEL_OUTPUT_HDMI);
> - if (IS_I830(dev_priv))
> + if (IS_I830(dev_priv)) {
>   crt->base.crtc_mask = (1 << 0);
> - else
> - crt->base.crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
> + } else {
> + for_each_pipe(dev_priv, pipe)
> + crt->base.crtc_mask |= (1 << pipe);
> + }

The only places you have to touch are DDI and MST. None of the other
encoder types are relevant for new platforms at all.

Looks like you actually missed MST in this patch, and it looks like the
code there is just wrong even now. It should really just set
'crtc_mask = BIT(pipe)' since the fake mst encoders are pipe specific.

In fact I think what we should do is have a small function that filters
out the non-existent pipes from the crtc_mask when populating
encoder->possible_crtcs. And I wouldn't be opposed to s/1<<0/BIT(PIPE_A)/
etc. everywhere we populate crtc_mask (maybe even s/crtc_mask/pipe_mask/
to make it clear what we're talking about).

And maybe actually get rid of crtc_mask entirely and just populate
possible_crtcs directly (with the help of aforementioned filtering
function).

Possibly some igt would be nice to confirm that possibly_crtcs etc.
don't advertize invalid crtc indices.

-- 
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] ✗ Fi.CI.IGT: warning for drm/i915/skl: DMC firmware for skylake v1.27

[Imre Deak]

On Fri, Nov 10, 2017 at 09:20:10AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/skl: DMC firmware for skylake v1.27
> URL   : https://patchwork.freedesktop.org/series/33568/
> State : warning

Thanks for the patch, pushed it to drm-tip.

> 
> == Summary ==
> 
> Test kms_setmode:
> Subgroup basic:
> pass   -> FAIL   (shard-hsw) fdo#99912
> Test kms_vblank:
> Subgroup wait-idle:
> pass   -> SKIP   (shard-hsw)
> Test kms_flip:
> Subgroup plain-flip-ts-check:
> pass   -> FAIL   (shard-hsw) fdo#100368
> Subgroup dpms-vs-vblank-race-interruptible:
> pass   -> FAIL   (shard-hsw) fdo#103060
> 
> fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
> fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
> fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
> 
> shard-hswtotal:2584 pass:1449 dwarn:2   dfail:2   fail:12  skip:1119 
> time:9378s
> 
> == Logs ==
> 
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7049/shards.html
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix compilation (panel orientation x enum plane rename).

[Joonas Lahtinen]

On Tue, 2017-12-05 at 15:38 +0200, Ville Syrjälä wrote:
> On Mon, Dec 04, 2017 at 04:04:15PM -0800, Rodrigo Vivi wrote:
> > When commit '82daca297506 ("drm/i915: Add "panel orientation"
> > property to the panel connector, v6.")' was done and tested
> > by CI, commit 'ed15030d7ab0 ("drm/i915: s/enum plane/enum
> > i9xx_plane_id/")' wasn't there already.
> > 
> > On this race the second patch got merged first so the first one
> > broke i915 compilation. Thanks to Michel this was found quickly.
> > 
> > Cc: Michel Thierry 
> > Cc: Daniel Vetter 
> > Cc: Hans de Goede 
> > Suggested-by: Michel Thierry 
> > Fixes: 82daca297506 ("drm/i915: Add "panel orientation" property to the 
> > panel connector, v6.")
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/intel_dsi.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> > b/drivers/gpu/drm/i915/intel_dsi.c
> > index 1b60df3c14a0..f67d321376e4 100644
> > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > @@ -1670,7 +1670,7 @@ static int intel_dsi_get_panel_orientation(struct 
> > intel_connector *connector)
> >  {
> > struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > int orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
> > -   enum plane plane;
> > +   enum i9xx_plane_id plane;
> 
> s/plane/i9xx_plane/ for consistency

I pushed the minimal fix to unbreak the tree.

> Not that I particularly like having this code here in the first
> place. Ideally it would be part of proper plane state readout, but since
> we don't have that I think it should be in some more central place so
> that every connector can use it.

I guess further changes should be queued as a follow-up patch to drm-
misc-next (just remember to refresh the -fixup.patch).

Regards, Joonas

> 
> > u32 val;
> >  
> > if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> > -- 
> > 2.13.6
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> 
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

[Lionel Landwerlin]

Hey Sagar,

Sorry for the delay looking into this series.
I've done some userspace/UI work in GPUTop to try to correlate perf 
samples/tracepoints with i915 perf reports.


I wanted to avoid having to add too much logic into the kernel and tried 
to sample both cpu clocks & gpu timestamps from userspace.
So far that's not working. People more knowledgable than I would have 
realized that the kernel can sneak in work into syscalls.
So result is that 2 syscalls (one to get the cpu clock, one for the gpu 
timestamp) back to back from the same thread leads to time differences 
of anywhere from a few microseconds to in some cases close to 
1millisecond. So it's basically unworkable.

Anyway the UI work won't go to waste :)

I'm thinking to go with your approach.
From my experiment with gputop, it seems we might want to use a 
different cpu clock source though or make it configurable.
The perf infrastructure allows you to choose what clock you want to use. 
Since we want to avoid time adjustments on that clock (because we're 
adding deltas), a clock monotonic raw would make most sense.


I'll look at adding some tests for this too.

Thanks,

-
Lionel

On 15/11/17 12:13, Sagar Arun Kamble wrote:

We can compute system time corresponding to GPU timestamp by taking a
reference point (CPU monotonic time, GPU timestamp) and then adding
delta time computed using timecounter/cyclecounter support in kernel.
We have to configure cyclecounter with the GPU timestamp frequency.
Earlier approach that was based on cross-timestamp is not needed. It
was being used to approximate the frequency based on invalid assumptions
(possibly drift was being seen in the time due to precision issue).
The precision of time from GPU clocks is already in ns and timecounter
takes care of it as verified over variable durations.

This series adds base timecounter/cyclecounter changes and changes to
get GPU and CPU timestamps in OA samples.

Sagar Arun Kamble (1):
   drm/i915/perf: Add support to correlate GPU timestamp with system time

Sourab Gupta (3):
   drm/i915/perf: Add support for collecting 64 bit timestamps with OA
 reports
   drm/i915/perf: Extract raw GPU timestamps from OA reports
   drm/i915/perf: Send system clock monotonic time in perf samples

  drivers/gpu/drm/i915/i915_drv.h  |  11 
  drivers/gpu/drm/i915/i915_perf.c | 124 ++-
  drivers/gpu/drm/i915/i915_reg.h  |   6 ++
  include/uapi/drm/i915_drm.h  |  14 +
  4 files changed, 154 insertions(+), 1 deletion(-)



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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Flush pending GTT writes before unbinding (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Flush pending GTT writes before 
unbinding (rev2)
URL   : https://patchwork.freedesktop.org/series/34900/
State : success

== Summary ==

Series 34900v2 series starting with [1/2] drm/i915: Flush pending GTT writes 
before unbinding
https://patchwork.freedesktop.org/api/1.0/series/34900/revisions/2/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> DMESG-FAIL (fi-elk-e7500) fdo#103989 +1
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:438s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:446s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:381s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:527s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:515s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:489s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:475s
fi-elk-e7500 total:224  pass:163  dwarn:14  dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:1   dfail:0   fail:0   skip:108 
time:267s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:538s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:374s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:258s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:391s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:483s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:446s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:489s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:533s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:475s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:540s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:586s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:460s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:544s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:572s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:520s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:499s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:457s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:412s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:616s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:614s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:495s

80da3dbebd28bbae73d15acf06eeaea420369b13 drm-tip: 2017y-12m-05d-13h-00m-30s UTC 
integration manifest
09fc8c2dfb3f drm/i915: Track GGTT writes on the vma
4dc5fea40899 drm/i915: Flush pending GTT writes before unbinding

== Logs ==

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

Re: [Intel-gfx] [RFC 4/4] drm/i915/perf: Send system clock monotonic time in perf samples

[Lionel Landwerlin]

On 15/11/17 12:13, Sagar Arun Kamble wrote:

From: Sourab Gupta 

Currently, we have the ability to only forward the GPU timestamps in the
samples (which are generated via OA reports). This limits the ability to
correlate these samples with the system events.

An ability is therefore needed to report timestamps in different clock
domains, such as CLOCK_MONOTONIC, in the perf samples to be of more
practical use to the userspace. This ability becomes important
when we want to correlate/plot GPU events/samples with other system events
on the same timeline (e.g. vblank events, or timestamps when work was
submitted to kernel, etc.)

The patch here proposes a mechanism to achieve this. The correlation
between gpu time and system time is established using the timestamp clock
associated with the command stream, abstracted as timecounter/cyclecounter
to retrieve gpu/system time correlated values.

v2: Added i915_driver_init_late() function to capture the new late init
phase for perf (Chris)

v3: Removed cross-timestamp changes.

Signed-off-by: Sourab Gupta 
Signed-off-by: Sagar Arun Kamble 
Cc: Lionel Landwerlin 
Cc: Chris Wilson 
Cc: Sourab Gupta 
Cc: Matthew Auld 
---
  drivers/gpu/drm/i915/i915_perf.c | 27 +++
  include/uapi/drm/i915_drm.h  |  7 +++
  2 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 3b721d7..94ee924 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -336,6 +336,7 @@
  
  #define SAMPLE_OA_REPORT	BIT(0)

  #define SAMPLE_GPU_TS BIT(1)
+#define SAMPLE_SYSTEM_TS   BIT(2)
  
  /**

   * struct perf_open_properties - for validated properties given to open a 
stream
@@ -622,6 +623,7 @@ static int append_oa_sample(struct i915_perf_stream *stream,
struct drm_i915_perf_record_header header;
u32 sample_flags = stream->sample_flags;
u64 gpu_ts = 0;
+   u64 system_ts = 0;
  
  	header.type = DRM_I915_PERF_RECORD_SAMPLE;

header.pad = 0;
@@ -647,6 +649,23 @@ static int append_oa_sample(struct i915_perf_stream 
*stream,
  
  		if (copy_to_user(buf, &gpu_ts, I915_PERF_TS_SAMPLE_SIZE))

return -EFAULT;
+   buf += I915_PERF_TS_SAMPLE_SIZE;


This is a ridiculous nit, but I think using sizeof(u64) would be more 
readable than this I915_PERF_TS_SAMPLE_SIZE define.



+   }
+
+   if (sample_flags & SAMPLE_SYSTEM_TS) {
+   gpu_ts = get_gpu_ts_from_oa_report(stream, report);
+   /*
+* XXX: timecounter_cyc2time considers time backwards if delta
+* timestamp is more than half the max ns time covered by
+* counter. It will be ~35min for 36 bit counter. If this much
+* sampling duration is needed we will have to update tc->nsec
+* by explicitly reading the timecounter (timecounter_read)
+* before this duration.
+*/
+   system_ts = timecounter_cyc2time(&stream->tc, gpu_ts);
+
+   if (copy_to_user(buf, &system_ts, I915_PERF_TS_SAMPLE_SIZE))
+   return -EFAULT;
}
  
  	(*offset) += header.size;

@@ -2137,6 +2156,11 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
stream->sample_size += I915_PERF_TS_SAMPLE_SIZE;
}
  
+	if (props->sample_flags & SAMPLE_SYSTEM_TS) {

+   stream->sample_flags |= SAMPLE_SYSTEM_TS;
+   stream->sample_size += I915_PERF_TS_SAMPLE_SIZE;
+   }
+
dev_priv->perf.oa.oa_buffer.format_size = format_size;
if (WARN_ON(dev_priv->perf.oa.oa_buffer.format_size == 0))
return -EINVAL;
@@ -2857,6 +2881,9 @@ static int read_properties_unlocked(struct 
drm_i915_private *dev_priv,
case DRM_I915_PERF_PROP_SAMPLE_GPU_TS:
props->sample_flags |= SAMPLE_GPU_TS;
break;
+   case DRM_I915_PERF_PROP_SAMPLE_SYSTEM_TS:
+   props->sample_flags |= SAMPLE_SYSTEM_TS;
+   break;
case DRM_I915_PERF_PROP_OA_METRICS_SET:
if (value == 0) {
DRM_DEBUG("Unknown OA metric set ID\n");
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 0b9249e..283859c 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1453,6 +1453,12 @@ enum drm_i915_perf_property_id {
DRM_I915_PERF_PROP_SAMPLE_GPU_TS,
  
  	/**

+* This property requests inclusion of CLOCK_MONOTONIC system time in
+* the perf sample data.
+*/
+   DRM_I915_PERF_PROP_SAMPLE_SYSTEM_TS,
+
+   /**
 * The value specifies which set of OA unit metrics should be
 * be configured, defining the contents of any OA unit reports.
 */
@@ -1539,6 +1545,7 @@ enum drm_i915_perf_record_type {

Re: [Intel-gfx] [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

[Robert Bragg]

On Tue, Dec 5, 2017 at 2:16 PM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> Hey Sagar,
>
> Sorry for the delay looking into this series.
> I've done some userspace/UI work in GPUTop to try to correlate perf
> samples/tracepoints with i915 perf reports.
>
> I wanted to avoid having to add too much logic into the kernel and tried
> to sample both cpu clocks & gpu timestamps from userspace.
> So far that's not working. People more knowledgable than I would have
> realized that the kernel can sneak in work into syscalls.
> So result is that 2 syscalls (one to get the cpu clock, one for the gpu
> timestamp) back to back from the same thread leads to time differences of
> anywhere from a few microseconds to in some cases close to 1millisecond. So
> it's basically unworkable.
> Anyway the UI work won't go to waste :)
>
> I'm thinking to go with your approach.
> From my experiment with gputop, it seems we might want to use a different
> cpu clock source though or make it configurable.
> The perf infrastructure allows you to choose what clock you want to use.
> Since we want to avoid time adjustments on that clock (because we're adding
> deltas), a clock monotonic raw would make most sense.
>

I would guess the most generally useful clock domain to correlate with the
largest number of interesting events would surely be CLOCK_MONOTONIC, not
_MONOTONIC_RAW.

E.g. here's some discussion around why vblank events use CLOCK_MONOTINIC:
https://lists.freedesktop.org/archives/dri-devel/2012-October/028878.html

Br,
- Robert


> I'll look at adding some tests for this too.
>
> Thanks,
>
> -
> Lionel
>
> On 15/11/17 12:13, Sagar Arun Kamble wrote:
>
>> We can compute system time corresponding to GPU timestamp by taking a
>> reference point (CPU monotonic time, GPU timestamp) and then adding
>> delta time computed using timecounter/cyclecounter support in kernel.
>> We have to configure cyclecounter with the GPU timestamp frequency.
>> Earlier approach that was based on cross-timestamp is not needed. It
>> was being used to approximate the frequency based on invalid assumptions
>> (possibly drift was being seen in the time due to precision issue).
>> The precision of time from GPU clocks is already in ns and timecounter
>> takes care of it as verified over variable durations.
>>
>> This series adds base timecounter/cyclecounter changes and changes to
>> get GPU and CPU timestamps in OA samples.
>>
>> Sagar Arun Kamble (1):
>>drm/i915/perf: Add support to correlate GPU timestamp with system time
>>
>> Sourab Gupta (3):
>>drm/i915/perf: Add support for collecting 64 bit timestamps with OA
>>  reports
>>drm/i915/perf: Extract raw GPU timestamps from OA reports
>>drm/i915/perf: Send system clock monotonic time in perf samples
>>
>>   drivers/gpu/drm/i915/i915_drv.h  |  11 
>>   drivers/gpu/drm/i915/i915_perf.c | 124 ++
>> -
>>   drivers/gpu/drm/i915/i915_reg.h  |   6 ++
>>   include/uapi/drm/i915_drm.h  |  14 +
>>   4 files changed, 154 insertions(+), 1 deletion(-)
>>
>>
> ___
> 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 v3 9/9] drm/i915: Implement HDCP for DisplayPort

[Ramalingam C]

On Tuesday 05 December 2017 10:45 AM, Sean Paul wrote:

+static
+bool intel_dp_hdcp_check_link(struct intel_digital_port *intel_dig_port)
+{
+   ssize_t ret;
+   u8 bstatus;
+   ret = drm_dp_dpcd_read(&intel_dig_port->dp.aux, DP_AUX_HDCP_BSTATUS,
+  &bstatus, 1);
+   if (ret != 1) {
+   DRM_ERROR("Read bstatus from DP/AUX failed (%ld)\n", ret);
+   return ret >= 0 ? -EIO : ret;
+   }
+   return !(bstatus & DP_BSTATUS_LINK_FAILURE);
+}
as per link integrity check should cover other indication from the 
repeater like


REAUTHENTICATION_REQUEST - request for reauth due to unauthenticated 
state at downstream for some unknown reason


-Ram

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

Re: [Intel-gfx] [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

[Lionel Landwerlin]

On 05/12/17 14:28, Robert Bragg wrote:



On Tue, Dec 5, 2017 at 2:16 PM, Lionel Landwerlin 
mailto:lionel.g.landwer...@intel.com>> 
wrote:


Hey Sagar,

Sorry for the delay looking into this series.
I've done some userspace/UI work in GPUTop to try to correlate
perf samples/tracepoints with i915 perf reports.

I wanted to avoid having to add too much logic into the kernel and
tried to sample both cpu clocks & gpu timestamps from userspace.
So far that's not working. People more knowledgable than I would
have realized that the kernel can sneak in work into syscalls.
So result is that 2 syscalls (one to get the cpu clock, one for
the gpu timestamp) back to back from the same thread leads to time
differences of anywhere from a few microseconds to in some cases
close to 1millisecond. So it's basically unworkable.
Anyway the UI work won't go to waste :)

I'm thinking to go with your approach.
>From my experiment with gputop, it seems we might want to use a
different cpu clock source though or make it configurable.
The perf infrastructure allows you to choose what clock you want
to use. Since we want to avoid time adjustments on that clock
(because we're adding deltas), a clock monotonic raw would make
most sense.


I would guess the most generally useful clock domain to correlate with 
the largest number of interesting events would surely be 
CLOCK_MONOTONIC, not _MONOTONIC_RAW.


E.g. here's some discussion around why vblank events use 
CLOCK_MONOTINIC: 
https://lists.freedesktop.org/archives/dri-devel/2012-October/028878.html


Br,
- Robert


Thanks Rob, then I guess making it configurable when opening the stream 
would be the safest option.





I'll look at adding some tests for this too.

Thanks,

-
Lionel

On 15/11/17 12:13, Sagar Arun Kamble wrote:

We can compute system time corresponding to GPU timestamp by
taking a
reference point (CPU monotonic time, GPU timestamp) and then
adding
delta time computed using timecounter/cyclecounter support in
kernel.
We have to configure cyclecounter with the GPU timestamp
frequency.
Earlier approach that was based on cross-timestamp is not
needed. It
was being used to approximate the frequency based on invalid
assumptions
(possibly drift was being seen in the time due to precision
issue).
The precision of time from GPU clocks is already in ns and
timecounter
takes care of it as verified over variable durations.

This series adds base timecounter/cyclecounter changes and
changes to
get GPU and CPU timestamps in OA samples.

Sagar Arun Kamble (1):
   drm/i915/perf: Add support to correlate GPU timestamp with
system time

Sourab Gupta (3):
   drm/i915/perf: Add support for collecting 64 bit timestamps
with OA
     reports
   drm/i915/perf: Extract raw GPU timestamps from OA reports
   drm/i915/perf: Send system clock monotonic time in perf samples

  drivers/gpu/drm/i915/i915_drv.h  |  11 
  drivers/gpu/drm/i915/i915_perf.c | 124
++-
  drivers/gpu/drm/i915/i915_reg.h  |   6 ++
  include/uapi/drm/i915_drm.h      |  14 +
  4 files changed, 154 insertions(+), 1 deletion(-)


___
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] [RFC PATCH 0/6] drm/i915: Implement HDCP

[Sean Paul]

On Tue, Dec 5, 2017 at 8:45 AM, Ville Syrjälä
 wrote:
> On Thu, Nov 30, 2017 at 08:50:38AM +0100, Daniel Vetter wrote:
>> On Wed, Nov 29, 2017 at 10:08:55PM -0500, Sean Paul wrote:
>> > Here's the RFC for my i915 HDCP patchset. The UABI is based on what we've 
>> > been
>> > using in Chrome for the past 3 years. I posted the property to the list 
>> > back
>> > then, but never had a mainline driver to implement it. I do now :-)
>> >
>> > Things are mostly in place, danvet gave me some feedback that I will
>> > incorporate in v1. However, in the interest of gaining more early 
>> > feedback, I'm
>> > posting this now.
>> >
>> > TODO:
>> > - Add kerneldoc for property
>>
>> The big thing I'd like to see here is clear description of the flows
>> between kernel and userspace (since there's no helpers on the kernel side
>> to standardize this).
>>
>> One thing we discussed in that context is the addition of an uevent (like
>> we do for anything else that changes with connectors, link_status is one
>> example). But since the hdcp spec explicitly demands that the video player
>> must poll the status an event is moot and won't be used. And I'm no fan of
>> speculative uapi :-)
>
> Speaking of uapi... Do we have an open source userspace and igts for
> this somewhere?
>

The userspace is implemented in Chrome for Chrome OS:
https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_display.cc

I posted an igt test on the list earlier today.

Sean

> I'm also concerned about debugging this. It will be a real PITA
> to do if we can't even test it easily.
>
>>
>> > - Fix '//' comments
>> > - Change to MIT license
>> > - Rebase on Ville's gmbus fixes (thanks Ville)
>> > - Improve documentation on drm_intel_hdcp_shim
>> > - Fix async commit locking (ie: don't use connection_mutex)
>> > - Don't change connector->state in enable, defer to worker
>>
>> Same holds for the disable callback, you can't touch state in there.
>>
>> With the link_status prop (which is somewhat similar) we only reset it in
>> atomic_check (where we hold the state locks) and in the async worker (same
>> applies).
>> -Daniel
>>
>> > - Add igt coverage for the feature.
>> >
>> > Thanks!
>> >
>> > Sean
>> >
>> >
>> > Sean Paul (6):
>> >   drm: Add Content Protection property
>> >   drm: Add some HDCP related #defines
>> >   drm/i915: Add HDCP framework + base implementation
>> >   drm/i915: Add function to output Aksv over GMBUS
>> >   drm/i915: Implement HDCP for HDMI
>> >   drm/i915: Implement HDCP for DisplayPort
>> >
>> >  drivers/gpu/drm/drm_atomic.c|   8 +
>> >  drivers/gpu/drm/drm_connector.c |  43 +++
>> >  drivers/gpu/drm/drm_sysfs.c |  29 ++
>> >  drivers/gpu/drm/i915/Makefile   |   1 +
>> >  drivers/gpu/drm/i915/i915_drv.h |   1 +
>> >  drivers/gpu/drm/i915/i915_reg.h |  85 +
>> >  drivers/gpu/drm/i915/intel_atomic.c |  26 +-
>> >  drivers/gpu/drm/i915/intel_ddi.c|  64 
>> >  drivers/gpu/drm/i915/intel_dp.c | 243 +-
>> >  drivers/gpu/drm/i915/intel_drv.h|  53 +++
>> >  drivers/gpu/drm/i915/intel_hdcp.c   | 636 
>> > 
>> >  drivers/gpu/drm/i915/intel_hdmi.c   | 253 ++
>> >  drivers/gpu/drm/i915/intel_i2c.c|  54 ++-
>> >  include/drm/drm_connector.h |  16 +
>> >  include/drm/drm_dp_helper.h |  17 +
>> >  include/drm/drm_hdcp.h  |  44 +++
>> >  include/uapi/drm/drm_mode.h |   4 +
>> >  17 files changed, 1560 insertions(+), 17 deletions(-)
>> >  create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
>> >  create mode 100644 include/drm/drm_hdcp.h
>> >
>> > --
>> > 2.15.0.531.g2ccb3012c9-goog
>> >
>> > ___
>> > Intel-gfx mailing list
>> > Intel-gfx@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Generalize definition for crtc mask

[Mika Kahola]

On Tue, 2017-12-05 at 15:59 +0200, Ville Syrjälä wrote:
> On Tue, Dec 05, 2017 at 12:15:39PM +0200, Mika Kahola wrote:
> > 
> > crtc_mask is defined explicitly defined for a certain number of
> > pipes per
> > platform. Let's generalize this in a way that crtc_mask dependens
> > only on
> > the number of pipes defined in device info.
> > 
> > Signed-off-by: Mika Kahola 
> > ---
> >  drivers/gpu/drm/i915/intel_crt.c  |  9 ++---
> >  drivers/gpu/drm/i915/intel_ddi.c  |  5 -
> >  drivers/gpu/drm/i915/intel_dp.c   | 12 
> >  drivers/gpu/drm/i915/intel_hdmi.c |  4 +++-
> >  drivers/gpu/drm/i915/intel_lvds.c | 12 +++-
> >  drivers/gpu/drm/i915/intel_sdvo.c |  5 -
> >  drivers/gpu/drm/i915/intel_tv.c   |  6 +-
> >  7 files changed, 37 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_crt.c
> > b/drivers/gpu/drm/i915/intel_crt.c
> > index 9f31aea..34f65b5 100644
> > --- a/drivers/gpu/drm/i915/intel_crt.c
> > +++ b/drivers/gpu/drm/i915/intel_crt.c
> > @@ -903,6 +903,7 @@ void intel_crt_init(struct drm_i915_private
> > *dev_priv)
> >     struct intel_connector *intel_connector;
> >     i915_reg_t adpa_reg;
> >     u32 adpa;
> > +   enum pipe pipe;
> >  
> >     if (HAS_PCH_SPLIT(dev_priv))
> >     adpa_reg = PCH_ADPA;
> > @@ -950,10 +951,12 @@ void intel_crt_init(struct drm_i915_private
> > *dev_priv)
> >  
> >     crt->base.type = INTEL_OUTPUT_ANALOG;
> >     crt->base.cloneable = (1 << INTEL_OUTPUT_DVO) | (1 <<
> > INTEL_OUTPUT_HDMI);
> > -   if (IS_I830(dev_priv))
> > +   if (IS_I830(dev_priv)) {
> >     crt->base.crtc_mask = (1 << 0);
> > -   else
> > -   crt->base.crtc_mask = (1 << 0) | (1 << 1) | (1 <<
> > 2);
> > +   } else {
> > +   for_each_pipe(dev_priv, pipe)
> > +   crt->base.crtc_mask |= (1 << pipe);
> > +   }
> The only places you have to touch are DDI and MST. None of the other
> encoder types are relevant for new platforms at all.
That's true. For these newer platforms I wouldn't have needed to touch
other encoder types but I decided to go that road due to consistency. I
may drop these for the next iteration of the patch.
> 
> Looks like you actually missed MST in this patch, and it looks like
> the
> code there is just wrong even now. It should really just set
> 'crtc_mask = BIT(pipe)' since the fake mst encoders are pipe
> specific.
Ouch, I completely missed the MST part.

> 
> In fact I think what we should do is have a small function that
> filters
> out the non-existent pipes from the crtc_mask when populating
> encoder->possible_crtcs. And I wouldn't be opposed to
> s/1<<0/BIT(PIPE_A)/
> etc. everywhere we populate crtc_mask (maybe even
> s/crtc_mask/pipe_mask/
> to make it clear what we're talking about).
I'll test this small helper function and see what the outcome looks
like.

Thanks for the review!
> 
> And maybe actually get rid of crtc_mask entirely and just populate
> possible_crtcs directly (with the help of aforementioned filtering
> function).
> 
> Possibly some igt would be nice to confirm that possibly_crtcs etc.
> don't advertize invalid crtc indices.
> 
-- 
Mika Kahola - Intel OTC

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

Re: [Intel-gfx] Fixes that failed to cleanly apply to v4.15-rc1

[Joonas Lahtinen]

Dropping GVT folks that are not affected.

Keeping Zhenyu and Zhi as a heads-up, there's no need for GVT pull for this rc?

On Tue, 2017-11-28 at 10:54 +0200, Joonas Lahtinen wrote:
> Hello,
> 
> TL;DR Reply with backported patches for v4.15-rc1 latest TODAY
> 
> Dear patch authors/Cc:s, the following patches failed to cleanly
> backport to v4.15-rc1, if you believe they still are valid patches to
> be included in drm-intel-fixes, please backport them and send them as a
> REPLY TO THIS EMAIL before the END OF TODAY.



> 0cfecb7c4b9b ("Revert "drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, 
> glk"")

This patch still fails to apply and I'm looking at -rc3 already.

Rodrigo and Radhakrishna, do we actually want to see the patch
backported?

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Restore GT performance in headless mode with DMC loaded (rev6)

[Patchwork]

== Series Details ==

Series: drm/i915: Restore GT performance in headless mode with DMC loaded (rev6)
URL   : https://patchwork.freedesktop.org/series/24017/
State : failure

== Summary ==

Series 24017v6 drm/i915: Restore GT performance in headless mode with DMC loaded
https://patchwork.freedesktop.org/api/1.0/series/24017/revisions/6/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989 +4
Test gem_exec_reloc:
Subgroup basic-gtt-read:
incomplete -> PASS   (fi-byt-j1900)
Test gem_ringfill:
Subgroup basic-default-hang:
dmesg-warn -> PASS   (fi-elk-e7500)
Test gem_sync:
Subgroup basic-all:
skip   -> PASS   (fi-elk-e7500)
Subgroup basic-each:
skip   -> PASS   (fi-elk-e7500)
Subgroup basic-many-each:
skip   -> PASS   (fi-elk-e7500)
Subgroup basic-store-all:
skip   -> PASS   (fi-elk-e7500)
Subgroup basic-store-each:
skip   -> PASS   (fi-elk-e7500)
Test gem_tiled_blits:
Subgroup basic:
skip   -> PASS   (fi-elk-e7500)
Test gem_tiled_fence_blits:
Subgroup basic:
skip   -> PASS   (fi-elk-e7500)
Test gem_wait:
Subgroup basic-busy-all:
skip   -> PASS   (fi-elk-e7500)
Subgroup basic-wait-all:
skip   -> PASS   (fi-elk-e7500)
Subgroup basic-await-all:
skip   -> PASS   (fi-elk-e7500)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-kbl-r)
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test drv_module_reload:
Subgroup basic-reload:
pass   -> INCOMPLETE (fi-bwr-2160)

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:436s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:447s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:388s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:517s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:104
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:505s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:510s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:486s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:480s
fi-elk-e7500 total:224  pass:163  dwarn:14  dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:264s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:541s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:375s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:257s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:393s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:482s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:452s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:485s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:530s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:473s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:535s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:592s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:459s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:536s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:515s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:504s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:445s
fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:544s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:415s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:610s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:627s
fi-glk-dsi   total:288  pass:257  dwarn:0   dfail:0   fail:1   skip:30  
time:499s

73c6ae44485ad50f39ca0ed5

Re: [Intel-gfx] [PATCH v3 3/9] drm: Add Content Protection property

[Daniel Vetter]

On Tue, Dec 05, 2017 at 09:07:58AM +0100, Hans Verkuil wrote:
> On 12/05/2017 06:15 AM, Sean Paul wrote:
> > This patch adds a new optional connector property to allow userspace to 
> > enable
> > protection over the content it is displaying. This will typically be 
> > implemented
> > by the driver using HDCP.
> > 
> > The property is a tri-state with the following values:
> > - OFF: Self explanatory, no content protection
> > - DESIRED: Userspace requests that the driver enable protection
> > - ENABLED: Once the driver has authenticated the link, it sets this value
> > 
> > The driver is responsible for downgrading ENABLED to DESIRED if the link 
> > becomes
> > unprotected. The driver should also maintain the desiredness of protection
> > across hotplug/dpms/suspend.
> > 
> > If this looks familiar, I posted [1] this 3 years ago. We have been using 
> > this
> > in ChromeOS across exynos, mediatek, and rockchip over that time.
> > 
> > Changes in v2:
> >  - Pimp kerneldoc for content_protection_property (Daniel)
> >  - Drop sysfs attribute
> > Changes in v3:
> >  - None
> > 
> > Cc: Daniel Vetter 
> > Signed-off-by: Sean Paul 
> > 
> > [1] 
> > https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.html
> > ---
> >  drivers/gpu/drm/drm_atomic.c|  8 +
> >  drivers/gpu/drm/drm_connector.c | 71 
> > +
> >  drivers/gpu/drm/drm_sysfs.c |  1 +
> >  include/drm/drm_connector.h | 16 ++
> >  include/uapi/drm/drm_mode.h |  4 +++
> >  5 files changed, 100 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index c2da5585e201..676025d755b2 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1196,6 +1196,12 @@ static int drm_atomic_connector_set_property(struct 
> > drm_connector *connector,
> > state->picture_aspect_ratio = val;
> > } else if (property == connector->scaling_mode_property) {
> > state->scaling_mode = val;
> > +   } else if (property == connector->content_protection_property) {
> > +   if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
> > +   DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
> > +   return -EINVAL;
> > +   }
> > +   state->content_protection = val;
> > } else if (connector->funcs->atomic_set_property) {
> > return connector->funcs->atomic_set_property(connector,
> > state, property, val);
> > @@ -1275,6 +1281,8 @@ drm_atomic_connector_get_property(struct 
> > drm_connector *connector,
> > *val = state->picture_aspect_ratio;
> > } else if (property == connector->scaling_mode_property) {
> > *val = state->scaling_mode;
> > +   } else if (property == connector->content_protection_property) {
> > +   *val = state->content_protection;
> > } else if (connector->funcs->atomic_get_property) {
> > return connector->funcs->atomic_get_property(connector,
> > state, property, val);
> > diff --git a/drivers/gpu/drm/drm_connector.c 
> > b/drivers/gpu/drm/drm_connector.c
> > index f14b48e6e839..8626aa8f485e 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -698,6 +698,13 @@ static const struct drm_prop_enum_list 
> > drm_tv_subconnector_enum_list[] = {
> >  DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
> >  drm_tv_subconnector_enum_list)
> >  
> > +static struct drm_prop_enum_list drm_cp_enum_list[] = {
> > +{ DRM_MODE_CONTENT_PROTECTION_OFF, "Off" },
> > +{ DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
> > +{ DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
> > +};
> > +DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
> > +
> >  /**
> >   * DOC: standard connector properties
> >   *
> > @@ -764,6 +771,34 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
> >   *  after modeset, the kernel driver may set this to "BAD" and issue a
> >   *  hotplug uevent. Drivers should update this value using
> >   *  drm_mode_connector_set_link_status_property().
> > + * Content Protection:
> > + * This property is used by userspace to request the kernel protect future
> > + * content communicated over the link. When requested, kernel will apply
> > + * the appropriate means of protection (most often HDCP), and use the
> > + * property to tell userspace the protection is active.
> > + *
> > + * The value of this property can be one of the following:
> > + *
> > + * - DRM_MODE_CONTENT_PROTECTION_OFF = 0
> > + * The link is not protected, content is transmitted in the clear.
> > + * - DRM_MODE_CONTENT_PROTECTION_DESIRED = 1
> > + * Userspace has requested content protection, but the link is not
> > + * currently protected. When in this state, kernel should enable
> > + * Content Protection as

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

[Daniel Vetter]

On Tue, Dec 05, 2017 at 05:21:25AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Implement HDCP (rev3)
> URL   : https://patchwork.freedesktop.org/series/34671/
> State : failure
> 
> == Summary ==
> 
> Applying: drm: Fix link-status kerneldoc line lengths
> error: Failed to merge in the changes.
> Using index info to reconstruct a base tree...
> M drivers/gpu/drm/drm_connector.c
> Falling back to patching base and 3-way merge...
> Auto-merging drivers/gpu/drm/drm_connector.c
> CONFLICT (content): Merge conflict in drivers/gpu/drm/drm_connector.c
> Patch failed at 0001 drm: Fix link-status kerneldoc line lengths
> The copy of the patch that failed is found in: .git/rebase-apply/patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".

You need to rebase onto drm-tip to appease CI.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] lockdep: Mark up lock disabling with TAINT_CRAP

[Chris Wilson]

When testing with lockdep disabled, if it becomes disabled due to some
error or other that makes subsequenting testing incomplete, it taints
the test result. Make this obvious to the test infrastructure by adding
TAINT_CRAP.

Signed-off-by: Chris Wilson 
Cc: Tomi Sarvela 
Cc: Daniel Vetter 
---
Thoughts? Preferred over parsing lock_stats in addition to kernel/taint?
Downside is that since locks are disabled before oops printing and the
like, we will see TAINT_CRAP on first oops/panic (I think) rather than
subsequent oopses.
-Chris
---
 kernel/panic.c| 4 +++-
 lib/debug_locks.c | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/kernel/panic.c b/kernel/panic.c
index 2cfef408fec9..f4ba13e94be6 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -392,8 +392,10 @@ unsigned long get_taint(void)
  */
 void add_taint(unsigned flag, enum lockdep_ok lockdep_ok)
 {
-   if (lockdep_ok == LOCKDEP_NOW_UNRELIABLE && __debug_locks_off())
+   if (lockdep_ok == LOCKDEP_NOW_UNRELIABLE && __debug_locks_off()) {
pr_warn("Disabling lock debugging due to kernel taint\n");
+   set_bit(TAINT_CRAP, &tainted_mask);
+   }
 
set_bit(flag, &tainted_mask);
 }
diff --git a/lib/debug_locks.c b/lib/debug_locks.c
index 96c4c633d95e..8abe7bb50842 100644
--- a/lib/debug_locks.c
+++ b/lib/debug_locks.c
@@ -38,6 +38,7 @@ EXPORT_SYMBOL_GPL(debug_locks_silent);
 int debug_locks_off(void)
 {
if (__debug_locks_off()) {
+   add_taint(TAINT_CRAP, LOCKDEP_STILL_OK);
if (!debug_locks_silent) {
console_verbose();
return 1;
-- 
2.15.1

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

Re: [Intel-gfx] [PATCH v3 3/9] drm: Add Content Protection property

[Daniel Vetter]

On Tue, Dec 05, 2017 at 12:15:02AM -0500, Sean Paul wrote:
> This patch adds a new optional connector property to allow userspace to enable
> protection over the content it is displaying. This will typically be 
> implemented
> by the driver using HDCP.
> 
> The property is a tri-state with the following values:
> - OFF: Self explanatory, no content protection
> - DESIRED: Userspace requests that the driver enable protection
> - ENABLED: Once the driver has authenticated the link, it sets this value
> 
> The driver is responsible for downgrading ENABLED to DESIRED if the link 
> becomes
> unprotected. The driver should also maintain the desiredness of protection
> across hotplug/dpms/suspend.
> 
> If this looks familiar, I posted [1] this 3 years ago. We have been using this
> in ChromeOS across exynos, mediatek, and rockchip over that time.
> 
> Changes in v2:
>  - Pimp kerneldoc for content_protection_property (Daniel)
>  - Drop sysfs attribute
> Changes in v3:
>  - None
> 
> Cc: Daniel Vetter 
> Signed-off-by: Sean Paul 
> 
> [1] https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.html
> ---
>  drivers/gpu/drm/drm_atomic.c|  8 +
>  drivers/gpu/drm/drm_connector.c | 71 
> +
>  drivers/gpu/drm/drm_sysfs.c |  1 +
>  include/drm/drm_connector.h | 16 ++
>  include/uapi/drm/drm_mode.h |  4 +++
>  5 files changed, 100 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c2da5585e201..676025d755b2 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1196,6 +1196,12 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   state->picture_aspect_ratio = val;
>   } else if (property == connector->scaling_mode_property) {
>   state->scaling_mode = val;
> + } else if (property == connector->content_protection_property) {
> + if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
> + DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
> + return -EINVAL;
> + }
> + state->content_protection = val;
>   } else if (connector->funcs->atomic_set_property) {
>   return connector->funcs->atomic_set_property(connector,
>   state, property, val);
> @@ -1275,6 +1281,8 @@ drm_atomic_connector_get_property(struct drm_connector 
> *connector,
>   *val = state->picture_aspect_ratio;
>   } else if (property == connector->scaling_mode_property) {
>   *val = state->scaling_mode;
> + } else if (property == connector->content_protection_property) {
> + *val = state->content_protection;
>   } else if (connector->funcs->atomic_get_property) {
>   return connector->funcs->atomic_get_property(connector,
>   state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index f14b48e6e839..8626aa8f485e 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -698,6 +698,13 @@ static const struct drm_prop_enum_list 
> drm_tv_subconnector_enum_list[] = {
>  DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>drm_tv_subconnector_enum_list)
>  
> +static struct drm_prop_enum_list drm_cp_enum_list[] = {
> +{ DRM_MODE_CONTENT_PROTECTION_OFF, "Off" },
> +{ DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
> +{ DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
> +};
> +DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
> +
>  /**
>   * DOC: standard connector properties
>   *
> @@ -764,6 +771,34 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>   *  after modeset, the kernel driver may set this to "BAD" and issue a
>   *  hotplug uevent. Drivers should update this value using
>   *  drm_mode_connector_set_link_status_property().
> + * Content Protection:
> + *   This property is used by userspace to request the kernel protect future
> + *   content communicated over the link. When requested, kernel will apply
> + *   the appropriate means of protection (most often HDCP), and use the
> + *   property to tell userspace the protection is active.
> + *
> + *   The value of this property can be one of the following:
> + *
> + *   - DRM_MODE_CONTENT_PROTECTION_OFF = 0
> + *   The link is not protected, content is transmitted in the clear.
> + *   - DRM_MODE_CONTENT_PROTECTION_DESIRED = 1
> + *   Userspace has requested content protection, but the link is not
> + *   currently protected. When in this state, kernel should enable
> + *   Content Protection as soon as possible.
> + *   - DRM_MODE_CONTENT_PROTECTION_ENABLED = 2
> + *   Userspace has requested content protection, and the link is
> + *   protected. Only the driver can set the proper

Re: [Intel-gfx] [PATCH v3 3/9] drm: Add Content Protection property

[Chris Wilson]

Quoting Daniel Vetter (2017-12-05 15:34:36)
> Two bits missing imo:
> - Should explain that userspace should poll this property to detect a
>   change from ENABLED to DESIRED (and take adequate actions and e.g. stop
>   the stream). No uevent will be sent out because the HDCP specs require
>   polling anyway.

What's more polling than poll()? :-p
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 2/2] kms_content_protection: Add Content Protection test

[Sean Paul]

On Tue, Dec 5, 2017 at 3:22 AM, Petri Latvala  wrote:
> On Tue, Dec 05, 2017 at 12:23:33AM -0500, Sean Paul wrote:
>> Pretty simple test:
>> - initializes the output
>> - clears the content protection property
>> - verifies that it clears
>> - sets the content protection property to desired
>> - verifies that it transitions to enabled
>>
>> Does this for both legacy and atomic.
>>
>> Signed-off-by: Sean Paul 
>> ---
>>  lib/igt_kms.c  |   3 +-
>>  lib/igt_kms.h  |   1 +
>>  tests/Makefile.sources |   1 +
>>  tests/kms_content_protection.c | 128 
>> +
>>  tests/meson.build  |   1 +
>>  5 files changed, 133 insertions(+), 1 deletion(-)
>>  create mode 100644 tests/kms_content_protection.c
>>
>> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
>> index 125ecb19..907db694 100644
>> --- a/lib/igt_kms.c
>> +++ b/lib/igt_kms.c
>> @@ -190,7 +190,8 @@ const char 
>> *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
>>   "scaling mode",
>>   "CRTC_ID",
>>   "DPMS",
>> - "Broadcast RGB"
>> + "Broadcast RGB",
>> + "Content Protection"
>>  };
>>
>>  /*
>> diff --git a/lib/igt_kms.h b/lib/igt_kms.h
>> index 2a480bf3..93e59dc7 100644
>> --- a/lib/igt_kms.h
>> +++ b/lib/igt_kms.h
>> @@ -118,6 +118,7 @@ enum igt_atomic_connector_properties {
>> IGT_CONNECTOR_CRTC_ID,
>> IGT_CONNECTOR_DPMS,
>> IGT_CONNECTOR_BROADCAST_RGB,
>> +   IGT_CONNECTOR_CONTENT_PROTECTION,
>> IGT_NUM_CONNECTOR_PROPS
>>  };
>>
>> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
>> index 34ca71a0..e0466411 100644
>> --- a/tests/Makefile.sources
>> +++ b/tests/Makefile.sources
>> @@ -179,6 +179,7 @@ TESTS_progs = \
>>   kms_chv_cursor_fail \
>>   kms_color \
>>   kms_concurrent \
>> + kms_content_protection\
>>   kms_crtc_background_color \
>>   kms_cursor_crc \
>>   kms_cursor_legacy \
>> diff --git a/tests/kms_content_protection.c b/tests/kms_content_protection.c
>> new file mode 100644
>> index ..7bfe9a69
>> --- /dev/null
>> +++ b/tests/kms_content_protection.c
>> @@ -0,0 +1,128 @@
>> +/*
>> + * Copyright © 2017 Google, Inc.
>> + *
>> + * 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"
>> +
>> +IGT_TEST_DESCRIPTION("Test content protection (HDCP)");
>> +
>> +typedef struct {
>> + int drm_fd;
>> + igt_display_t display;
>> +} data_t;
>> +
>> +static bool
>> +wait_for_prop_value(igt_output_t *output, uint64_t expected)
>> +{
>> + uint64_t val;
>> + int i;
>> +
>> + for (i = 0; i < 2000; i++) {
>> + val = igt_output_get_prop(output,
>> +   IGT_CONNECTOR_CONTENT_PROTECTION);
>> + if (val == expected)
>> + return true;
>> + usleep(1000);
>> + }
>> + igt_info("prop_value mismatch %ld != %ld\n", val, expected);
>> + return false;
>> +}
>> +
>> +static void
>> +test_pipe_output(igt_display_t *display, const enum pipe pipe,
>> +  igt_output_t *output, enum igt_commit_style s)
>> +{
>> + drmModeModeInfo mode;
>> + igt_plane_t *primary;
>> + struct igt_fb red;
>> + bool ret;
>> +
>> + igt_assert(kmstest_get_connector_default_mode(
>> + display->drm_fd, output->config.connector, &mode));
>> +
>> + igt_output_override_mode(output, &mode);
>> + igt_output_set_pipe(output, pipe);
>> +
>> + igt_create_color_fb(display->drm_fd, mode.hdisplay, mode.vdisplay,
>> + DRM_FORMAT_XRGB, LOCAL_DRM_FORMAT_MOD_NONE,
>> + 1.f, 0.f, 0.f, &red);
>> + primary = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY);
>> + igt_plane_set_fb(primary, &red);
>> + igt_display_commit2(d

Re: [Intel-gfx] [PATCH i-g-t 2/2] kms_content_protection: Add Content Protection test

[Ville Syrjälä]

On Tue, Dec 05, 2017 at 12:23:33AM -0500, Sean Paul wrote:
> Pretty simple test:
> - initializes the output
> - clears the content protection property
> - verifies that it clears
> - sets the content protection property to desired
> - verifies that it transitions to enabled

Can we get a chamelium based test that actually verfifies
that the other end can correctly decrypt the data?

> 
> Does this for both legacy and atomic.
> 
> Signed-off-by: Sean Paul 
> ---
>  lib/igt_kms.c  |   3 +-
>  lib/igt_kms.h  |   1 +
>  tests/Makefile.sources |   1 +
>  tests/kms_content_protection.c | 128 
> +
>  tests/meson.build  |   1 +
>  5 files changed, 133 insertions(+), 1 deletion(-)
>  create mode 100644 tests/kms_content_protection.c
> 
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index 125ecb19..907db694 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -190,7 +190,8 @@ const char 
> *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
>   "scaling mode",
>   "CRTC_ID",
>   "DPMS",
> - "Broadcast RGB"
> + "Broadcast RGB",
> + "Content Protection"
>  };
>  
>  /*
> diff --git a/lib/igt_kms.h b/lib/igt_kms.h
> index 2a480bf3..93e59dc7 100644
> --- a/lib/igt_kms.h
> +++ b/lib/igt_kms.h
> @@ -118,6 +118,7 @@ enum igt_atomic_connector_properties {
> IGT_CONNECTOR_CRTC_ID,
> IGT_CONNECTOR_DPMS,
> IGT_CONNECTOR_BROADCAST_RGB,
> +   IGT_CONNECTOR_CONTENT_PROTECTION,
> IGT_NUM_CONNECTOR_PROPS
>  };
>  
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 34ca71a0..e0466411 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -179,6 +179,7 @@ TESTS_progs = \
>   kms_chv_cursor_fail \
>   kms_color \
>   kms_concurrent \
> + kms_content_protection\
>   kms_crtc_background_color \
>   kms_cursor_crc \
>   kms_cursor_legacy \
> diff --git a/tests/kms_content_protection.c b/tests/kms_content_protection.c
> new file mode 100644
> index ..7bfe9a69
> --- /dev/null
> +++ b/tests/kms_content_protection.c
> @@ -0,0 +1,128 @@
> +/*
> + * Copyright © 2017 Google, Inc.
> + *
> + * 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"
> +
> +IGT_TEST_DESCRIPTION("Test content protection (HDCP)");
> +
> +typedef struct {
> + int drm_fd;
> + igt_display_t display;
> +} data_t;
> +
> +static bool
> +wait_for_prop_value(igt_output_t *output, uint64_t expected)
> +{
> + uint64_t val;
> + int i;
> +
> + for (i = 0; i < 2000; i++) {
> + val = igt_output_get_prop(output,
> +   IGT_CONNECTOR_CONTENT_PROTECTION);
> + if (val == expected)
> + return true;
> + usleep(1000);
> + }
> + igt_info("prop_value mismatch %ld != %ld\n", val, expected);
> + return false;
> +}
> +
> +static void
> +test_pipe_output(igt_display_t *display, const enum pipe pipe,
> +  igt_output_t *output, enum igt_commit_style s)
> +{
> + drmModeModeInfo mode;
> + igt_plane_t *primary;
> + struct igt_fb red;
> + bool ret;
> +
> + igt_assert(kmstest_get_connector_default_mode(
> + display->drm_fd, output->config.connector, &mode));
> +
> + igt_output_override_mode(output, &mode);
> + igt_output_set_pipe(output, pipe);
> +
> + igt_create_color_fb(display->drm_fd, mode.hdisplay, mode.vdisplay,
> + DRM_FORMAT_XRGB, LOCAL_DRM_FORMAT_MOD_NONE,
> + 1.f, 0.f, 0.f, &red);
> + primary = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY);
> + igt_plane_set_fb(primary, &red);
> + igt_display_commit2(display, s);
> +
> + igt_output_set_prop_value(output, IGT_CONNECTOR_CONTENT_PROTECT

Re: [Intel-gfx] [PATCH i-g-t 2/2] kms_content_protection: Add Content Protection test

[Sean Paul]

On Tue, Dec 5, 2017 at 11:07 AM, Ville Syrjälä
 wrote:
> On Tue, Dec 05, 2017 at 12:23:33AM -0500, Sean Paul wrote:
>> Pretty simple test:
>> - initializes the output
>> - clears the content protection property
>> - verifies that it clears
>> - sets the content protection property to desired
>> - verifies that it transitions to enabled
>
> Can we get a chamelium based test that actually verfifies
> that the other end can correctly decrypt the data?
>

I'm not certain chamelium has HDCP receiver support. I'm guessing it
doesn't, so not until we have that in place.

Sean

>>
>> Does this for both legacy and atomic.
>>
>> Signed-off-by: Sean Paul 
>> ---
>>  lib/igt_kms.c  |   3 +-
>>  lib/igt_kms.h  |   1 +
>>  tests/Makefile.sources |   1 +
>>  tests/kms_content_protection.c | 128 
>> +
>>  tests/meson.build  |   1 +
>>  5 files changed, 133 insertions(+), 1 deletion(-)
>>  create mode 100644 tests/kms_content_protection.c
>>
>> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
>> index 125ecb19..907db694 100644
>> --- a/lib/igt_kms.c
>> +++ b/lib/igt_kms.c
>> @@ -190,7 +190,8 @@ const char 
>> *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
>>   "scaling mode",
>>   "CRTC_ID",
>>   "DPMS",
>> - "Broadcast RGB"
>> + "Broadcast RGB",
>> + "Content Protection"
>>  };
>>
>>  /*
>> diff --git a/lib/igt_kms.h b/lib/igt_kms.h
>> index 2a480bf3..93e59dc7 100644
>> --- a/lib/igt_kms.h
>> +++ b/lib/igt_kms.h
>> @@ -118,6 +118,7 @@ enum igt_atomic_connector_properties {
>> IGT_CONNECTOR_CRTC_ID,
>> IGT_CONNECTOR_DPMS,
>> IGT_CONNECTOR_BROADCAST_RGB,
>> +   IGT_CONNECTOR_CONTENT_PROTECTION,
>> IGT_NUM_CONNECTOR_PROPS
>>  };
>>
>> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
>> index 34ca71a0..e0466411 100644
>> --- a/tests/Makefile.sources
>> +++ b/tests/Makefile.sources
>> @@ -179,6 +179,7 @@ TESTS_progs = \
>>   kms_chv_cursor_fail \
>>   kms_color \
>>   kms_concurrent \
>> + kms_content_protection\
>>   kms_crtc_background_color \
>>   kms_cursor_crc \
>>   kms_cursor_legacy \
>> diff --git a/tests/kms_content_protection.c b/tests/kms_content_protection.c
>> new file mode 100644
>> index ..7bfe9a69
>> --- /dev/null
>> +++ b/tests/kms_content_protection.c
>> @@ -0,0 +1,128 @@
>> +/*
>> + * Copyright © 2017 Google, Inc.
>> + *
>> + * 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"
>> +
>> +IGT_TEST_DESCRIPTION("Test content protection (HDCP)");
>> +
>> +typedef struct {
>> + int drm_fd;
>> + igt_display_t display;
>> +} data_t;
>> +
>> +static bool
>> +wait_for_prop_value(igt_output_t *output, uint64_t expected)
>> +{
>> + uint64_t val;
>> + int i;
>> +
>> + for (i = 0; i < 2000; i++) {
>> + val = igt_output_get_prop(output,
>> +   IGT_CONNECTOR_CONTENT_PROTECTION);
>> + if (val == expected)
>> + return true;
>> + usleep(1000);
>> + }
>> + igt_info("prop_value mismatch %ld != %ld\n", val, expected);
>> + return false;
>> +}
>> +
>> +static void
>> +test_pipe_output(igt_display_t *display, const enum pipe pipe,
>> +  igt_output_t *output, enum igt_commit_style s)
>> +{
>> + drmModeModeInfo mode;
>> + igt_plane_t *primary;
>> + struct igt_fb red;
>> + bool ret;
>> +
>> + igt_assert(kmstest_get_connector_default_mode(
>> + display->drm_fd, output->config.connector, &mode));
>> +
>> + igt_output_override_mode(output, &mode);
>> + igt_output_set_pipe(output, pipe);
>> +
>> + igt_create_color_fb(display->drm_fd, mode.hdisplay, mode.vdisplay,
>> + DRM_FORMA

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Put all non-blocking modesets onto an ordered wq

[Patchwork]

== Series Details ==

Series: drm/i915: Put all non-blocking modesets onto an ordered wq
URL   : https://patchwork.freedesktop.org/series/33712/
State : success

== Summary ==

Series 33712v1 drm/i915: Put all non-blocking modesets onto an ordered wq
https://patchwork.freedesktop.org/api/1.0/series/33712/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> PASS   (fi-elk-e7500) fdo#103989 +1
dmesg-warn -> PASS   (fi-bdw-gvtdvm) fdo#103938 +1

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:445s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:445s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:385s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:523s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:505s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:504s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:484s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:476s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:269s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:542s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:367s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:258s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:392s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:450s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:489s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:527s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:534s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:589s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:448s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:539s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:517s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:494s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:549s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:416s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:605s
fi-cnl-y total:281  pass:255  dwarn:0   dfail:0   fail:0   skip:25 
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:488s

0d0fe916f52ad8f05dddab384ae7c90bb62ebac4 drm-tip: 2017y-12m-05d-14h-52m-17s UTC 
integration manifest
8d1afc151847 drm/i915: Put all non-blocking modesets onto an ordered wq

== Logs ==

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

[Intel-gfx] [PATCH v3 1/8] drm/i915/huc: Move firmware selection to init_early

[Michal Wajdeczko]

Doing HuC firmware path selection from sanitize_options function
is not perfect, while there is no problem with doing so during
early init stage as we already have all needed data.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h  |  3 ++
 drivers/gpu/drm/i915/intel_huc.c | 60 +---
 drivers/gpu/drm/i915/intel_huc.h |  2 +-
 drivers/gpu/drm/i915/intel_uc.c  |  4 +--
 4 files changed, 42 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 594fd14..bd4eea5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3234,6 +3234,9 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define HAS_GUC_CT(dev_priv)   ((dev_priv)->info.has_guc_ct)
 #define HAS_GUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
 #define HAS_GUC_SCHED(dev_priv)(HAS_GUC(dev_priv))
+
+/* For now, anything with a GuC has also HuC */
+#define HAS_HUC(dev_priv)  (HAS_GUC(dev_priv))
 #define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
 
 #define HAS_RESOURCE_STREAMER(dev_priv) 
((dev_priv)->info.has_resource_streamer)
diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index 98d1725..6d0e050 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -77,43 +77,57 @@ MODULE_FIRMWARE(I915_KBL_HUC_UCODE);
 #define I915_GLK_HUC_UCODE HUC_FW_PATH(glk, GLK_HUC_FW_MAJOR, \
GLK_HUC_FW_MINOR, GLK_BLD_NUM)
 
-/**
- * intel_huc_select_fw() - selects HuC firmware for loading
- * @huc:   intel_huc struct
- */
-void intel_huc_select_fw(struct intel_huc *huc)
+static void huc_fw_select(struct intel_uc_fw *huc_fw)
 {
+   struct intel_huc *huc = container_of(huc_fw, struct intel_huc, fw);
struct drm_i915_private *dev_priv = huc_to_i915(huc);
 
-   intel_uc_fw_init(&huc->fw, INTEL_UC_FW_TYPE_HUC);
+   GEM_BUG_ON(huc_fw->type != INTEL_UC_FW_TYPE_HUC);
+
+   if (!HAS_HUC(dev_priv))
+   return;
 
if (i915_modparams.huc_firmware_path) {
-   huc->fw.path = i915_modparams.huc_firmware_path;
-   huc->fw.major_ver_wanted = 0;
-   huc->fw.minor_ver_wanted = 0;
+   huc_fw->path = i915_modparams.huc_firmware_path;
+   huc_fw->major_ver_wanted = 0;
+   huc_fw->minor_ver_wanted = 0;
} else if (IS_SKYLAKE(dev_priv)) {
-   huc->fw.path = I915_SKL_HUC_UCODE;
-   huc->fw.major_ver_wanted = SKL_HUC_FW_MAJOR;
-   huc->fw.minor_ver_wanted = SKL_HUC_FW_MINOR;
+   huc_fw->path = I915_SKL_HUC_UCODE;
+   huc_fw->major_ver_wanted = SKL_HUC_FW_MAJOR;
+   huc_fw->minor_ver_wanted = SKL_HUC_FW_MINOR;
} else if (IS_BROXTON(dev_priv)) {
-   huc->fw.path = I915_BXT_HUC_UCODE;
-   huc->fw.major_ver_wanted = BXT_HUC_FW_MAJOR;
-   huc->fw.minor_ver_wanted = BXT_HUC_FW_MINOR;
+   huc_fw->path = I915_BXT_HUC_UCODE;
+   huc_fw->major_ver_wanted = BXT_HUC_FW_MAJOR;
+   huc_fw->minor_ver_wanted = BXT_HUC_FW_MINOR;
} else if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) {
-   huc->fw.path = I915_KBL_HUC_UCODE;
-   huc->fw.major_ver_wanted = KBL_HUC_FW_MAJOR;
-   huc->fw.minor_ver_wanted = KBL_HUC_FW_MINOR;
+   huc_fw->path = I915_KBL_HUC_UCODE;
+   huc_fw->major_ver_wanted = KBL_HUC_FW_MAJOR;
+   huc_fw->minor_ver_wanted = KBL_HUC_FW_MINOR;
} else if (IS_GEMINILAKE(dev_priv)) {
-   huc->fw.path = I915_GLK_HUC_UCODE;
-   huc->fw.major_ver_wanted = GLK_HUC_FW_MAJOR;
-   huc->fw.minor_ver_wanted = GLK_HUC_FW_MINOR;
+   huc_fw->path = I915_GLK_HUC_UCODE;
+   huc_fw->major_ver_wanted = GLK_HUC_FW_MAJOR;
+   huc_fw->minor_ver_wanted = GLK_HUC_FW_MINOR;
} else {
-   DRM_ERROR("No HuC firmware known for platform with HuC!\n");
-   return;
+   DRM_WARN("%s: No firmware known for this platform!\n",
+intel_uc_fw_type_repr(huc_fw->type));
}
 }
 
 /**
+ * intel_huc_init_early() - initializes HuC struct
+ * @huc: intel_huc struct
+ *
+ * On platforms with HuC selects firmware for uploading
+ */
+void intel_huc_init_early(struct intel_huc *huc)
+{
+   struct intel_uc_fw *huc_fw = &huc->fw;
+
+   intel_uc_fw_init(huc_fw, INTEL_UC_FW_TYPE_HUC);
+   huc_fw_select(huc_fw);
+}
+
+/**
  * huc_ucode_xfer() - DMA's the firmware
  * @dev_priv: the drm_i915_private device
  *
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index aaa38b9..3d757bc 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -34,7 +34,7 @@ st

[Intel-gfx] [PATCH v3 2/8] drm/i915/guc: Move firmware selection to init_early

[Michal Wajdeczko]

Doing GuC firmware path selection from sanitize_options function
is not perfect, while there is no problem with doing so during
early init stage as we already have all needed data.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_guc.c|  1 +
 drivers/gpu/drm/i915/intel_guc_fw.c | 63 +
 drivers/gpu/drm/i915/intel_guc_fw.h |  2 +-
 drivers/gpu/drm/i915/intel_uc.c |  2 +-
 drivers/gpu/drm/i915/intel_uc_fw.h  |  5 +++
 5 files changed, 44 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index d08e760..df86907 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -61,6 +61,7 @@ void intel_guc_init_send_regs(struct intel_guc *guc)
 
 void intel_guc_init_early(struct intel_guc *guc)
 {
+   intel_guc_fw_init_early(guc);
intel_guc_ct_init_early(&guc->ct);
 
mutex_init(&guc->send_mutex);
diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c 
b/drivers/gpu/drm/i915/intel_guc_fw.c
index 89862fa..cbc51c9 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -56,45 +56,54 @@ MODULE_FIRMWARE(I915_KBL_GUC_UCODE);
 
 #define I915_GLK_GUC_UCODE GUC_FW_PATH(glk, GLK_FW_MAJOR, GLK_FW_MINOR)
 
-/**
- * intel_guc_fw_select() - selects GuC firmware for uploading
- *
- * @guc:   intel_guc struct
- *
- * Return: zero when we know firmware, non-zero in other case
- */
-int intel_guc_fw_select(struct intel_guc *guc)
+static void guc_fw_select(struct intel_uc_fw *guc_fw)
 {
+   struct intel_guc *guc = container_of(guc_fw, struct intel_guc, fw);
struct drm_i915_private *dev_priv = guc_to_i915(guc);
 
-   intel_uc_fw_init(&guc->fw, INTEL_UC_FW_TYPE_GUC);
+   GEM_BUG_ON(guc_fw->type != INTEL_UC_FW_TYPE_GUC);
+
+   if (!HAS_GUC(dev_priv))
+   return;
 
if (i915_modparams.guc_firmware_path) {
-   guc->fw.path = i915_modparams.guc_firmware_path;
-   guc->fw.major_ver_wanted = 0;
-   guc->fw.minor_ver_wanted = 0;
+   guc_fw->path = i915_modparams.guc_firmware_path;
+   guc_fw->major_ver_wanted = 0;
+   guc_fw->minor_ver_wanted = 0;
} else if (IS_SKYLAKE(dev_priv)) {
-   guc->fw.path = I915_SKL_GUC_UCODE;
-   guc->fw.major_ver_wanted = SKL_FW_MAJOR;
-   guc->fw.minor_ver_wanted = SKL_FW_MINOR;
+   guc_fw->path = I915_SKL_GUC_UCODE;
+   guc_fw->major_ver_wanted = SKL_FW_MAJOR;
+   guc_fw->minor_ver_wanted = SKL_FW_MINOR;
} else if (IS_BROXTON(dev_priv)) {
-   guc->fw.path = I915_BXT_GUC_UCODE;
-   guc->fw.major_ver_wanted = BXT_FW_MAJOR;
-   guc->fw.minor_ver_wanted = BXT_FW_MINOR;
+   guc_fw->path = I915_BXT_GUC_UCODE;
+   guc_fw->major_ver_wanted = BXT_FW_MAJOR;
+   guc_fw->minor_ver_wanted = BXT_FW_MINOR;
} else if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) {
-   guc->fw.path = I915_KBL_GUC_UCODE;
-   guc->fw.major_ver_wanted = KBL_FW_MAJOR;
-   guc->fw.minor_ver_wanted = KBL_FW_MINOR;
+   guc_fw->path = I915_KBL_GUC_UCODE;
+   guc_fw->major_ver_wanted = KBL_FW_MAJOR;
+   guc_fw->minor_ver_wanted = KBL_FW_MINOR;
} else if (IS_GEMINILAKE(dev_priv)) {
-   guc->fw.path = I915_GLK_GUC_UCODE;
-   guc->fw.major_ver_wanted = GLK_FW_MAJOR;
-   guc->fw.minor_ver_wanted = GLK_FW_MINOR;
+   guc_fw->path = I915_GLK_GUC_UCODE;
+   guc_fw->major_ver_wanted = GLK_FW_MAJOR;
+   guc_fw->minor_ver_wanted = GLK_FW_MINOR;
} else {
-   DRM_ERROR("No GuC firmware known for platform with GuC!\n");
-   return -ENOENT;
+   DRM_WARN("%s: No firmware known for this platform!\n",
+intel_uc_fw_type_repr(guc_fw->type));
}
+}
 
-   return 0;
+/**
+ * intel_guc_fw_init_early() - initializes GuC firmware struct
+ * @guc: intel_guc struct
+ *
+ * On platforms with GuC selects firmware for uploading
+ */
+void intel_guc_fw_init_early(struct intel_guc *guc)
+{
+   struct intel_uc_fw *guc_fw = &guc->fw;
+
+   intel_uc_fw_init(guc_fw, INTEL_UC_FW_TYPE_GUC);
+   guc_fw_select(guc_fw);
 }
 
 static void guc_prepare_xfer(struct intel_guc *guc)
diff --git a/drivers/gpu/drm/i915/intel_guc_fw.h 
b/drivers/gpu/drm/i915/intel_guc_fw.h
index 023f5ba..4ec5d3d 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.h
+++ b/drivers/gpu/drm/i915/intel_guc_fw.h
@@ -27,7 +27,7 @@
 
 struct intel_guc;
 
-int intel_guc_fw_select(struct intel_guc *guc);
+void intel_guc_fw_init_early(struct intel_guc *guc);
 int intel_guc_fw_upload(struct intel_guc *guc);
 
 #endif
diff --git a

[Intel-gfx] [PATCH v3 4/8] drm/i915/uc: Don't fetch GuC firmware if no plan to use GuC

[Michal Wajdeczko]

If we don't plan to use GuC then we should not try to fetch GuC and
HuC firmwares. We can save memory and avoid possible dmesg noise.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_uc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index ed2dd76..c3981aa 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -86,12 +86,18 @@ void intel_uc_init_early(struct drm_i915_private *dev_priv)
 
 void intel_uc_init_fw(struct drm_i915_private *dev_priv)
 {
+   if (!USES_GUC(dev_priv))
+   return;
+
intel_uc_fw_fetch(dev_priv, &dev_priv->huc.fw);
intel_uc_fw_fetch(dev_priv, &dev_priv->guc.fw);
 }
 
 void intel_uc_fini_fw(struct drm_i915_private *dev_priv)
 {
+   if (!USES_GUC(dev_priv))
+   return;
+
intel_uc_fw_fini(&dev_priv->guc.fw);
intel_uc_fw_fini(&dev_priv->huc.fw);
 }
-- 
2.7.4

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

[Intel-gfx] [PATCH v3 6/8] drm/i915/guc: Combine enable_guc_loading|submission modparams

[Michal Wajdeczko]

We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1. We also need
loading=1 when we want to want to load and verify the HuC.

Lets combine above module parameters into one "enable_guc"
modparam. New supported bit values are:

 0=disable GuC (no GuC submission, no HuC)
 1=enable GuC submission
 2=enable HuC load

Special value "-1" can be used to let driver decide what
option should be enabled for given platform based on
hardware/firmware availability or preference.

Explicit enabling any of the GuC features makes GuC load
a required step, fallback to non-GuC mode will not be
supported.

v2: Don't use -EIO
v3: define modparam bits (Chris)

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 
---
 drivers/gpu/drm/i915/i915_drv.h|   5 +-
 drivers/gpu/drm/i915/i915_params.c |  11 ++--
 drivers/gpu/drm/i915/i915_params.h |   7 ++-
 drivers/gpu/drm/i915/intel_uc.c| 109 ++---
 drivers/gpu/drm/i915/intel_uc.h|  19 +++
 5 files changed, 96 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 937fa02..02551c7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3240,8 +3240,9 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
 
 /* Having a GuC is not the same as using a GuC */
-#define USES_GUC(dev_priv) (i915_modparams.enable_guc_loading)
-#define USES_GUC_SUBMISSION(dev_priv)  (i915_modparams.enable_guc_submission)
+#define USES_GUC(dev_priv) intel_uc_is_using_guc()
+#define USES_GUC_SUBMISSION(dev_priv)  intel_uc_is_using_guc_submission()
+#define USES_HUC(dev_priv) intel_uc_is_using_huc()
 
 #define HAS_RESOURCE_STREAMER(dev_priv) 
((dev_priv)->info.has_resource_streamer)
 
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 7bc5386..8dfea03 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -147,13 +147,10 @@ i915_param_named_unsafe(edp_vswing, int, 0400,
"(0=use value from vbt [default], 1=low power swing(200mV),"
"2=default swing(400mV))");
 
-i915_param_named_unsafe(enable_guc_loading, int, 0400,
-   "Enable GuC firmware loading "
-   "(-1=auto, 0=never [default], 1=if available, 2=required)");
-
-i915_param_named_unsafe(enable_guc_submission, int, 0400,
-   "Enable GuC submission "
-   "(-1=auto, 0=never [default], 1=if available, 2=required)");
+i915_param_named_unsafe(enable_guc, int, 0400,
+   "Enable GuC load for GuC submission and/or HuC load. "
+   "Required functionality can be selected using bitmask values. "
+   "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)");
 
 i915_param_named(guc_log_level, int, 0400,
"GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index c48c88b..792ce26 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -25,8 +25,12 @@
 #ifndef _I915_PARAMS_H_
 #define _I915_PARAMS_H_
 
+#include 
 #include  /* for __read_mostly */
 
+#define ENABLE_GUC_SUBMISSION  BIT(0)
+#define ENABLE_GUC_LOAD_HUCBIT(1)
+
 #define I915_PARAMS_FOR_EACH(param) \
param(char *, vbt_firmware, NULL) \
param(int, modeset, -1) \
@@ -41,8 +45,7 @@
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc_loading, 0) \
-   param(int, enable_guc_submission, 0) \
+   param(int, enable_guc, 0) \
param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index c3981aa..7dfc7e0 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -47,35 +47,65 @@ static int __intel_uc_reset_hw(struct drm_i915_private 
*dev_priv)
return ret;
 }
 
-void intel_uc_sanitize_options(struct drm_i915_private *dev_priv)
+static int __get_platform_enable_guc(struct drm_i915_private *dev_priv)
 {
-   if (!HAS_GUC(dev_priv)) {
-   if (i915_modparams.enable_guc_loading > 0 ||
-   i915_modparams.enable_guc_submission > 0)
-   DRM_INFO("Ignoring GuC options, no hardware\n");
+   struct intel_uc_fw *guc_fw = &dev_priv->guc.fw;
+   struct intel_uc_fw *huc_fw = &dev_priv->huc.fw;
+   int enable_guc = 0;
 
-   i915_modparams.enable_guc_loading = 0;
-   i915_modparams.enable_guc_submission = 0;
-   return;
-   }
+   

[Intel-gfx] [PATCH v3 8/8] HAX enable GuC/HuC load

[Michal Wajdeczko]

Also revert ("drm/i915/guc: Assert that we switch between
known ggtt->invalidate functions")

v2: don't enable GuC on GLK

Signed-off-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++--
 drivers/gpu/drm/i915/i915_params.h  | 2 +-
 drivers/gpu/drm/i915/intel_uc.c | 2 ++
 3 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 209bb11..a5e75a3 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3590,17 +3590,13 @@ int i915_ggtt_enable_hw(struct drm_i915_private 
*dev_priv)
 
 void i915_ggtt_enable_guc(struct drm_i915_private *i915)
 {
-   GEM_BUG_ON(i915->ggtt.invalidate != gen6_ggtt_invalidate);
-
i915->ggtt.invalidate = guc_ggtt_invalidate;
 }
 
 void i915_ggtt_disable_guc(struct drm_i915_private *i915)
 {
-   /* We should only be called after i915_ggtt_enable_guc() */
-   GEM_BUG_ON(i915->ggtt.invalidate != guc_ggtt_invalidate);
-
-   i915->ggtt.invalidate = gen6_ggtt_invalidate;
+   if (i915->ggtt.invalidate == guc_ggtt_invalidate)
+   i915->ggtt.invalidate = gen6_ggtt_invalidate;
 }
 
 void i915_gem_restore_gtt_mappings(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 792ce26..9725c5a 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -45,7 +45,7 @@
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 49bccc9..22b0afe 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -60,6 +60,8 @@ static int __get_platform_enable_guc(struct drm_i915_private 
*dev_priv)
enable_guc |= ENABLE_GUC_LOAD_HUC;
 
/* Any platform specific fine-tuning can be done here */
+   if (IS_GEMINILAKE(dev_priv))
+   enable_guc = 0; /* no firmware on CI machines */
 
return enable_guc;
 }
-- 
2.7.4

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

[Intel-gfx] [PATCH v3 5/8] drm/i915/uc: Don't use -EIO to report missing firmware

[Michal Wajdeczko]

-EIO has special meaning and is used when we want to allow
engine initialization to fail and mark GPU as wedged.

However here at this function we should return error code
that corresponds to upload status only, as any decision how
to handle missing firmware should be done higher level function
(silent fallback to non-GuC mode, fail into wedged mode, or
abort driver load with fatal error).

v2: commit message update (Michal)

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_uc_fw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_uc_fw.c 
b/drivers/gpu/drm/i915/intel_uc_fw.c
index b376dd3..784eff9 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/intel_uc_fw.c
@@ -214,7 +214,7 @@ int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,
 intel_uc_fw_type_repr(uc_fw->type), uc_fw->path);
 
if (uc_fw->fetch_status != INTEL_UC_FIRMWARE_SUCCESS)
-   return -EIO;
+   return -ENOEXEC;
 
uc_fw->load_status = INTEL_UC_FIRMWARE_PENDING;
DRM_DEBUG_DRIVER("%s fw load %s\n",
-- 
2.7.4

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

[Intel-gfx] [PATCH v3 3/8] drm/i915/guc: Introduce USES_GUC_xxx helper macros

[Michal Wajdeczko]

In the upcoming patch we will change the way how to recognize
when GuC is in use. Using helper macros will minimize scope
of that changes. While here, update dev_info message.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h|  4 
 drivers/gpu/drm/i915/i915_gem_context.c|  4 ++--
 drivers/gpu/drm/i915/i915_gem_gtt.c|  2 +-
 drivers/gpu/drm/i915/i915_irq.c|  2 +-
 drivers/gpu/drm/i915/intel_guc.c   |  2 +-
 drivers/gpu/drm/i915/intel_guc_log.c   |  6 +++---
 drivers/gpu/drm/i915/intel_gvt.c   |  2 +-
 drivers/gpu/drm/i915/intel_uc.c| 23 +++
 drivers/gpu/drm/i915/selftests/intel_guc.c |  2 +-
 9 files changed, 25 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bd4eea5..937fa02 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3239,6 +3239,10 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define HAS_HUC(dev_priv)  (HAS_GUC(dev_priv))
 #define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
 
+/* Having a GuC is not the same as using a GuC */
+#define USES_GUC(dev_priv) (i915_modparams.enable_guc_loading)
+#define USES_GUC_SUBMISSION(dev_priv)  (i915_modparams.enable_guc_submission)
+
 #define HAS_RESOURCE_STREAMER(dev_priv) 
((dev_priv)->info.has_resource_streamer)
 
 #define HAS_POOLED_EU(dev_priv)((dev_priv)->info.has_pooled_eu)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index ce3139e..21ce374 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -316,7 +316,7 @@ __create_hw_context(struct drm_i915_private *dev_priv,
 * present or not in use we still need a small bias as ring wraparound
 * at offset 0 sometimes hangs. No idea why.
 */
-   if (HAS_GUC(dev_priv) && i915_modparams.enable_guc_loading)
+   if (USES_GUC(dev_priv))
ctx->ggtt_offset_bias = GUC_WOPCM_TOP;
else
ctx->ggtt_offset_bias = I915_GTT_PAGE_SIZE;
@@ -409,7 +409,7 @@ i915_gem_context_create_gvt(struct drm_device *dev)
i915_gem_context_set_closed(ctx); /* not user accessible */
i915_gem_context_clear_bannable(ctx);
i915_gem_context_set_force_single_submission(ctx);
-   if (!i915_modparams.enable_guc_submission)
+   if (!USES_GUC_SUBMISSION(to_i915(dev)))
ctx->ring_size = 512 * PAGE_SIZE; /* Max ring buffer size */
 
GEM_BUG_ON(i915_gem_context_is_kernel(ctx));
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index f3c35e8..209bb11 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3503,7 +3503,7 @@ int i915_ggtt_probe_hw(struct drm_i915_private *dev_priv)
 * currently don't have any bits spare to pass in this upper
 * restriction!
 */
-   if (HAS_GUC(dev_priv) && i915_modparams.enable_guc_loading) {
+   if (USES_GUC(dev_priv)) {
ggtt->base.total = min_t(u64, ggtt->base.total, GUC_GGTT_TOP);
ggtt->mappable_end = min(ggtt->mappable_end, ggtt->base.total);
}
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7cac07d..3517c65 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1400,7 +1400,7 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 
iir, int test_shift)
 
if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) {
notify_ring(engine);
-   tasklet |= i915_modparams.enable_guc_submission;
+   tasklet |= USES_GUC_SUBMISSION(engine->i915);
}
 
if (tasklet)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index df86907..177ee69 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -129,7 +129,7 @@ void intel_guc_init_params(struct intel_guc *guc)
}
 
/* If GuC submission is enabled, set up additional parameters here */
-   if (i915_modparams.enable_guc_submission) {
+   if (USES_GUC_SUBMISSION(dev_priv)) {
u32 ads = guc_ggtt_offset(guc->ads_vma) >> PAGE_SHIFT;
u32 pgs = guc_ggtt_offset(dev_priv->guc.stage_desc_pool);
u32 ctx_in_16 = GUC_MAX_STAGE_DESCRIPTORS / 16;
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 76d3eb1..1a2c5ee 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -505,7 +505,7 @@ static void guc_flush_logs(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
 
-   if (!i915_modparams.enable_guc_submission ||
+   

[Intel-gfx] [PATCH v3 7/8] drm/i915/huc: Load HuC only if requested

[Michal Wajdeczko]

Our new "enable_guc" modparam allows to control whenever HuC
should be loaded. However existing code will try load and
authenticate HuC always when we use the GuC. This patch is
trying to enforce modparam selection.

v2: no need to cast PTR_ERR (Chris)
fetch/fini only if required (Michal)
fix wrong break (Sagar)

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_huc.c | 21 +++--
 drivers/gpu/drm/i915/intel_huc.h |  4 ++--
 drivers/gpu/drm/i915/intel_uc.c  | 25 +
 3 files changed, 34 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index 6d0e050..974be3d 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -181,17 +181,17 @@ static int huc_ucode_xfer(struct intel_uc_fw *huc_fw, 
struct i915_vma *vma)
  * intel_huc_init_hw() - load HuC uCode to device
  * @huc: intel_huc structure
  *
- * Called from guc_setup() during driver loading and also after a GPU reset.
- * Be note that HuC loading must be done before GuC loading.
+ * Called from intel_uc_init_hw() during driver loading and also after a GPU
+ * reset. Be note that HuC loading must be done before GuC loading.
  *
  * The firmware image should have already been fetched into memory by the
- * earlier call to intel_huc_init(), so here we need only check that
+ * earlier call to intel_uc_init_fw(), so here we need only check that
  * is succeeded, and then transfer the image to the h/w.
  *
  */
-void intel_huc_init_hw(struct intel_huc *huc)
+int intel_huc_init_hw(struct intel_huc *huc)
 {
-   intel_uc_fw_upload(&huc->fw, huc_ucode_xfer);
+   return intel_uc_fw_upload(&huc->fw, huc_ucode_xfer);
 }
 
 /**
@@ -205,7 +205,7 @@ void intel_huc_init_hw(struct intel_huc *huc)
  * signature through intel_guc_auth_huc(). It then waits for 50ms for
  * firmware verification ACK and unpins the object.
  */
-void intel_huc_auth(struct intel_huc *huc)
+int intel_huc_auth(struct intel_huc *huc)
 {
struct drm_i915_private *i915 = huc_to_i915(huc);
struct intel_guc *guc = &i915->guc;
@@ -213,14 +213,14 @@ void intel_huc_auth(struct intel_huc *huc)
int ret;
 
if (huc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
-   return;
+   return -ENOEXEC;
 
vma = i915_gem_object_ggtt_pin(huc->fw.obj, NULL, 0, 0,
PIN_OFFSET_BIAS | GUC_WOPCM_TOP);
if (IS_ERR(vma)) {
-   DRM_ERROR("failed to pin huc fw object %d\n",
-   (int)PTR_ERR(vma));
-   return;
+   ret = PTR_ERR(vma);
+   DRM_ERROR("HuC: Failed to pin huc fw object %d\n", ret);
+   return ret;
}
 
ret = intel_guc_auth_huc(guc,
@@ -243,4 +243,5 @@ void intel_huc_auth(struct intel_huc *huc)
 
 out:
i915_vma_unpin(vma);
+   return ret;
 }
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index 3d757bc..40039db 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -35,7 +35,7 @@ struct intel_huc {
 };
 
 void intel_huc_init_early(struct intel_huc *huc);
-void intel_huc_init_hw(struct intel_huc *huc);
-void intel_huc_auth(struct intel_huc *huc);
+int intel_huc_init_hw(struct intel_huc *huc);
+int intel_huc_auth(struct intel_huc *huc);
 
 #endif
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 7dfc7e0..49bccc9 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -119,7 +119,9 @@ void intel_uc_init_fw(struct drm_i915_private *dev_priv)
if (!USES_GUC(dev_priv))
return;
 
-   intel_uc_fw_fetch(dev_priv, &dev_priv->huc.fw);
+   if (USES_HUC(dev_priv))
+   intel_uc_fw_fetch(dev_priv, &dev_priv->huc.fw);
+
intel_uc_fw_fetch(dev_priv, &dev_priv->guc.fw);
 }
 
@@ -129,7 +131,9 @@ void intel_uc_fini_fw(struct drm_i915_private *dev_priv)
return;
 
intel_uc_fw_fini(&dev_priv->guc.fw);
-   intel_uc_fw_fini(&dev_priv->huc.fw);
+
+   if (USES_HUC(dev_priv))
+   intel_uc_fw_fini(&dev_priv->huc.fw);
 }
 
 /**
@@ -186,6 +190,7 @@ static void guc_disable_communication(struct intel_guc *guc)
 int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 {
struct intel_guc *guc = &dev_priv->guc;
+   struct intel_huc *huc = &dev_priv->huc;
int ret, attempts;
 
if (!USES_GUC(dev_priv))
@@ -233,7 +238,12 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
if (ret)
goto err_submission;
 
-   intel_huc_init_hw(&dev_priv->huc);
+   if (USES_HUC(dev_priv)) {
+   ret = intel_huc_init_hw(huc);
+   if (ret)
+   goto err_submission;
+   

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] drm/i915: Flush pending GTT writes before unbinding (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Flush pending GTT writes before 
unbinding (rev2)
URL   : https://patchwork.freedesktop.org/series/34900/
State : warning

== Summary ==

Test kms_draw_crc:
Subgroup draw-method-xrgb2101010-mmap-wc-untiled:
pass   -> SKIP   (shard-hsw)
Test kms_cursor_legacy:
Subgroup long-nonblocking-modeset-vs-cursor-atomic:
skip   -> PASS   (shard-snb)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-indfb-draw-mmap-wc:
skip   -> PASS   (shard-snb)
Test drv_selftest:
Subgroup mock_sanitycheck:
dmesg-warn -> PASS   (shard-hsw) fdo#102707
Test kms_atomic:
Subgroup crtc_invalid_params_fence:
pass   -> SKIP   (shard-snb)
Test kms_universal_plane:
Subgroup universal-plane-pipe-b-functional:
pass   -> SKIP   (shard-snb)
Test drv_module_reload:
Subgroup basic-reload-inject:
pass   -> DMESG-WARN (shard-hsw) fdo#103706
Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252 +1
Test kms_flip:
Subgroup flip-vs-modeset-interruptible:
pass   -> DMESG-WARN (shard-hsw) fdo#102614
Subgroup plain-flip-ts-check-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-a-planes:
pass   -> INCOMPLETE (shard-hsw) fdo#103540

fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#103706 https://bugs.freedesktop.org/show_bug.cgi?id=103706
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540

shard-hswtotal:2645 pass:1516 dwarn:3   dfail:0   fail:12  skip:1113 
time:9265s
shard-snbtotal:2612 pass:1272 dwarn:1   dfail:0   fail:10  skip:1328 
time:7815s
Blacklisted hosts:
shard-apltotal:2590 pass:1613 dwarn:3   dfail:0   fail:21  skip:951 
time:13083s

== Logs ==

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Taint (TAINT_DIE) the kernel if the GPU reset fails

[Chris Wilson]

Quoting Joonas Lahtinen (2017-12-04 13:41:11)
> On Wed, 2017-11-29 at 14:05 +, Chris Wilson wrote:
> > History tells us that if we cannot reset the GPU now, we never will. This
> > then impacts everything that is run subsequently. On failing the reset,
> > we mark the driver as wedged, trying to prevent further execution on the
> > GPU, forcing userspace to fallback to using the CPU to update its
> > framebuffers and let the user know what happened.
> > 
> > We also want to go one step further and add a taint to the kernel so that
> > any subsequent faults can be traced back to this failure. This is
> > important for igt, where if the GPU/driver fails we want to reboot and
> > restart testing rather than continue on into oblivion.
> > 
> > TAINT_DIE is colloquially known as "system on fire", which seems
> > appropriate for unresponsive hardware.
> > 
> > v2: Also taint if the recovery fails (again history shows us that is
> > typically fatal).
> > 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=103514
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> > Cc: Daniel Vetter 
> > Cc: Michał Winiarski 
> 
> 
> 
> > @@ -1951,6 +1954,19 @@ void i915_reset(struct drm_i915_private *i915, 
> > unsigned int flags)
> >   wake_up_bit(&error->flags, I915_RESET_HANDOFF);
> >   return;
> >  
> > +taint:
> > + /*
> > +  * History tells us that if we cannot reset the GPU now, we
> > +  * never will. This then impacts everything that is run
> > +  * subsequently. On failing the reset, we mark the driver
> > +  * as wedged, preventing further execution on the GPU.
> > +  * We also want to go one step further and add a taint to the
> > +  * kernel so that any subsequent faults can be traced back to
> > +  * this failure. This is important for igt, where if the
> > +  * GPU/driver fails we want to reboot and restart testing
> > +  * rather than continue on into oblivion.
> > +  */
> 
> As Marta mentioned too, How igt works on a given day is bit volatile to
> document in the kernel comments.

More to the point, CI now implements the described response to
TAINT_DIE, without which this is pointless (userspace sees the wedged
and either handles it or dies; CI sees the wedged as a challenge).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for lockdep: Mark up lock disabling with TAINT_CRAP

[Patchwork]

== Series Details ==

Series: lockdep: Mark up lock disabling with TAINT_CRAP
URL   : https://patchwork.freedesktop.org/series/34915/
State : success

== Summary ==

Series 34915v1 lockdep: Mark up lock disabling with TAINT_CRAP
https://patchwork.freedesktop.org/api/1.0/series/34915/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> PASS   (fi-elk-e7500) fdo#103989 +1
dmesg-warn -> PASS   (fi-bdw-gvtdvm) fdo#103938 +1

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:440s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:440s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:382s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:515s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:501s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:505s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:487s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:478s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:276s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:543s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:374s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:266s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:389s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:479s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:445s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:489s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:532s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:479s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:532s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:596s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:465s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:548s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:514s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:497s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:547s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:415s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:603s
fi-cnl-y total:209  pass:188  dwarn:0   dfail:0   fail:0   skip:20 
fi-glk-dsi   total:52   pass:44   dwarn:0   dfail:0   fail:0   skip:7  

0d0fe916f52ad8f05dddab384ae7c90bb62ebac4 drm-tip: 2017y-12m-05d-14h-52m-17s UTC 
integration manifest
e4281f1eccfb lockdep: Mark up lock disabling with TAINT_CRAP

== Logs ==

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

[Intel-gfx] [PATCH] intel/atomic: Stop updating legacy fb parameters

[Daniel Vetter]

Even fbc isn't using this stuff anymore, so time to remove it.

Cleaning up one small piece of the atomic conversion cruft at the time
...

Cc: Paulo Zanoni 
Cc: Ville Syrjälä 
Cc: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 29 -
 1 file changed, 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 1f7e312d0d0d..c883e14a06d3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10967,31 +10967,6 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
return ret;
 }
 
-static void
-intel_modeset_update_crtc_state(struct drm_atomic_state *state)
-{
-   struct drm_crtc *crtc;
-   struct drm_crtc_state *new_crtc_state;
-   int i;
-
-   /* Double check state. */
-   for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
-   to_intel_crtc(crtc)->config = 
to_intel_crtc_state(new_crtc_state);
-
-   /*
-* Update legacy state to satisfy fbc code. This can
-* be removed when fbc uses the atomic state.
-*/
-   if (drm_atomic_get_existing_plane_state(state, crtc->primary)) {
-   struct drm_plane_state *plane_state = 
crtc->primary->state;
-
-   crtc->primary->fb = plane_state->fb;
-   crtc->x = plane_state->src_x >> 16;
-   crtc->y = plane_state->src_y >> 16;
-   }
-   }
-}
-
 static bool intel_fuzzy_clock_check(int clock1, int clock2)
 {
int diff;
@@ -12364,10 +12339,6 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
}
}
 
-   /* Only after disabling all output pipelines that will be changed can we
-* update the the output configuration. */
-   intel_modeset_update_crtc_state(state);
-
if (intel_state->modeset) {
drm_atomic_helper_update_legacy_modeset_state(state->dev, 
state);
 
-- 
2.15.0

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

Re: [Intel-gfx] [PATCH v3 5/9] drm/i915: Add HDCP framework + base implementation

[Daniel Vetter]

On Tue, Dec 05, 2017 at 12:15:04AM -0500, Sean Paul wrote:
> This patch adds the framework required to add HDCP support to intel
> connectors. It implements Aksv loading from fuse, and parts 1/2/3
> of the HDCP authentication scheme.
> 
> Note that without shim implementations, this does not actually implement
> HDCP. That will come in subsequent patches.
> 
> Changes in v2:
> - Don't open code wait_fors (Chris)
> - drm_hdcp.c under MIT license (Daniel)
> - Move intel_hdcp_disable() call above ddi_disable (Ram)
> - Fix // comments (I wore a cone of shame for 12 hours to atone) (Daniel)
> - Justify intel_hdcp_shim with comments (Daniel)
> - Fixed async locking issues by adding hdcp_mutex (Daniel)
> - Don't alter connector_state in enable/disable (Daniel)
> Changes in v3:
> - Added hdcp_mutex/hdcp_value to make async reasonable
> - Added hdcp_prop_work to separate link checking & property setting
> - Added new helper for atomic_check state tracking (Daniel)
> - Moved enable/disable into atomic_commit with matching helpers
> - Moved intel_hdcp_check_link out of all locks when called from dp
> - Bumped up ksv_fifo timeout (noticed failure on one of my dongles)
> 
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Ramalingam C 
> Signed-off-by: Sean Paul 
> ---
>  drivers/gpu/drm/i915/Makefile|   1 +
>  drivers/gpu/drm/i915/i915_reg.h  |  83 
>  drivers/gpu/drm/i915/intel_atomic.c  |   2 +
>  drivers/gpu/drm/i915/intel_display.c |  14 +
>  drivers/gpu/drm/i915/intel_drv.h |  88 +
>  drivers/gpu/drm/i915/intel_hdcp.c| 731 
> +++
>  6 files changed, 919 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 42bc8bd4ff06..3facea4eefdb 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -107,6 +107,7 @@ i915-y += intel_audio.o \
> intel_fbc.o \
> intel_fifo_underrun.o \
> intel_frontbuffer.o \
> +   intel_hdcp.o \
> intel_hotplug.o \
> intel_modes.o \
> intel_overlay.o \
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 09bf043c1c2e..2bd2cc8441d4 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8034,6 +8034,7 @@ enum {
>  #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT 8
>  #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT 16
>  #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT 24
> +#define   SKL_PCODE_LOAD_HDCP_KEYS   0x5

SKL_ prefix feels right here, since this is for skl, kbl, ... only, and
doesn't apply to bxt. So not gen9 stuff.

>  #define   SKL_PCODE_CDCLK_CONTROL0x7
>  #define SKL_CDCLK_PREPARE_FOR_CHANGE 0x3
>  #define SKL_CDCLK_READY_FOR_CHANGE   0x1
> @@ -8335,6 +8336,88 @@ enum skl_power_gate {
>  #define  SKL_PW_TO_PG(pw)((pw) - SKL_DISP_PW_1 + SKL_PG1)
>  #define  SKL_FUSE_PG_DIST_STATUS(pg) (1 << (27 - (pg)))
>  
> +
> +/* HDCP Key Registers */
> +#define SKL_HDCP_KEY_CONF_MMIO(0x66c00)
> +#define   SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
> +#define  SKL_HDCP_CLEAR_KEYS_TRIGGER BIT(30)
> +#define SKL_HDCP_KEY_STATUS  _MMIO(0x66c04)
> +#define  SKL_HDCP_FUSE_IN_PROGRESS   BIT(7)
> +#define  SKL_HDCP_FUSE_ERROR BIT(6)
> +#define  SKL_HDCP_FUSE_DONE  BIT(5)
> +#define  SKL_HDCP_KEY_LOAD_STATUSBIT(1)
> +#define  SKL_HDCP_KEY_LOAD_DONE  BIT(0)
> +#define SKL_HDCP_AKSV_LO _MMIO(0x66c10)
> +#define SKL_HDCP_AKSV_HI _MMIO(0x66c14)
> +
> +/* HDCP Repeater Registers */
> +#define SKL_HDCP_REP_CTL _MMIO(0x66d00)
> +#define  SKL_HDCP_DDIB_REP_PRESENT   BIT(30)
> +#define  SKL_HDCP_DDIB_REP_PRESENT   BIT(30)
> +#define  SKL_HDCP_DDIA_REP_PRESENT   BIT(29)
> +#define  SKL_HDCP_DDIC_REP_PRESENT   BIT(28)
> +#define  SKL_HDCP_DDID_REP_PRESENT   BIT(27)
> +#define  SKL_HDCP_DDIF_REP_PRESENT   BIT(26)
> +#define  SKL_HDCP_DDIE_REP_PRESENT   BIT(25)
> +#define  SKL_HDCP_DDIB_SHA1_M0   (1 << 20)
> +#define  SKL_HDCP_DDIA_SHA1_M0   (2 << 20)
> +#define  SKL_HDCP_DDIC_SHA1_M0   (3 << 20)
> +#define  SKL_HDCP_DDID_SHA1_M0   (4 << 20)
> +#define  SKL_HDCP_DDIF_SHA1_M0   (5 << 20)
> +#define  SKL_HDCP_DDIE_SHA1_M0   (6 << 20) /* Bspec says 5? */

Yeah that's one good wtf :-)

> +#define  SKL_HDCP_SHA1_BUSY  BIT(16)
> +#define  SKL_HDCP_SHA1_READY BIT(17)
> +#define  SKL_HDCP_SHA1_COMPLETE  BIT(18)
> +#define  SKL_HDCP_SHA1_V_MATCH   BIT(19)
> +#define  SKL_HDCP_SHA1_TEXT_32   (1 << 1)
> +#define  SKL_HDCP_SHA1_COMPLETE_HASH (2 << 1)
> +#define  SKL_HDCP_SHA1_TEXT_24   (4 << 1)
> +#define  SKL_HDCP_SHA1_TEXT_16   (5 << 1)
> +#define  SKL_HDCP_SHA1_TEXT_8(6 << 1)
> +#define  SKL_HDCP_SHA1_TEXT

Re: [Intel-gfx] [PATCH v3 6/9] drm/i915: Make use of indexed write GMBUS feature

[Daniel Vetter]

On Tue, Dec 05, 2017 at 12:15:05AM -0500, Sean Paul wrote:
> This patch enables the indexed write feature of the GMBUS to concatenate
> 2 consecutive messages into one. The criteria for an indexed write is
> that both messages are writes, the first is length == 1, and the second
> is length > 0. The first message is sent out by the GMBUS as the slave
> command, and the second one is sent via the GMBUS FIFO as usual.
> 
> Changes in v3:
> - Added to series
> 
> Suggested-by: Ville Syrjälä 
> Signed-off-by: Sean Paul 

lgtm. Will probably never see a user except the aksv write, but oh well
:-)

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/intel_i2c.c | 39 ++-
>  1 file changed, 34 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
> b/drivers/gpu/drm/i915/intel_i2c.c
> index 49fdf09f9919..7399009aee0a 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -373,7 +373,8 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, struct 
> i2c_msg *msg,
>  
>  static int
>  gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
> -unsigned short addr, u8 *buf, unsigned int len)
> +unsigned short addr, u8 *buf, unsigned int len,
> +u32 gmbus1_index)
>  {
>   unsigned int chunk_size = len;
>   u32 val, loop;
> @@ -386,7 +387,7 @@ gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
>  
>   I915_WRITE_FW(GMBUS3, val);
>   I915_WRITE_FW(GMBUS1,
> -   GMBUS_CYCLE_WAIT |
> +   gmbus1_index | GMBUS_CYCLE_WAIT |
> (chunk_size << GMBUS_BYTE_COUNT_SHIFT) |
> (addr << GMBUS_SLAVE_ADDR_SHIFT) |
> GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
> @@ -409,7 +410,8 @@ gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
>  }
>  
>  static int
> -gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg)
> +gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
> +  u32 gmbus1_index)
>  {
>   u8 *buf = msg->buf;
>   unsigned int tx_size = msg->len;
> @@ -419,7 +421,8 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, 
> struct i2c_msg *msg)
>   do {
>   len = min(tx_size, GMBUS_BYTE_COUNT_MAX);
>  
> - ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len);
> + ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len,
> +  gmbus1_index);
>   if (ret)
>   return ret;
>  
> @@ -430,6 +433,14 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, 
> struct i2c_msg *msg)
>   return 0;
>  }
>  
> +static int
> +gmbus_xfer_index_write(struct drm_i915_private *dev_priv, u8 cmd,
> +struct i2c_msg *msg)
> +{
> + u8 gmbus1_index = GMBUS_CYCLE_INDEX | (cmd << GMBUS_SLAVE_INDEX_SHIFT);
> + return gmbus_xfer_write(dev_priv, msg, gmbus1_index);
> +}
> +
>  /*
>   * The gmbus controller can combine a 1 or 2 byte write with a read that
>   * immediately follows it by using an "INDEX" cycle.
> @@ -444,6 +455,20 @@ gmbus_is_index_read(struct i2c_msg *msgs, int i, int num)
>   (msgs[i + 1].flags & I2C_M_RD));
>  }
>  
> +/*
> + * The gmbus controller can combine a 2-msg write into a single write that
> + * immediately follows it by using an "INDEX" cycle.
> + */
> +static bool
> +gmbus_is_index_write(struct i2c_msg *msgs, int i, int num)
> +{
> + return (i + 1 < num &&
> + msgs[i].addr == msgs[i + 1].addr &&
> + !(msgs[i].flags & I2C_M_RD) &&
> + !(msgs[i + 1].flags & I2C_M_RD) &&
> + (msgs[i].len == 1 || msgs[i + 1].len > 0));
> +}
> +
>  static int
>  gmbus_xfer_index_read(struct drm_i915_private *dev_priv, struct i2c_msg 
> *msgs)
>  {
> @@ -489,10 +514,14 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct 
> i2c_msg *msgs, int num)
>   if (gmbus_is_index_read(msgs, i, num)) {
>   ret = gmbus_xfer_index_read(dev_priv, &msgs[i]);
>   inc = 2; /* an index read is two msgs */
> + } else if (gmbus_is_index_write(msgs, i, num)) {
> + ret = gmbus_xfer_index_write(dev_priv, msgs[i].buf[0],
> + &msgs[i + 1]);
> + inc = 2; /* an index write is two msgs */
>   } else if (msgs[i].flags & I2C_M_RD) {
>   ret = gmbus_xfer_read(dev_priv, &msgs[i], 0);
>   } else {
> - ret = gmbus_xfer_write(dev_priv, &msgs[i]);
> + ret = gmbus_xfer_write(dev_priv, &msgs[i], 0);
>   }
>  
>   if (!ret)
> -- 
> 2.15.0.531.g2ccb3012c9-goog
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailma

Re: [Intel-gfx] [PATCH v3 7/9] drm/i915: Add function to output Aksv over GMBUS

[Daniel Vetter]

On Tue, Dec 05, 2017 at 12:15:06AM -0500, Sean Paul wrote:
> Once the Aksv is available in the PCH, we need to get it on the wire to
> the receiver via DDC. The hardware doesn't allow us to read the value
> directly, so we need to tell GMBUS to source the Aksv internally and
> send it to the right offset on the receiver.
> 
> The way we do this is to initiate an indexed write where the index is
> the Aksv register offset. We write dummy values to GMBUS3 as if we were
> sending the key, and the hardware slips in the "real" values when it
> goes out.
> 
> Changes in v2:
> - None
> Changes in v3:
> - Uses new index write feature (Ville)
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Sean Paul 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/i915_reg.h  |  1 +
>  drivers/gpu/drm/i915/intel_i2c.c | 47 
> +---
>  3 files changed, 46 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index bddd65839f60..6b39081c5e53 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -4049,6 +4049,7 @@ extern int intel_setup_gmbus(struct drm_i915_private 
> *dev_priv);
>  extern void intel_teardown_gmbus(struct drm_i915_private *dev_priv);
>  extern bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv,
>unsigned int pin);
> +extern int intel_gmbus_output_aksv(struct i2c_adapter *adapter);
>  
>  extern struct i2c_adapter *
>  intel_gmbus_get_adapter(struct drm_i915_private *dev_priv, unsigned int pin);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2bd2cc8441d4..107e16392710 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3043,6 +3043,7 @@ enum i915_power_well_id {
>  # define GPIO_DATA_PULLUP_DISABLE(1 << 13)
>  
>  #define GMBUS0   _MMIO(dev_priv->gpio_mmio_base + 
> 0x5100) /* clock/port select */
> +#define   GMBUS_AKSV_SELECT  (1<<11)
>  #define   GMBUS_RATE_100KHZ  (0<<8)
>  #define   GMBUS_RATE_50KHZ   (1<<8)
>  #define   GMBUS_RATE_400KHZ  (2<<8) /* reserved on Pineview */
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
> b/drivers/gpu/drm/i915/intel_i2c.c
> index 7399009aee0a..0a4c7486fc7b 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "intel_drv.h"
>  #include 
>  #include "i915_drv.h"
> @@ -497,7 +498,8 @@ gmbus_xfer_index_read(struct drm_i915_private *dev_priv, 
> struct i2c_msg *msgs)
>  }
>  
>  static int
> -do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num)
> +do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num,
> +   u32 gmbus0_source)
>  {
>   struct intel_gmbus *bus = container_of(adapter,
>  struct intel_gmbus,
> @@ -507,7 +509,7 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
> *msgs, int num)
>   int ret = 0;
>  
>  retry:
> - I915_WRITE_FW(GMBUS0, bus->reg0);
> + I915_WRITE_FW(GMBUS0, gmbus0_source | bus->reg0);
>  
>   for (; i < num; i += inc) {
>   inc = 1;
> @@ -629,7 +631,7 @@ gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
> *msgs, int num)
>   if (ret < 0)
>   bus->force_bit &= ~GMBUS_FORCE_BIT_RETRY;
>   } else {
> - ret = do_gmbus_xfer(adapter, msgs, num);
> + ret = do_gmbus_xfer(adapter, msgs, num, 0);
>   if (ret == -EAGAIN)
>   bus->force_bit |= GMBUS_FORCE_BIT_RETRY;
>   }
> @@ -639,6 +641,45 @@ gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
> *msgs, int num)
>   return ret;
>  }
>  
> +int intel_gmbus_output_aksv(struct i2c_adapter *adapter)
> +{
> + struct intel_gmbus *bus = container_of(adapter, struct intel_gmbus,
> +adapter);
> + struct drm_i915_private *dev_priv = bus->dev_priv;
> + int ret;
> + u8 cmd = DRM_HDCP_DDC_AKSV ;
> + u8 buf[DRM_HDCP_KSV_LEN] = { 0 };
> + struct i2c_msg msgs[] = {
> + {
> + .addr = DRM_HDCP_DDC_ADDR,
> + .flags = 0,
> + .len = sizeof(cmd),
> + .buf = &cmd,
> + },
> + {
> + .addr = DRM_HDCP_DDC_ADDR,
> + .flags = 0,
> + .len = sizeof(buf),
> + .buf = buf,
> + }
> + };
> +
> + intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
> + mutex_lock(&dev_priv->gmbus_mutex);
> +
> + /*
> +  * In order to output Aksv to the receiver, use an indexed write to
> +  * pass the i2c command, and tell GMBUS to use the HW-provided value
> +  * instead of sourc