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

2017-12-05 Thread 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, ));
> +
> + igt_output_override_mode(output, );
> + 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, );
> + primary = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY);
> + igt_plane_set_fb(primary, );
> + 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);
> +   

Re: [Intel-gfx] [PATCH i-g-t 1/2] CONTRIBUTING: Fix spelling mistake and line length

2017-12-05 Thread 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


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

2017-12-05 Thread 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] [PATCH v3 3/9] drm: Add Content Protection property

2017-12-05 Thread 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. 

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

2017-12-05 Thread 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] intel_aubdump: Add ability to simulate execlist submission

2017-12-05 Thread 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

2017-12-05 Thread 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 = _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, ) < 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

2017-12-05 Thread 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 

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

2017-12-05 Thread 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] ✗ Fi.CI.IGT: warning for series starting with [1/2] CONTRIBUTING: Fix spelling mistake and line length

2017-12-05 Thread 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

2017-12-05 Thread 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 foo> (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_feature_name>.

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

2017-12-05 Thread 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  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
> 

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

2017-12-05 Thread 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


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

2017-12-05 Thread 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] ✓ Fi.CI.BAT: success for series starting with [1/1] lib/igt_gt: Add sentinel to intel_execution_engines2

2017-12-05 Thread 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] drm/i915: Fix compilation (panel orientation x enum plane rename).

2017-12-05 Thread 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 3/3] i965: check scratch page in a locked fashion on each ioctl

2017-12-05 Thread 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


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

2017-12-05 Thread 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

2017-12-05 Thread 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(>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

2017-12-05 Thread 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


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

2017-12-05 Thread 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 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 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, >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(>free_work, drm_connector_free_work_fn);
> +
>   connector->base.properties = >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(>base.refcount.refcount))
> + schedule_work(>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(>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(_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(_iter);
> + /* connector_iter drops references in a work item. */
> + flush_scheduled_work();
>   if (WARN_ON(!list_empty(>mode_config.connector_list))) {
>   drm_connector_list_iter_begin(dev, _iter);
>   drm_for_each_connector_iter(connector, _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 

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

2017-12-05 Thread 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] [RFC PATCH 1/6] drm: Add Content Protection property

2017-12-05 Thread 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

2017-12-05 Thread 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());
+
+   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, );
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, );
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

2017-12-05 Thread 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());
+
+   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

2017-12-05 Thread 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 3/3] i965: check scratch page in a locked fashion on each ioctl

2017-12-05 Thread 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 = >screen->devinfo;
> -   __DRIscreen *dri_screen = brw->screen->driScrnPriv;
> +   struct intel_screen *screen = brw->screen;
> +   __DRIscreen *dri_screen = screen->driScrnPriv;
> struct intel_batchbuffer *batch = >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(>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


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

2017-12-05 Thread 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

2017-12-05 Thread 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

2017-12-05 Thread 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  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

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

2017-12-05 Thread 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 foo> (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 3/3] meson: build a full dependency for lib_igt_perf

2017-12-05 Thread 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] [PATCH] drm/i915: Fix compilation (panel orientation x enum plane rename).

2017-12-05 Thread 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


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

2017-12-05 Thread 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 

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

2017-12-05 Thread 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] [PATCH 3/3] i965: check scratch page in a locked fashion on each ioctl

2017-12-05 Thread 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


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

2017-12-05 Thread 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


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

2017-12-05 Thread 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] ✗ Fi.CI.IGT: failure for series starting with [1/1] lib/igt_gt: Add sentinel to intel_execution_engines2

2017-12-05 Thread 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

2017-12-05 Thread 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 

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

2017-12-05 Thread 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

2017-12-05 Thread 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(_dig_port->dp.aux, DP_AUX_HDCP_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

2017-12-05 Thread Lionel Landwerlin

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



On Tue, Dec 5, 2017 at 2:16 PM, Lionel Landwerlin 
> 
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

2017-12-05 Thread 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

2017-12-05 Thread 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


[Intel-gfx] ✓ Fi.CI.BAT: success for lib: Check and report if a subtest triggers a new kernel taint (rev2)

2017-12-05 Thread Patchwork
== Series Details ==

Series: lib: Check and report if a subtest triggers a new kernel taint (rev2)
URL   : https://patchwork.freedesktop.org/series/34616/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
1db12466cb5ad8483cd469753d2e312a62d717b7 meson: build a full dependency for 
lib_igt_perf

with latest DRM-Tip kernel build CI_DRM_3461
0d0fe916f52a drm-tip: 2017y-12m-05d-14h-52m-17s UTC integration manifest

No testlist changes.

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> PASS   (fi-elk-e7500) fdo#103989 +1
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test drv_module_reload:
Subgroup basic-reload:
dmesg-warn -> DMESG-FAIL (fi-gdg-551) fdo#102707

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
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:527s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:284s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:506s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:512s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:498s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:482s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:1   fail:0   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:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:365s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:259s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:478s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
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:483s
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:597s
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:544s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:574s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:516s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:500s
fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:552s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:425s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:615s
fi-cnl-y total:240  pass:215  dwarn:0   dfail:0   fail:0   skip:24 
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:495s

== Logs ==

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


Re: [Intel-gfx] [PATCH v3 00/11] drm/fb-helper: Add .last_close and .output_poll_changed helpers

2017-12-05 Thread Alex Deucher
On Tue, Dec 5, 2017 at 1:24 PM, Noralf Trønnes  wrote:
> The helpers are applied and have reached airlied/drm-next.
>
> amd has gained another .poll_changed user since last.

Patches 1, 2, 9 applied to my -next tree.  Thanks!

Alex

>
> i915 doesn't really need the .poll_changed helper since it now does a
> sync and has to open code it after:
> drm/i915/fbdev: Serialise early hotplug events with async fbdev config
>
> vboxvideo will be re-sent when the helper functions have landed in
> Greg's staging tree.
>
> Noralf.
>
> Changes since version 2:
> - Helper functions have been applied
> - Add drm/amd/display: Use drm_fb_helper_poll_changed()
> - Rebase drm/amdgpu patch
> - Rebase drm/msm patch
> - Drop i915 patch, not applicable after:
>   drm/i915/fbdev: Serialise early hotplug events with async fbdev config
> - Drop vboxvideo patch, it will be re-sent when the helper functions
>   have reached Greg's staging tree.
>
> Changes since version 1:
> - drm_device.drm_fb_helper_private -> drm_device.fb_helper (Ville)
>
> Noralf Trønnes (11):
>   drm/amd/display: Use drm_fb_helper_poll_changed()
>   drm/amdgpu: Use drm_fb_helper_lastclose() and _poll_changed()
>   drm/armada: Use drm_fb_helper_lastclose() and _poll_changed()
>   drm/exynos: Use drm_fb_helper_lastclose() and _poll_changed()
>   drm/gma500: Use drm_fb_helper_lastclose() and _poll_changed()
>   drm/msm: Use drm_fb_helper_lastclose() and _poll_changed()
>   drm/nouveau: Use drm_fb_helper_output_poll_changed()
>   drm/omap: Use drm_fb_helper_lastclose() and _poll_changed()
>   drm/radeon: Use drm_fb_helper_lastclose() and _poll_changed()
>   drm/rockchip: Use drm_fb_helper_lastclose() and _poll_changed()
>   drm/tegra: Use drm_fb_helper_lastclose() and _poll_changed()
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  9 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.h   |  2 --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 27 --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   |  4 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  4 ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  2 +-
>  drivers/gpu/drm/armada/armada_drm.h   |  1 -
>  drivers/gpu/drm/armada/armada_drv.c   |  8 ++
>  drivers/gpu/drm/armada/armada_fb.c| 11 +---
>  drivers/gpu/drm/armada/armada_fbdev.c |  8 --
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  8 ++
>  drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 18 
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.h |  2 --
>  drivers/gpu/drm/gma500/framebuffer.c  |  9 +-
>  drivers/gpu/drm/gma500/psb_drv.c  | 15 +-
>  drivers/gpu/drm/msm/msm_drv.c | 18 ++--
>  drivers/gpu/drm/nouveau/nouveau_display.c |  3 +-
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c   |  8 --
>  drivers/gpu/drm/nouveau/nouveau_fbcon.h   |  2 --
>  drivers/gpu/drm/nouveau/nouveau_vga.c |  3 +-
>  drivers/gpu/drm/nouveau/nv50_display.c|  2 +-
>  drivers/gpu/drm/omapdrm/omap_drv.c| 34 
> ++-
>  drivers/gpu/drm/radeon/radeon_display.c   |  9 ++
>  drivers/gpu/drm/radeon/radeon_fb.c| 22 ---
>  drivers/gpu/drm/radeon/radeon_kms.c   |  5 ++--
>  drivers/gpu/drm/radeon/radeon_mode.h  |  3 --
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  9 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  9 +-
>  drivers/gpu/drm/tegra/drm.c   | 13 ++---
>  drivers/gpu/drm/tegra/drm.h   |  4 ---
>  drivers/gpu/drm/tegra/fb.c| 14 --
>  32 files changed, 29 insertions(+), 259 deletions(-)
>
> --
> 2.14.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2017-12-05 Thread Rodrigo Vivi

Is this a real attempt or enabling GuC by default or is it only
for CI validating the series?

If it is the second option I'd like to see CI testing
this series without this patch here as well to make sure
these changes are not breaking any of the current default flow.

One case or the other I believe we should have more info here
on the commit message.

Thanks,
Rodrigo.

On Tue, Dec 05, 2017 at 04:38:44PM +, Michal Wajdeczko wrote:
> 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 mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2017-12-05 Thread Patchwork
== Series Details ==

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

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623
Subgroup fbc-rgb101010-draw-render:
skip   -> PASS   (shard-snb) fdo#103167
Test drv_module_reload:
Subgroup basic-no-display:
dmesg-warn -> PASS   (shard-hsw) fdo#102707
Test prime_mmap_kms:
Subgroup buffer-sharing:
skip   -> PASS   (shard-snb)
Test drv_suspend:
Subgroup fence-restore-tiled2untiled-hibernate:
fail   -> SKIP   (shard-snb) fdo#103375
Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-top-edge:
incomplete -> PASS   (shard-hsw)
Test kms_flip:
Subgroup vblank-vs-modeset-suspend-interruptible:
skip   -> PASS   (shard-snb)

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

shard-hswtotal:2679 pass:1536 dwarn:1   dfail:0   fail:10  skip:1132 
time:9440s
shard-snbtotal:2679 pass:1308 dwarn:2   dfail:0   fail:10  skip:1359 
time:8079s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7412/shards.html
___
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: Taint (TAINT_DIE) the kernel if the GPU reset fails (rev4)

2017-12-05 Thread Patchwork
== Series Details ==

Series: drm/i915: Taint (TAINT_DIE) the kernel if the GPU reset fails (rev4)
URL   : https://patchwork.freedesktop.org/series/34623/
State : success

== Summary ==

Test drv_suspend:
Subgroup fence-restore-untiled-hibernate:
fail   -> SKIP   (shard-snb) fdo#103375 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-rgb101010-draw-render:
skip   -> PASS   (shard-snb) fdo#103167
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623 +1
Test kms_flip:
Subgroup vblank-vs-modeset-suspend-interruptible:
skip   -> PASS   (shard-snb)
Test drv_module_reload:
Subgroup basic-no-display:
dmesg-warn -> PASS   (shard-snb) fdo#102707
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (shard-hsw) fdo#103706
Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-top-edge:
incomplete -> PASS   (shard-hsw)
Test prime_mmap_kms:
Subgroup buffer-sharing:
skip   -> PASS   (shard-snb)

fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#103706 https://bugs.freedesktop.org/show_bug.cgi?id=103706

shard-hswtotal:2672 pass:1529 dwarn:2   dfail:0   fail:9   skip:1131 
time:9254s
shard-snbtotal:2679 pass:1308 dwarn:1   dfail:0   fail:10  skip:1360 
time:8030s
Blacklisted hosts:
shard-apltotal:2657 pass:1650 dwarn:1   dfail:1   fail:27  skip:977 
time:13244s
shard-kbltotal:2679 pass:1792 dwarn:2   dfail:0   fail:26  skip:859 
time:10862s

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.IGT: warning for lib: Check and report if a subtest triggers a new kernel taint (rev2)

2017-12-05 Thread Patchwork
== Series Details ==

Series: lib: Check and report if a subtest triggers a new kernel taint (rev2)
URL   : https://patchwork.freedesktop.org/series/34616/
State : warning

== Summary ==

Test prime_mmap_kms:
Subgroup buffer-sharing:
skip   -> PASS   (shard-snb)
Test gem_tiled_swapping:
Subgroup non-threaded:
pass   -> INCOMPLETE (shard-hsw) fdo#104009
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-a-planes:
pass   -> INCOMPLETE (shard-hsw) fdo#103540
Test kms_flip:
Subgroup vblank-vs-modeset-suspend-interruptible:
skip   -> PASS   (shard-snb)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623
Subgroup fbc-rgb101010-draw-render:
skip   -> PASS   (shard-snb) fdo#103167
Test kms_cursor_crc:
Subgroup cursor-256x85-random:
pass   -> SKIP   (shard-hsw)
Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-top-edge:
incomplete -> PASS   (shard-hsw)
Test drv_module_reload:
Subgroup basic-no-display:
dmesg-warn -> PASS   (shard-snb) fdo#102707

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

shard-hswtotal:2569 pass:1469 dwarn:1   dfail:0   fail:10  skip:1087 
time:9005s
shard-snbtotal:2679 pass:1309 dwarn:1   dfail:0   fail:11  skip:1358 
time:8139s
Blacklisted hosts:
shard-kbltotal:2679 pass:1796 dwarn:1   dfail:0   fail:22  skip:860 
time:10881s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_600/shards.html
___
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

2017-12-05 Thread Daniel Vetter
On Tue, Dec 05, 2017 at 03:59:35PM +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.
> 
> 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.

+1 on a generic (i.e. DRIVER_ANY) igt that validates the various
possible_* masks. Lots of drivers e.g. don't set anything, hooray.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [IGT] IGT/tests/firmware: Test firmware loading by reading debugfs

2017-12-05 Thread Srivatsa, Anusha


>-Original Message-
>From: Vivi, Rodrigo
>Sent: Friday, December 1, 2017 2:33 PM
>To: Srivatsa, Anusha 
>Cc: intel-gfx@lists.freedesktop.org
>Subject: Re: [IGT] IGT/tests/firmware: Test firmware loading by reading debugfs
>
>On Fri, Dec 01, 2017 at 09:40:35PM +, Anusha Srivatsa wrote:
>> Read debugfs and sysfs entries to check for GuC loading conditions.
>>
>> The patch is still WIP. Once all check conditions are covered, it can
>> be extended to huc debugfs file too.
>>
>> Cc: Rodrigo Vivi 
>> Signed-off-by: Anusha Srivatsa 
>> ---
>>  tests/Makefile.sources |  1 +
>>  tests/test_firmware.c  | 96
>> ++
>>  2 files changed, 97 insertions(+)
>>  create mode 100644 tests/test_firmware.c
>>
>> diff --git a/tests/Makefile.sources b/tests/Makefile.sources index
>> 0f4e39a..841fc54 100644
>> --- a/tests/Makefile.sources
>> +++ b/tests/Makefile.sources
>> @@ -234,6 +234,7 @@ TESTS_progs = \
>>  template \
>>  tools_test \
>>  vgem_basic \
>> +test_firmware \
>
>note that igt tests names are meaningful... _
>
>so probably better to use fw_basic

OK... fw_basic or fw_debugfs?

>>  vgem_slow \
>
>and also they are more or less sorted out here...
>but you added on the middle of a vgem group...

Oops  will change the order.

>>  $(NULL)
>>
>> diff --git a/tests/test_firmware.c b/tests/test_firmware.c new file
>> mode 100644 index 000..a5d621a
>> --- /dev/null
>> +++ b/tests/test_firmware.c
>> @@ -0,0 +1,96 @@
>> +/*
>> + * Copyright (c) 2013 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.
>> + *
>> + * Authors: Anusha Srivatsa
>> + *
>> + */
>> +
>> +#include "igt.h"
>> +#include "stdio.h"
>> +#include "stdlib.h"
>> +#include "igt_sysfs.h"
>> +#include "igt_debugfs.h"
>> +#include "i915_drm.h"
>> +#include "fcntl.h"
>> +
>> +IGT_TEST_DESCRIPTION("Read contents of debugfs to check for firmware
>> +status.");
>> +
>> +static void guc_load(int drm_fd, int debugfs, int gen) {
>> +char firmware_buf[250];
>> +float fw_version_wanted;
>> +float fw_version_found;
>> +int ret;
>> +int enable_guc_loading;
>> +FILE *fp;
>> +
>> +igt_skip_on_f(gen < 6,
>> +  "GuC not available on platforms prior to Skylake\n");
>> +
>> +igt_sysfs_scanf(debugfs, "i915_enable_guc_loading", "%d",
>_guc_loading);
>> +igt_skip_on_f(!(enable_guc_loading < 1), "GuC loading not
>> +enabled\n");
>> +
>> +ret = igt_debugfs_open(drm_fd, "i915_guc_load_status", O_RDONLY);
>> +fp = fdopen(ret, "r");
>> +igt_fail_on_f(ret < 0, "Not able to open the debugfs file\n");
>> +
>> +igt_debugfs_read(drm_fd, "i915_guc_load_status", firmware_buf);
>> +
>> +fseek(fp, 99, SEEK_CUR);
>
>This is risky/fragile imo... any small change on debugfs this will break...

I agree totally. I am not very happy about it either. Any suggestions on 
how else I can scan it? 

>Have you consider the new kernel seftest thing to make the tests inside kernel
>itself without need for parse this debugfs interface?

Good point. Let me have a look at it.
Thanks a lot Rodrigo.

Anusha
>> +fscanf(fp, "%f", _version_wanted);
>> +fseek(fp, 119, SEEK_SET);
>> +fscanf(fp, "%f", _version_found);
>> +
>> +igt_fail_on_f((fw_version_wanted != fw_version_found),
>> +  "Firmware version found not the version wanted\n");
>> +igt_fail_on_f(strstr(firmware_buf, "fetch: NONE"),
>> +  "Firmware not fetched\n");
>> +igt_fail_on_f(strstr(firmware_buf, "fetch: SUCCESS") &&
>> +  strstr(firmware_buf, "load: NONE "),
>> +  "Firmware not loaded\n");
>> +}
>> +
>> +int drm_fd;
>> +int debugfs;
>> +int 

[Intel-gfx] [PATCH v3 00/11] drm/fb-helper: Add .last_close and .output_poll_changed helpers

2017-12-05 Thread Noralf Trønnes
The helpers are applied and have reached airlied/drm-next.

amd has gained another .poll_changed user since last.

i915 doesn't really need the .poll_changed helper since it now does a
sync and has to open code it after:
drm/i915/fbdev: Serialise early hotplug events with async fbdev config

vboxvideo will be re-sent when the helper functions have landed in
Greg's staging tree.

Noralf.

Changes since version 2:
- Helper functions have been applied
- Add drm/amd/display: Use drm_fb_helper_poll_changed()
- Rebase drm/amdgpu patch
- Rebase drm/msm patch
- Drop i915 patch, not applicable after:
  drm/i915/fbdev: Serialise early hotplug events with async fbdev config
- Drop vboxvideo patch, it will be re-sent when the helper functions
  have reached Greg's staging tree.

Changes since version 1:
- drm_device.drm_fb_helper_private -> drm_device.fb_helper (Ville)

Noralf Trønnes (11):
  drm/amd/display: Use drm_fb_helper_poll_changed()
  drm/amdgpu: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/armada: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/exynos: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/gma500: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/msm: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/nouveau: Use drm_fb_helper_output_poll_changed()
  drm/omap: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/radeon: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/rockchip: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/tegra: Use drm_fb_helper_lastclose() and _poll_changed()

 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  9 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.h   |  2 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 27 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   |  4 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  4 ---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  2 +-
 drivers/gpu/drm/armada/armada_drm.h   |  1 -
 drivers/gpu/drm/armada/armada_drv.c   |  8 ++
 drivers/gpu/drm/armada/armada_fb.c| 11 +---
 drivers/gpu/drm/armada/armada_fbdev.c |  8 --
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |  8 ++
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 18 
 drivers/gpu/drm/exynos/exynos_drm_fbdev.h |  2 --
 drivers/gpu/drm/gma500/framebuffer.c  |  9 +-
 drivers/gpu/drm/gma500/psb_drv.c  | 15 +-
 drivers/gpu/drm/msm/msm_drv.c | 18 ++--
 drivers/gpu/drm/nouveau/nouveau_display.c |  3 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   |  8 --
 drivers/gpu/drm/nouveau/nouveau_fbcon.h   |  2 --
 drivers/gpu/drm/nouveau/nouveau_vga.c |  3 +-
 drivers/gpu/drm/nouveau/nv50_display.c|  2 +-
 drivers/gpu/drm/omapdrm/omap_drv.c| 34 ++-
 drivers/gpu/drm/radeon/radeon_display.c   |  9 ++
 drivers/gpu/drm/radeon/radeon_fb.c| 22 ---
 drivers/gpu/drm/radeon/radeon_kms.c   |  5 ++--
 drivers/gpu/drm/radeon/radeon_mode.h  |  3 --
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  9 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  9 +-
 drivers/gpu/drm/tegra/drm.c   | 13 ++---
 drivers/gpu/drm/tegra/drm.h   |  4 ---
 drivers/gpu/drm/tegra/fb.c| 14 --
 32 files changed, 29 insertions(+), 259 deletions(-)

-- 
2.14.2

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


[Intel-gfx] [PATCH v3 07/11] drm/nouveau: Use drm_fb_helper_output_poll_changed()

2017-12-05 Thread Noralf Trønnes
This driver can use drm_fb_helper_output_poll_changed() instead of
its own nouveau_fbcon_output_poll_changed().

Cc: Ben Skeggs 
Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 3 ++-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   | 8 
 drivers/gpu/drm/nouveau/nouveau_fbcon.h   | 2 --
 drivers/gpu/drm/nouveau/nouveau_vga.c | 3 ++-
 drivers/gpu/drm/nouveau/nv50_display.c| 2 +-
 5 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 2e7785f49e6d..009713404cc4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -292,7 +293,7 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
 
 static const struct drm_mode_config_funcs nouveau_mode_config_funcs = {
.fb_create = nouveau_user_framebuffer_create,
-   .output_poll_changed = nouveau_fbcon_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
 };
 
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index c533d8e04afc..45a4572cd2fb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -413,14 +413,6 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
return ret;
 }
 
-void
-nouveau_fbcon_output_poll_changed(struct drm_device *dev)
-{
-   struct nouveau_drm *drm = nouveau_drm(dev);
-   if (drm->fbcon)
-   drm_fb_helper_hotplug_event(>fbcon->helper);
-}
-
 static int
 nouveau_fbcon_destroy(struct drm_device *dev, struct nouveau_fbdev *fbcon)
 {
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.h 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.h
index e2bca729721e..a6f192ea3fa6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.h
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.h
@@ -68,8 +68,6 @@ void nouveau_fbcon_set_suspend(struct drm_device *dev, int 
state);
 void nouveau_fbcon_accel_save_disable(struct drm_device *dev);
 void nouveau_fbcon_accel_restore(struct drm_device *dev);
 
-void nouveau_fbcon_output_poll_changed(struct drm_device *dev);
-
 extern int nouveau_nofbaccel;
 
 #endif /* __NV50_FBCON_H__ */
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c 
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index 52e52a360fb1..3da5a4305aa4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -4,6 +4,7 @@
 
 #include 
 #include 
+#include 
 
 #include "nouveau_drv.h"
 #include "nouveau_acpi.h"
@@ -61,7 +62,7 @@ static void
 nouveau_switcheroo_reprobe(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
-   nouveau_fbcon_output_poll_changed(dev);
+   drm_fb_helper_output_poll_changed(dev);
 }
 
 static bool
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
b/drivers/gpu/drm/nouveau/nv50_display.c
index 65336948e807..b22c37bde13f 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -4311,7 +4311,7 @@ nv50_disp_atomic_state_alloc(struct drm_device *dev)
 static const struct drm_mode_config_funcs
 nv50_disp_func = {
.fb_create = nouveau_user_framebuffer_create,
-   .output_poll_changed = nouveau_fbcon_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = nv50_disp_atomic_check,
.atomic_commit = nv50_disp_atomic_commit,
.atomic_state_alloc = nv50_disp_atomic_state_alloc,
-- 
2.14.2

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


[Intel-gfx] [PATCH v3 03/11] drm/armada: Use drm_fb_helper_lastclose() and _poll_changed()

2017-12-05 Thread Noralf Trønnes
This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Russell King 
Signed-off-by: Noralf Trønnes 
Acked-by: Russell King 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/armada/armada_drm.h   |  1 -
 drivers/gpu/drm/armada/armada_drv.c   |  8 ++--
 drivers/gpu/drm/armada/armada_fb.c| 11 +--
 drivers/gpu/drm/armada/armada_fbdev.c |  8 
 4 files changed, 3 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_drm.h 
b/drivers/gpu/drm/armada/armada_drm.h
index b064879ecdbd..cc4c557c9f66 100644
--- a/drivers/gpu/drm/armada/armada_drm.h
+++ b/drivers/gpu/drm/armada/armada_drm.h
@@ -84,7 +84,6 @@ void armada_drm_queue_unref_work(struct drm_device *,
 extern const struct drm_mode_config_funcs armada_drm_mode_config_funcs;
 
 int armada_fbdev_init(struct drm_device *);
-void armada_fbdev_lastclose(struct drm_device *);
 void armada_fbdev_fini(struct drm_device *);
 
 int armada_overlay_plane_create(struct drm_device *, unsigned long);
diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index e857b88a9799..4b11b6b52f1d 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "armada_crtc.h"
 #include "armada_drm.h"
@@ -54,15 +55,10 @@ static struct drm_ioctl_desc armada_ioctls[] = {
DRM_IOCTL_DEF_DRV(ARMADA_GEM_PWRITE, armada_gem_pwrite_ioctl, 0),
 };
 
-static void armada_drm_lastclose(struct drm_device *dev)
-{
-   armada_fbdev_lastclose(dev);
-}
-
 DEFINE_DRM_GEM_FOPS(armada_drm_fops);
 
 static struct drm_driver armada_drm_driver = {
-   .lastclose  = armada_drm_lastclose,
+   .lastclose  = drm_fb_helper_lastclose,
.gem_free_object_unlocked = armada_gem_free_object,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
diff --git a/drivers/gpu/drm/armada/armada_fb.c 
b/drivers/gpu/drm/armada/armada_fb.c
index a38d5a0892a9..ac92bce07ecd 100644
--- a/drivers/gpu/drm/armada/armada_fb.c
+++ b/drivers/gpu/drm/armada/armada_fb.c
@@ -154,16 +154,7 @@ static struct drm_framebuffer *armada_fb_create(struct 
drm_device *dev,
return ERR_PTR(ret);
 }
 
-static void armada_output_poll_changed(struct drm_device *dev)
-{
-   struct armada_private *priv = dev->dev_private;
-   struct drm_fb_helper *fbh = priv->fbdev;
-
-   if (fbh)
-   drm_fb_helper_hotplug_event(fbh);
-}
-
 const struct drm_mode_config_funcs armada_drm_mode_config_funcs = {
.fb_create  = armada_fb_create,
-   .output_poll_changed= armada_output_poll_changed,
+   .output_poll_changed= drm_fb_helper_output_poll_changed,
 };
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index a2ce83f84800..2a59db0994b2 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -159,14 +159,6 @@ int armada_fbdev_init(struct drm_device *dev)
return ret;
 }
 
-void armada_fbdev_lastclose(struct drm_device *dev)
-{
-   struct armada_private *priv = dev->dev_private;
-
-   if (priv->fbdev)
-   drm_fb_helper_restore_fbdev_mode_unlocked(priv->fbdev);
-}
-
 void armada_fbdev_fini(struct drm_device *dev)
 {
struct armada_private *priv = dev->dev_private;
-- 
2.14.2

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


[Intel-gfx] [PATCH v3 08/11] drm/omap: Use drm_fb_helper_lastclose() and _poll_changed()

2017-12-05 Thread Noralf Trønnes
This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Tomi Valkeinen 
Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 34 ++
 1 file changed, 2 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index cdf5b0601eba..96857c508ee0 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -46,14 +46,6 @@
  * devices
  */
 
-static void omap_fb_output_poll_changed(struct drm_device *dev)
-{
-   struct omap_drm_private *priv = dev->dev_private;
-   DBG("dev=%p", dev);
-   if (priv->fbdev)
-   drm_fb_helper_hotplug_event(priv->fbdev);
-}
-
 static void omap_atomic_wait_for_completion(struct drm_device *dev,
struct drm_atomic_state *old_state)
 {
@@ -132,7 +124,7 @@ static const struct drm_mode_config_helper_funcs 
omap_mode_config_helper_funcs =
 
 static const struct drm_mode_config_funcs omap_mode_config_funcs = {
.fb_create = omap_framebuffer_create,
-   .output_poll_changed = omap_fb_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
 };
@@ -467,28 +459,6 @@ static int dev_open(struct drm_device *dev, struct 
drm_file *file)
return 0;
 }
 
-/**
- * lastclose - clean up after all DRM clients have exited
- * @dev: DRM device
- *
- * Take care of cleaning up after all DRM clients have exited.  In the
- * mode setting case, we want to restore the kernel's initial mode (just
- * in case the last client left us in a bad state).
- */
-static void dev_lastclose(struct drm_device *dev)
-{
-   struct omap_drm_private *priv = dev->dev_private;
-   int ret;
-
-   DBG("lastclose: dev=%p", dev);
-
-   if (priv->fbdev) {
-   ret = drm_fb_helper_restore_fbdev_mode_unlocked(priv->fbdev);
-   if (ret)
-   DBG("failed to restore crtc mode");
-   }
-}
-
 static const struct vm_operations_struct omap_gem_vm_ops = {
.fault = omap_gem_fault,
.open = drm_gem_vm_open,
@@ -511,7 +481,7 @@ static struct drm_driver omap_drm_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM  | DRIVER_PRIME |
DRIVER_ATOMIC | DRIVER_RENDER,
.open = dev_open,
-   .lastclose = dev_lastclose,
+   .lastclose = drm_fb_helper_lastclose,
 #ifdef CONFIG_DEBUG_FS
.debugfs_init = omap_debugfs_init,
 #endif
-- 
2.14.2

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


[Intel-gfx] [PATCH v3 10/11] drm/rockchip: Use drm_fb_helper_lastclose() and _poll_changed()

2017-12-05 Thread Noralf Trønnes
This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Mark Yao 
Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 9 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 9 +
 2 files changed, 2 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 76d63de5921d..d85431400a0d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -207,13 +207,6 @@ static void rockchip_drm_unbind(struct device *dev)
drm_dev_unref(drm_dev);
 }
 
-static void rockchip_drm_lastclose(struct drm_device *dev)
-{
-   struct rockchip_drm_private *priv = dev->dev_private;
-
-   drm_fb_helper_restore_fbdev_mode_unlocked(>fbdev_helper);
-}
-
 static const struct file_operations rockchip_drm_driver_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -228,7 +221,7 @@ static const struct file_operations 
rockchip_drm_driver_fops = {
 static struct drm_driver rockchip_drm_driver = {
.driver_features= DRIVER_MODESET | DRIVER_GEM |
  DRIVER_PRIME | DRIVER_ATOMIC,
-   .lastclose  = rockchip_drm_lastclose,
+   .lastclose  = drm_fb_helper_lastclose,
.gem_vm_ops = _gem_cma_vm_ops,
.gem_free_object_unlocked = rockchip_gem_free_object,
.dumb_create= rockchip_gem_dumb_create,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index cd2ace0c3caa..e266539e04e5 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -167,20 +167,13 @@ rockchip_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
return ERR_PTR(ret);
 }
 
-static void rockchip_drm_output_poll_changed(struct drm_device *dev)
-{
-   struct rockchip_drm_private *private = dev->dev_private;
-
-   drm_fb_helper_hotplug_event(>fbdev_helper);
-}
-
 static const struct drm_mode_config_helper_funcs rockchip_mode_config_helpers 
= {
.atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
 };
 
 static const struct drm_mode_config_funcs rockchip_drm_mode_config_funcs = {
.fb_create = rockchip_user_fb_create,
-   .output_poll_changed = rockchip_drm_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
 };
-- 
2.14.2

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


[Intel-gfx] [PATCH v3 05/11] drm/gma500: Use drm_fb_helper_lastclose() and _poll_changed()

2017-12-05 Thread Noralf Trønnes
This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Patrik Jakobsson 
Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/gma500/framebuffer.c |  9 +
 drivers/gpu/drm/gma500/psb_drv.c | 15 +--
 2 files changed, 2 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 2570c7f647a6..cb0a2ae916e0 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -576,13 +576,6 @@ static void psb_fbdev_fini(struct drm_device *dev)
dev_priv->fbdev = NULL;
 }
 
-static void psbfb_output_poll_changed(struct drm_device *dev)
-{
-   struct drm_psb_private *dev_priv = dev->dev_private;
-   struct psb_fbdev *fbdev = (struct psb_fbdev *)dev_priv->fbdev;
-   drm_fb_helper_hotplug_event(>psb_fb_helper);
-}
-
 /**
  * psb_user_framebuffer_create_handle - add hamdle to a framebuffer
  * @fb: framebuffer
@@ -623,7 +616,7 @@ static void psb_user_framebuffer_destroy(struct 
drm_framebuffer *fb)
 
 static const struct drm_mode_config_funcs psb_mode_funcs = {
.fb_create = psb_user_framebuffer_create,
-   .output_poll_changed = psbfb_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
 };
 
 static void psb_setup_outputs(struct drm_device *dev)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 8f5cc1f471cd..38d09d4b3ed5 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -107,19 +107,6 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
 static const struct drm_ioctl_desc psb_ioctls[] = {
 };
 
-static void psb_driver_lastclose(struct drm_device *dev)
-{
-   int ret;
-   struct drm_psb_private *dev_priv = dev->dev_private;
-   struct psb_fbdev *fbdev = dev_priv->fbdev;
-
-   ret = drm_fb_helper_restore_fbdev_mode_unlocked(>psb_fb_helper);
-   if (ret)
-   DRM_DEBUG("failed to restore crtc mode\n");
-
-   return;
-}
-
 static int psb_do_init(struct drm_device *dev)
 {
struct drm_psb_private *dev_priv = dev->dev_private;
@@ -479,7 +466,7 @@ static struct drm_driver driver = {
   DRIVER_MODESET | DRIVER_GEM,
.load = psb_driver_load,
.unload = psb_driver_unload,
-   .lastclose = psb_driver_lastclose,
+   .lastclose = drm_fb_helper_lastclose,
 
.num_ioctls = ARRAY_SIZE(psb_ioctls),
.irq_preinstall = psb_irq_preinstall,
-- 
2.14.2

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


[Intel-gfx] [PATCH v3 09/11] drm/radeon: Use drm_fb_helper_lastclose() and _poll_changed()

2017-12-05 Thread Noralf Trønnes
This driver can use drm_fb_helper_lastclose() in its .lastclose function.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Alex Deucher 
Cc: "Christian König" 
Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/radeon/radeon_display.c |  9 ++---
 drivers/gpu/drm/radeon/radeon_fb.c  | 22 --
 drivers/gpu/drm/radeon/radeon_kms.c |  5 ++---
 drivers/gpu/drm/radeon/radeon_mode.h|  3 ---
 4 files changed, 4 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index ddfe91efa61e..dfda5e0ed166 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -32,6 +32,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1362,15 +1363,9 @@ radeon_user_framebuffer_create(struct drm_device *dev,
return _fb->base;
 }
 
-static void radeon_output_poll_changed(struct drm_device *dev)
-{
-   struct radeon_device *rdev = dev->dev_private;
-   radeon_fb_output_poll_changed(rdev);
-}
-
 static const struct drm_mode_config_funcs radeon_mode_funcs = {
.fb_create = radeon_user_framebuffer_create,
-   .output_poll_changed = radeon_output_poll_changed
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
 };
 
 static const struct drm_prop_enum_list radeon_tmds_pll_enum_list[] =
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c 
b/drivers/gpu/drm/radeon/radeon_fb.c
index 33b821d6d018..57c5404a1654 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -306,12 +306,6 @@ static int radeonfb_create(struct drm_fb_helper *helper,
return ret;
 }
 
-void radeon_fb_output_poll_changed(struct radeon_device *rdev)
-{
-   if (rdev->mode_info.rfbdev)
-   drm_fb_helper_hotplug_event(>mode_info.rfbdev->helper);
-}
-
 static int radeon_fbdev_destroy(struct drm_device *dev, struct radeon_fbdev 
*rfbdev)
 {
struct radeon_framebuffer *rfb = >rfb;
@@ -422,19 +416,3 @@ void radeon_fb_remove_connector(struct radeon_device 
*rdev, struct drm_connector
if (rdev->mode_info.rfbdev)

drm_fb_helper_remove_one_connector(>mode_info.rfbdev->helper, connector);
 }
-
-void radeon_fbdev_restore_mode(struct radeon_device *rdev)
-{
-   struct radeon_fbdev *rfbdev = rdev->mode_info.rfbdev;
-   struct drm_fb_helper *fb_helper;
-   int ret;
-
-   if (!rfbdev)
-   return;
-
-   fb_helper = >helper;
-
-   ret = drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
-   if (ret)
-   DRM_DEBUG("failed to restore crtc mode\n");
-}
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index cde037f213d7..dec1e081f529 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -26,6 +26,7 @@
  *  Jerome Glisse
  */
 #include 
+#include 
 #include "radeon.h"
 #include 
 #include "radeon_asic.h"
@@ -629,9 +630,7 @@ static int radeon_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
  */
 void radeon_driver_lastclose_kms(struct drm_device *dev)
 {
-   struct radeon_device *rdev = dev->dev_private;
-
-   radeon_fbdev_restore_mode(rdev);
+   drm_fb_helper_lastclose(dev);
vga_switcheroo_process_delayed_switch();
 }
 
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
b/drivers/gpu/drm/radeon/radeon_mode.h
index ca0a7ed28c9b..3243e5e01432 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -984,9 +984,6 @@ int radeon_fbdev_init(struct radeon_device *rdev);
 void radeon_fbdev_fini(struct radeon_device *rdev);
 void radeon_fbdev_set_suspend(struct radeon_device *rdev, int state);
 bool radeon_fbdev_robj_is_fb(struct radeon_device *rdev, struct radeon_bo 
*robj);
-void radeon_fbdev_restore_mode(struct radeon_device *rdev);
-
-void radeon_fb_output_poll_changed(struct radeon_device *rdev);
 
 void radeon_crtc_handle_vblank(struct radeon_device *rdev, int crtc_id);
 
-- 
2.14.2

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


[Intel-gfx] [PATCH 7/9] drm/i915: make mappable struct resource centric

2017-12-05 Thread Matthew Auld
Now that we are using struct resource to track the stolen region, it is
more convenient if we track the mappable region in a resource as well.

v2: prefer iomap and gmadr naming scheme
prefer DEFINE_RES_MEM

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Paulo Zanoni 
---
 drivers/gpu/drm/i915/gvt/gvt.h|  2 +-
 drivers/gpu/drm/i915/i915_drv.c   |  2 +-
 drivers/gpu/drm/i915/i915_gem.c   |  8 +++
 drivers/gpu/drm/i915/i915_gem_execbuffer.c|  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c   | 31 +--
 drivers/gpu/drm/i915/i915_gem_gtt.h   |  4 ++--
 drivers/gpu/drm/i915/i915_gpu_error.c |  2 +-
 drivers/gpu/drm/i915/i915_vma.c   |  2 +-
 drivers/gpu/drm/i915/intel_display.c  |  2 +-
 drivers/gpu/drm/i915/intel_overlay.c  |  4 ++--
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |  4 ++--
 drivers/gpu/drm/i915/selftests/mock_gtt.c |  4 ++--
 12 files changed, 38 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 393066726993..0e160bd00e2e 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -336,7 +336,7 @@ int intel_gvt_load_firmware(struct intel_gvt *gvt);
 
 /* Aperture/GM space definitions for GVT device */
 #define gvt_aperture_sz(gvt) (gvt->dev_priv->ggtt.mappable_end)
-#define gvt_aperture_pa_base(gvt) (gvt->dev_priv->ggtt.mappable_base)
+#define gvt_aperture_pa_base(gvt) (gvt->dev_priv->ggtt.gmadr.start)
 
 #define gvt_ggtt_gm_sz(gvt)  (gvt->dev_priv->ggtt.base.total)
 #define gvt_ggtt_sz(gvt) \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7faf20aff25a..d89e7b07eb5d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -726,7 +726,7 @@ static int i915_kick_out_firmware_fb(struct 
drm_i915_private *dev_priv)
if (!ap)
return -ENOMEM;
 
-   ap->ranges[0].base = ggtt->mappable_base;
+   ap->ranges[0].base = ggtt->gmadr.start;
ap->ranges[0].size = ggtt->mappable_end;
 
primary =
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e083f242b8dc..87388e2d58f1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1106,7 +1106,7 @@ i915_gem_gtt_pread(struct drm_i915_gem_object *obj,
page_base += offset & PAGE_MASK;
}
 
-   if (gtt_user_read(>mappable, page_base, page_offset,
+   if (gtt_user_read(>iomap, page_base, page_offset,
  user_data, page_length)) {
ret = -EFAULT;
break;
@@ -1314,7 +1314,7 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_gem_object *obj,
 * If the object is non-shmem backed, we retry again with the
 * path that handles page fault.
 */
-   if (ggtt_write(>mappable, page_base, page_offset,
+   if (ggtt_write(>iomap, page_base, page_offset,
   user_data, page_length)) {
ret = -EFAULT;
break;
@@ -1960,9 +1960,9 @@ int i915_gem_fault(struct vm_fault *vmf)
/* Finally, remap it using the new GTT offset */
ret = remap_io_mapping(area,
   area->vm_start + (vma->ggtt_view.partial.offset 
<< PAGE_SHIFT),
-  (ggtt->mappable_base + vma->node.start) >> 
PAGE_SHIFT,
+  (ggtt->gmadr.start + vma->node.start) >> 
PAGE_SHIFT,
   min_t(u64, vma->size, area->vm_end - 
area->vm_start),
-  >mappable);
+  >iomap);
if (ret)
goto err_fence;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 70ccd63cbf8e..4401068ff468 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1012,7 +1012,7 @@ static void *reloc_iomap(struct drm_i915_gem_object *obj,
offset += page << PAGE_SHIFT;
}
 
-   vaddr = (void __force *)io_mapping_map_atomic_wc(>mappable,
+   vaddr = (void __force *)io_mapping_map_atomic_wc(>iomap,
 offset);
cache->page = page;
cache->vaddr = (unsigned long)vaddr;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 32e06d9ccc52..8d19480b65c5 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2912,7 +2912,7 @@ void i915_ggtt_cleanup_hw(struct drm_i915_private 
*dev_priv)

[Intel-gfx] [PATCH 6/9] drm/i915: make reserved struct resource centric

2017-12-05 Thread Matthew Auld
Now that we are using struct resource to track the stolen region, it is
more convenient if we track the reserved portion of that region in a
resource as well.

v2: s/<= end + 1/< end/ (Chris)
v3: prefer DEFINE_RES_MEM

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h|  4 
 drivers/gpu/drm/i915/i915_gem_gtt.h|  2 --
 drivers/gpu/drm/i915/i915_gem_stolen.c | 15 ++-
 drivers/gpu/drm/i915/intel_pm.c|  6 ++
 4 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 39c8e99f3d3a..18905badd494 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2259,6 +2259,10 @@ struct drm_i915_private {
 * while ggtt->stolen_size gives us the total size of the stolen region.
 */
struct resource dsm;
+   /**
+* Reseved portion of Data Stolen Memory
+*/
+   struct resource dsm_reserved;
 
void __iomem *regs;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 93211a96fdad..84bb3ee17dd7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -383,8 +383,6 @@ struct i915_ggtt {
 */
u32 stolen_size;/* Total size of stolen memory */
u32 stolen_usable_size; /* Total size minus reserved ranges */
-   u32 stolen_reserved_base;
-   u32 stolen_reserved_size;
 
/** "Graphics Stolen Memory" holds the global PTEs */
void __iomem *gsm;
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index eb84db633a23..6e2550ff750f 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -397,18 +397,15 @@ int i915_gem_init_stolen(struct drm_i915_private 
*dev_priv)
reserved_base = stolen_top;
}
 
-   if (reserved_base < dev_priv->dsm.start ||
-   reserved_base + reserved_size > stolen_top) {
-   dma_addr_t reserved_top = reserved_base + reserved_size;
-   DRM_ERROR("Stolen reserved area [%pad - %pad] outside stolen 
memory [%pad - %pad]\n",
- _base, _top,
- _priv->dsm.start, _top);
+   dev_priv->dsm_reserved =
+   (struct resource) DEFINE_RES_MEM(reserved_base, reserved_size);
+
+   if (!resource_contains(_priv->dsm, _priv->dsm_reserved)) {
+   DRM_ERROR("Stolen reserved area %pR outside stolen memory 
%pR\n",
+ _priv->dsm_reserved, _priv->dsm);
return 0;
}
 
-   ggtt->stolen_reserved_base = reserved_base;
-   ggtt->stolen_reserved_size = reserved_size;
-
/* It is possible for the reserved area to end before the end of stolen
 * memory, so just consider the start. */
reserved_total = stolen_top - reserved_base;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2fa2d82f61f2..016feecafe8d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6416,7 +6416,6 @@ static void valleyview_disable_rps(struct 
drm_i915_private *dev_priv)
 
 static bool bxt_check_bios_rc6_setup(struct drm_i915_private *dev_priv)
 {
-   struct i915_ggtt *ggtt = _priv->ggtt;
bool enable_rc6 = true;
unsigned long rc6_ctx_base;
u32 rc_ctl;
@@ -6441,9 +6440,8 @@ static bool bxt_check_bios_rc6_setup(struct 
drm_i915_private *dev_priv)
 * for this check.
 */
rc6_ctx_base = I915_READ(RC6_CTX_BASE) & RC6_CTX_BASE_MASK;
-   if (!((rc6_ctx_base >= ggtt->stolen_reserved_base) &&
- (rc6_ctx_base + PAGE_SIZE <= ggtt->stolen_reserved_base +
-   ggtt->stolen_reserved_size))) {
+   if (!((rc6_ctx_base >= dev_priv->dsm_reserved.start) &&
+ (rc6_ctx_base + PAGE_SIZE < dev_priv->dsm_reserved.end))) {
DRM_DEBUG_DRIVER("RC6 Base address not as expected.\n");
enable_rc6 = false;
}
-- 
2.14.3

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


[Intel-gfx] [PATCH 8/9] drm/i915: prefer resource_size_t for everything stolen

2017-12-05 Thread Matthew Auld
Keeps things consistent now that we make use of struct resource. This
should keep us covered in case we ever get huge amounts of stolen
memory.

v2: bunch of missing conversions (Chris)

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Paulo Zanoni 
---
 drivers/char/agp/intel-gtt.c   | 14 +-
 drivers/gpu/drm/i915/i915_debugfs.c|  4 +--
 drivers/gpu/drm/i915/i915_drv.h|  9 ---
 drivers/gpu/drm/i915/i915_gem_gtt.c| 10 
 drivers/gpu/drm/i915/i915_gem_gtt.h|  6 ++---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 47 +-
 drivers/gpu/drm/i915/intel_pm.c| 10 
 include/drm/intel-gtt.h|  4 +--
 8 files changed, 52 insertions(+), 52 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 9b6b6023193b..6a2a7b062eac 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -80,7 +80,7 @@ static struct _intel_private {
unsigned int needs_dmar : 1;
phys_addr_t gma_bus_addr;
/*  Size of memory reserved for graphics by the BIOS */
-   unsigned int stolen_size;
+   resource_size_t stolen_size;
/* Total number of gtt entries. */
unsigned int gtt_total_entries;
/* Part of the gtt that is mappable by the cpu, for those chips where
@@ -333,13 +333,13 @@ static void i810_write_entry(dma_addr_t addr, unsigned 
int entry,
writel_relaxed(addr | pte_flags, intel_private.gtt + entry);
 }
 
-static unsigned int intel_gtt_stolen_size(void)
+static resource_size_t intel_gtt_stolen_size(void)
 {
u16 gmch_ctrl;
u8 rdct;
int local = 0;
static const int ddt[4] = { 0, 16, 32, 64 };
-   unsigned int stolen_size = 0;
+   resource_size_t stolen_size = 0;
 
if (INTEL_GTT_GEN == 1)
return 0; /* no stolen mem on i81x */
@@ -417,8 +417,8 @@ static unsigned int intel_gtt_stolen_size(void)
}
 
if (stolen_size > 0) {
-   dev_info(_private.bridge_dev->dev, "detected %dK %s 
memory\n",
-  stolen_size / KB(1), local ? "local" : "stolen");
+   dev_info(_private.bridge_dev->dev, "detected %lluK %s 
memory\n",
+  (u64)stolen_size / KB(1), local ? "local" : "stolen");
} else {
dev_info(_private.bridge_dev->dev,
   "no pre-allocated video memory detected\n");
@@ -1422,9 +1422,9 @@ int intel_gmch_probe(struct pci_dev *bridge_pdev, struct 
pci_dev *gpu_pdev,
 EXPORT_SYMBOL(intel_gmch_probe);
 
 void intel_gtt_get(u64 *gtt_total,
-  u32 *stolen_size,
+  resource_size_t *stolen_size,
   phys_addr_t *mappable_base,
-  u64 *mappable_end)
+  resource_size_t *mappable_end)
 {
*gtt_total = intel_private.gtt_total_entries << PAGE_SHIFT;
*stolen_size = intel_private.stolen_size;
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 28294470ae31..fad4116f61c5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -522,8 +522,8 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
seq_printf(m, "%u display objects (globally pinned), %llu bytes\n",
   dpy_count, dpy_size);
 
-   seq_printf(m, "%llu [%llu] gtt total\n",
-  ggtt->base.total, ggtt->mappable_end);
+   seq_printf(m, "%llu [%pa] gtt total\n",
+  ggtt->base.total, >mappable_end);
seq_printf(m, "Supported page sizes: %s\n",
   stringify_page_sizes(INTEL_INFO(dev_priv)->page_sizes,
buf, sizeof(buf)));
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 18905badd494..4e749df0cae8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3911,12 +3911,13 @@ void i915_gem_stolen_remove_node(struct 
drm_i915_private *dev_priv,
 int i915_gem_init_stolen(struct drm_i915_private *dev_priv);
 void i915_gem_cleanup_stolen(struct drm_device *dev);
 struct drm_i915_gem_object *
-i915_gem_object_create_stolen(struct drm_i915_private *dev_priv, u32 size);
+i915_gem_object_create_stolen(struct drm_i915_private *dev_priv,
+ resource_size_t size);
 struct drm_i915_gem_object *
 i915_gem_object_create_stolen_for_preallocated(struct drm_i915_private 
*dev_priv,
-  u32 stolen_offset,
-  u32 gtt_offset,
-  u32 size);
+  resource_size_t stolen_offset,
+  resource_size_t 

[Intel-gfx] [PATCH 5/9] drm/i915: make dsm struct resource centric

2017-12-05 Thread Matthew Auld
Now that we are using struct resource to track the stolen region, it is
more convenient if we track dsm in a resource as well.

v2: check range_overflow when writing to 32b registers (Chris)
pepper in some comments (Chris)
v3: refit i915_stolen_to_dma()

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h| 13 --
 drivers/gpu/drm/i915/i915_gem_stolen.c | 84 +-
 drivers/gpu/drm/i915/intel_fbc.c   | 10 +++-
 drivers/gpu/drm/i915/intel_pm.c| 17 +--
 4 files changed, 72 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 594fd14e66c5..39c8e99f3d3a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1537,9 +1537,6 @@ struct i915_gem_mm {
 */
struct pagevec wc_stash;
 
-   /** Usable portion of the GTT for GEM */
-   dma_addr_t stolen_base; /* limited to low memory (32-bit) */
-
/**
 * tmpfs instance used for shmem backed objects
 */
@@ -2253,6 +2250,16 @@ struct drm_i915_private {
 
const struct intel_device_info info;
 
+   /**
+* Data Stolen Memory - aka "i915 stolen memory" gives us the start and
+* end of stolen which we can optionally use to create GEM objects
+* backed by stolen memory. Note that ggtt->stolen_usable_size tells us
+* exactly how much of this we are actually allowed to use, given that
+* some portion of it is in fact reserved for use by hardware functions,
+* while ggtt->stolen_size gives us the total size of the stolen region.
+*/
+   struct resource dsm;
+
void __iomem *regs;
 
struct intel_uncore uncore;
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index f8ac1438c35d..eb84db633a23 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -76,27 +76,27 @@ void i915_gem_stolen_remove_node(struct drm_i915_private 
*dev_priv,
mutex_unlock(_priv->mm.stolen_lock);
 }
 
-static dma_addr_t i915_stolen_to_dma(struct drm_i915_private *dev_priv)
+static int i915_adjust_stolen(struct drm_i915_private *dev_priv,
+ struct resource *dsm)
 {
struct i915_ggtt *ggtt = _priv->ggtt;
-   dma_addr_t base = intel_graphics_stolen_res.start;
+   dma_addr_t base = dsm->start;
struct resource *r;
 
GEM_BUG_ON(overflows_type(intel_graphics_stolen_res.start, base));
 
if (base == 0 || add_overflows(base, ggtt->stolen_size))
-   return 0;
+   return -EINVAL;
 
/* make sure we don't clobber the GTT if it's within stolen memory */
if (INTEL_GEN(dev_priv) <= 4 &&
!IS_G33(dev_priv) && !IS_PINEVIEW(dev_priv) && !IS_G4X(dev_priv)) {
-   struct {
-   dma_addr_t start, end;
-   } stolen[2] = {
-   { .start = base, .end = base + ggtt->stolen_size, },
-   { .start = base, .end = base + ggtt->stolen_size, },
+   struct resource stolen[2] = {
+   DEFINE_RES_MEM(base, ggtt->stolen_size),
+   DEFINE_RES_MEM(base, ggtt->stolen_size),
};
-   u64 ggtt_start, ggtt_end;
+   struct resource ggtt_res;
+   u64 ggtt_start;
 
ggtt_start = I915_READ(PGTBL_CTL);
if (IS_GEN4(dev_priv))
@@ -104,36 +104,31 @@ static dma_addr_t i915_stolen_to_dma(struct 
drm_i915_private *dev_priv)
 (ggtt_start & PGTBL_ADDRESS_HI_MASK) << 28;
else
ggtt_start &= PGTBL_ADDRESS_LO_MASK;
-   ggtt_end = ggtt_start + ggtt_total_entries(ggtt) * 4;
 
-   if (ggtt_start >= stolen[0].start && ggtt_start < stolen[0].end)
-   stolen[0].end = ggtt_start;
-   if (ggtt_end > stolen[1].start && ggtt_end <= stolen[1].end)
-   stolen[1].start = ggtt_end;
+   ggtt_res =
+   (struct resource) DEFINE_RES_MEM(ggtt_start,
+
ggtt_total_entries(ggtt) * 4);
+
+   if (ggtt_res.start >= stolen[0].start && ggtt_res.start < 
stolen[0].end)
+   stolen[0].end = ggtt_res.start;
+   if (ggtt_res.end > stolen[1].start && ggtt_res.end <= 
stolen[1].end)
+   stolen[1].start = ggtt_res.end;
 
/* pick the larger of the two chunks */
-   if (stolen[0].end - stolen[0].start >
-   stolen[1].end - stolen[1].start) {
-   base = stolen[0].start;

[Intel-gfx] [PATCH 1/9] x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit

2017-12-05 Thread Matthew Auld
From: Joonas Lahtinen 

To give upcoming SKU BIOSes more flexibility in placing the Intel
graphics stolen memory, make all variables storing the placement or size
compatible with full 64 bit range. Also by exporting the stolen region
as a resource, we can then nuke the duplicated stolen discovery in i915.

v2: export the stolen region as a resource
fix u16 << 16 (Chris)
v3: actually fix u16 << 16

Signed-off-by: Joonas Lahtinen 
Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Ville Syrjälä 
Cc: Chris Wilson 
Cc: Paulo Zanoni 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: x...@kernel.org
Cc: linux-ker...@vger.kernel.org
Reviewed-by: Chris Wilson  #v1
---
 arch/x86/kernel/early-quirks.c | 86 +++---
 include/drm/i915_drm.h |  3 ++
 2 files changed, 50 insertions(+), 39 deletions(-)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 1e82f787c160..d7236e2f5eed 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -243,7 +243,7 @@ static void __init intel_remapping_check(int num, int slot, 
int func)
 #define KB(x)  ((x) * 1024UL)
 #define MB(x)  (KB (KB (x)))
 
-static size_t __init i830_tseg_size(void)
+static resource_size_t __init i830_tseg_size(void)
 {
u8 esmramc = read_pci_config_byte(0, 0, 0, I830_ESMRAMC);
 
@@ -256,7 +256,7 @@ static size_t __init i830_tseg_size(void)
return KB(512);
 }
 
-static size_t __init i845_tseg_size(void)
+static resource_size_t __init i845_tseg_size(void)
 {
u8 esmramc = read_pci_config_byte(0, 0, 0, I845_ESMRAMC);
u8 tseg_size = esmramc & I845_TSEG_SIZE_MASK;
@@ -273,7 +273,7 @@ static size_t __init i845_tseg_size(void)
return 0;
 }
 
-static size_t __init i85x_tseg_size(void)
+static resource_size_t __init i85x_tseg_size(void)
 {
u8 esmramc = read_pci_config_byte(0, 0, 0, I85X_ESMRAMC);
 
@@ -283,12 +283,12 @@ static size_t __init i85x_tseg_size(void)
return MB(1);
 }
 
-static size_t __init i830_mem_size(void)
+static resource_size_t __init i830_mem_size(void)
 {
return read_pci_config_byte(0, 0, 0, I830_DRB3) * MB(32);
 }
 
-static size_t __init i85x_mem_size(void)
+static resource_size_t __init i85x_mem_size(void)
 {
return read_pci_config_byte(0, 0, 1, I85X_DRB3) * MB(32);
 }
@@ -297,36 +297,36 @@ static size_t __init i85x_mem_size(void)
  * On 830/845/85x the stolen memory base isn't available in any
  * register. We need to calculate it as TOM-TSEG_SIZE-stolen_size.
  */
-static phys_addr_t __init i830_stolen_base(int num, int slot, int func,
-  size_t stolen_size)
+static resource_size_t __init i830_stolen_base(int num, int slot, int func,
+  resource_size_t stolen_size)
 {
-   return (phys_addr_t)i830_mem_size() - i830_tseg_size() - stolen_size;
+   return i830_mem_size() - i830_tseg_size() - stolen_size;
 }
 
-static phys_addr_t __init i845_stolen_base(int num, int slot, int func,
-  size_t stolen_size)
+static resource_size_t __init i845_stolen_base(int num, int slot, int func,
+  resource_size_t stolen_size)
 {
-   return (phys_addr_t)i830_mem_size() - i845_tseg_size() - stolen_size;
+   return i830_mem_size() - i845_tseg_size() - stolen_size;
 }
 
-static phys_addr_t __init i85x_stolen_base(int num, int slot, int func,
-  size_t stolen_size)
+static resource_size_t __init i85x_stolen_base(int num, int slot, int func,
+  resource_size_t stolen_size)
 {
-   return (phys_addr_t)i85x_mem_size() - i85x_tseg_size() - stolen_size;
+   return i85x_mem_size() - i85x_tseg_size() - stolen_size;
 }
 
-static phys_addr_t __init i865_stolen_base(int num, int slot, int func,
-  size_t stolen_size)
+static resource_size_t __init i865_stolen_base(int num, int slot, int func,
+  resource_size_t stolen_size)
 {
u16 toud = 0;
 
toud = read_pci_config_16(0, 0, 0, I865_TOUD);
 
-   return (phys_addr_t)(toud << 16) + i845_tseg_size();
+   return (toud * KB(64)) + i845_tseg_size();
 }
 
-static phys_addr_t __init gen3_stolen_base(int num, int slot, int func,
-  size_t stolen_size)
+static resource_size_t __init gen3_stolen_base(int num, int slot, int func,
+  resource_size_t stolen_size)
 {
u32 bsm;
 
@@ -337,10 +337,10 @@ 

[Intel-gfx] [PATCH 4/9] drm/i915: nuke the duplicated stolen discovery

2017-12-05 Thread Matthew Auld
We duplicate the stolen discovery code in early-quirks and in i915,
however now that the stolen region is exported as a resource from
early-quirks we can nuke the duplication.

v2: check overflows_type

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Paulo Zanoni 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c|  51 +--
 drivers/gpu/drm/i915/i915_gem_stolen.c | 109 +
 2 files changed, 5 insertions(+), 155 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index f3c35e826321..32e06d9ccc52 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2949,50 +2949,6 @@ static unsigned int chv_get_total_gtt_size(u16 gmch_ctrl)
return 0;
 }
 
-static size_t gen6_get_stolen_size(u16 snb_gmch_ctl)
-{
-   snb_gmch_ctl >>= SNB_GMCH_GMS_SHIFT;
-   snb_gmch_ctl &= SNB_GMCH_GMS_MASK;
-   return (size_t)snb_gmch_ctl << 25; /* 32 MB units */
-}
-
-static size_t gen8_get_stolen_size(u16 bdw_gmch_ctl)
-{
-   bdw_gmch_ctl >>= BDW_GMCH_GMS_SHIFT;
-   bdw_gmch_ctl &= BDW_GMCH_GMS_MASK;
-   return (size_t)bdw_gmch_ctl << 25; /* 32 MB units */
-}
-
-static size_t chv_get_stolen_size(u16 gmch_ctrl)
-{
-   gmch_ctrl >>= SNB_GMCH_GMS_SHIFT;
-   gmch_ctrl &= SNB_GMCH_GMS_MASK;
-
-   /*
-* 0x0  to 0x10: 32MB increments starting at 0MB
-* 0x11 to 0x16: 4MB increments starting at 8MB
-* 0x17 to 0x1d: 4MB increments start at 36MB
-*/
-   if (gmch_ctrl < 0x11)
-   return (size_t)gmch_ctrl << 25;
-   else if (gmch_ctrl < 0x17)
-   return (size_t)(gmch_ctrl - 0x11 + 2) << 22;
-   else
-   return (size_t)(gmch_ctrl - 0x17 + 9) << 22;
-}
-
-static size_t gen9_get_stolen_size(u16 gen9_gmch_ctl)
-{
-   gen9_gmch_ctl >>= BDW_GMCH_GMS_SHIFT;
-   gen9_gmch_ctl &= BDW_GMCH_GMS_MASK;
-
-   if (gen9_gmch_ctl < 0xf0)
-   return (size_t)gen9_gmch_ctl << 25; /* 32 MB units */
-   else
-   /* 4MB increments starting at 0xf0 for 4MB */
-   return (size_t)(gen9_gmch_ctl - 0xf0 + 1) << 22;
-}
-
 static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 size)
 {
struct drm_i915_private *dev_priv = ggtt->base.i915;
@@ -3343,14 +3299,13 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
 
pci_read_config_word(pdev, SNB_GMCH_CTRL, _gmch_ctl);
 
+   ggtt->stolen_size = resource_size(_graphics_stolen_res);
+
if (INTEL_GEN(dev_priv) >= 9) {
-   ggtt->stolen_size = gen9_get_stolen_size(snb_gmch_ctl);
size = gen8_get_total_gtt_size(snb_gmch_ctl);
} else if (IS_CHERRYVIEW(dev_priv)) {
-   ggtt->stolen_size = chv_get_stolen_size(snb_gmch_ctl);
size = chv_get_total_gtt_size(snb_gmch_ctl);
} else {
-   ggtt->stolen_size = gen8_get_stolen_size(snb_gmch_ctl);
size = gen8_get_total_gtt_size(snb_gmch_ctl);
}
 
@@ -3408,7 +3363,7 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
DRM_ERROR("Can't set DMA mask/consistent mask (%d)\n", err);
pci_read_config_word(pdev, SNB_GMCH_CTRL, _gmch_ctl);
 
-   ggtt->stolen_size = gen6_get_stolen_size(snb_gmch_ctl);
+   ggtt->stolen_size = resource_size(_graphics_stolen_res);
 
size = gen6_get_total_gtt_size(snb_gmch_ctl);
ggtt->base.total = (size / sizeof(gen6_pte_t)) << PAGE_SHIFT;
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 1877ae9a1d9b..f8ac1438c35d 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -30,9 +30,6 @@
 #include 
 #include "i915_drv.h"
 
-#define KB(x) ((x) * 1024)
-#define MB(x) (KB(x) * 1024)
-
 /*
  * The BIOS typically reserves some of the system's memory for the exclusive
  * use of the integrated graphics. This memory is no longer available for
@@ -81,113 +78,11 @@ void i915_gem_stolen_remove_node(struct drm_i915_private 
*dev_priv,
 
 static dma_addr_t i915_stolen_to_dma(struct drm_i915_private *dev_priv)
 {
-   struct pci_dev *pdev = dev_priv->drm.pdev;
struct i915_ggtt *ggtt = _priv->ggtt;
+   dma_addr_t base = intel_graphics_stolen_res.start;
struct resource *r;
-   dma_addr_t base;
-
-   /* Almost universally we can find the Graphics Base of Stolen Memory
-* at register BSM (0x5c) in the igfx configuration space. On a few
-* (desktop) machines this is also mirrored in the bridge device at
-* different locations, or in the MCHBAR.
-*
-* On 865 we just check the TOUD register.
-*
-* On 830/845/85x the stolen memory base isn't available in any
-* 

[Intel-gfx] [PATCH 9/9] drm/i915: use stolen_usable_size for the range sanity check

2017-12-05 Thread Matthew Auld
In i915_pages_create_for_stolen it probably makes more sense to check if
the range overflows the stolen_usable_size, since stolen_size will
also include the reserved portion which we can't touch.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 91c1127af872..4ec4084de0ad 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -435,7 +435,8 @@ i915_pages_create_for_stolen(struct drm_device *dev,
struct sg_table *st;
struct scatterlist *sg;
 
-   GEM_BUG_ON(range_overflows(offset, size, dev_priv->ggtt.stolen_size));
+   GEM_BUG_ON(range_overflows(offset, size,
+  dev_priv->ggtt.stolen_usable_size));
 
/* We hide that we have no struct page backing our stolen object
 * by wrapping the contiguous physical allocation with a fake
-- 
2.14.3

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


[Intel-gfx] [PATCH 3/9] x86/early-quirks: reverse the if ladders

2017-12-05 Thread Matthew Auld
Makes things a little easier to follow.

Suggested-by: Ville Syrjälä 
Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Ville Syrjälä 
Cc: Chris Wilson 
Cc: Paulo Zanoni 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: x...@kernel.org
Cc: linux-ker...@vger.kernel.org
---
 arch/x86/kernel/early-quirks.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index b5b912f3dce8..ba6e96381bfc 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -425,12 +425,12 @@ static resource_size_t __init chv_stolen_size(int num, 
int slot, int func)
 * 0x11 to 0x16: 4MB increments starting at 8MB
 * 0x17 to 0x1d: 4MB increments start at 36MB
 */
-   if (gms < 0x11)
-   return gms * MB(32);
-   else if (gms < 0x17)
+   if (gms >= 0x17)
+   return (gms - 0x17) * MB(4) + MB(36);
+   else if (gms >= 0x11)
return (gms - 0x11) * MB(4) + MB(8);
else
-   return (gms - 0x17) * MB(4) + MB(36);
+   return gms * MB(32);
 }
 
 static resource_size_t __init gen9_stolen_size(int num, int slot, int func)
@@ -443,10 +443,10 @@ static resource_size_t __init gen9_stolen_size(int num, 
int slot, int func)
 
/* 0x0  to 0xef: 32MB increments starting at 0MB */
/* 0xf0 to 0xfe: 4MB increments starting at 4MB */
-   if (gms < 0xf0)
-   return gms * MB(32);
-   else
+   if (gms >= 0xf0)
return (gms - 0xf0) * MB(4) + MB(4);
+   else
+   return gms * MB(32);
 }
 
 struct intel_early_ops {
-- 
2.14.3

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


[Intel-gfx] [PATCH 2/9] x86/early-quirks: replace the magical increment start values

2017-12-05 Thread Matthew Auld
Replace the magical +2, +9 etc. with +MB, which is far easier to read.

Suggested-by: Ville Syrjälä 
Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Ville Syrjälä 
Cc: Chris Wilson 
Cc: Paulo Zanoni 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: x...@kernel.org
Cc: linux-ker...@vger.kernel.org
Reviewed-by: Ville Syrjälä 
---
 arch/x86/kernel/early-quirks.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index d7236e2f5eed..b5b912f3dce8 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -428,9 +428,9 @@ static resource_size_t __init chv_stolen_size(int num, int 
slot, int func)
if (gms < 0x11)
return gms * MB(32);
else if (gms < 0x17)
-   return (gms - 0x11 + 2) * MB(4);
+   return (gms - 0x11) * MB(4) + MB(8);
else
-   return (gms - 0x17 + 9) * MB(4);
+   return (gms - 0x17) * MB(4) + MB(36);
 }
 
 static resource_size_t __init gen9_stolen_size(int num, int slot, int func)
@@ -446,7 +446,7 @@ static resource_size_t __init gen9_stolen_size(int num, int 
slot, int func)
if (gms < 0xf0)
return gms * MB(32);
else
-   return (gms - 0xf0 + 1) * MB(4);
+   return (gms - 0xf0) * MB(4) + MB(4);
 }
 
 struct intel_early_ops {
-- 
2.14.3

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


[Intel-gfx] [PATCH 0/9] make stolen resource centric

2017-12-05 Thread Matthew Auld
Continuation of Paulo' stolen series[1], addressing the feedback from Joonas and
Chris.

[1] https://patchwork.freedesktop.org/series/30923/

Joonas Lahtinen (1):
  x86/early-quirks: Extend Intel graphics stolen memory placement to
64bit

Matthew Auld (8):
  x86/early-quirks: replace the magical increment start values
  x86/early-quirks: reverse the if ladders
  drm/i915: nuke the duplicated stolen discovery
  drm/i915: make dsm struct resource centric
  drm/i915: make reserved struct resource centric
  drm/i915: make mappable struct resource centric
  drm/i915: prefer resource_size_t for everything stolen
  drm/i915: use stolen_usable_size for the range sanity check

 arch/x86/kernel/early-quirks.c|  92 +-
 drivers/char/agp/intel-gtt.c  |  14 +-
 drivers/gpu/drm/i915/gvt/gvt.h|   2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |   4 +-
 drivers/gpu/drm/i915/i915_drv.c   |   2 +-
 drivers/gpu/drm/i915/i915_drv.h   |  26 ++-
 drivers/gpu/drm/i915/i915_gem.c   |   8 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c|   2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c   |  92 +++---
 drivers/gpu/drm/i915/i915_gem_gtt.h   |  12 +-
 drivers/gpu/drm/i915/i915_gem_stolen.c| 244 +++---
 drivers/gpu/drm/i915/i915_gpu_error.c |   2 +-
 drivers/gpu/drm/i915/i915_vma.c   |   2 +-
 drivers/gpu/drm/i915/intel_display.c  |   2 +-
 drivers/gpu/drm/i915/intel_fbc.c  |  10 +-
 drivers/gpu/drm/i915/intel_overlay.c  |   4 +-
 drivers/gpu/drm/i915/intel_pm.c   |  33 ++--
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |   4 +-
 drivers/gpu/drm/i915/selftests/mock_gtt.c |   4 +-
 include/drm/i915_drm.h|   3 +
 include/drm/intel-gtt.h   |   4 +-
 21 files changed, 227 insertions(+), 339 deletions(-)

-- 
2.14.3

___
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 [v3,1/2] drm/i915: follow single notation for workaround number

2017-12-05 Thread Patchwork
== Series Details ==

Series: series starting with [v3,1/2] drm/i915: follow single notation for 
workaround number
URL   : https://patchwork.freedesktop.org/series/34937/
State : warning

== Summary ==

Test kms_flip:
Subgroup vblank-vs-modeset-suspend-interruptible:
skip   -> PASS   (shard-snb)
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-a-planes:
pass   -> INCOMPLETE (shard-hsw) fdo#103540
Test kms_frontbuffer_tracking:
Subgroup fbc-rgb101010-draw-render:
skip   -> PASS   (shard-snb) fdo#103167
Subgroup fbc-rgb565-draw-mmap-cpu:
pass   -> SKIP   (shard-hsw)
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623 +1
Test prime_mmap_kms:
Subgroup buffer-sharing:
skip   -> PASS   (shard-snb)
Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-top-edge:
incomplete -> PASS   (shard-hsw)
Test drv_module_reload:
Subgroup basic-no-display:
dmesg-warn -> PASS   (shard-snb) fdo#102707 +1

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

shard-hswtotal:2637 pass:1512 dwarn:1   dfail:0   fail:10  skip:1113 
time:9311s
shard-snbtotal:2679 pass:1308 dwarn:1   dfail:0   fail:12  skip:1358 
time:8085s
Blacklisted hosts:
shard-apltotal:2679 pass:1677 dwarn:1   dfail:0   fail:24  skip:977 
time:13591s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7419/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

2017-12-05 Thread Daniel Stone
Hi Pavel,

On 5 December 2017 at 17:34, Pavel Machek  wrote:
> Yes, so... This patch makes it more likely to see machines with locked
> down kernels, preventing developers from working with systems their
> own, running hardware. That is evil, and direct threat to Free
> software movement.
>
> Users compiling their own kernels get no benefit from it. Actually it
> looks like this only benefits Intel and Disney. We don't want that.

With all due respect, you can't claim to speak for the entire kernel
and FLOSS community of users and developers.

The feature is optional: it does not enforce additional constraints on
users, but exposes additional functionality already present in
hardware, for those who wish to opt in to it. Those who wish to avoid
it can do so, by simply not making active use of it.

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


[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/fb-helper: Add .last_close and .output_poll_changed helpers (rev3)

2017-12-05 Thread Patchwork
== Series Details ==

Series: drm/fb-helper: Add .last_close and .output_poll_changed helpers (rev3)
URL   : https://patchwork.freedesktop.org/series/32332/
State : warning

== Summary ==

Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-top-edge:
incomplete -> PASS   (shard-hsw)
Test drv_module_reload:
Subgroup basic-no-display:
dmesg-warn -> PASS   (shard-hsw) fdo#102707
Test prime_mmap_kms:
Subgroup buffer-sharing:
skip   -> PASS   (shard-snb)
Test kms_frontbuffer_tracking:
Subgroup fbc-rgb101010-draw-render:
skip   -> PASS   (shard-snb) fdo#103167
Test kms_flip:
Subgroup vblank-vs-modeset-suspend-interruptible:
skip   -> PASS   (shard-snb)
Subgroup vblank-vs-dpms-suspend-interruptible:
pass   -> INCOMPLETE (shard-hsw) fdo#103706
Test kms_atomic_transition:
Subgroup plane-all-transition-fencing:
pass   -> SKIP   (shard-hsw)
Test drv_selftest:
Subgroup live_hangcheck:
pass   -> INCOMPLETE (shard-snb) fdo#103880

fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103706 https://bugs.freedesktop.org/show_bug.cgi?id=103706
fdo#103880 https://bugs.freedesktop.org/show_bug.cgi?id=103880

shard-hswtotal:2620 pass:1505 dwarn:1   dfail:0   fail:10  skip:1103 
time:8774s
shard-snbtotal:2661 pass:1288 dwarn:2   dfail:0   fail:12  skip:1358 
time:7965s
Blacklisted hosts:
shard-apltotal:2657 pass:1654 dwarn:2   dfail:0   fail:23  skip:977 
time:13414s
shard-kbltotal:2620 pass:1755 dwarn:1   dfail:0   fail:24  skip:839 
time:10705s

== Logs ==

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


Re: [Intel-gfx] [PATCH v3 2/2] drm/i915: add platform tag to WA

2017-12-05 Thread Rodrigo Vivi
On Tue, Dec 05, 2017 at 07:01:18PM +, Lucas De Marchi wrote:
> v2: add more missing platform tags
> v3: change tag to cnp rather than using gen9,gen10

thanks!
both patches merged to dinq 
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Lucas De Marchi 
> Reviewed-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
>  drivers/gpu/drm/i915/intel_pm.c   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 691600ce48c4..c42a6c672b73 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1380,7 +1380,7 @@ static bool hdmi_12bpc_possible(const struct 
> intel_crtc_state *crtc_state)
>   }
>   }
>  
> - /* Display WA #1139 */
> + /* Display WA #1139: glk */
>   if (IS_GLK_REVID(dev_priv, 0, GLK_REVID_A1) &&
>   crtc_state->base.adjusted_mode.htotal > 5460)
>   return false;
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 07ee5ad5a13f..5836181d6f8a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -8417,7 +8417,7 @@ static void cnp_init_clock_gating(struct 
> drm_i915_private *dev_priv)
>   if (!HAS_PCH_CNP(dev_priv))
>   return;
>  
> - /* Display WA #1181 */
> + /* Display WA #1181: cnp */
>   I915_WRITE(SOUTH_DSPCLK_GATE_D, I915_READ(SOUTH_DSPCLK_GATE_D) |
>  CNP_PWM_CGE_GATING_DISABLE);
>  }
> -- 
> 2.14.3
> 
> ___
> 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 3/9] x86/early-quirks: reverse the if ladders

2017-12-05 Thread Ville Syrjälä
On Tue, Dec 05, 2017 at 09:02:43PM +, Matthew Auld wrote:
> Makes things a little easier to follow.
> 
> Suggested-by: Ville Syrjälä 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Ville Syrjälä 
> Cc: Chris Wilson 
> Cc: Paulo Zanoni 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: H. Peter Anvin 
> Cc: x...@kernel.org
> Cc: linux-ker...@vger.kernel.org

Reviewed-by: Ville Syrjälä 

> ---
>  arch/x86/kernel/early-quirks.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
> index b5b912f3dce8..ba6e96381bfc 100644
> --- a/arch/x86/kernel/early-quirks.c
> +++ b/arch/x86/kernel/early-quirks.c
> @@ -425,12 +425,12 @@ static resource_size_t __init chv_stolen_size(int num, 
> int slot, int func)
>* 0x11 to 0x16: 4MB increments starting at 8MB
>* 0x17 to 0x1d: 4MB increments start at 36MB
>*/
> - if (gms < 0x11)
> - return gms * MB(32);
> - else if (gms < 0x17)
> + if (gms >= 0x17)
> + return (gms - 0x17) * MB(4) + MB(36);
> + else if (gms >= 0x11)
>   return (gms - 0x11) * MB(4) + MB(8);
>   else
> - return (gms - 0x17) * MB(4) + MB(36);
> + return gms * MB(32);
>  }
>  
>  static resource_size_t __init gen9_stolen_size(int num, int slot, int func)
> @@ -443,10 +443,10 @@ static resource_size_t __init gen9_stolen_size(int num, 
> int slot, int func)
>  
>   /* 0x0  to 0xef: 32MB increments starting at 0MB */
>   /* 0xf0 to 0xfe: 4MB increments starting at 4MB */
> - if (gms < 0xf0)
> - return gms * MB(32);
> - else
> + if (gms >= 0xf0)
>   return (gms - 0xf0) * MB(4) + MB(4);
> + else
> + return gms * MB(32);
>  }
>  
>  struct intel_early_ops {
> -- 
> 2.14.3

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


[Intel-gfx] ✓ Fi.CI.IGT: success for e1000e: Taint a HW lockup

2017-12-05 Thread Patchwork
== Series Details ==

Series: e1000e: Taint a HW lockup
URL   : https://patchwork.freedesktop.org/series/34931/
State : success

== Summary ==

Test kms_flip:
Subgroup vblank-vs-modeset-suspend:
pass   -> SKIP   (shard-snb) fdo#102365
Subgroup modeset-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060
Subgroup vblank-vs-modeset-suspend-interruptible:
skip   -> PASS   (shard-snb)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623
Subgroup fbc-rgb101010-draw-render:
skip   -> PASS   (shard-snb) fdo#103167 +1
Test drv_module_reload:
Subgroup basic-no-display:
dmesg-warn -> PASS   (shard-hsw) fdo#102707
Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-top-edge:
incomplete -> PASS   (shard-hsw)
Test prime_mmap_kms:
Subgroup buffer-sharing:
skip   -> PASS   (shard-snb)

fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707

shard-hswtotal:2679 pass:1535 dwarn:1   dfail:0   fail:11  skip:1132 
time:9438s
shard-snbtotal:2679 pass:1306 dwarn:2   dfail:0   fail:11  skip:1360 
time:8041s
Blacklisted hosts:
shard-apltotal:2636 pass:1636 dwarn:0   dfail:0   fail:23  skip:977 
time:13356s
shard-kbltotal:2545 pass:1694 dwarn:5   dfail:1   fail:22  skip:822 
time:10261s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7417/shards.html
___
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 [v3,1/2] drm/i915: follow single notation for workaround number

2017-12-05 Thread Patchwork
== Series Details ==

Series: series starting with [v3,1/2] drm/i915: follow single notation for 
workaround number
URL   : https://patchwork.freedesktop.org/series/34937/
State : success

== Summary ==

Series 34937v1 series starting with [v3,1/2] drm/i915: follow single notation 
for workaround number
https://patchwork.freedesktop.org/api/1.0/series/34937/revisions/1/mbox/

Test gem_exec_reloc:
Subgroup basic-gtt-active:
pass   -> FAIL   (fi-gdg-551) fdo#102582 +4
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:439s
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:520s
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:505s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:512s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:485s
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:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:174  dwarn:1   dfail:0   fail:5   skip:108 
time:268s
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:381s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:258s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:481s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:445s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:529s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
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:594s
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:546s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:578s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:516s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:506s
fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:548s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:425s
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:637s
fi-glk-dsi   total:48   pass:40   dwarn:0   dfail:0   fail:1   skip:6  

0d0fe916f52ad8f05dddab384ae7c90bb62ebac4 drm-tip: 2017y-12m-05d-14h-52m-17s UTC 
integration manifest
1865ffb38093 drm/i915: add platform tag to WA
2b69b57062b0 drm/i915: follow single notation for workaround number

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for make stolen resource centric (rev4)

2017-12-05 Thread Patchwork
== Series Details ==

Series: make stolen resource centric (rev4)
URL   : https://patchwork.freedesktop.org/series/34256/
State : success

== Summary ==

Series 34256v4 make stolen resource centric
https://patchwork.freedesktop.org/api/1.0/series/34256/revisions/4/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:436s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:383s
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:502s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:506s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:490s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:474s
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:536s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:356s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:257s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:477s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:440s
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:476s
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:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
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:570s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:513s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:497s
fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:553s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:411s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:609s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:616s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:487s

0d0fe916f52ad8f05dddab384ae7c90bb62ebac4 drm-tip: 2017y-12m-05d-14h-52m-17s UTC 
integration manifest
a9fba99319e9 drm/i915: use stolen_usable_size for the range sanity check
8f826a04a489 drm/i915: prefer resource_size_t for everything stolen
42ceaf431573 drm/i915: make mappable struct resource centric
653f96c78929 drm/i915: make reserved struct resource centric
906ad9ccad52 drm/i915: make dsm struct resource centric
e4fef045cc70 drm/i915: nuke the duplicated stolen discovery
209ebd8df53a x86/early-quirks: reverse the if ladders
c6793eb95980 x86/early-quirks: replace the magical increment start values
a1e3704b09b0 x86/early-quirks: Extend Intel graphics stolen memory placement to 
64bit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7420/
___
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

2017-12-05 Thread 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 = _priv->guc.fw;
+   struct intel_uc_fw *huc_fw = _priv->huc.fw;
+   int enable_guc = 0;
 
- 

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

2017-12-05 Thread 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

2017-12-05 Thread 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

2017-12-05 Thread 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-gfx] [PATCH v3 1/8] drm/i915/huc: Move firmware selection to init_early

2017-12-05 Thread 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(>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 = >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 

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

2017-12-05 Thread 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(>ct);
 
mutex_init(>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(>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 = >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-gfx] [PATCH v3 7/8] drm/i915/huc: Load HuC only if requested

2017-12-05 Thread 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(>fw, huc_ucode_xfer);
+   return intel_uc_fw_upload(>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 = >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, _priv->huc.fw);
+   if (USES_HUC(dev_priv))
+   intel_uc_fw_fetch(dev_priv, _priv->huc.fw);
+
intel_uc_fw_fetch(dev_priv, _priv->guc.fw);
 }
 
@@ -129,7 +131,9 @@ void intel_uc_fini_fw(struct drm_i915_private *dev_priv)
return;
 
intel_uc_fw_fini(_priv->guc.fw);
-   intel_uc_fw_fini(_priv->huc.fw);
+
+   if (USES_HUC(dev_priv))
+   intel_uc_fw_fini(_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 = _priv->guc;
+   struct intel_huc *huc = _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(_priv->huc);
+   if (USES_HUC(dev_priv)) {
+   ret = intel_huc_init_hw(huc);
+   if 

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

2017-12-05 Thread 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, _priv->huc.fw);
intel_uc_fw_fetch(dev_priv, _priv->guc.fw);
 }
 
 void intel_uc_fini_fw(struct drm_i915_private *dev_priv)
 {
+   if (!USES_GUC(dev_priv))
+   return;
+
intel_uc_fw_fini(_priv->guc.fw);
intel_uc_fw_fini(_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] drm/i915: Taint (TAINT_WARN) the kernel if the GPU reset fails

2017-12-05 Thread Chris Wilson
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
useful for CI, where if the GPU/driver fails we want to reboot and
restart testing rather than continue on into oblivion. For everyone
else, the warning taint is a testament to the system unreliability.

TAINT_WARN is used anytime a WARN() is emitted, which is suitable for
our purposes here as well; the driver/system may behave unexpectedly
after the failure.

v2: Also taint if the recovery fails (again history shows us that is
typically fatal).
v3: Use TAINT_WARN

References: https://bugs.freedesktop.org/show_bug.cgi?id=103514
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Daniel Vetter 
Cc: Michał Winiarski 
Reviewed-by: Joonas Lahtinen 
Acked-by: Tomi Sarvela 
---
 drivers/gpu/drm/i915/i915_drv.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7faf20aff25a..71213c4a13a8 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1897,9 +1897,9 @@ void i915_reset(struct drm_i915_private *i915, unsigned 
int flags)
disable_irq(i915->drm.irq);
ret = i915_gem_reset_prepare(i915);
if (ret) {
-   DRM_ERROR("GPU recovery failed\n");
+   dev_err(i915->drm.dev, "GPU recovery failed\n");
intel_gpu_reset(i915, ALL_ENGINES);
-   goto error;
+   goto taint;
}
 
if (!intel_has_gpu_reset(i915)) {
@@ -1916,7 +1916,7 @@ void i915_reset(struct drm_i915_private *i915, unsigned 
int flags)
}
if (ret) {
dev_err(i915->drm.dev, "Failed to reset chip\n");
-   goto error;
+   goto taint;
}
 
i915_gem_reset(i915);
@@ -1959,6 +1959,20 @@ void i915_reset(struct drm_i915_private *i915, unsigned 
int flags)
wake_up_bit(>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 CI, where if the
+* GPU/driver fails we would like to reboot and restart testing
+* rather than continue on into oblivion. For everyone else,
+* the system should still plod around, but they have been warned!
+*/
+   add_taint(TAINT_WARN, LOCKDEP_STILL_OK);
 error:
i915_gem_set_wedged(i915);
i915_gem_retire_requests(i915);
-- 
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 6/9] drm/i915: Make use of indexed write GMBUS feature

2017-12-05 Thread Ville Syrjälä
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 
> ---
>  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);
> +}

Instead of a duplicating the entire thing I'd just

- gmbus_xfer_index_read
+ gmbus_xfer_index
  {
  ...
+   if (msgs[1].flags & I2C_M_RD)
gmbus_xfer_read()
+   else
+   gmbus_xfer_write()
  ...
  }

Matches the current pattern better (no 'cmd' passed in), and
will give us the 2 byte index for free as well.

> +
>  /*
>   * 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));

Hmm. We don't have the len check for the second msg for reads. I wonder
if gmbus can actually do a zero length "read/write"?

> +}
> +
>  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, [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],
> + [i + 1]);
> + inc = 2; /* an index write is two msgs */
>   } else if (msgs[i].flags & I2C_M_RD) {
>   ret = gmbus_xfer_read(dev_priv, 

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

2017-12-05 Thread Pavel Machek
On Tue 2017-12-05 11:45:38, Daniel Vetter wrote:
> 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.

Yep. So my first question was: why would user of the machine ever want
encryption "ENABLED" or "DESIRED"? Could you answer it?

> 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

Yes, so... This patch makes it more likely to see machines with locked
down kernels, preventing developers from working with systems their
own, running hardware. That is evil, and direct threat to Free
software movement.

Users compiling their own kernels get no benefit from it. Actually it
looks like this only benefits Intel and Disney. We don't want that.

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

Well, it does not belong in kernel, no matter what is the name.

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: warning for drm/i915: Restore GT performance in headless mode with DMC loaded (rev6)

2017-12-05 Thread Patchwork
== Series Details ==

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

== 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 -> PASS   (fi-bdw-gvtdvm) fdo#103938 +1
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-kbl-r)

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:439s
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:386s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:528s
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:482s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:479s
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:271s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:540s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:363s
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:399s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:468s
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:486s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:529s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-kbl-r total:288  pass:260  dwarn:1   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:455s
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:568s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:513s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:507s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:451s
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:413s
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:629s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:489s

0d0fe916f52ad8f05dddab384ae7c90bb62ebac4 drm-tip: 2017y-12m-05d-14h-52m-17s UTC 
integration manifest
02f30d0e595d drm/i915: Restore GT performance in headless mode with DMC loaded

== Logs ==

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


Re: [Intel-gfx] [PATCH] e1000e: Taint a HW lockup

2017-12-05 Thread Chris Wilson
Quoting Chris Wilson (2017-12-05 18:00:00)
> When we see an e1000e HW lockup in CI, it is typically fatal with the
> hang repeating until the host is forcibly rebooted. Speed up that
> process by tainting the kernel, which CI can trivially detect (and is
> being used to detect similarly fatal CI conditions) and reboot soon
> after.
> 
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Tomi Sarvela 

I'm not concerned on selling this to e1000e, but if it helps improving
CI robustness, then topic/core-for-CI. Or maybe we should create a new
topic, Daniel? topic/taints-for-CI?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v3 2/9] drm/i915: Add more control to wait_for routines

2017-12-05 Thread Daniel Vetter
On Tue, Dec 05, 2017 at 12:15:01AM -0500, Sean Paul wrote:
> This patch adds a little more control to a couple wait_for routines such
> that we can avoid open-coding read/wait/timeout patterns which:
>  - need the value of the register after the wait_for
>  - run arbitrary operation for the read portion
> 
> This patch also chooses the correct sleep function (based on
> timers-howto.txt) for the polling interval the caller specifies.
> 
> Changes in v2:
> - Added to the series
> Changes in v3:
> - Rebased on drm-intel-next-queued and the new Wmin/max _wait_for
> - Removed msleep option
> 
> Suggested-by: Chris Wilson 
> Signed-off-by: Sean Paul 

Patches 1&2:

Reviewed-by: Daniel Vetter 

I can't find the dang docs for patch 3 ... needs a bit of digging or a
different victim.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_drv.h| 17 ++---
>  drivers/gpu/drm/i915/intel_uncore.c | 23 ---
>  drivers/gpu/drm/i915/intel_uncore.h | 14 +-
>  3 files changed, 39 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 64426d3e078e..852b3d161754 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -41,20 +41,21 @@
>  #include 
>  
>  /**
> - * _wait_for - magic (register) wait macro
> + * __wait_for - magic wait macro
>   *
> - * Does the right thing for modeset paths when run under kdgb or similar 
> atomic
> - * contexts. Note that it's important that we check the condition again after
> - * having timed out, since the timeout could be due to preemption or similar 
> and
> - * we've never had a chance to check the condition before the timeout.
> + * Macro to help avoid open coding check/wait/timeout patterns. Note that 
> it's
> + * important that we check the condition again after having timed out, since 
> the
> + * timeout could be due to preemption or similar and we've never had a 
> chance to
> + * check the condition before the timeout.
>   */
> -#define _wait_for(COND, US, Wmin, Wmax) ({ \
> +#define __wait_for(OP, COND, US, Wmin, Wmax) ({ \
>   unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;   \
>   long wait__ = (Wmin); /* recommended min for usleep is 10 us */ \
>   int ret__;  \
>   might_sleep();  \
>   for (;;) {  \
>   bool expired__ = time_after(jiffies, timeout__);\
> + OP; \
>   if (COND) { \
>   ret__ = 0;  \
>   break;  \
> @@ -70,7 +71,9 @@
>   ret__;  \
>  })
>  
> -#define wait_for(COND, MS)   _wait_for((COND), (MS) * 1000, 10, 1000)
> +#define _wait_for(COND, US, Wmin, Wmax)  __wait_for(;, (COND), (US), 
> (Wmin), \
> +(Wmax))
> +#define wait_for(COND, MS)   _wait_for((COND), (MS) * 1000, 10, 1000)
>  
>  /* If CONFIG_PREEMPT_COUNT is disabled, in_atomic() always reports false. */
>  #if defined(CONFIG_DRM_I915_DEBUG) && defined(CONFIG_PREEMPT_COUNT)
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index b4621271e7a2..9c7d07151f16 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1770,12 +1770,14 @@ int __intel_wait_for_register_fw(struct 
> drm_i915_private *dev_priv,
>  }
>  
>  /**
> - * intel_wait_for_register - wait until register matches expected state
> + * __intel_wait_for_register - wait until register matches expected state
>   * @dev_priv: the i915 device
>   * @reg: the register to read
>   * @mask: mask to apply to register value
>   * @value: expected value
> - * @timeout_ms: timeout in millisecond
> + * @fast_timeout_us: fast timeout in microsecond for atomic/tight wait
> + * @slow_timeout_ms: slow timeout in millisecond
> + * @out_value: optional placeholder to hold registry value
>   *
>   * This routine waits until the target register @reg contains the expected
>   * @value after applying the @mask, i.e. it waits until ::
> @@ -1786,15 +1788,18 @@ int __intel_wait_for_register_fw(struct 
> drm_i915_private *dev_priv,
>   *
>   * Returns 0 if the register matches the desired condition, or -ETIMEOUT.
>   */
> -int intel_wait_for_register(struct drm_i915_private *dev_priv,
> +int __intel_wait_for_register(struct drm_i915_private *dev_priv,
>   i915_reg_t reg,
>   u32 mask,
>   u32 value,
> - unsigned int 

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

2017-12-05 Thread Alex Deucher
On Tue, Dec 5, 2017 at 12:34 PM, Pavel Machek  wrote:
> On Tue 2017-12-05 11:45:38, Daniel Vetter wrote:
>> 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.
>
> Yep. So my first question was: why would user of the machine ever want
> encryption "ENABLED" or "DESIRED"? Could you answer it?

How about for sensitive video streams in government offices where you
want to avoid a spy potentially tapping the cable to see the video
stream?

>
>> 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
>
> Yes, so... This patch makes it more likely to see machines with locked
> down kernels, preventing developers from working with systems their
> own, running hardware. That is evil, and direct threat to Free
> software movement.
>
> Users compiling their own kernels get no benefit from it. Actually it
> looks like this only benefits Intel and Disney. We don't want that.

And just about every SoC manufacturer and google and amazon and a ton
of other companies and organizations.  Who gets to decide who's
benefit gets taken into account?

>
>> 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.
>
> Well, it does not belong in kernel, no matter what is the name.

Should we remove support for encrypted file systems and encrypted
virtual machines?  Just like them the option is there is you want to
use it.  If you don't want to, you don't have to.


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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Taint (TAINT_DIE) the kernel if the GPU reset fails (rev4)

2017-12-05 Thread Patchwork
== Series Details ==

Series: drm/i915: Taint (TAINT_DIE) the kernel if the GPU reset fails (rev4)
URL   : https://patchwork.freedesktop.org/series/34623/
State : success

== Summary ==

Series 34623v4 drm/i915: Taint (TAINT_DIE) the kernel if the GPU reset fails
https://patchwork.freedesktop.org/api/1.0/series/34623/revisions/4/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> 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:435s
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:520s
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:503s
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:490s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:472s
fi-elk-e7500 total:224  pass:162  dwarn:15  dfail:0   fail:1   skip:45 
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:369s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:261s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:475s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:444s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:520s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:473s
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:544s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
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:508s
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:414s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:609s
fi-cnl-y total:197  pass:185  dwarn:0   dfail:0   fail:0   skip:11 
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:489s

0d0fe916f52ad8f05dddab384ae7c90bb62ebac4 drm-tip: 2017y-12m-05d-14h-52m-17s UTC 
integration manifest
50f3430f4200 drm/i915: Taint (TAINT_WARN) the kernel if the GPU reset fails

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7416/
___
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

2017-12-05 Thread Sean Paul
On Tue, Dec 5, 2017 at 12:34 PM, Pavel Machek  wrote:
> On Tue 2017-12-05 11:45:38, Daniel Vetter wrote:
>> 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.
>
> Yep. So my first question was: why would user of the machine ever want
> encryption "ENABLED" or "DESIRED"? Could you answer it?
>

Sure. We have a lot of Chrome OS users who would really like to enjoy
premium hd content on their tvs.


>> 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
>
> Yes, so... This patch makes it more likely to see machines with locked
> down kernels, preventing developers from working with systems their
> own, running hardware. That is evil, and direct threat to Free
> software movement.
>
> Users compiling their own kernels get no benefit from it. Actually it
> looks like this only benefits Intel and Disney. We don't want that.
>

Major citation needed here. Did you actually read the code? If you
did, you would realize that the feature is already latent in your
computer. This patchset merely exposes how that hardware can be
enabled to encrypt your video link. Would you have the same problems
with a new whizzbang video encoding format, or is it just the "Content
Protection" name? Perhaps you'd prefer this feature was implemented in
Intel's firmware, or a userspace blob? It wouldn't change the fact
that those registers exist and _can_ be used for HDCP, it's just that
now you know about it.

Having all of the code in the open allows users to see what is
happening with their hardware, how is this a bad thing?

Sean


>> 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.
>
> Well, it does not belong in kernel, no matter what is the name.
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/fb-helper: Add .last_close and .output_poll_changed helpers (rev3)

2017-12-05 Thread Patchwork
== Series Details ==

Series: drm/fb-helper: Add .last_close and .output_poll_changed helpers (rev3)
URL   : https://patchwork.freedesktop.org/series/32332/
State : success

== Summary ==

Series 32332v3 drm/fb-helper: Add .last_close and .output_poll_changed helpers
https://patchwork.freedesktop.org/api/1.0/series/32332/revisions/3/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test gem_exec_reloc:
Subgroup basic-cpu-active:
pass   -> FAIL   (fi-gdg-551) fdo#102582

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:439s
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:512s
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:507s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:485s
fi-elk-e7500 total:224  pass:163  dwarn:14  dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:177  dwarn:1   dfail:0   fail:2   skip:108 
time:271s
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:358s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:261s
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:448s
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:475s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:537s
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:464s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:541s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:559s
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:503s
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:414s
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:626s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:492s
fi-byt-n2820 failed to collect. IGT log at Patchwork_7418/fi-byt-n2820/igt.log

0d0fe916f52ad8f05dddab384ae7c90bb62ebac4 drm-tip: 2017y-12m-05d-14h-52m-17s UTC 
integration manifest
55265d6c7050 drm/tegra: Use drm_fb_helper_lastclose() and _poll_changed()
9fafdf63c834 drm/rockchip: Use drm_fb_helper_lastclose() and _poll_changed()
df3bbded40da drm/radeon: Use drm_fb_helper_lastclose() and _poll_changed()
333f1890023d drm/omap: Use drm_fb_helper_lastclose() and _poll_changed()
0c6eec2e08a3 drm/nouveau: Use drm_fb_helper_output_poll_changed()
cdf2e7cf9bbb drm/msm: Use drm_fb_helper_lastclose() and _poll_changed()
6e8639cd8208 drm/gma500: Use drm_fb_helper_lastclose() and _poll_changed()
0e6a351972ee drm/exynos: Use drm_fb_helper_lastclose() and _poll_changed()
f5ebbfb307a2 drm/armada: Use drm_fb_helper_lastclose() and _poll_changed()
1232ff1b16b0 drm/amdgpu: Use drm_fb_helper_lastclose() and _poll_changed()
97f12a3e8c50 drm/amd/display: Use drm_fb_helper_poll_changed()

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7418/
___
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

2017-12-05 Thread Daniel Vetter
On Tue, Dec 05, 2017 at 12:15:08AM -0500, Sean Paul wrote:
> This patch adds HDCP support for DisplayPort connectors by implementing
> the intel_hdcp_shim.
> 
> Most of this is straightforward read/write from/to DPCD registers. One
> thing worth pointing out is the Aksv output bit. It wasn't easily
> separable like it's HDMI counterpart, so it's crammed in with the rest
> of it.
> 
> Changes in v2:
> - Moved intel_hdcp_check_link out of intel_dp_check_link and only call
>   it on short pulse. Since intel_hdcp_check_link does its own locking,
>   this ensures we don't deadlock when intel_dp_check_link is called
>   holding connection_mutex.
> - Rebased on drm-intel-next
> Changes in v3:
> - Initialize new worker
> - Move intel_hdcp_check_link further out to avoid calling it while
>   holding _any_ locks
> 
> Signed-off-by: Sean Paul 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 248 
> ++--
>  1 file changed, 241 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index c603d4c903e1..dc303e18c1dd 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -36,7 +36,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include "intel_drv.h"
>  #include 
>  #include "i915_drv.h"
> @@ -1025,10 +1027,29 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp 
> *intel_dp,
>  DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
>  }
>  
> +static uint32_t intel_dp_get_aux_send_ctl(struct intel_dp *intel_dp,
> +   bool has_aux_irq,
> +   int send_bytes,
> +   uint32_t aux_clock_divider,
> +   bool aksv_write)
> +{
> + uint32_t val = 0;
> +
> + if (aksv_write) {
> + send_bytes += 5;
> + val |= DP_AUX_CH_CTL_AUX_AKSV_SELECT;
> + }
> +
> + return val | intel_dp->get_aux_send_ctl(intel_dp,
> + has_aux_irq,
> + send_bytes,
> + aux_clock_divider);
> +}
> +
>  static int
>  intel_dp_aux_ch(struct intel_dp *intel_dp,
>   const uint8_t *send, int send_bytes,
> - uint8_t *recv, int recv_size)
> + uint8_t *recv, int recv_size, bool aksv_write)
>  {
>   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>   struct drm_i915_private *dev_priv =
> @@ -1088,10 +1109,11 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
>   }
>  
>   while ((aux_clock_divider = intel_dp->get_aux_clock_divider(intel_dp, 
> clock++))) {
> - u32 send_ctl = intel_dp->get_aux_send_ctl(intel_dp,
> -   has_aux_irq,
> -   send_bytes,
> -   aux_clock_divider);
> + u32 send_ctl = intel_dp_get_aux_send_ctl(intel_dp,
> +  has_aux_irq,
> +  send_bytes,
> +  aux_clock_divider,
> +  aksv_write);
>  
>   /* Must try at least 3 times according to DP spec */
>   for (try = 0; try < 5; try++) {
> @@ -1228,7 +1250,8 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
> drm_dp_aux_msg *msg)
>   if (msg->buffer)
>   memcpy(txbuf + HEADER_SIZE, msg->buffer, msg->size);
>  
> - ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize);
> + ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize,
> +   false);
>   if (ret > 0) {
>   msg->reply = rxbuf[0] >> 4;
>  
> @@ -1250,7 +1273,8 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
> drm_dp_aux_msg *msg)
>   if (WARN_ON(rxsize > 20))
>   return -E2BIG;
>  
> - ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize);
> + ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize,
> +   false);
>   if (ret > 0) {
>   msg->reply = rxbuf[0] >> 4;
>   /*
> @@ -4981,6 +5005,203 @@ void intel_dp_encoder_suspend(struct intel_encoder 
> *intel_encoder)
>   pps_unlock(intel_dp);
>  }
>  
> +static
> +int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
> + u8 *an)
> +{
> + struct intel_dp *intel_dp = enc_to_intel_dp(_dig_port->base.base);
> + uint8_t txbuf[4], rxbuf[2], reply = 0;
> + ssize_t dpcd_ret;
> + int ret;
> +
> + 

[Intel-gfx] [PATCH v3 11/11] drm/tegra: Use drm_fb_helper_lastclose() and _poll_changed()

2017-12-05 Thread Noralf Trønnes
This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Thierry Reding 
Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/tegra/drm.c | 13 ++---
 drivers/gpu/drm/tegra/drm.h |  4 
 drivers/gpu/drm/tegra/fb.c  | 14 --
 3 files changed, 2 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 52552b9b89ef..f157bc675269 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -120,7 +120,7 @@ static int tegra_atomic_commit(struct drm_device *drm,
 static const struct drm_mode_config_funcs tegra_drm_mode_funcs = {
.fb_create = tegra_fb_create,
 #ifdef CONFIG_DRM_FBDEV_EMULATION
-   .output_poll_changed = tegra_fb_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
 #endif
.atomic_check = drm_atomic_helper_check,
.atomic_commit = tegra_atomic_commit,
@@ -286,15 +286,6 @@ static void tegra_drm_context_free(struct 
tegra_drm_context *context)
kfree(context);
 }
 
-static void tegra_drm_lastclose(struct drm_device *drm)
-{
-#ifdef CONFIG_DRM_FBDEV_EMULATION
-   struct tegra_drm *tegra = drm->dev_private;
-
-   tegra_fbdev_restore_mode(tegra->fbdev);
-#endif
-}
-
 static struct host1x_bo *
 host1x_bo_lookup(struct drm_file *file, u32 handle)
 {
@@ -1100,7 +1091,7 @@ static struct drm_driver tegra_drm_driver = {
.unload = tegra_drm_unload,
.open = tegra_drm_open,
.postclose = tegra_drm_postclose,
-   .lastclose = tegra_drm_lastclose,
+   .lastclose = drm_fb_helper_lastclose,
 
 #if defined(CONFIG_DEBUG_FS)
.debugfs_init = tegra_debugfs_init,
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index ddae331ad8b6..0009f6ea21b6 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -188,10 +188,6 @@ int tegra_drm_fb_init(struct drm_device *drm);
 void tegra_drm_fb_exit(struct drm_device *drm);
 void tegra_drm_fb_suspend(struct drm_device *drm);
 void tegra_drm_fb_resume(struct drm_device *drm);
-#ifdef CONFIG_DRM_FBDEV_EMULATION
-void tegra_fbdev_restore_mode(struct tegra_fbdev *fbdev);
-void tegra_fb_output_poll_changed(struct drm_device *drm);
-#endif
 
 extern struct platform_driver tegra_dc_driver;
 extern struct platform_driver tegra_hdmi_driver;
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 80540c1c66dc..8dfe3c6c217e 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -361,20 +361,6 @@ static void tegra_fbdev_exit(struct tegra_fbdev *fbdev)
drm_fb_helper_fini(>base);
tegra_fbdev_free(fbdev);
 }
-
-void tegra_fbdev_restore_mode(struct tegra_fbdev *fbdev)
-{
-   if (fbdev)
-   drm_fb_helper_restore_fbdev_mode_unlocked(>base);
-}
-
-void tegra_fb_output_poll_changed(struct drm_device *drm)
-{
-   struct tegra_drm *tegra = drm->dev_private;
-
-   if (tegra->fbdev)
-   drm_fb_helper_hotplug_event(>fbdev->base);
-}
 #endif
 
 int tegra_drm_fb_prepare(struct drm_device *drm)
-- 
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 6/9] drm/i915: Make use of indexed write GMBUS feature

2017-12-05 Thread 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, [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],
> + [i + 1]);
> + inc = 2; /* an index write is two msgs */
>   } else if (msgs[i].flags & I2C_M_RD) {
>   ret = gmbus_xfer_read(dev_priv, [i], 0);
>   } else {
> - ret = gmbus_xfer_write(dev_priv, [i]);
> + ret = gmbus_xfer_write(dev_priv, [i], 0);
>   }
>  
>   if (!ret)
> -- 
> 2.15.0.531.g2ccb3012c9-goog
> 
> ___
> Intel-gfx mailing list
> 

Re: [Intel-gfx] [PATCH v3 8/9] drm/i915: Implement HDCP for HDMI

2017-12-05 Thread Daniel Vetter
On Tue, Dec 05, 2017 at 12:15:07AM -0500, Sean Paul wrote:
> This patch adds HDCP support for HDMI connectors by implementing
> the intel_hdcp_shim.
> 
> Nothing too special, just a bunch of DDC reads/writes.
> 
> Changes in v2:
> - Rebased on drm-intel-next
> Changes in v3:
> - Initialize new worker
> 
> Signed-off-by: Sean Paul 
> ---
>  drivers/gpu/drm/i915/i915_reg.h   |   1 +
>  drivers/gpu/drm/i915/intel_ddi.c  |  50 
>  drivers/gpu/drm/i915/intel_drv.h  |   2 +
>  drivers/gpu/drm/i915/intel_hdmi.c | 257 
> ++
>  4 files changed, 310 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 107e16392710..79944ab4218a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8450,6 +8450,7 @@ enum skl_power_gate {
>  #define  TRANS_DDI_EDP_INPUT_A_ONOFF (4<<12)
>  #define  TRANS_DDI_EDP_INPUT_B_ONOFF (5<<12)
>  #define  TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
> +#define  TRANS_DDI_HDCP_SIGNALLING   (1<<9)
>  #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC   (1<<8)
>  #define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
>  #define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index eff3b51872eb..a179fd9968a5 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1615,6 +1615,56 @@ void intel_ddi_disable_transcoder_func(struct 
> drm_i915_private *dev_priv,
>   I915_WRITE(reg, val);
>  }
>  
> +int intel_ddi_disable_hdcp_signalling(struct intel_encoder *intel_encoder)
> +{
> + struct drm_device *dev = intel_encoder->base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + enum pipe pipe = 0;
> + int ret = 0;
> + uint32_t tmp;
> +
> + if (!intel_display_power_get_if_enabled(dev_priv,
> + intel_encoder->power_domain))
> + return -ENXIO;
> +
> + if (!intel_encoder->get_hw_state(intel_encoder, )) {
> + ret = -EIO;
> + goto out;
> + }

Hm, do we really need these checks here? With the new worker design I
think they'd indicate a synchronization bug (misplaced
cancel_delayed_work_sync probably).

If you want to keep them for safetey please wrap in a WARN_ON. Same for
the one below.

Otherwise looks all good to me.

> +
> + tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
> + tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
> + I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
> +out:
> + intel_display_power_put(dev_priv, intel_encoder->power_domain);
> + return ret;
> +}
> +
> +int intel_ddi_enable_hdcp_signalling(struct intel_encoder *intel_encoder)
> +{
> + struct drm_device *dev = intel_encoder->base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + enum pipe pipe = 0;
> + int ret = 0;
> + uint32_t tmp;
> +
> + if (!intel_display_power_get_if_enabled(dev_priv,
> + intel_encoder->power_domain))
> + return -ENXIO;
> +
> + if (!intel_encoder->get_hw_state(intel_encoder, )) {
> + ret = -EIO;
> + goto out;
> + }
> +
> + tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
> + tmp |= TRANS_DDI_HDCP_SIGNALLING;
> + I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
> +out:
> + intel_display_power_put(dev_priv, intel_encoder->power_domain);
> + return ret;
> +}
> +
>  bool intel_ddi_connector_get_hw_state(struct intel_connector 
> *intel_connector)
>  {
>   struct drm_device *dev = intel_connector->base.dev;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 6f47a4227f5f..0b4405f3e988 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1379,6 +1379,8 @@ void intel_ddi_compute_min_voltage_level(struct 
> drm_i915_private *dev_priv,
>  u32 bxt_signal_levels(struct intel_dp *intel_dp);
>  uint32_t ddi_signal_levels(struct intel_dp *intel_dp);
>  u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder);
> +int intel_ddi_enable_hdcp_signalling(struct intel_encoder *intel_encoder);
> +int intel_ddi_disable_hdcp_signalling(struct intel_encoder *intel_encoder);
>  
>  unsigned int intel_fb_align_height(const struct drm_framebuffer *fb,
>  int plane, unsigned int height);
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 9d5e72728475..17a525b9fcf9 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "intel_drv.h"
>  #include 
> @@ -873,6 +874,252 @@ void intel_dp_dual_mode_set_tmds_output(struct 
> intel_hdmi *hdmi, bool enable)
>adapter, enable);
>  }
>  
> +static int 

  1   2   >