[Intel-gfx] ✓ Fi.CI.IGT: success for ICP initial support (rev2)

[Patchwork]

== Series Details ==

Series: ICP initial support (rev2)
URL   : https://patchwork.freedesktop.org/series/36350/
State : success

== Summary ==

Test kms_flip:
Subgroup 2x-vblank-vs-dpms-suspend:
skip   -> PASS   (shard-hsw)
Subgroup plain-flip-fb-recreate:
fail   -> PASS   (shard-apl) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623
Test perf:
Subgroup enable-disable:
fail   -> PASS   (shard-apl) fdo#103715
Subgroup oa-exponents:
pass   -> FAIL   (shard-apl) fdo#102254
Subgroup buffer-fill:
fail   -> PASS   (shard-apl) fdo#103755
Test gem_tiled_swapping:
Subgroup non-threaded:
incomplete -> PASS   (shard-hsw) fdo#104218
Test testdisplay:
dmesg-warn -> PASS   (shard-apl)

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#103755 https://bugs.freedesktop.org/show_bug.cgi?id=103755
fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218

shard-apltotal:2780 pass:1716 dwarn:1   dfail:0   fail:23  skip:1040 
time:14777s
shard-hswtotal:2780 pass:1724 dwarn:1   dfail:0   fail:12  skip:1042 
time:15636s
shard-snbtotal:2780 pass:1316 dwarn:1   dfail:0   fail:13  skip:1450 
time:8066s
Blacklisted hosts:
shard-kbltotal:2702 pass:1777 dwarn:1   dfail:0   fail:24  skip:900 
time:10707s

== Logs ==

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

[Patchwork]

== Series Details ==

Series: DRM management via cgroups
URL   : https://patchwork.freedesktop.org/series/36837/
State : warning

== Summary ==

Series 36837v1 DRM management via cgroups
https://patchwork.freedesktop.org/api/1.0/series/36837/revisions/1/mbox/

Test core_auth:
Subgroup basic-auth:
pass   -> DMESG-WARN (fi-gdg-551)
pass   -> DMESG-WARN (fi-blb-e6850)
pass   -> DMESG-WARN (fi-pnv-d510)
pass   -> DMESG-WARN (fi-bwr-2160)
pass   -> DMESG-WARN (fi-elk-e7500)
pass   -> DMESG-WARN (fi-ilk-650)
pass   -> DMESG-WARN (fi-snb-2520m)
pass   -> DMESG-WARN (fi-snb-2600)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-byt-j1900)
pass   -> DMESG-WARN (fi-byt-n2820)
pass   -> DMESG-WARN (fi-hsw-4770)
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> DMESG-WARN (fi-bdw-5557u)
pass   -> DMESG-WARN (fi-bdw-gvtdvm)
pass   -> DMESG-WARN (fi-bsw-n3050)
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6600u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6700k2)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-dsi)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-kbl-7567u)
pass   -> DMESG-WARN (fi-kbl-r)
pass   -> DMESG-WARN (fi-glk-1)
Test core_prop_blob:
Subgroup basic:
pass   -> DMESG-WARN (fi-gdg-551)
pass   -> DMESG-WARN (fi-blb-e6850)
pass   -> DMESG-WARN (fi-pnv-d510)
pass   -> DMESG-WARN (fi-bwr-2160)
pass   -> DMESG-WARN (fi-elk-e7500)
pass   -> DMESG-WARN (fi-ilk-650)
pass   -> DMESG-WARN (fi-snb-2520m)
pass   -> DMESG-WARN (fi-snb-2600)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-byt-j1900)
pass   -> DMESG-WARN (fi-byt-n2820)
pass   -> DMESG-WARN (fi-hsw-4770)
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> DMESG-WARN (fi-bdw-5557u)
pass   -> DMESG-WARN (fi-bdw-gvtdvm)
pass   -> DMESG-WARN (fi-bsw-n3050)
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6600u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6700k2)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-dsi)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-kbl-7567u)
pass   -> DMESG-WARN (fi-kbl-r)
pass   -> DMESG-WARN (fi-glk-1)
Test debugfs_test:
Subgroup read_all_entries:
pass   -> DMESG-WARN (fi-gdg-551)
pass   -> DMESG-WARN (fi-blb-e6850)
pass   -> DMESG-WARN (fi-pnv-d510)
pass   -> DMESG-WARN (fi-bwr-2160)
pass   -> DMESG-WARN (fi-elk-e7500) fdo#103989 +7
pass   -> DMESG-WARN (fi-ilk-650)
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
pass   -> DMESG-WARN (fi-snb-2600)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-byt-j1900)
pass   -> DMESG-WARN (fi-byt-n2820)
pass   -> DMESG-WARN (fi-hsw-4770)
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> DMESG-WARN (fi-bdw-5557u)
pass   -> DMESG-WARN (fi-bdw-gvtdvm) fdo#103938 +1
pass   -> DMESG-WARN (fi-bsw-n3050)
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6600u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6700k2)
pass   -> DMESG-WARN 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Implement display w/a #1143

[Patchwork]

== Series Details ==

Series: drm/i915: Implement display w/a #1143
URL   : https://patchwork.freedesktop.org/series/36813/
State : failure

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623 +1
Test perf:
Subgroup oa-exponents:
pass   -> FAIL   (shard-apl) fdo#102254
Subgroup enable-disable:
pass   -> FAIL   (shard-apl) fdo#103715
Test kms_flip:
Subgroup plain-flip-fb-recreate:
fail   -> PASS   (shard-apl) fdo#100368 +1
Subgroup 2x-vblank-vs-dpms-suspend:
pass   -> SKIP   (shard-hsw)
Subgroup vblank-vs-modeset-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#104682
Subgroup 2x-vblank-vs-dpms-suspend-interruptible:
pass   -> INCOMPLETE (shard-hsw)

fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#104682 https://bugs.freedesktop.org/show_bug.cgi?id=104682

shard-apltotal:2780 pass:1715 dwarn:1   dfail:0   fail:24  skip:1040 
time:14733s
shard-hswtotal:2754 pass:1709 dwarn:1   dfail:0   fail:11  skip:1029 
time:13799s
shard-snbtotal:2780 pass:1316 dwarn:1   dfail:0   fail:13  skip:1450 
time:8087s
Blacklisted hosts:
shard-kbltotal:2780 pass:1834 dwarn:1   dfail:0   fail:26  skip:919 
time:3s

== Logs ==

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

[Intel-gfx] [PATCH RFC 9/9] drm/i915: Add context priority to debugfs

[Matt Roper]

Update i915_context_status to include priority.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index cc659b4b2a45..075b269ac63b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1915,6 +1915,8 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
seq_putc(m, ctx->remap_slice ? 'R' : 'r');
seq_putc(m, '\n');
 
+   seq_printf(m, "Priority %d\n", ctx->priority);
+
for_each_engine(engine, dev_priv, id) {
struct intel_context *ce = >engine[engine->id];
 
-- 
2.14.3

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

[Intel-gfx] [PATCH RFC 8/9] drm/i915: Allow default context priority to be set via cgroup parameter

[Matt Roper]

GPU contexts are usually created with "normal" priority as a starting point and
then may be adjusted from their either via explicit methods (context_set_param)
or implicit methods (boosts/penalization due to runtime behavior).  Let's allow
a system integrator to override this starting GPU priority for a group of
processes by setting a parameter on the cgroup that these processes belong to.

Cc: Tejun Heo 
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/i915_cgroups.c | 162 
 drivers/gpu/drm/i915/i915_drv.c |   4 +
 drivers/gpu/drm/i915/i915_drv.h |  32 +++
 drivers/gpu/drm/i915/i915_gem_context.c |   2 +-
 include/uapi/drm/i915_drm.h |   9 ++
 6 files changed, 209 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/i915_cgroups.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3bddd8a06806..b9f00a6c1e64 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -47,6 +47,7 @@ i915-y := i915_drv.o \
 i915-$(CONFIG_COMPAT)   += i915_ioc32.o
 i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o
 i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o
+i915-$(CONFIG_CGROUPS)  += i915_cgroups.o
 
 # GEM code
 i915-y += i915_cmd_parser.o \
diff --git a/drivers/gpu/drm/i915/i915_cgroups.c 
b/drivers/gpu/drm/i915/i915_cgroups.c
new file mode 100644
index ..6e42ba01b8e8
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_cgroups.c
@@ -0,0 +1,162 @@
+/*
+ * Copyright © 2018 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.
+ */
+
+/**
+ * DOC: cgroups integration
+ *
+ * i915 makes use of the DRM cgroup helper library.  Currently i915 only
+ * supports a single cgroup parameter:
+ *
+ * I915_CGRP_DEF_CONTEXT_PRIORITY -
+ *   Setting this parameter on a cgroup will cause GPU contexts created by
+ *   processes in the cgroup to start with the specified default priority (in
+ *   the range of I915_CONTEXT_MIN_USER_PRIORITY to
+ *   I915_CONTEXT_MAX_USER_PRIORITY) instead of the usual priority of
+ *   I915_CONTEXT_DEFAULT_PRIORITY.  This cgroup parameter only provides
+ *   a default starting point; the context priorities may still be overridden
+ *   by other mechanisms (e.g., I915_CONTEXT_PARAM_PRIORITY) or adjusted at
+ *   runtime due to system behavior.
+ */
+
+#include 
+#include 
+
+#include "i915_drv.h"
+
+static struct drm_cgroup_funcs i915_cgrp = {
+   .set_param = drm_cgrp_helper_set_param,
+};
+
+static struct drm_cgroup_helper_data *
+i915_cgrp_alloc_params(void)
+{
+   struct i915_cgroup_data *data;
+
+   data = kzalloc(sizeof *data, GFP_KERNEL);
+   if (!data)
+   return ERR_PTR(-ENOMEM);
+
+   return >base;
+}
+
+static int
+i915_cgrp_update_param(struct drm_cgroup_helper_data *data,
+  uint64_t param, int64_t val)
+{
+   struct i915_cgroup_data *idata =
+   container_of(data, struct i915_cgroup_data, base);
+
+   if (param != I915_CGRP_DEF_CONTEXT_PRIORITY) {
+   DRM_DEBUG_DRIVER("Invalid cgroup parameter %llu\n", param);
+   return -EINVAL;
+   }
+
+   if (val > I915_CONTEXT_MAX_USER_PRIORITY ||
+   val < I915_CONTEXT_MIN_USER_PRIORITY) {
+   DRM_DEBUG_DRIVER("Context priority must be in range (%d,%d)\n",
+I915_CONTEXT_MIN_USER_PRIORITY,
+I915_CONTEXT_MAX_USER_PRIORITY);
+   return -EINVAL;
+   }
+
+   idata->priority = val;
+
+   return 0;
+}
+
+static int
+i915_cgrp_read_param(struct drm_cgroup_helper_data *data,
+uint64_t param, int64_t *val)
+{
+   struct i915_cgroup_data *idata =
+   container_of(data, struct 

[Intel-gfx] [PATCH RFC 2/9] cgroup: Add notifier call chain for cgroup destruction

[Matt Roper]

Drivers or other kernel subsystems may allow subsystem-specific policy and
configuration to be applied to cgroups.  If these subsystems track private data
on a per-cgroup basis, they need a way to be notified about cgroup destruction
so that they can clean up their own internal data for that cgroup.  Let's add a
blocking_notifier that will be called whenever a cgroup in the v2 hierarchy is
destroyed to allow this cleanup.

I'm arbitrarily restricting this behavior to the default (cgroup-v2) hierarchy
for now since I don't anticipate it being terribly useful on the legacy
hierarchies.  We can certainly relax that restriction if someone comes up with
a use case that needs this on the v1 hierarchies.

Cc: Tejun Heo 
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper 
---
 include/linux/cgroup.h |  3 +++
 kernel/cgroup/cgroup.c | 18 ++
 2 files changed, 21 insertions(+)

diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 473e0c0abb86..c9896027ed99 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -43,6 +43,9 @@
 /* walk all threaded css_sets in the domain */
 #define CSS_TASK_ITER_THREADED (1U << 1)
 
+/* Driver-registered callbacks for cgroup destruction */
+extern struct blocking_notifier_head cgroup_destroy_notifier_list;
+
 /* a css_task_iter should be treated as an opaque object */
 struct css_task_iter {
struct cgroup_subsys*ss;
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 2cf06c274e4c..f12c32c6ec7f 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -75,6 +75,15 @@
 DEFINE_MUTEX(cgroup_mutex);
 DEFINE_SPINLOCK(css_set_lock);
 
+/*
+ * Driver-registered callbacks for cgroup destruction.  Drivers may wish to
+ * track their own per-cgroup data.  Registering a callback on this list will
+ * allow them to detect cgroup destruction and perform any appropriate cleanup
+ * of that data when the cgroup is destroyed.
+ */
+BLOCKING_NOTIFIER_HEAD(cgroup_destroy_notifier_list);
+EXPORT_SYMBOL_GPL(cgroup_destroy_notifier_list);
+
 #ifdef CONFIG_PROVE_RCU
 EXPORT_SYMBOL_GPL(cgroup_mutex);
 EXPORT_SYMBOL_GPL(css_set_lock);
@@ -5086,6 +5095,15 @@ static int cgroup_destroy_locked(struct cgroup *cgrp)
for_each_css(css, ssid, cgrp)
kill_css(css);
 
+   /*
+* Notify listeners of cgroup destruction on the default hierarchy.
+* Drivers that store per-cgroup data may register for callback to know
+* when it's safe to reap that data.
+*/
+   if (cgroup_on_dfl(cgrp))
+   blocking_notifier_call_chain(_destroy_notifier_list,
+0, cgrp);
+
/*
 * Remove @cgrp directory along with the base files.  @cgrp has an
 * extra ref on its kn.
-- 
2.14.3

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

[Intel-gfx] [PATCH RFC 5/9] drm: Introduce DRM_IOCTL_CGROUP_SETPARAM

[Matt Roper]

cgroups are a convenient mechanism for system integrators to organize processes
into a logical hierarchy for system configuration purposes.  cgroups can be
used to control resources (memory, cpu time share, etc.) or apply other types
of subsystem-specific policy (network priorty, BPF programs, etc.) to subsets
of processes.

The DRM subsystem manages several concepts that would be good candidates for
exposure and control via the existing cgroup hierarchy --- GPU priorities for
sets of applications, limits on discrete or stolen video memories, etc.  Let's
add a 'setparam' ioctl to the DRM subsystem that allows a userspace tool to
set parameters on a cgroup for use by a DRM driver.

DRM cgroup parameters are a (u64 param, s64 value) pair associated with a
cgroup for a specific drm_device.  In the future there may potentially be both
driver-specific parameters as well as common parameters supported by all DRM
drivers.  We define parameter keys 0-0xFF as being driver-specific
parameters and reserve all higher keys for DRM core use.

Cc: Tejun Heo 
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/drm_cgroup.c | 120 +++
 drivers/gpu/drm/drm_ioctl.c  |   5 ++
 include/drm/drm_cgroup.h |  38 ++
 include/drm/drm_device.h |   8 +++
 include/uapi/drm/drm.h   |  10 
 6 files changed, 182 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_cgroup.c
 create mode 100644 include/drm/drm_cgroup.h

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index dd5ae67f8e2b..351f3817bc27 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -30,6 +30,7 @@ drm-$(CONFIG_OF) += drm_of.o
 drm-$(CONFIG_AGP) += drm_agpsupport.o
 drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
 drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+drm-$(CONFIG_CGROUPS) += drm_cgroup.o
 
 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
diff --git a/drivers/gpu/drm/drm_cgroup.c b/drivers/gpu/drm/drm_cgroup.c
new file mode 100644
index ..0d9187ee435d
--- /dev/null
+++ b/drivers/gpu/drm/drm_cgroup.c
@@ -0,0 +1,120 @@
+/*
+ * Copyright (c) 2018 Intel Corporation
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+
+/**
+ * DOC: cgroup handling
+ *
+ * cgroups are a core kernel mechanism for organizing OS processes into logical
+ * groupings to which policy configuration or resource management may be
+ * applied.  Some DRM drivers may control resources or have policy settings
+ * that a system integrator would wish to configure according to the system
+ * cgroups hierarchy.  To support such use cases, the DRM framework allows
+ * drivers to track 'parameters' on a per-cgroup basis.  Parameters are a (u64
+ * key, s64 value) pair which would generally be set on specific cgroups
+ * during system configuration (e.g., by a sysv init script or systemd service)
+ * and then used by the driver at runtime to manage GPU-specific resources or
+ * control driver-specific policy.
+ */
+
+/**
+ * drm_cgroup_setparam_ioctl
+ * @dev: DRM device
+ * @data: data pointer for the ioctl
+ * @file_priv: DRM file handle for the ioctl call
+ *
+ * Set DRM-specific parameters for a cgroup
+ */
+int
+drm_cgroup_setparam_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+   struct drm_cgroup_setparam *req = data;
+   struct cgroup *cgrp;
+   struct file *f;
+   struct inode *inode = NULL;
+   int ret;
+
+   /*
+* We'll let drivers create their own parameters with ID's from
+* 0-0xFF.  We'll reserve parameter ID's above that range 

[Intel-gfx] [PATCH RFC 6/9] drm: Add cgroup helper library

[Matt Roper]

Most DRM drivers will want to handle the CGROUP_SETPARAM ioctl by looking up a
driver-specific per-cgroup data structure (or allocating a new one) and storing
the supplied parameter value into the data structure (possibly after doing some
checking and sanitization on the provided value).  Let's provide a helper
library for drivers that will take care of the details of storing per-cgroup
data structures in a hashtable and destroying those structures if/when the
cgroup itself is removed.

Cc: Tejun Heo 
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/drm_cgroup_helper.c | 244 
 include/drm/drm_cgroup_helper.h | 153 ++
 include/drm/drm_device.h|   5 +
 4 files changed, 403 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_cgroup_helper.c
 create mode 100644 include/drm/drm_cgroup_helper.h

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 351f3817bc27..45cd58d66658 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -31,6 +31,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
 drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
 drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 drm-$(CONFIG_CGROUPS) += drm_cgroup.o
+drm-$(CONFIG_CGROUPS) += drm_cgroup_helper.o
 
 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
diff --git a/drivers/gpu/drm/drm_cgroup_helper.c 
b/drivers/gpu/drm/drm_cgroup_helper.c
new file mode 100644
index ..b62843456f63
--- /dev/null
+++ b/drivers/gpu/drm/drm_cgroup_helper.c
@@ -0,0 +1,244 @@
+/*
+ * Copyright (c) 2018 Intel Corporation
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+
+/**
+ * DOC: cgroup helper library
+ *
+ * This helper library provides implementations for the DRM cgroup parameter
+ * entry points.  Most drivers will wish to store driver-specific data
+ * associated with individual cgroups; this helper will manage the storage
+ * and lookup of these data structures and will ensure that they are properly
+ * destroyed when the corresponding cgroup is destroyed.
+ *
+ * This helper library should be initialized by calling drm_cgrp_helper_init()
+ * and torn down (on driver unload) by calling drm_cgrp_helper_shutdown().
+ * Drivers wishing to make use of this helper library should subclass the
+ * _cgroup_helper_data structure to store values for any driver-specific
+ * cgroup parameters and provide implementations of at least
+ * _cgroup_helper.alloc_params, _cgroup_helper.update_param, and
+ * _cgroup_helper.read_param.
+ */
+
+/**
+ * drm_cgrp_helper_set_param - set parameter value for cgroup
+ * @dev: DRM device
+ * @cgrp: cgroup to set parameter for
+ * @param: parameter to set
+ * @val: value to assign to parameter
+ *
+ * Provides a default handler for the CGROUP_SETPARAM ioctl.  At this time
+ * parameters may only be set on cgroups in the v2 hierarchy.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure
+ */
+int
+drm_cgrp_helper_set_param(struct drm_device *dev,
+ struct cgroup *cgrp,
+ uint64_t param,
+ int64_t val)
+{
+   struct drm_cgroup_helper *helper = dev->cgroup_helper;
+   struct drm_cgroup_helper_data *data;
+   int ret;
+
+   if (WARN_ON(!helper))
+   return -EINVAL;
+
+   mutex_lock(>hash_mutex);
+
+   /*
+* Search for an existing parameter set for this cgroup and update
+* it if found.
+*/
+   hash_for_each_possible(helper->param_hash, data, node, cgrp->id) {
+   if (data->cgroup == cgrp) {
+   

[Intel-gfx] [PATCH RFC 7/9] drm: Add helper to obtain cgroup of drm_file's owning process

[Matt Roper]

Cc: Tejun Heo 
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper 
---
 include/drm/drm_file.h | 28 
 1 file changed, 28 insertions(+)

diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 0e0c868451a5..08855a99069c 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -32,6 +32,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -378,4 +379,31 @@ void drm_event_cancel_free(struct drm_device *dev,
 void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event 
*e);
 void drm_send_event(struct drm_device *dev, struct drm_pending_event *e);
 
+#ifdef CONFIG_CGROUPS
+/**
+ * drm_file_get_cgroup - obtain cgroup for drm_file's owning process
+ * @file_priv: DRM file
+ * @root: cgroup hierarchy to search for process in
+ *
+ * Obtains the cgroup from a specific hierarchy that the drm_file's owning
+ * process belongs to.  The cgroup may be used to set driver-specific
+ * policy (priority, vram usage, etc.).
+ */
+static inline struct cgroup *
+drm_file_get_cgroup(struct drm_file *file_priv, struct cgroup_root *root)
+{
+   struct task_struct *task = pid_task(file_priv->pid, PIDTYPE_PID);
+   struct cgroup *cgrp;
+
+   mutex_lock(_mutex);
+   cgrp = task_cgroup_from_root(task, root);
+   mutex_unlock(_mutex);
+
+   return cgrp;
+}
+#else
+static inline struct cgroup *
+drm_file_get_cgroup(struct drm_file *file_priv) { return NULL; }
+#endif
+
 #endif /* _DRM_FILE_H_ */
-- 
2.14.3

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

[Intel-gfx] [PATCH RFC 1/9] kernfs: Export kernfs_get_inode

[Matt Roper]

Drivers may wish to access a cgroup's inode to perform permission checks on
driver-specific operations.

Cc: Tejun Heo 
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper 
---
 fs/kernfs/inode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/kernfs/inode.c b/fs/kernfs/inode.c
index a34303981deb..e1e8a0404c5b 100644
--- a/fs/kernfs/inode.c
+++ b/fs/kernfs/inode.c
@@ -272,6 +272,7 @@ struct inode *kernfs_get_inode(struct super_block *sb, 
struct kernfs_node *kn)
 
return inode;
 }
+EXPORT_SYMBOL(kernfs_get_inode);
 
 /*
  * The kernfs_node serves as both an inode and a directory entry for
-- 
2.14.3

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

[Intel-gfx] [PATCH RFC 3/9] cgroup: Export cgroup_on_dfl() to drivers

[Matt Roper]

Drivers may wish to limit their own cgroup operations to cgroups in the
cgroup-v2 hierarchy.  Let's make this helper function usable outside the cgroup
core code.

Cc: Tejun Heo 
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper 
---
 include/linux/cgroup.h  | 2 ++
 kernel/cgroup/cgroup-internal.h | 1 -
 kernel/cgroup/cgroup.c  | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index c9896027ed99..1c1758ac1a97 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -656,6 +656,8 @@ static inline union kernfs_node_id 
*cgroup_get_kernfs_id(struct cgroup *cgrp)
 
 void cgroup_path_from_kernfs_id(const union kernfs_node_id *id,
char *buf, size_t buflen);
+bool cgroup_on_dfl(const struct cgroup *cgrp);
+
 #else /* !CONFIG_CGROUPS */
 
 struct cgroup_subsys_state;
diff --git a/kernel/cgroup/cgroup-internal.h b/kernel/cgroup/cgroup-internal.h
index b928b27050c6..7338083ee3bc 100644
--- a/kernel/cgroup/cgroup-internal.h
+++ b/kernel/cgroup/cgroup-internal.h
@@ -156,7 +156,6 @@ static inline void get_css_set(struct css_set *cset)
 }
 
 bool cgroup_ssid_enabled(int ssid);
-bool cgroup_on_dfl(const struct cgroup *cgrp);
 bool cgroup_is_thread_root(struct cgroup *cgrp);
 bool cgroup_is_threaded(struct cgroup *cgrp);
 
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index f12c32c6ec7f..6069191653f8 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -298,6 +298,7 @@ bool cgroup_on_dfl(const struct cgroup *cgrp)
 {
return cgrp->root == _dfl_root;
 }
+EXPORT_SYMBOL(cgroup_on_dfl);
 
 /* IDR wrappers which synchronize using cgroup_idr_lock */
 static int cgroup_idr_alloc(struct idr *idr, void *ptr, int start, int end,
-- 
2.14.3

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

[Intel-gfx] [PATCH RFC 0/9] DRM management via cgroups

[Matt Roper]

cgroups are core kernel mechanism that allows a system integrator /
system administrator to collect OS processes into a hierarchy of groups
according to their intended role in the overall system; resource
management and policy configuration can then be applied to each cgroup
independently.

The DRM subsystem manages several concepts that would be a good match
for cgroup-level configuration.  This series adds infrastructure to
allow DRM drivers to track 'parameters' associated with individual
cgroups.  These parameters can be used to manage things like GPU
priority, discrete/stolen memory limits, etc.; drivers will be able to
query the parameters set for a process' cgroup and then apply
appropriate driver-level policy.

The series is organized as follows:
 * Patches 1-4 export some additional interfaces from the cgroup core
   kernel implementation to make them accessible to modules and drivers.
 * Patch 5 introduces a new DRM ioctl that allows userspace to set
   parameter values for specific cgroups.
 * Patch 6 introduces a DRM helper library to simplify the management
   of allocation/storage/fetching of per-cgroup driver-specific data.
 * Patch 7 adds a helper function to obtain the v2 cgroup of the process
   associated with a drm_file.
 * Patch 8 implements support for GPU priority as a cgroup parameter in
   the i915 driver.
 * Patch 9 adds context priority to i915's debugfs output to make it
   easier to verify that context priorities are being initialized as
   expected.

Anticipated questions / concerns


Q:  What's the userspace consumer of this?

A:  I'll send a follow-up to the dri-devel / intel-gfx mailing lists
with a small patch that adds a simple command line tool to the
libdrm tests directory.  Although it looks more like a simple test
program than a real consumer, I think it's about the only userspace
we'll ever want/need.  Keep in mind that the real "consumers" here
aren't the graphics applications themselves, but rather the system
startup process (e.g., a sysv-init script or systemd service).  The
startup scripts can shuffle the various services/programs into
appropriate cgroups and then make some calls like:

   drm_set_cgrp_param /dev/dri/card0 /cgroup2/safety_critical/ 1 900
   drm_set_cgrp_param /dev/dri/card0 /cgroup2/high_priority/ 1 100
   drm_set_cgrp_param /dev/dri/card0 /cgroup2/best_effort/ 1 -200

to define the priority policy for each cgroup.  Aside from initial
startup scripts, none of the actual graphics clients are expected to
touch this interface.


Q:  The initial use case here is for setting i915 GPU priority according
to cgroup.  How/why does this differ from existing priority
mechanisms (e.g., setting I915_CONTEXT_PARAM_PRIORITY via the
I915_GEM_CONTEXT_SETPARAM ioctl on individual GPU contexts)?

A:  Existing mechanisms like the i915 context priority parameter will
ultimately be called by the software that priority is being assigned
for (e.g., a 3D application might use EGL_IMG_context_priority to
self-classify as high priority or low priority).  However the
priority of an application usually isn't a characteristic of an
application itself, but rather a decision that an admin/integrator
makes from a system-level perspective.  cgroups provide a standard,
convenient mechanism for a system integrator to apply the specific
policy he needs to build a cohesive system.

Note that the cgroups support for i915 priority  here just assigns the
initial/default priority for GPU contexts and doesn't block runtime
adjustment of the priority via other mechanisms.


Q:  Do we really anticipate other DRM concepts (beyond GPU priority)
being a reasonable match for cgroups-style management/control?

A:  I think there's a lot of potential to use cgroups to manage limits
on various types of "graphics memory" in the future.  That could
either be things like stolen memory on i915 (granted, we don't allow
direct allocations of this from userspace today, but it's been
talked about in the past) or discrete video RAM on systems that have
that.


Q:  Why is this implemented via DRM ioctl rather than as a cgroup
controller which would expose settings via kernfs nodes?

A:  The kernel has a concept of 'cgroup controllers' for exposing
settings via virtual filesystem nodes.  My initial thought was to
expose this kind of functionality as a driver-level cgroup
controller so that, for example, virtual files like "i915.priority"
would appear in each cgroup folder and be readable/writable
directly.  However as of commit ("3ed80a6 ("cgroup: drop module
support")), it's now required that controllers be built directly
into the kernel; they can no longer be provided by modules.  There
was some discussion about this direction at the time here:
  https://www.spinics.net/lists/cgroups/msg10077.html

[Intel-gfx] [PATCH RFC 4/9] cgroup: Export task_cgroup_from_root() and cgroup_mutex for drivers

[Matt Roper]

Drivers that handle processes on a per-cgroup basis need to be able to lookup
the cgroup that a process belongs to.

Cc: Tejun Heo 
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper 
---
 include/linux/cgroup.h  | 5 -
 kernel/cgroup/cgroup-internal.h | 3 ---
 kernel/cgroup/cgroup.c  | 8 +---
 3 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 1c1758ac1a97..1b93fb018bfc 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -103,6 +103,8 @@ struct cgroup_subsys_state 
*css_tryget_online_from_dir(struct dentry *dentry,
 
 struct cgroup *cgroup_get_from_path(const char *path);
 struct cgroup *cgroup_get_from_fd(int fd);
+struct cgroup *task_cgroup_from_root(struct task_struct *task,
+struct cgroup_root *root);
 
 int cgroup_attach_task_all(struct task_struct *from, struct task_struct *);
 int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from);
@@ -432,7 +434,6 @@ static inline void cgroup_put(struct cgroup *cgrp)
  * as locks used during the cgroup_subsys::attach() methods.
  */
 #ifdef CONFIG_PROVE_RCU
-extern struct mutex cgroup_mutex;
 extern spinlock_t css_set_lock;
 #define task_css_set_check(task, __c)  \
rcu_dereference_check((task)->cgroups,  \
@@ -444,6 +445,8 @@ extern spinlock_t css_set_lock;
rcu_dereference((task)->cgroups)
 #endif
 
+extern struct mutex cgroup_mutex;
+
 /**
  * task_css_check - obtain css for (task, subsys) w/ extra access conds
  * @task: the target task
diff --git a/kernel/cgroup/cgroup-internal.h b/kernel/cgroup/cgroup-internal.h
index 7338083ee3bc..5471f8fe8c2d 100644
--- a/kernel/cgroup/cgroup-internal.h
+++ b/kernel/cgroup/cgroup-internal.h
@@ -99,7 +99,6 @@ struct cgroup_sb_opts {
bool none;
 };
 
-extern struct mutex cgroup_mutex;
 extern spinlock_t css_set_lock;
 extern struct cgroup_subsys *cgroup_subsys[];
 extern struct list_head cgroup_roots;
@@ -160,8 +159,6 @@ bool cgroup_is_thread_root(struct cgroup *cgrp);
 bool cgroup_is_threaded(struct cgroup *cgrp);
 
 struct cgroup_root *cgroup_root_from_kf(struct kernfs_root *kf_root);
-struct cgroup *task_cgroup_from_root(struct task_struct *task,
-struct cgroup_root *root);
 struct cgroup *cgroup_kn_lock_live(struct kernfs_node *kn, bool drain_offline);
 void cgroup_kn_unlock(struct kernfs_node *kn);
 int cgroup_path_ns_locked(struct cgroup *cgrp, char *buf, size_t buflen,
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 6069191653f8..0a0093a36a7f 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -69,8 +69,9 @@
  * css_set_lock protects task->cgroups pointer, the list of css_set
  * objects, and the chain of tasks off each css_set.
  *
- * These locks are exported if CONFIG_PROVE_RCU so that accessors in
- * cgroup.h can use them for lockdep annotations.
+ * cgroup_mutex is always exported so that it may be taken by non-controller
+ * drivers.  css_set_lock is exported if CONFIG_PROVE_RCU so that accessors in
+ * cgroup.h can use it for lockdep annotations.
  */
 DEFINE_MUTEX(cgroup_mutex);
 DEFINE_SPINLOCK(css_set_lock);
@@ -84,8 +85,8 @@ DEFINE_SPINLOCK(css_set_lock);
 BLOCKING_NOTIFIER_HEAD(cgroup_destroy_notifier_list);
 EXPORT_SYMBOL_GPL(cgroup_destroy_notifier_list);
 
-#ifdef CONFIG_PROVE_RCU
 EXPORT_SYMBOL_GPL(cgroup_mutex);
+#ifdef CONFIG_PROVE_RCU
 EXPORT_SYMBOL_GPL(css_set_lock);
 #endif
 
@@ -1367,6 +1368,7 @@ struct cgroup *task_cgroup_from_root(struct task_struct 
*task,
 */
return cset_cgroup_from_root(task_css_set(task), root);
 }
+EXPORT_SYMBOL(task_cgroup_from_root);
 
 /*
  * A task must hold cgroup_mutex to modify cgroups.
-- 
2.14.3

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

[Intel-gfx] ✓ Fi.CI.BAT: success for scripts/trace.pl: Re-order calculations and fixups

[Patchwork]

== Series Details ==

Series: scripts/trace.pl: Re-order calculations and fixups
URL   : https://patchwork.freedesktop.org/series/36829/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
94bd67c5d6184c435c2fed0bfb39d75b3138b7a8 tools/intel_vbt_decode: update vbt 
defs from kernel

with latest DRM-Tip kernel build CI_DRM_3663
85f8773e7d77 drm-tip: 2018y-01m-19d-21h-19m-11s UTC integration manifest

No testlist changes.

Test debugfs_test:
Subgroup read_all_entries:
pass   -> DMESG-WARN (fi-elk-e7500) fdo#103989 +1
incomplete -> PASS   (fi-snb-2520m) fdo#103713 +1

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:432s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:435s
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:519s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:294s
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:501s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:495s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:484s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:302s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:410s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:425s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:472s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:421s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:464s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:504s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:459s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:629s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:446s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:516s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:537s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:493s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:493s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:441s
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:402s
Blacklisted hosts:
fi-cfl-s2total:288  pass:256  dwarn:0   dfail:0   fail:3   skip:26  
time:574s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:428s

== Logs ==

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

Re: [Intel-gfx] [PATCH 02/15] drm/i915/skl+: refactor WM calculation for NV12

[kbuild test robot]

Hi Mahesh,

Thank you for the patch! Perhaps something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Vidya-Srinivas/Adding-NV12-support/20180120-064213
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/i915/intel_pm.c:4794:73: sparse: Using plain integer as NULL 
>> pointer

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

  4764  
  4765  static void skl_write_plane_wm(struct intel_crtc *intel_crtc,
  4766 const struct skl_plane_wm *wm,
  4767 const struct skl_ddb_allocation *ddb,
  4768 enum plane_id plane_id)
  4769  {
  4770  struct drm_crtc *crtc = _crtc->base;
  4771  struct drm_device *dev = crtc->dev;
  4772  struct drm_i915_private *dev_priv = to_i915(dev);
  4773  int level, max_level = ilk_wm_max_level(dev_priv);
  4774  enum pipe pipe = intel_crtc->pipe;
  4775  
  4776  for (level = 0; level <= max_level; level++) {
  4777  skl_write_wm_level(dev_priv, PLANE_WM(pipe, plane_id, 
level),
  4778 >wm[level]);
  4779  }
  4780  skl_write_wm_level(dev_priv, PLANE_WM_TRANS(pipe, plane_id),
  4781 >trans_wm);
  4782  
  4783  if (wm->is_nv12) {
  4784  skl_ddb_entry_write(dev_priv, PLANE_BUF_CFG(pipe, 
plane_id),
  4785  >uv_plane[pipe][plane_id]);
  4786  skl_ddb_entry_write(dev_priv,
  4787  PLANE_NV12_BUF_CFG(pipe, plane_id),
  4788  >plane[pipe][plane_id]);
  4789  } else {
  4790  skl_ddb_entry_write(dev_priv, PLANE_BUF_CFG(pipe, 
plane_id),
  4791  >plane[pipe][plane_id]);
  4792  /* No NV12 buffer allocation for non NV12 pixel formats 
*/
  4793  skl_ddb_entry_write(dev_priv,
> 4794  PLANE_NV12_BUF_CFG(pipe, plane_id), 
> 0x0);
  4795  }
  4796  }
  4797  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
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 [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.

[Patchwork]

== Series Details ==

Series: series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for 
another SKU.
URL   : https://patchwork.freedesktop.org/series/36828/
State : success

== Summary ==

Series 36828v1 series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI 
IDs for another SKU.
https://patchwork.freedesktop.org/api/1.0/series/36828/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> DMESG-WARN (fi-elk-e7500) fdo#103989 +1

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:430s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:435s
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:515s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:294s
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:503s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:504s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:485s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:307s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:528s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:398s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:407s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:421s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:421s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:466s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:508s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:469s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:514s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:633s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:443s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:521s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:536s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:500s
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:444s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:405s
Blacklisted hosts:
fi-cfl-s2total:288  pass:256  dwarn:0   dfail:0   fail:3   skip:26  
time:570s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:421s

85f8773e7d771137795eed8a9f1f5ed3e7f725b7 drm-tip: 2018y-01m-19d-21h-19m-11s UTC 
integration manifest
8d3779f6394b drm/i915/cnl: Don't try to manage Port F power wells on all CNL.
a2551962c25b drm/i915/cnl: Fix DP max rate for Cannonlake with port F.
0d02b4b199c6 drm/i915/cnl: Enable DDI-F on Cannonlake.
d5ade4a3d893 drm/i915/cnl: Add HPD support for Port F.
5e733bf5da5f drm/i915: For HPD connected port use hpd_pin instead of port.
1c5bff32da8d drm/i915/cnl: Add right GMBUS pin number for HDMI on Port F.
97aa34aa3a96 drm/i915: Fix DPLCLKA_CFGCR0 bits for Port F.
5b141965257f drm/i915/cnl: Fix _CNL_PORT_TX_DW2_LN0_F definition.
e87eb870d82b drm/i915/cnl: Add AUX-F support
74b2dea2d2cf drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.

== Logs ==

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

[Intel-gfx] [PATCH i-g-t 4/4] scripts/trace.pl: Simplify 'end' & 'notify' generation

[John . C . Harrison]

From: John Harrison 

Delay the auto-generation of end/notify values until the point where
everything is known. As opposed to potentially generating them
multiple times with differing values.

Signed-off-by: John Harrison 
Cc: Tvrtko Ursulin 
---
 scripts/trace.pl | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/scripts/trace.pl b/scripts/trace.pl
index c5d822aa..fbf4b92e 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -467,10 +467,11 @@ while (<>) {
 }
 
 # Sanitation pass to fixup up out of order notify and context complete, and to
-# fine the largest seqno to be used for timeline sorting purposes.
+# find the largest seqno to be used for timeline sorting purposes.
 my $max_seqno = 0;
 foreach my $key (keys %db) {
my $gkey = global_key($db{$key}->{'ring'}, $db{$key}->{'global'});
+   my $notify = $notify{$gkey};
 
die unless exists $db{$key}->{'start'};
 
@@ -478,23 +479,21 @@ foreach my $key (keys %db) {
 
unless (exists $db{$key}->{'end'}) {
# Context complete not received.
-   if (exists $notify{$gkey}) {
+   $db{$key}->{'no-end'} = 1;
+
+   if (defined($notify)) {
# No context complete due req merging - use notify.
-   $db{$key}->{'notify'} = $notify{$gkey};
-   $db{$key}->{'end'} = $db{$key}->{'notify'};
-   $db{$key}->{'no-end'} = 1;
+   $db{$key}->{'notify'} = $notify;
+   $db{$key}->{'end'} = $notify;
} else {
-   # No notify and no context complete - mark it.
-   $db{$key}->{'no-end'} = 1;
-   $db{$key}->{'end'} = $db{$key}->{'start'} + 999;
-   $db{$key}->{'notify'} = $db{$key}->{'end'};
+   # No notify and no context complete - give up for now.
$db{$key}->{'incomplete'} = 1;
}
} else {
# Notify arrived after context complete.
-   if (exists $db{$key}->{'no-notify'} and exists $notify{$gkey}) {
+   if (exists $db{$key}->{'no-notify'} and defined($notify)) {
delete $db{$key}->{'no-notify'};
-   $db{$key}->{'notify'} = $notify{$gkey};
+   $db{$key}->{'notify'} = $notify;
}
}
 }
@@ -511,6 +510,7 @@ foreach my $key (@keys) {
my $seqno = $db{$key}->{'seqno'};
my $next_key;
my $i = 1;
+   my $end;
 
do {
$next_key = db_key($ring, $ctx, $seqno + $i);
@@ -519,9 +519,14 @@ foreach my $key (@keys) {
 or $i > $keyCount);  # ugly stop hack
 
if (exists $db{$next_key}) {
-   $db{$key}->{'notify'} = $db{$next_key}->{'end'};
-   $db{$key}->{'end'} = $db{$key}->{'notify'};
+   $end = $db{$next_key}->{'end'};
+   } else {
+   # No info at all, fake it:
+   $end = $db{$key}->{'start'} + 999;
}
+
+   $db{$key}->{'notify'} = $end;
+   $db{$key}->{'end'} = $end;
 }
 
 # GPU time accounting
-- 
2.15.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/4] scripts/trace.pl: Calculate stats only after all munging

[John . C . Harrison]

From: John Harrison 

There are various statistics being calculated multiple times in
multiple places while the log file is being read in. Some of these are
then re-calculated when the database is munged to correct various
issues with the logs. This patch consolidates the calculations into a
separate pass after all the reading and munging has been done.

Note that this actually produces a different final output as the
'execute-delay' values were not previously being re-calculated after
all the fixups. Thus were based on an incorrect calculation.

Signed-off-by: John Harrison 
Cc: Tvrtko Ursulin 
---
 scripts/trace.pl | 54 --
 1 file changed, 28 insertions(+), 26 deletions(-)

diff --git a/scripts/trace.pl b/scripts/trace.pl
index cf841b7e..c5d822aa 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -437,8 +437,7 @@ while (<>) {
$req{'global'} = $tp{'global'};
$req{'port'} = $tp{'port'};
$req{'queue'} = $queue{$key};
-   $req{'submit-delay'} = $submit{$key} - $queue{$key};
-   $req{'execute-delay'} = $req{'start'} - $submit{$key};
+   $req{'submit'} = $submit{$key};
$rings{$ring} = $gid++ unless exists $rings{$ring};
$ringmap{$rings{$ring}} = $ring;
$db{$key} = \%req;
@@ -458,8 +457,6 @@ while (<>) {
$db{$key}->{'notify'} = $db{$key}->{'end'};
$db{$key}->{'no-notify'} = 1;
}
-   $db{$key}->{'duration'} = $db{$key}->{'notify'} - 
$db{$key}->{'start'};
-   $db{$key}->{'context-complete-delay'} = $db{$key}->{'end'} - 
$db{$key}->{'notify'};
} elsif ($tp_name eq 'i915:intel_engine_notify:') {
$notify{global_key($ring, $seqno)} = $time;
} elsif ($tp_name eq 'i915:intel_gpu_freq_change:') {
@@ -493,16 +490,11 @@ foreach my $key (keys %db) {
$db{$key}->{'notify'} = $db{$key}->{'end'};
$db{$key}->{'incomplete'} = 1;
}
-
-   $db{$key}->{'duration'} = $db{$key}->{'notify'} - 
$db{$key}->{'start'};
-   $db{$key}->{'context-complete-delay'} = $db{$key}->{'end'} - 
$db{$key}->{'notify'};
} else {
# Notify arrived after context complete.
if (exists $db{$key}->{'no-notify'} and exists $notify{$gkey}) {
delete $db{$key}->{'no-notify'};
$db{$key}->{'notify'} = $notify{$gkey};
-   $db{$key}->{'duration'} = $db{$key}->{'notify'} - 
$db{$key}->{'start'};
-   $db{$key}->{'context-complete-delay'} = 
$db{$key}->{'end'} - $db{$key}->{'notify'};
}
}
 }
@@ -529,8 +521,6 @@ foreach my $key (@keys) {
if (exists $db{$next_key}) {
$db{$key}->{'notify'} = $db{$next_key}->{'end'};
$db{$key}->{'end'} = $db{$key}->{'notify'};
-   $db{$key}->{'duration'} = $db{$key}->{'notify'} - 
$db{$key}->{'start'};
-   $db{$key}->{'context-complete-delay'} = $db{$key}->{'end'} - 
$db{$key}->{'notify'};
}
 }
 
@@ -565,19 +555,14 @@ die "Database changed size?!" unless scalar(@sorted_keys) 
== $keyCount;
 foreach my $key (@sorted_keys) {
my $ring = $db{$key}->{'ring'};
my $end = $db{$key}->{'end'};
+   my $start = $db{$key}->{'start'};
+   my $notify = $db{$key}->{'notify'};
 
$first_ts = $db{$key}->{'queue'} if not defined $first_ts or 
$db{$key}->{'queue'} < $first_ts;
$last_ts = $end if $end > $last_ts;
 
-   $running{$ring} += $end - $db{$key}->{'start'} unless exists 
$db{$key}->{'no-end'};
-   $runnable{$ring} += $db{$key}->{'execute-delay'};
-   $queued{$ring} += $db{$key}->{'start'} - $db{$key}->{'execute-delay'} - 
$db{$key}->{'queue'};
-
-   $batch_count{$ring}++;
-
# correct duration of merged batches
if ($correct_durations and exists $db{$key}->{'no-end'}) {
-   my $start = $db{$key}->{'start'};
my $ctx = $db{$key}->{'ctx'};
my $seqno = $db{$key}->{'seqno'};
my $next_key;
@@ -591,24 +576,41 @@ foreach my $key (@sorted_keys) {
# 20us tolerance
if (exists $db{$next_key} and $db{$next_key}->{'start'} < 
$start + 20) {
$re_sort = 1;
-   $db{$next_key}->{'start'} = $start + 
$db{$key}->{'duration'};
+   $db{$next_key}->{'start'} = $notify;
$db{$next_key}->{'start'} = $db{$next_key}->{'end'} if 
$db{$next_key}->{'start'} > $db{$next_key}->{'end'};
-   $db{$next_key}->{'duration'} = 
$db{$next_key}->{'notify'} - $db{$next_key}->{'start'};
-   $end = $db{$key}->{'notify'};

[Intel-gfx] [PATCH i-g-t 2/4] scripts/trace.pl: Sort order

[John . C . Harrison]

From: John Harrison 

Add an extra level to the databse key sort so that the ordering is
deterministic. If the time stamp matches, it now compares the key
itself as well (context/seqno). This makes it much easier to determine
if a change has actually broken anything. Previously back to back runs
with no changes could still produce different output, especially when
adding extra debug output during the calculations.

As the comparison test is now more than a single equation, moved it
out into a separate sort function.

Signed-off-by: John Harrison 
Cc: Tvrtko Ursulin 
---
 scripts/trace.pl | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/scripts/trace.pl b/scripts/trace.pl
index 7b8a920e..cf841b7e 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -540,7 +540,25 @@ my (%submit_avg, %execute_avg, %ctxsave_avg);
 my $last_ts = 0;
 my $first_ts;
 
-my @sorted_keys = sort {$db{$a}->{'start'} <=> $db{$b}->{'start'}} keys %db;
+sub sortStart {
+   my $as = $db{$a}->{'start'};
+   my $bs = $db{$b}->{'start'};
+
+   return $as <=> $bs if($as ne $bs);
+
+   return $a cmp $b;
+}
+
+sub sortQueue {
+   my $as = $db{$a}->{'queue'};
+   my $bs = $db{$b}->{'queue'};
+
+   return $as <=> $bs if($as ne $bs);
+
+   return $a cmp $b;
+}
+
+my @sorted_keys = sort sortStart keys %db;
 my $re_sort = 0;
 die "Database changed size?!" unless scalar(@sorted_keys) == $keyCount;
 
@@ -589,9 +607,9 @@ foreach my $key (@sorted_keys) {
$ctxsave_avg{$ring} += $db{$key}->{'end'} - $db{$key}->{'notify'};
 }
 
-@sorted_keys = sort {$db{$a}->{'start'} <=> $db{$b}->{'start'}} keys %db if 
$re_sort;
+@sorted_keys = sort sortStart keys %db if $re_sort;
 
-foreach my $ring (keys %batch_avg) {
+foreach my $ring (sort keys %batch_avg) {
$batch_avg{$ring} /= $batch_count{$ring};
$batch_total_avg{$ring} /= $batch_count{$ring};
$submit_avg{$ring} /= $batch_count{$ring};
@@ -831,7 +849,7 @@ print <{'queue'} <=> $db{$b}->{'queue'}} keys %db) {
+foreach my $key (sort sortQueue keys %db) {
my ($name, $ctx, $seqno) = ($db{$key}->{'name'}, $db{$key}->{'ctx'}, 
$db{$key}->{'seqno'});
my ($queue, $start, $notify, $end) = ($db{$key}->{'queue'}, 
$db{$key}->{'start'}, $db{$key}->{'notify'}, $db{$key}->{'end'});
my $submit = $queue + $db{$key}->{'submit-delay'};
-- 
2.15.1

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

[Intel-gfx] [PATCH i-g-t 1/4] scripts/trace.pl: More hash key optimisations

[John . C . Harrison]

From: John Harrison 

Cache the key count value rather than querying the hash every time.
Also assert that the database does not magically change size after the
fixups.

Signed-off-by: John Harrison 
Cc: Tvrtko Ursulin 
---
 scripts/trace.pl | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/scripts/trace.pl b/scripts/trace.pl
index cb93900d..7b8a920e 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -508,7 +508,9 @@ foreach my $key (keys %db) {
 }
 
 # Fix up incompletes
-foreach my $key (keys %db) {
+my @keys = keys(%db);
+my $keyCount = scalar(@keys);
+foreach my $key (@keys) {
next unless exists $db{$key}->{'incomplete'};
 
# End the incomplete batch at the time next one starts
@@ -522,7 +524,7 @@ foreach my $key (keys %db) {
$next_key = db_key($ring, $ctx, $seqno + $i);
$i++;
} until ((exists $db{$next_key} and not exists 
$db{$next_key}->{'incomplete'})
-or $i > scalar(keys(%db)));  # ugly stop hack
+or $i > $keyCount);  # ugly stop hack
 
if (exists $db{$next_key}) {
$db{$key}->{'notify'} = $db{$next_key}->{'end'};
@@ -540,6 +542,7 @@ my $first_ts;
 
 my @sorted_keys = sort {$db{$a}->{'start'} <=> $db{$b}->{'start'}} keys %db;
 my $re_sort = 0;
+die "Database changed size?!" unless scalar(@sorted_keys) == $keyCount;
 
 foreach my $key (@sorted_keys) {
my $ring = $db{$key}->{'ring'};
@@ -565,7 +568,7 @@ foreach my $key (@sorted_keys) {
do {
$next_key = db_key($ring, $ctx, $seqno + $i);
$i++;
-   } until (exists $db{$next_key} or $i > scalar(keys(%db)));  # 
ugly stop hack
+   } until (exists $db{$next_key} or $i > $keyCount);  # ugly stop 
hack
 
# 20us tolerance
if (exists $db{$next_key} and $db{$next_key}->{'start'} < 
$start + 20) {
-- 
2.15.1

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

[Intel-gfx] [PATCH i-g-t 0/4] scripts/trace.pl: Re-order calculations and fixups

[John . C . Harrison]

From: John Harrison 

The trace.pl script calculates a bunch of statistics. It also
re-generates some timestamp values to correct issues with the log
being processed. These operations were all mixed up together thus some
were done multiple times (with different results each time). Whereas
some stats were not being re-calculated after the underlying data had
changed and thus were not actually correct at the end. Also, the
ordering of some operations was non-deterministic due to being based
on internal Perl hash ordering.

These patches rationalise all of this processing to ensure that it all
happens in the correct order and in a consistent manner.

John Harrison (4):
  scripts/trace.pl: More hash key optimisations
  scripts/trace.pl: Sort order
  scripts/trace.pl: Calculate stats only after all munging
  scripts/trace.pl: Simplify 'end' & 'notify' generation

 scripts/trace.pl | 118 ++-
 1 file changed, 73 insertions(+), 45 deletions(-)

-- 
2.15.1

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

[Intel-gfx] [PATCH 05/10] drm/i915/cnl: Add right GMBUS pin number for HDMI on Port F.

[Rodrigo Vivi]

On CNP Pin 3 is for misc of Port F usage depending on the
configuration. For CNL that uses Port F, pin 3 is the one.

v2: Make it more generic and update commit message.

Cc: Anusha Srivatsa 
Cc: Lucas De Marchi 
Cc: Manasi Navare 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 978f22bb96c2..0d924ba42075 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2178,6 +2178,9 @@ static u8 cnp_port_to_ddc_pin(struct drm_i915_private 
*dev_priv,
case PORT_D:
ddc_pin = GMBUS_PIN_4_CNP;
break;
+   case PORT_F:
+   ddc_pin = GMBUS_PIN_3_BXT;
+   break;
default:
MISSING_CASE(port);
ddc_pin = GMBUS_PIN_1_BXT;
-- 
2.13.6

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

[Intel-gfx] [PATCH 07/10] drm/i915/cnl: Add HPD support for Port F.

[Rodrigo Vivi]

On CNP boards that are using DDI F,
bit 25 (SDE_PORTE_HOTPLUG_SPT) is representing
the Digital Port F hotplug line when the Digital
Port F hotplug detect input is enabled.

v2: Reuse all existent structure instead of adding a
new HPD_PORT_F pointing to pin of port E.
v3: Use IS_CNL_WITH_PORT_F so we can start upstreaming
this right now. If that SKU ever get a proper name
we come back and update it.
v4: Rebase on top of digital connected port using encoder
instead of port.
v5: Moved IS_CNL_WITH_PORT_F definition to the PCI IDs patch.

Cc: Lucas De Marchi 
Cc: Manasi Navare 
Cc: Dhinakaran Pandiyan 
Cc: Ville Syrjälä 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h  |  6 --
 drivers/gpu/drm/i915/i915_irq.c  | 35 +++
 drivers/gpu/drm/i915/intel_dp.c  |  4 +++-
 drivers/gpu/drm/i915/intel_hdmi.c|  2 +-
 drivers/gpu/drm/i915/intel_hotplug.c | 19 +++
 5 files changed, 42 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7206c7c5f81c..0b5f8d887bfd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2957,8 +2957,10 @@ void intel_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
 void intel_hpd_init(struct drm_i915_private *dev_priv);
 void intel_hpd_init_work(struct drm_i915_private *dev_priv);
 void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
-enum port intel_hpd_pin_to_port(enum hpd_pin pin);
-enum hpd_pin intel_hpd_pin(enum port port);
+enum port intel_hpd_pin_to_port(struct drm_i915_private *dev_priv,
+   enum hpd_pin pin);
+enum hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv,
+  enum port port);
 bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
 void intel_hpd_enable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 0af970d4b3cf..78af4594eb38 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1568,10 +1568,11 @@ static bool i9xx_port_hotplug_long_detect(enum port 
port, u32 val)
  *
  * Note that the caller is expected to zero out the masks initially.
  */
-static void intel_get_hpd_pins(u32 *pin_mask, u32 *long_mask,
-u32 hotplug_trigger, u32 dig_hotplug_reg,
-const u32 hpd[HPD_NUM_PINS],
-bool long_pulse_detect(enum port port, u32 val))
+static void intel_get_hpd_pins(struct drm_i915_private *dev_priv,
+  u32 *pin_mask, u32 *long_mask,
+  u32 hotplug_trigger, u32 dig_hotplug_reg,
+  const u32 hpd[HPD_NUM_PINS],
+  bool long_pulse_detect(enum port port, u32 val))
 {
enum port port;
int i;
@@ -1582,7 +1583,7 @@ static void intel_get_hpd_pins(u32 *pin_mask, u32 
*long_mask,
 
*pin_mask |= BIT(i);
 
-   port = intel_hpd_pin_to_port(i);
+   port = intel_hpd_pin_to_port(dev_priv, i);
if (port == PORT_NONE)
continue;
 
@@ -1970,8 +1971,9 @@ static void i9xx_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_G4X;
 
if (hotplug_trigger) {
-   intel_get_hpd_pins(_mask, _mask, 
hotplug_trigger,
-  hotplug_trigger, hpd_status_g4x,
+   intel_get_hpd_pins(dev_priv, _mask, _mask,
+  hotplug_trigger, hotplug_trigger,
+  hpd_status_g4x,
   i9xx_port_hotplug_long_detect);
 
intel_hpd_irq_handler(dev_priv, pin_mask, long_mask);
@@ -1983,8 +1985,9 @@ static void i9xx_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_I915;
 
if (hotplug_trigger) {
-   intel_get_hpd_pins(_mask, _mask, 
hotplug_trigger,
-  hotplug_trigger, hpd_status_i915,
+   intel_get_hpd_pins(dev_priv, _mask, _mask,
+  hotplug_trigger, hotplug_trigger,
+  hpd_status_i915,
   i9xx_port_hotplug_long_detect);
intel_hpd_irq_handler(dev_priv, pin_mask, long_mask);
}
@@ -2185,7 +2188,7 @@ static void ibx_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
if 

[Intel-gfx] [PATCH 02/10] drm/i915/cnl: Add AUX-F support

[Rodrigo Vivi]

On some Cannonlake SKUs we have a dedicated Aux for port F,
that is only the full split between port A and port E.

There is still no Aux E for Port E, as in previous platforms,
because port_E still means shared lanes with port A.

v2: Rebase.
v3: Add couple missed PORT_F cases on intel_dp.
v4: Rebase and fix commit message.
v5: Squash Imre's "drm/i915: Add missing AUX_F power well string"
v6: Rebase on top of display headers rework.
v7: s/IS_CANNONLAKE/IS_CNL_WITH_PORT_F (DK)

Cc: Dhinakaran Pandiyan 
Cc: Lucas De Marchi 
Cc: Imre Deak 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_irq.c |  6 ++
 drivers/gpu/drm/i915/i915_reg.h |  9 +
 drivers/gpu/drm/i915/intel_display.h|  1 +
 drivers/gpu/drm/i915/intel_dp.c |  8 
 drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +++
 6 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3d3727829ac7..7206c7c5f81c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1255,6 +1255,7 @@ enum modeset_restore {
 #define DP_AUX_B 0x10
 #define DP_AUX_C 0x20
 #define DP_AUX_D 0x30
+#define DP_AUX_F 0x50
 
 #define DDC_PIN_B  0x05
 #define DDC_PIN_C  0x04
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index db3466ec6faa..0af970d4b3cf 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2579,6 +2579,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
GEN9_AUX_CHANNEL_C |
GEN9_AUX_CHANNEL_D;
 
+   if (IS_CNL_WITH_PORT_F(dev_priv))
+   tmp_mask |= CNL_AUX_CHANNEL_F;
+
if (iir & tmp_mask) {
dp_aux_irq_handler(dev_priv);
found = true;
@@ -3617,6 +3620,9 @@ static void gen8_de_irq_postinstall(struct 
drm_i915_private *dev_priv)
de_pipe_masked |= GEN8_DE_PIPE_IRQ_FAULT_ERRORS;
}
 
+   if (IS_CNL_WITH_PORT_F(dev_priv))
+   de_port_masked |= CNL_AUX_CHANNEL_F;
+
de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
   GEN8_PIPE_FIFO_UNDERRUN;
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 83b3f02d33b7..381c6758f3a6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1312,6 +1312,7 @@ enum i915_power_well_id {
CNL_DISP_PW_AUX_B = GLK_DISP_PW_AUX_B,
CNL_DISP_PW_AUX_C = GLK_DISP_PW_AUX_C,
CNL_DISP_PW_AUX_D,
+   CNL_DISP_PW_AUX_F = 13,
 
SKL_DISP_PW_1 = 14,
SKL_DISP_PW_2,
@@ -5284,6 +5285,13 @@ enum {
 #define _DPD_AUX_CH_DATA4  (dev_priv->info.display_mmio_offset + 0x64320)
 #define _DPD_AUX_CH_DATA5  (dev_priv->info.display_mmio_offset + 0x64324)
 
+#define _DPF_AUX_CH_CTL(dev_priv->info.display_mmio_offset + 
0x64510)
+#define _DPF_AUX_CH_DATA1  (dev_priv->info.display_mmio_offset + 0x64514)
+#define _DPF_AUX_CH_DATA2  (dev_priv->info.display_mmio_offset + 0x64518)
+#define _DPF_AUX_CH_DATA3  (dev_priv->info.display_mmio_offset + 0x6451c)
+#define _DPF_AUX_CH_DATA4  (dev_priv->info.display_mmio_offset + 0x64520)
+#define _DPF_AUX_CH_DATA5  (dev_priv->info.display_mmio_offset + 0x64524)
+
 #define DP_AUX_CH_CTL(port)_MMIO_PORT(port, _DPA_AUX_CH_CTL, 
_DPB_AUX_CH_CTL)
 #define DP_AUX_CH_DATA(port, i)_MMIO(_PORT(port, _DPA_AUX_CH_DATA1, 
_DPB_AUX_CH_DATA1) + (i) * 4) /* 5 registers */
 
@@ -6939,6 +6947,7 @@ enum {
 #define GEN8_DE_PORT_IMR _MMIO(0x4)
 #define GEN8_DE_PORT_IIR _MMIO(0x8)
 #define GEN8_DE_PORT_IER _MMIO(0xc)
+#define  CNL_AUX_CHANNEL_F (1 << 28)
 #define  GEN9_AUX_CHANNEL_D(1 << 27)
 #define  GEN9_AUX_CHANNEL_C(1 << 26)
 #define  GEN9_AUX_CHANNEL_B(1 << 25)
diff --git a/drivers/gpu/drm/i915/intel_display.h 
b/drivers/gpu/drm/i915/intel_display.h
index e47638931b51..30fa2041a45f 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -172,6 +172,7 @@ enum intel_display_power_domain {
POWER_DOMAIN_AUX_B,
POWER_DOMAIN_AUX_C,
POWER_DOMAIN_AUX_D,
+   POWER_DOMAIN_AUX_F,
POWER_DOMAIN_GMBUS,
POWER_DOMAIN_MODESET,
POWER_DOMAIN_GT_IRQ,
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a2e88715..ae3b0b030177 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1323,6 +1323,9 @@ static enum 

[Intel-gfx] [PATCH 03/10] drm/i915/cnl: Fix _CNL_PORT_TX_DW2_LN0_F definition.

[Rodrigo Vivi]

This was wrong since its introduction on commit '04416108ccea
("drm/i915/cnl: Add registers related to voltage swing sequences.")'

But since no Port F was needed so far we don't need to
propagate fixes back there.

Cc: Lucas De Marchi 
Cc: Manasi Navare 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_reg.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 381c6758f3a6..3ad9ad4a7918 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1964,7 +1964,7 @@ enum i915_power_well_id {
 #define _CNL_PORT_TX_DW2_LN0_B 0x162648
 #define _CNL_PORT_TX_DW2_LN0_C 0x162C48
 #define _CNL_PORT_TX_DW2_LN0_D 0x162E48
-#define _CNL_PORT_TX_DW2_LN0_F 0x162A48
+#define _CNL_PORT_TX_DW2_LN0_F 0x162848
 #define CNL_PORT_TX_DW2_GRP(port)  _MMIO_PORT6(port, \
_CNL_PORT_TX_DW2_GRP_AE, \
_CNL_PORT_TX_DW2_GRP_B, \
-- 
2.13.6

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

[Intel-gfx] [PATCH 10/10] drm/i915/cnl: Don't try to manage Port F power wells on all CNL.

[Rodrigo Vivi]

SKUs that lacks on the full port F split will just time out
when touching this power well bits, causing a noisy warn.

This macro style is a deviation from the original definition in use
for other platforms, but it at least avoid code duplication.
Other smart alternatives like providing a joint list was also considered
but it would require some extra memory handling that would be
a deviation from the original simplistic definitions here anyways,
plus requiring extra tests and possibly creating some corner cases
for one single platform. So let's move with the simplest and safest
approach.

Cc: Lucas De Marchi 
Cc: Imre Deak 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 177 +---
 1 file changed, 94 insertions(+), 83 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 433048ffa5c6..8dbc9b138ffd 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2334,89 +2334,96 @@ static struct i915_power_well glk_power_wells[] = {
},
 };
 
+#define basic_cnl_power_wells  \
+   {   \
+   .name = "always-on",\
+   .always_on = 1, \
+   .domains = POWER_DOMAIN_MASK,   \
+   .ops = _always_on_power_well_ops,  \
+   .id = I915_DISP_PW_ALWAYS_ON,   \
+   },  \
+   {   \
+   .name = "power well 1", \
+   /* Handled by the DMC firmware */   \
+   .domains = 0,   \
+   .ops = _power_well_ops, \
+   .id = SKL_DISP_PW_1,\
+   {   \
+   .hsw.has_fuses = true,  \
+   },  \
+   },  \
+   {   \
+   .name = "AUX A",\
+   .domains = CNL_DISPLAY_AUX_A_POWER_DOMAINS, \
+   .ops = _power_well_ops, \
+   .id = CNL_DISP_PW_AUX_A,\
+   },  \
+   {   \
+   .name = "AUX B",\
+   .domains = CNL_DISPLAY_AUX_B_POWER_DOMAINS, \
+   .ops = _power_well_ops, \
+   .id = CNL_DISP_PW_AUX_B,\
+   },  \
+   {   \
+   .name = "AUX C",\
+   .domains = CNL_DISPLAY_AUX_C_POWER_DOMAINS, \
+   .ops = _power_well_ops, \
+   .id = CNL_DISP_PW_AUX_C,\
+   },  \
+   {   \
+   .name = "AUX D",\
+   .domains = CNL_DISPLAY_AUX_D_POWER_DOMAINS, \
+   .ops = _power_well_ops, \
+   .id = CNL_DISP_PW_AUX_D,\
+   },  \
+   {   \
+   .name = "DC off",   \
+   .domains = CNL_DISPLAY_DC_OFF_POWER_DOMAINS,\
+   .ops = _dc_off_power_well_ops, \
+   .id = SKL_DISP_PW_DC_OFF,   \
+   },  \
+   {   \
+   .name = "power well 2", \
+   .domains = CNL_DISPLAY_POWERWELL_2_POWER_DOMAINS,   \
+   .ops = _power_well_ops,   

[Intel-gfx] [PATCH 08/10] drm/i915/cnl: Enable DDI-F on Cannonlake.

[Rodrigo Vivi]

Now let's finish the Port-F support by adding the
proper port F detection, irq and power well support.

v2: Rebase
v3: Use BIT_ULL
v4: Cover missed case on ddi init.
v5: Update commit message.
v6: Rebase on top of display headers rework.

Cc: Manasi Navare 
Cc: Ville Syrjälä 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_reg.h |  2 ++
 drivers/gpu/drm/i915/intel_ddi.c|  4 
 drivers/gpu/drm/i915/intel_display.c|  6 +-
 drivers/gpu/drm/i915/intel_display.h|  2 ++
 drivers/gpu/drm/i915/intel_runtime_pm.c | 13 +
 5 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 861a7d5a27af..32ec64eb2c5a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1304,6 +1304,7 @@ enum i915_power_well_id {
SKL_DISP_PW_DDI_B,
SKL_DISP_PW_DDI_C,
SKL_DISP_PW_DDI_D,
+   CNL_DISP_PW_DDI_F = 6,
 
GLK_DISP_PW_AUX_A = 8,
GLK_DISP_PW_AUX_B,
@@ -8939,6 +8940,7 @@ enum skl_power_gate {
 #define  SFUSE_STRAP_RAW_FREQUENCY (1<<8)
 #define  SFUSE_STRAP_DISPLAY_DISABLED  (1<<7)
 #define  SFUSE_STRAP_CRT_DISABLED  (1<<6)
+#define  SFUSE_STRAP_DDIF_DETECTED (1<<3)
 #define  SFUSE_STRAP_DDIB_DETECTED (1<<2)
 #define  SFUSE_STRAP_DDIC_DETECTED (1<<1)
 #define  SFUSE_STRAP_DDID_DETECTED (1<<0)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 6260a882fbe4..ba56eea826d5 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2904,6 +2904,10 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
intel_dig_port->ddi_io_power_domain =
POWER_DOMAIN_PORT_DDI_E_IO;
break;
+   case PORT_F:
+   intel_dig_port->ddi_io_power_domain =
+   POWER_DOMAIN_PORT_DDI_F_IO;
+   break;
default:
MISSING_CASE(port);
}
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 91f3c0a64596..d4942a5e23f4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5633,6 +5633,8 @@ enum intel_display_power_domain 
intel_port_to_power_domain(enum port port)
return POWER_DOMAIN_PORT_DDI_D_LANES;
case PORT_E:
return POWER_DOMAIN_PORT_DDI_E_LANES;
+   case PORT_F:
+   return POWER_DOMAIN_PORT_DDI_F_LANES;
default:
MISSING_CASE(port);
return POWER_DOMAIN_PORT_OTHER;
@@ -13586,7 +13588,7 @@ static void intel_setup_outputs(struct drm_i915_private 
*dev_priv)
if (found || IS_GEN9_BC(dev_priv))
intel_ddi_init(dev_priv, PORT_A);
 
-   /* DDI B, C and D detection is indicated by the SFUSE_STRAP
+   /* DDI B, C, D, and F detection is indicated by the SFUSE_STRAP
 * register */
found = I915_READ(SFUSE_STRAP);
 
@@ -13596,6 +13598,8 @@ static void intel_setup_outputs(struct drm_i915_private 
*dev_priv)
intel_ddi_init(dev_priv, PORT_C);
if (found & SFUSE_STRAP_DDID_DETECTED)
intel_ddi_init(dev_priv, PORT_D);
+   if (found & SFUSE_STRAP_DDIF_DETECTED)
+   intel_ddi_init(dev_priv, PORT_F);
/*
 * On SKL we don't have a way to detect DDI-E so we rely on VBT.
 */
diff --git a/drivers/gpu/drm/i915/intel_display.h 
b/drivers/gpu/drm/i915/intel_display.h
index 30fa2041a45f..c4042e342f50 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -157,11 +157,13 @@ enum intel_display_power_domain {
POWER_DOMAIN_PORT_DDI_C_LANES,
POWER_DOMAIN_PORT_DDI_D_LANES,
POWER_DOMAIN_PORT_DDI_E_LANES,
+   POWER_DOMAIN_PORT_DDI_F_LANES,
POWER_DOMAIN_PORT_DDI_A_IO,
POWER_DOMAIN_PORT_DDI_B_IO,
POWER_DOMAIN_PORT_DDI_C_IO,
POWER_DOMAIN_PORT_DDI_D_IO,
POWER_DOMAIN_PORT_DDI_E_IO,
+   POWER_DOMAIN_PORT_DDI_F_IO,
POWER_DOMAIN_PORT_DSI,
POWER_DOMAIN_PORT_CRT,
POWER_DOMAIN_PORT_OTHER,
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 27174d49a529..433048ffa5c6 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -94,6 +94,8 @@ intel_display_power_domain_str(enum 
intel_display_power_domain domain)
return "PORT_DDI_D_LANES";
case POWER_DOMAIN_PORT_DDI_E_LANES:
return "PORT_DDI_E_LANES";
+   case POWER_DOMAIN_PORT_DDI_F_LANES:
+   return "PORT_DDI_F_LANES";
case POWER_DOMAIN_PORT_DDI_A_IO:

[Intel-gfx] [PATCH 01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.

[Rodrigo Vivi]

The only difference is that this SKUs has the full
Port A/E split named as Port F.

But since SKUs differences don't matter on the platform
definition group and ids, let's merge all off them together.

v2: Really include the PCI IDs to the picidlist[];
v3: Add the PCI Id for another SKU (Anusha).
v4: Update IDs, really include to pciidlists again.
v5: Unify all GT2 IDs.
v6: Unify in a way that we don't break early-quirks.c
v7: Remove GT reference since it doesn't matter here (Paulo)
Also move IS_CNL_WITH_PORT_F macro to this patch to
make it easier for review this part and also to get
used sooner.

Cc: Dhinakaran Pandiyan 
Cc: Paulo Zanoni 
Cc: Lucas De Marchi 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 ++
 drivers/gpu/drm/i915/i915_pci.c |  5 ++---
 include/drm/i915_pciids.h   | 18 +++---
 3 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8333692dac5a..3d3727829ac7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2647,6 +2647,8 @@ intel_info(const struct drm_i915_private *dev_priv)
 (dev_priv)->info.gt == 2)
 #define IS_CFL_GT3(dev_priv)   (IS_COFFEELAKE(dev_priv) && \
 (dev_priv)->info.gt == 3)
+#define IS_CNL_WITH_PORT_F(dev_priv)   (IS_CANNONLAKE(dev_priv) && \
+   (INTEL_DEVID(dev_priv) & 0x0004) == 
0x0004)
 
 #define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support)
 
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f28c165fc49d..7eb3d5e4350e 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -571,7 +571,7 @@ static const struct intel_device_info 
intel_coffeelake_gt3_info __initconst = {
.ddb_size = 1024, \
GLK_COLORS
 
-static const struct intel_device_info intel_cannonlake_gt2_info __initconst = {
+static const struct intel_device_info intel_cannonlake_info __initconst = {
GEN10_FEATURES,
.is_alpha_support = 1,
.platform = INTEL_CANNONLAKE,
@@ -649,8 +649,7 @@ static const struct pci_device_id pciidlist[] = {
INTEL_CFL_U_GT1_IDS(_coffeelake_gt1_info),
INTEL_CFL_U_GT2_IDS(_coffeelake_gt2_info),
INTEL_CFL_U_GT3_IDS(_coffeelake_gt3_info),
-   INTEL_CNL_U_GT2_IDS(_cannonlake_gt2_info),
-   INTEL_CNL_Y_GT2_IDS(_cannonlake_gt2_info),
+   INTEL_CNL_IDS(_cannonlake_info),
{0, 0, 0}
 };
 MODULE_DEVICE_TABLE(pci, pciidlist);
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 5db0458dd832..9e1fe6634424 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -414,24 +414,20 @@
INTEL_CFL_U_GT2_IDS(info), \
INTEL_CFL_U_GT3_IDS(info)
 
-/* CNL U 2+2 */
-#define INTEL_CNL_U_GT2_IDS(info) \
+/* CNL */
+#define INTEL_CNL_IDS(info) \
INTEL_VGA_DEVICE(0x5A52, info), \
INTEL_VGA_DEVICE(0x5A5A, info), \
INTEL_VGA_DEVICE(0x5A42, info), \
-   INTEL_VGA_DEVICE(0x5A4A, info)
-
-/* CNL Y 2+2 */
-#define INTEL_CNL_Y_GT2_IDS(info) \
+   INTEL_VGA_DEVICE(0x5A4A, info), \
INTEL_VGA_DEVICE(0x5A51, info), \
INTEL_VGA_DEVICE(0x5A59, info), \
INTEL_VGA_DEVICE(0x5A41, info), \
INTEL_VGA_DEVICE(0x5A49, info), \
INTEL_VGA_DEVICE(0x5A71, info), \
-   INTEL_VGA_DEVICE(0x5A79, info)
-
-#define INTEL_CNL_IDS(info) \
-   INTEL_CNL_U_GT2_IDS(info), \
-   INTEL_CNL_Y_GT2_IDS(info)
+   INTEL_VGA_DEVICE(0x5A79, info), \
+   INTEL_VGA_DEVICE(0x5A54, info), \
+   INTEL_VGA_DEVICE(0x5A5C, info), \
+   INTEL_VGA_DEVICE(0x5A44, info)
 
 #endif /* _I915_PCIIDS_H */
-- 
2.13.6

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

[Intel-gfx] [PATCH 09/10] drm/i915/cnl: Fix DP max rate for Cannonlake with port F.

[Rodrigo Vivi]

On CNL SKUs that uses port F,  max DP rate is 8.1G for all
ports when we have the elevated voltage.

v2: Make commit message more generic.

Cc: Lucas De Marchi 
Cc: Manasi Navare 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4b963732454d..36826460d8fb 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -240,8 +240,9 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
source_rates = cnl_rates;
size = ARRAY_SIZE(cnl_rates);
voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
-   if (port == PORT_A || port == PORT_D ||
-   voltage == VOLTAGE_INFO_0_85V)
+   if (voltage == VOLTAGE_INFO_0_85V ||
+   (!IS_CNL_WITH_PORT_F(dev_priv) && (port == PORT_A ||
+  port == PORT_D)))
size -= 2;
} else if (IS_GEN9_BC(dev_priv)) {
source_rates = skl_rates;
-- 
2.13.6

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

[Intel-gfx] [PATCH 04/10] drm/i915: Fix DPLCLKA_CFGCR0 bits for Port F.

[Rodrigo Vivi]

Since when it got introduced with commit '555e38d27317
("drm/i915/cnl: DDI - PLL mapping")' the support for Port F
was wrong, because Port F bits are far from bits used
for A to E.

Since Port F is not used so far we don't need to propagate
Fixes back there.

v2: Reuse _SHIFT definition to avoid complicated duplication (DK).

Cc: Dhinakaran Pandiyan 
Cc: Lucas De Marchi 
Cc: Manasi Navare 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_reg.h | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3ad9ad4a7918..861a7d5a27af 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8838,10 +8838,12 @@ enum skl_power_gate {
  * CNL Clocks
  */
 #define DPCLKA_CFGCR0  _MMIO(0x6C200)
-#define  DPCLKA_CFGCR0_DDI_CLK_OFF(port)   (1 << ((port)+10))
-#define  DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port)  (3 << ((port)*2))
-#define  DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port) ((port)*2)
-#define  DPCLKA_CFGCR0_DDI_CLK_SEL(pll, port)  ((pll) << ((port)*2))
+#define  DPCLKA_CFGCR0_DDI_CLK_OFF(port)   (1 << ((port) ==  PORT_F ? 23 : 
\
+ (port)+10))
+#define  DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port) ((port) == PORT_F ? 21 : \
+   (port)*2)
+#define  DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port)  (3 << 
DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port))
+#define  DPCLKA_CFGCR0_DDI_CLK_SEL(pll, port)  ((pll) << 
DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port))
 
 /* CNL PLL */
 #define DPLL0_ENABLE   0x46010
-- 
2.13.6

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

[Intel-gfx] [PATCH 06/10] drm/i915: For HPD connected port use hpd_pin instead of port.

[Rodrigo Vivi]

Let's try to simplify this mapping to hpd_pin -> bit
instead using port.
So for CNL with port F where we have this port using
hdp_pin and bits of other ports we don't need to duplicated
the mapping.

But for now this is only a re-org with no functional change
expected.

Cc: Lucas De Marchi 
Suggested-by: Ville Syrjälä 
Cc: Ville Syrjälä 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp.c | 144 ++--
 drivers/gpu/drm/i915/intel_drv.h|   3 +-
 drivers/gpu/drm/i915/intel_lspcon.c |   3 +-
 3 files changed, 72 insertions(+), 78 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ae3b0b030177..4ff6fcf542e9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4487,173 +4487,170 @@ edp_detect(struct intel_dp *intel_dp)
return status;
 }
 
-static bool ibx_digital_port_connected(struct drm_i915_private *dev_priv,
-  struct intel_digital_port *port)
+static bool ibx_digital_port_connected(struct intel_encoder *encoder)
 {
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 bit;
 
-   switch (port->base.port) {
-   case PORT_B:
+   switch (encoder->hpd_pin) {
+   case HPD_PORT_B:
bit = SDE_PORTB_HOTPLUG;
break;
-   case PORT_C:
+   case HPD_PORT_C:
bit = SDE_PORTC_HOTPLUG;
break;
-   case PORT_D:
+   case HPD_PORT_D:
bit = SDE_PORTD_HOTPLUG;
break;
default:
-   MISSING_CASE(port->base.port);
+   MISSING_CASE(encoder->hpd_pin);
return false;
}
 
return I915_READ(SDEISR) & bit;
 }
 
-static bool cpt_digital_port_connected(struct drm_i915_private *dev_priv,
-  struct intel_digital_port *port)
+static bool cpt_digital_port_connected(struct intel_encoder *encoder)
 {
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 bit;
 
-   switch (port->base.port) {
-   case PORT_B:
+   switch (encoder->hpd_pin) {
+   case HPD_PORT_B:
bit = SDE_PORTB_HOTPLUG_CPT;
break;
-   case PORT_C:
+   case HPD_PORT_C:
bit = SDE_PORTC_HOTPLUG_CPT;
break;
-   case PORT_D:
+   case HPD_PORT_D:
bit = SDE_PORTD_HOTPLUG_CPT;
break;
default:
-   MISSING_CASE(port->base.port);
+   MISSING_CASE(encoder->hpd_pin);
return false;
}
 
return I915_READ(SDEISR) & bit;
 }
 
-static bool spt_digital_port_connected(struct drm_i915_private *dev_priv,
-  struct intel_digital_port *port)
+static bool spt_digital_port_connected(struct intel_encoder *encoder)
 {
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 bit;
 
-   switch (port->base.port) {
-   case PORT_A:
+   switch (encoder->hpd_pin) {
+   case HPD_PORT_A:
bit = SDE_PORTA_HOTPLUG_SPT;
break;
-   case PORT_E:
+   case HPD_PORT_E:
bit = SDE_PORTE_HOTPLUG_SPT;
break;
default:
-   return cpt_digital_port_connected(dev_priv, port);
+   return cpt_digital_port_connected(encoder);
}
 
return I915_READ(SDEISR) & bit;
 }
 
-static bool g4x_digital_port_connected(struct drm_i915_private *dev_priv,
-  struct intel_digital_port *port)
+static bool g4x_digital_port_connected(struct intel_encoder *encoder)
 {
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 bit;
 
-   switch (port->base.port) {
-   case PORT_B:
+   switch (encoder->hpd_pin) {
+   case HPD_PORT_B:
bit = PORTB_HOTPLUG_LIVE_STATUS_G4X;
break;
-   case PORT_C:
+   case HPD_PORT_C:
bit = PORTC_HOTPLUG_LIVE_STATUS_G4X;
break;
-   case PORT_D:
+   case HPD_PORT_D:
bit = PORTD_HOTPLUG_LIVE_STATUS_G4X;
break;
default:
-   MISSING_CASE(port->base.port);
+   MISSING_CASE(encoder->hpd_pin);
return false;
}
 
return I915_READ(PORT_HOTPLUG_STAT) & bit;
 }
 
-static bool gm45_digital_port_connected(struct drm_i915_private *dev_priv,
-   struct intel_digital_port *port)
+static bool gm45_digital_port_connected(struct intel_encoder *encoder)
 {
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 bit;
 
-   switch (port->base.port) {
-   case PORT_B:
+   switch 

[Intel-gfx] ✗ Fi.CI.BAT: failure for igt/gen7_forcewake_mt: Make the mmio register as volatile

[Patchwork]

== Series Details ==

Series: igt/gen7_forcewake_mt: Make the mmio register as volatile
URL   : https://patchwork.freedesktop.org/series/36826/
State : failure

== Summary ==

IGT patchset tested on top of latest successful build
94bd67c5d6184c435c2fed0bfb39d75b3138b7a8 tools/intel_vbt_decode: update vbt 
defs from kernel

with latest DRM-Tip kernel build CI_DRM_3663
85f8773e7d77 drm-tip: 2018y-01m-19d-21h-19m-11s UTC integration manifest

No testlist changes.

Test debugfs_test:
Subgroup read_all_entries:
pass   -> FAIL   (fi-elk-e7500) fdo#103989
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a:
pass   -> FAIL   (fi-skl-6700k2)

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
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:429s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:432s
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:517s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:294s
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:505s
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:487s
fi-elk-e7500 total:224  pass:167  dwarn:10  dfail:0   fail:1   skip:45 
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:306s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:528s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:400s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:406s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:422s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:471s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:419s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:463s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:505s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:459s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:511s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:632s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:446s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:516s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:536s
fi-skl-6700k2total:288  pass:263  dwarn:0   dfail:0   fail:1   skip:24  
time:505s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:495s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:442s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:545s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:409s
Blacklisted hosts:
fi-cfl-s2total:288  pass:256  dwarn:0   dfail:0   fail:3   skip:26  
time:565s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:424s

== Logs ==

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

[Intel-gfx] [PATCH igt] igt/gen7_forcewake_mt: Make the mmio register as volatile

[Chris Wilson]

Prevent the compiler from caching reads/writes to the hw register as we
do want to perform mmio.

Signed-off-by: Chris Wilson 
---
 tests/gen7_forcewake_mt.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tests/gen7_forcewake_mt.c b/tests/gen7_forcewake_mt.c
index 07320ef9e..8a23d13e0 100644
--- a/tests/gen7_forcewake_mt.c
+++ b/tests/gen7_forcewake_mt.c
@@ -106,8 +106,9 @@ static void *igfx_get_mmio(void)
 static void *thread(void *arg)
 {
struct thread *t = arg;
-   uint32_t *forcewake_mt = (uint32_t *)((char *)t->mmio + FORCEWAKE_MT);
-   uint32_t bit = 1 << t->bit;
+   const uint32_t bit = 1 << t->bit;
+   volatile uint32_t *forcewake_mt =
+   (volatile uint32_t *)((char *)t->mmio + FORCEWAKE_MT);
 
while (1) {
*forcewake_mt = bit << 16 | bit;
-- 
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] drm/i915/icl: Set graphics mode register for gen11

[Daniele Ceraolo Spurio]

On 19/01/18 11:30, Kelvin Gardiner wrote:

This patch clears a single bit. The bit is 0 by default but expected not to be
set. Explicitly clearing the bit in this patch is intended to indicate some
thinking has occurred, and that we want this bit cleared and we are not just
excepting the default value.



We also stop setting GFX_RUN_LIST_ENABLE, which is correct since that 
bit is gone. Code is self-explanatory but could still use a mention in 
the commit message IMHO.



v2 (from Paulo): fix indentation.
v3: Changed GEN check to >= 11. Corrected author name.

Signed-off-by: Kelvin Gardiner 
Signed-off-by: Paulo Zanoni 


Reviewed-by: Daniele Ceraolo Spurio 

Thanks,
Daniele


---
  drivers/gpu/drm/i915/i915_reg.h  |  2 ++
  drivers/gpu/drm/i915/intel_lrc.c | 18 --
  2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 73c9c36..057f90e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2604,6 +2604,8 @@ enum i915_power_well_id {
  #define   GFX_FORWARD_VBLANK_ALWAYS   (1<<5)
  #define   GFX_FORWARD_VBLANK_COND (2<<5)
  
+#define   GEN11_GFX_DISABLE_LEGACY_MODE	(1<<3)

+
  #define VLV_DISPLAY_BASE 0x18
  #define VLV_MIPI_BASE VLV_DISPLAY_BASE
  #define BXT_MIPI_BASE 0x6
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index dab988f..d4cc5c9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1500,8 +1500,22 @@ static void enable_execlists(struct intel_engine_cs 
*engine)
struct drm_i915_private *dev_priv = engine->i915;
  
  	I915_WRITE(RING_HWSTAM(engine->mmio_base), 0x);

-   I915_WRITE(RING_MODE_GEN7(engine),
-  _MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE));
+
+   /*
+* Make sure we're not enabling the new 12-deep CSB
+* FIFO as that requires a slightly updated handling
+* in the ctx switch irq. Since we're currently only
+* using only 2 elements of the enhanced execlists the
+* deeper FIFO it's not needed and it's not worth adding
+* more statements to the irq handler to support it.
+   */
+   if (INTEL_GEN(dev_priv) >= 11)
+   I915_WRITE(RING_MODE_GEN7(engine),
+  _MASKED_BIT_DISABLE(GEN11_GFX_DISABLE_LEGACY_MODE));
+   else
+   I915_WRITE(RING_MODE_GEN7(engine),
+  _MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE));
+
I915_WRITE(RING_HWS_PGA(engine->mmio_base),
   engine->status_page.ggtt_offset);
POSTING_READ(RING_HWS_PGA(engine->mmio_base));


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

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Estimate and update missed vblanks.

[Rodrigo Vivi]

On Fri, Jan 19, 2018 at 09:42:14PM +, Pandiyan, Dhinakaran wrote:
> On Thu, 2018-01-18 at 23:26 -0800, Rodrigo Vivi wrote:
> > On Fri, Jan 12, 2018 at 09:57:07PM +, Dhinakaran Pandiyan wrote:
> > > The frame counter may have got reset between disabling and enabling vblank
> > > interrupts due to DMC putting the hardware to DC5/6 state if PSR was
> > > active. The frame counter also could have stalled if PSR is active in 
> > > cases
> > > where there is no DMC. The frame counter resetting as a user visible 
> > > impact
> > > of screen freezes. Use drm_vblank_restore() to compute missed vblanks
> > > in the duration for which vblank interrupts are disabled. There's no need
> > > particularly check if PSR was active in the interrupt disabled duration.
> > > 
> > > Enabling vblank interrupts wakes up the hardware from DC5/6 and prevents 
> > > it
> > > from going back again as long as the there are pending interrupts. So, we
> > > don't have to explicity disallow DC5/6 after enabling vblank interrupts
> > > to keep the counter running.
> > > 
> > > Let's not apply this to CHV for now, as enabling interrupts does not
> > > prevent the hardware from activating PSR and thereby stalling the counter.
> > > 
> > > Cc: Rodrigo Vivi 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/i915/i915_irq.c | 6 ++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > > b/drivers/gpu/drm/i915/i915_irq.c
> > > index 3517c6548e2c..db3466ec6faa 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -2956,6 +2956,9 @@ static int ironlake_enable_vblank(struct drm_device 
> > > *dev, unsigned int pipe)
> > >   ilk_enable_display_irq(dev_priv, bit);
> > >   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
> > >  
> > > + if (HAS_PSR(dev_priv))
> > > + drm_vblank_restore(dev, pipe);
> > > +
> > 
> > I don't believe we need this one here.
> > 
> > pre-gen9 platform has psr but not dmc, so the case
> > where we need to restore the counter doesn't exist.
> 
> Even without DMC, counter should be stuck when PSR is active as no
> frames are generated by the pipe. I am using drm_vblank_restore_count()
> to take care of that.

Oh oh! Indeed. Now I remember you had told me this here.
Can you please add a comment with this info somewhere so I don't ask
the same question again ;)

anyways:

Reviewed-by: Rodrigo Vivi 



> 
> > 
> > >   return 0;
> > >  }
> > >  
> > > @@ -2968,6 +2971,9 @@ static int gen8_enable_vblank(struct drm_device 
> > > *dev, unsigned int pipe)
> > >   bdw_enable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
> > >   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
> > >  
> > > + if (HAS_PSR(dev_priv))
> > 
> > HAS_PSR(dev_priv) && HAS_CSR(dev_priv)
> > maybe?
> > So it gets clear that it is not because PSR that we need to restore
> > the counter, but also don't do it when not needed.
> 
> Same reason as above, let me test this again by disabling DMC.
> 
> > 
> > > + drm_vblank_restore(dev, pipe);
> > > +
> > >   return 0;
> > >  }
> > >  
> > > -- 
> > > 2.11.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 4/5] drm/vblank: Restoring vblank counts after device PM events.

[Rodrigo Vivi]

On Fri, Jan 19, 2018 at 10:02:12PM +, Pandiyan, Dhinakaran wrote:
> 
> 
> 
> On Fri, 2018-01-19 at 00:01 -0800, Rodrigo Vivi wrote:
> > On Fri, Jan 12, 2018 at 09:57:06PM +, Dhinakaran Pandiyan wrote:
> > > The HW frame counter can get reset if device enters a low power state 
> > > after
> > > vblank interrupts were disabled. This messes up any following vblank count
> > > update as a negative diff (huge unsigned diff) is calculated from the HW
> > > frame counter change. We cannot ignore negative diffs altogther as there
> > > could be legitimate wrap arounds. So, allow drivers to update 
> > > vblank->count
> > > with missed vblanks for the time interrupts were disabled. This is similar
> > > to _crtc_vblank_on() except that vblanks interrupts are not enabled at the
> > > end as this function is expected to be called from the driver
> > > _enable_vblank() vfunc.
> > > 
> > > v2: drm_crtc_vblank_restore should take crtc as arg. (Chris)
> > > Add docs and sprinkle some asserts.
> > > 
> > > Cc: Daniel Vetter 
> > > Cc: Chris Wilson 
> > > Cc: Michel Dänzer 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/drm_vblank.c | 59 
> > > 
> > >  include/drm/drm_vblank.h |  2 ++
> > >  2 files changed, 61 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > > index 2559d2d7b907..2690966694f0 100644
> > > --- a/drivers/gpu/drm/drm_vblank.c
> > > +++ b/drivers/gpu/drm/drm_vblank.c
> > > @@ -1237,6 +1237,65 @@ void drm_crtc_vblank_on(struct drm_crtc *crtc)
> > >  }
> > >  EXPORT_SYMBOL(drm_crtc_vblank_on);
> > >  
> > > +/**
> > > + * drm_vblank_restore - estimated vblanks using timestamps and update it.
> > > + *
> > > + * Power manamement features can cause frame counter resets between 
> > > vblank
> > > + * disable and enable. Drivers can then use this function in their
> > > + * _crtc_funcs.enable_vblank implementation to estimate the vblanks 
> > > since
> > > + * the last _crtc_funcs.disable_vblank.
> > > + *
> > > + * This function is the legacy version of drm_crtc_vblank_restore().
> > > + */
> > > +void drm_vblank_restore(struct drm_device *dev, unsigned int pipe)
> > > +{
> > > + ktime_t t_vblank;
> > > + struct drm_vblank_crtc *vblank;
> > > + int framedur_ns;
> > > + u64 diff_ns;
> > > + u32 cur_vblank, diff = 1;
> > > + int count = DRM_TIMESTAMP_MAXRETRIES;
> > > +
> > > + if (WARN_ON(pipe >= dev->num_crtcs))
> > > + return;
> > > +
> > > + assert_spin_locked(>vbl_lock);
> > > + assert_spin_locked(>vblank_time_lock);
> > > +
> > > + vblank = >vblank[pipe];
> > > + WARN_ONCE((drm_debug & DRM_UT_VBL) && !vblank->framedur_ns,
> > 
> > do we really only need this warn on debug vlb?
> > 
> > > +   "Cannot compute missed vblanks without frame duration\n");
> > 
> > The message seems hard... if we *cannot* why do we move fwd?
> 
> We assume the diff is 1 and make an update, some kind of a default
> similar to what is implemented in drm_update_vblank_count()
> 
> > 
> > > + framedur_ns = vblank->framedur_ns;
> > > +
> > > + do {
> > > + cur_vblank = __get_vblank_counter(dev, pipe);
> > > + drm_get_last_vbltimestamp(dev, pipe, _vblank, false);
> > > + } while (cur_vblank != __get_vblank_counter(dev, pipe) && --count > 0);
> > 
> > Based on the commend of drm_update_vblank_count I don't feel that we have to
> 
> 
> This one? -
> "* We repeat the hardware vblank counter & timestamp query until
>  * we get consistent results. This to prevent races between gpu
>  * updating its hardware counter while we are retrieving the
>  * corresponding vblank timestamp." 
> 
> 
> I added the loop based on that comment. If the register if partially
> updated, we want to discard that and loop until it is stable.
> 
> 
> > do the loop here... And if we have maybe we should re-org things to avoid
> > duplication?
> > 
> 
> I considered that, we need to pass at least four args for three lines of
> code. Felt it was too small to warrant a separate function.
> 
> 
> > > +
> > > + diff_ns = ktime_to_ns(ktime_sub(t_vblank, vblank->time));
> > > + if (framedur_ns)
> > > + diff = DIV_ROUND_CLOSEST_ULL(diff_ns, framedur_ns);
> > > +
> > > +
> > > + DRM_DEBUG_VBL("missed %d vblanks in %lld ns, frame duration=%d ns, 
> > > hw_diff=%d\n",
> > > +   diff, diff_ns, framedur_ns, cur_vblank - vblank->last);
> > > + store_vblank(dev, pipe, diff, t_vblank, cur_vblank);
> > 
> > hm... I wonder if the simple store_vblank(... __get_vblank_counter(dev, 
> > pipe));
> > wouldn't work here...
> 
> We have to store a stable count.

I don't see why our counter wouldn't be stable at that point?

Our register is zero or the proper counter. Our frm_counter reg
doesn't stop when vblank interrupts are disabled afaik...

But well, I see your point of making something more 

Re: [Intel-gfx] [PATCH 4/5] drm/vblank: Restoring vblank counts after device PM events.

[Pandiyan, Dhinakaran]

On Fri, 2018-01-19 at 00:01 -0800, Rodrigo Vivi wrote:
> On Fri, Jan 12, 2018 at 09:57:06PM +, Dhinakaran Pandiyan wrote:
> > The HW frame counter can get reset if device enters a low power state after
> > vblank interrupts were disabled. This messes up any following vblank count
> > update as a negative diff (huge unsigned diff) is calculated from the HW
> > frame counter change. We cannot ignore negative diffs altogther as there
> > could be legitimate wrap arounds. So, allow drivers to update vblank->count
> > with missed vblanks for the time interrupts were disabled. This is similar
> > to _crtc_vblank_on() except that vblanks interrupts are not enabled at the
> > end as this function is expected to be called from the driver
> > _enable_vblank() vfunc.
> > 
> > v2: drm_crtc_vblank_restore should take crtc as arg. (Chris)
> > Add docs and sprinkle some asserts.
> > 
> > Cc: Daniel Vetter 
> > Cc: Chris Wilson 
> > Cc: Michel Dänzer 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_vblank.c | 59 
> > 
> >  include/drm/drm_vblank.h |  2 ++
> >  2 files changed, 61 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > index 2559d2d7b907..2690966694f0 100644
> > --- a/drivers/gpu/drm/drm_vblank.c
> > +++ b/drivers/gpu/drm/drm_vblank.c
> > @@ -1237,6 +1237,65 @@ void drm_crtc_vblank_on(struct drm_crtc *crtc)
> >  }
> >  EXPORT_SYMBOL(drm_crtc_vblank_on);
> >  
> > +/**
> > + * drm_vblank_restore - estimated vblanks using timestamps and update it.
> > + *
> > + * Power manamement features can cause frame counter resets between vblank
> > + * disable and enable. Drivers can then use this function in their
> > + * _crtc_funcs.enable_vblank implementation to estimate the vblanks 
> > since
> > + * the last _crtc_funcs.disable_vblank.
> > + *
> > + * This function is the legacy version of drm_crtc_vblank_restore().
> > + */
> > +void drm_vblank_restore(struct drm_device *dev, unsigned int pipe)
> > +{
> > +   ktime_t t_vblank;
> > +   struct drm_vblank_crtc *vblank;
> > +   int framedur_ns;
> > +   u64 diff_ns;
> > +   u32 cur_vblank, diff = 1;
> > +   int count = DRM_TIMESTAMP_MAXRETRIES;
> > +
> > +   if (WARN_ON(pipe >= dev->num_crtcs))
> > +   return;
> > +
> > +   assert_spin_locked(>vbl_lock);
> > +   assert_spin_locked(>vblank_time_lock);
> > +
> > +   vblank = >vblank[pipe];
> > +   WARN_ONCE((drm_debug & DRM_UT_VBL) && !vblank->framedur_ns,
> 
> do we really only need this warn on debug vlb?
> 
> > + "Cannot compute missed vblanks without frame duration\n");
> 
> The message seems hard... if we *cannot* why do we move fwd?

We assume the diff is 1 and make an update, some kind of a default
similar to what is implemented in drm_update_vblank_count()

> 
> > +   framedur_ns = vblank->framedur_ns;
> > +
> > +   do {
> > +   cur_vblank = __get_vblank_counter(dev, pipe);
> > +   drm_get_last_vbltimestamp(dev, pipe, _vblank, false);
> > +   } while (cur_vblank != __get_vblank_counter(dev, pipe) && --count > 0);
> 
> Based on the commend of drm_update_vblank_count I don't feel that we have to


This one? -
"* We repeat the hardware vblank counter & timestamp query until
 * we get consistent results. This to prevent races between gpu
 * updating its hardware counter while we are retrieving the
 * corresponding vblank timestamp." 


I added the loop based on that comment. If the register if partially
updated, we want to discard that and loop until it is stable.


> do the loop here... And if we have maybe we should re-org things to avoid
> duplication?
> 

I considered that, we need to pass at least four args for three lines of
code. Felt it was too small to warrant a separate function.


> > +
> > +   diff_ns = ktime_to_ns(ktime_sub(t_vblank, vblank->time));
> > +   if (framedur_ns)
> > +   diff = DIV_ROUND_CLOSEST_ULL(diff_ns, framedur_ns);
> > +
> > +
> > +   DRM_DEBUG_VBL("missed %d vblanks in %lld ns, frame duration=%d ns, 
> > hw_diff=%d\n",
> > + diff, diff_ns, framedur_ns, cur_vblank - vblank->last);
> > +   store_vblank(dev, pipe, diff, t_vblank, cur_vblank);
> 
> hm... I wonder if the simple store_vblank(... __get_vblank_counter(dev, 
> pipe));
> wouldn't work here...

We have to store a stable count.

> 
> > +}
> > +EXPORT_SYMBOL(drm_vblank_restore);
> > +
> > +/**
> > + * drm_crtc_vblank_restore - estimate vblanks using timestamps and update 
> > it.
> > + * Power manamement features can cause frame counter resets between vblank
> > + * disable and enable. Drivers can then use this function in their
> > + * _crtc_funcs.enable_vblank implementation to estimate the vblanks 
> > since
> > + * the last _crtc_funcs.disable_vblank.
> > + */
> > +void drm_crtc_vblank_restore(struct drm_crtc *crtc)
> > +{
> > +   

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Track the number of times we have woken the GPU up

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Track the number of times we have 
woken the GPU up
URL   : https://patchwork.freedesktop.org/series/36802/
State : failure

== Summary ==

Warning: bzip CI_DRM_3658/shard-glkb6/results22.json.bz2 wasn't in correct JSON 
format
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> SKIP   (shard-snb) fdo#103375 +1
Test gem_exec_schedule:
Subgroup wide-vebox:
pass   -> FAIL   (shard-apl) fdo#102848
Test perf:
Subgroup oa-exponents:
pass   -> FAIL   (shard-apl) fdo#102254
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw)
Subgroup vblank-vs-suspend-interruptible:
pass   -> INCOMPLETE (shard-hsw) fdo#100368
Subgroup flip-vs-modeset-vs-hang:
dmesg-warn -> PASS   (shard-snb) fdo#103821
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623 +1

fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#102848 https://bugs.freedesktop.org/show_bug.cgi?id=102848
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-apltotal:2780 pass:1714 dwarn:1   dfail:0   fail:24  skip:1041 
time:14671s
shard-hswtotal:2598 pass:1593 dwarn:1   dfail:1   fail:14  skip:987 
time:13414s
shard-snbtotal:2780 pass:1315 dwarn:1   dfail:1   fail:12  skip:1451 
time:7997s
Blacklisted hosts:
shard-kbltotal:2758 pass:1818 dwarn:1   dfail:1   fail:24  skip:913 
time:10528s

== Logs ==

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Estimate and update missed vblanks.

[Pandiyan, Dhinakaran]

On Thu, 2018-01-18 at 23:26 -0800, Rodrigo Vivi wrote:
> On Fri, Jan 12, 2018 at 09:57:07PM +, Dhinakaran Pandiyan wrote:
> > The frame counter may have got reset between disabling and enabling vblank
> > interrupts due to DMC putting the hardware to DC5/6 state if PSR was
> > active. The frame counter also could have stalled if PSR is active in cases
> > where there is no DMC. The frame counter resetting as a user visible impact
> > of screen freezes. Use drm_vblank_restore() to compute missed vblanks
> > in the duration for which vblank interrupts are disabled. There's no need
> > particularly check if PSR was active in the interrupt disabled duration.
> > 
> > Enabling vblank interrupts wakes up the hardware from DC5/6 and prevents it
> > from going back again as long as the there are pending interrupts. So, we
> > don't have to explicity disallow DC5/6 after enabling vblank interrupts
> > to keep the counter running.
> > 
> > Let's not apply this to CHV for now, as enabling interrupts does not
> > prevent the hardware from activating PSR and thereby stalling the counter.
> > 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_irq.c | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 3517c6548e2c..db3466ec6faa 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2956,6 +2956,9 @@ static int ironlake_enable_vblank(struct drm_device 
> > *dev, unsigned int pipe)
> > ilk_enable_display_irq(dev_priv, bit);
> > spin_unlock_irqrestore(_priv->irq_lock, irqflags);
> >  
> > +   if (HAS_PSR(dev_priv))
> > +   drm_vblank_restore(dev, pipe);
> > +
> 
> I don't believe we need this one here.
> 
> pre-gen9 platform has psr but not dmc, so the case
> where we need to restore the counter doesn't exist.

Even without DMC, counter should be stuck when PSR is active as no
frames are generated by the pipe. I am using drm_vblank_restore_count()
to take care of that.

> 
> > return 0;
> >  }
> >  
> > @@ -2968,6 +2971,9 @@ static int gen8_enable_vblank(struct drm_device *dev, 
> > unsigned int pipe)
> > bdw_enable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
> > spin_unlock_irqrestore(_priv->irq_lock, irqflags);
> >  
> > +   if (HAS_PSR(dev_priv))
> 
> HAS_PSR(dev_priv) && HAS_CSR(dev_priv)
> maybe?
> So it gets clear that it is not because PSR that we need to restore
> the counter, but also don't do it when not needed.

Same reason as above, let me test this again by disabling DMC.

> 
> > +   drm_vblank_restore(dev, pipe);
> > +
> > return 0;
> >  }
> >  
> > -- 
> > 2.11.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 1/5] drm/vblank: Fix return type for drm_vblank_count()

[Pandiyan, Dhinakaran]

On Thu, 2018-01-18 at 23:36 -0800, Rodrigo Vivi wrote:
> On Fri, Jan 12, 2018 at 09:57:03PM +, Dhinakaran Pandiyan wrote:
> > drm_vblank_count() has a u32 type returning what is a 64-bit vblank count.
> > The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
> > space requested vblank sequence using this clipped 32-bit count(when the
> > value is >= 2^32) as reference, the requested sequence remains a 32-bit
> > value and gets queued like that. However, the code that checks if the
> > requested sequence has passed compares this against the 64-bit vblank
> > count.
> 
> Worth to mention and probably
> Fixes: 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]")
> 
> btw, I spotted at least one more place even with the series applied.
> 32 current_vblank; at drm_mode_page_flip_ioctl...
> 

There seem to be several such callers for drm_crtc_vblank_count(). I can
fix it up as a follow-up series.

> so, probably worth to do a deeper check down to all paths...
> 
> anayway, for this patch:
> Reviewed-by: Rodrigo Vivi 
> 
> > 
> > Cc: Keith Packard 
> > Cc: Michel Dänzer 
> > Cc: Daniel Vetter 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_vblank.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > index 32d9bcf5be7f..768a8e44d99b 100644
> > --- a/drivers/gpu/drm/drm_vblank.c
> > +++ b/drivers/gpu/drm/drm_vblank.c
> > @@ -271,7 +271,7 @@ static void drm_update_vblank_count(struct drm_device 
> > *dev, unsigned int pipe,
> > store_vblank(dev, pipe, diff, t_vblank, cur_vblank);
> >  }
> >  
> > -static u32 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
> > +static u64 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
> >  {
> > struct drm_vblank_crtc *vblank = >vblank[pipe];
> >  
> > -- 
> > 2.11.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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Shrink the request kmem_cache on allocation error

[Patchwork]

== Series Details ==

Series: drm/i915: Shrink the request kmem_cache on allocation error
URL   : https://patchwork.freedesktop.org/series/36800/
State : success

== Summary ==

Warning: bzip CI_DRM_3658/shard-glkb6/results22.json.bz2 wasn't in correct JSON 
format
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623 +1
Test gem_tiled_swapping:
Subgroup non-threaded:
pass   -> INCOMPLETE (shard-snb) fdo#104218 +1
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103540
Subgroup cursor-256x256-suspend:
incomplete -> PASS   (shard-hsw) fdo#103375
Test kms_flip:
Subgroup modeset-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060
Subgroup plain-flip-ts-check-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Subgroup flip-vs-modeset-vs-hang:
dmesg-warn -> PASS   (shard-snb) fdo#103821
Test gen7_forcewake_mt:
fail   -> INCOMPLETE (shard-hsw)
Test gem_pwrite_pread:
Subgroup snooped-pwrite-blt-cpu_mmap-performance:
notrun -> INCOMPLETE (shard-hsw)
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252

fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-apltotal:2768 pass:1708 dwarn:1   dfail:0   fail:22  skip:1036 
time:14298s
shard-hswtotal:2697 pass:1659 dwarn:1   dfail:1   fail:14  skip:1018 
time:13463s
shard-snbtotal:2768 pass:1308 dwarn:1   dfail:1   fail:12  skip:1445 
time:7898s
Blacklisted hosts:
shard-kbltotal:2680 pass:1769 dwarn:1   dfail:0   fail:24  skip:885 
time:10373s

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Allow clients to query own per-engine busyness

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-19 13:45:24)
> +   case I915_CONTEXT_GET_ENGINE_BUSY:
> +   engine = intel_engine_lookup_user(i915, args->class,
> + args->instance);
> +   if (!engine) {
> +   ret = -EINVAL;
> +   break;
> +   }
> +
> +   ce = >engine[engine->id];
> +   if (!READ_ONCE(ce->stats.enabled)) {
> +   ret = i915_mutex_lock_interruptible(dev);
> +   if (!ret)
> +   break;
> +
> +   if (!ce->stats.enabled) {
> +   ret = intel_enable_engine_stats(engine);

* Blink.

This caught me by surprise. (Other than struct_mutex) Not too offensive,
but surprising. At the very least call out to a function to handle the
request. Where did args->class, args->instance come from? You surely
didn't extend the ioctl struct just for that?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 1/6] drm/i915: Track per-context engine busyness

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-19 16:26:16)
> From: Tvrtko Ursulin 
> 
> Some customers want to know how much of the GPU time are their clients
> using in order to make dynamic load balancing decisions.
> 
> With the hooks already in place which track the overall engine busyness,
> we can extend that slightly to split that time between contexts.
> 
> v2: Fix accounting for tail updates.
> v3: Rebase.
> v4: Mark currently running contexts as active on stats enable.
> v5: Include some headers to fix the build.
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: gordon.ke...@intel.com
> ---
>  drivers/gpu/drm/i915/i915_gem_context.h |  8 ++
>  drivers/gpu/drm/i915/intel_engine_cs.c  | 32 +
>  drivers/gpu/drm/i915/intel_lrc.c| 14 +
>  drivers/gpu/drm/i915/intel_ringbuffer.h | 50 
> +
>  4 files changed, 93 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.h 
> b/drivers/gpu/drm/i915/i915_gem_context.h
> index 4bfb72f8e1cb..7f5eebb67167 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.h
> +++ b/drivers/gpu/drm/i915/i915_gem_context.h
> @@ -29,6 +29,9 @@
>  #include 
>  #include 
>  
> +#include "i915_gem.h"
> +#include "i915_gem_request.h"

Yup, we need a patch for tip for

#include "i915_gem.h"

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

Re: [Intel-gfx] [PATCH] drm/i915: vbt defs typo fixes

[Adam Jackson]

On Fri, 2018-01-19 at 10:17 +0200, Jani Nikula wrote:
> On Thu, 18 Jan 2018, Adam Jackson  wrote:
> > On Thu, 2018-01-18 at 17:06 +0200, Jani Nikula wrote:
> > > No more sing-a-ling.
> > > 
> > > Reported-by: Adam Jackson 
> > 
> > Why'd you omit the typos I reported in tools/intel_vbt_decode.c ?
> 
> This one's for the kernel. I'll apply your original patch to igt. (Sorry
> for the delay.)

Sorry about that, just saw the file name not the repo. Thanks!

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

Re: [Intel-gfx] [RFC] drm/i915/guc: Keep GuC log disabled by default

[Chris Wilson]

Quoting Michał Winiarski (2018-01-19 13:36:27)
> On Fri, Jan 19, 2018 at 12:49:26PM +, Michal Wajdeczko wrote:
> > It looks that GuC log functionality is not fully functional yet and
> > causes issues when enabled by auto(-1) modparam on debug builds.
> > 
> > [   30.062893] ==
> > [   30.062894] WARNING: possible circular locking dependency detected
> > [   30.062895] 4.15.0-rc8-CI-CI_DRM_3648+ #1 Tainted: G U
> > [   30.062896] --
> > [   30.062897] debugfs_test/1268 is trying to acquire lock:
> > [   30.062898]  (>struct_mutex){+.+.}, at: [] 
> > i915_mutex_lock_interruptible+0x47/0x130 [i915]
> > [   30.062921]
> >but task is already holding lock:
> > [   30.062921]  (>mmap_sem){}, at: [] 
> > __do_page_fault+0x106/0x560
> > [   30.062924]
> >which lock already depends on the new lock.
> > 
> 
> I'd leave the lockdep splat out of here, since that's just the tip of the
> iceberg :)
> 
> > Fixes: 0ed87953532652 ("drm/i915/guc: Redefine guc_log_level modparam 
> > values")
> 
> s/Fixes/References
> 
> It allows us to get test results while we're fixing the logging issues, so:
> 
> Reviewed-by: Michał Winiarski 

I agree. It's a mess, but disabling it for now lets CI provide test
coverage and early warning for new breakage. So pushed, even though it's
an RFC.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Implement display w/a #1143

[Runyan, Arthur J]

Yes, this applies to CFL also.  CFL follows on from KBL and doesn't have any 
display changes, so for the workarounds you can translate KBL:All to CFL:All.  
There is a note about that.

-Original Message-
From: Vivi, Rodrigo 
Sent: Friday, 19 January, 2018 12:08 PM
To: Ville Syrjala 
Cc: intel-gfx@lists.freedesktop.org; Runyan, Arthur J 

Subject: Re: [Intel-gfx] [PATCH] drm/i915: Implement display w/a #1143

On Fri, Jan 19, 2018 at 06:45:49PM +, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Apparently SKL/KBL need some manual help to get the
> programmed HDMI vswing to stick. Implement the relevant
> workaround (display w/a #1143).
> 
> Note that the relevant chicken bits live in a transcoder register
> even though the bits affect a specific DDI port rather than a
> specific transcoder. Hence we must pick the correct transcoder
> register instance based on the port rather than based on the
> cpu_transcoder.
> 
> Also note that for completeness I included support for DDI A/E
> in the code even though we never have HDMI on those ports.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  8 ++--
>  drivers/gpu/drm/i915/intel_ddi.c | 42 
> 
>  2 files changed, 48 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 10e1269ad6af..2e6d0dc01dc7 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7012,8 +7012,12 @@ enum {
>  #define CHICKEN_TRANS_A 0x420c0
>  #define CHICKEN_TRANS_B 0x420c4
>  #define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A, 
> CHICKEN_TRANS_B)
> -#define PSR2_VSC_ENABLE_PROG_HEADER(1<<12)
> -#define PSR2_ADD_VERTICAL_LINE_COUNT   (1<<15)
> +#define  DDI_TRAINING_OVERRIDE_ENABLE(1<<19)
> +#define  DDI_TRAINING_OVERRIDE_VALUE (1<<18)
> +#define  DDIE_TRAINING_OVERRIDE_ENABLE   (1<<17) /* CHICKEN_TRANS_A only 
> */
> +#define  DDIE_TRAINING_OVERRIDE_VALUE(1<<16) /* CHICKEN_TRANS_A only 
> */

Wa on Bspec doesnt mention port E, although it makes sense to have...
maybe a WARN_ON if DDIE but not TRANS_A then?!

> +#define  PSR2_ADD_VERTICAL_LINE_COUNT   (1<<15)
> +#define  PSR2_VSC_ENABLE_PROG_HEADER(1<<12)
>  
>  #define DISP_ARB_CTL _MMIO(0x45000)
>  #define  DISP_FBC_MEMORY_WAKE(1<<31)
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 6260a882fbe4..7b1ab003279f 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2433,6 +2433,48 @@ static void intel_enable_ddi_hdmi(struct intel_encoder 
> *encoder,
> 
> crtc_state->hdmi_high_tmds_clock_ratio,
> crtc_state->hdmi_scrambling);
>  
> + /* Display WA #1143: skl,kbl */
> + if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {

on KBL, but not on CFL?! Strange... Art?

> + /*
> +  * For some reason these chicken bits have been
> +  * stuffed into a transcoder register, event though
> +  * the bits affect a specific DDI port rather than
> +  * a specific transcoder.
> +  */
> + static const enum transcoder port_to_transcoder[] = {
> + [PORT_A] = TRANSCODER_EDP,
> + [PORT_B] = TRANSCODER_A,
> + [PORT_C] = TRANSCODER_B,
> + [PORT_D] = TRANSCODER_C,
> + [PORT_E] = TRANSCODER_A,
> + };
> + enum transcoder transcoder = port_to_transcoder[port];
> + u32 val;
> +
> + val = I915_READ(CHICKEN_TRANS(transcoder));
> +
> + if (port == PORT_E)
> + val |= DDIE_TRAINING_OVERRIDE_ENABLE |
> + DDIE_TRAINING_OVERRIDE_VALUE;
> + else
> + val |= DDI_TRAINING_OVERRIDE_ENABLE |
> + DDI_TRAINING_OVERRIDE_VALUE;
> +
> + I915_WRITE(CHICKEN_TRANS(transcoder), val);
> + POSTING_READ(CHICKEN_TRANS(transcoder));
> +
> + udelay(1);
> +
> + if (port == PORT_E)
> + val &= ~(DDIE_TRAINING_OVERRIDE_ENABLE |
> +  DDIE_TRAINING_OVERRIDE_VALUE);
> + else
> + val &= ~(DDI_TRAINING_OVERRIDE_ENABLE |
> +  DDI_TRAINING_OVERRIDE_VALUE);
> +
> + I915_WRITE(CHICKEN_TRANS(transcoder), val);
> + }
> +
>   /* In HDMI/DVI mode, the port width, and swing/emphasis values
>* are ignored so nothing special needs to be done besides
>* enabling the port.
> -- 
> 2.13.6
> 
> 

Re: [Intel-gfx] [PATCH 07/27] drm/i915/icl: Interrupt handling

[Chris Wilson]

Quoting Paulo Zanoni (2018-01-19 18:10:51)
> Em Sex, 2018-01-19 às 17:30 +, Tvrtko Ursulin escreveu:
> > On 10/01/2018 10:16, Joonas Lahtinen wrote:
> > > If these are in a later patch, should be squashed here.
> > 
> > It might be possible in some cases, or it might be quite challenging
> > in 
> > others. Need to look into it but no promises. We might have to live
> > with 
> > having place holders like this in the code which get removed by
> > later 
> > patches/series. It's quite complex logistically to organise multiple 
> > series, written by multiple authors, at different times, and make it 
> > look 100% pretty. (And not just squash and butcher everything up at 
> > merge time.)
> 
> I agree with Tvrtko here and in the other points above. If we take
> Joonas's point to the extreme, ICL enabling would be a single giant
> patch. We have to accept that some things are going to be incomplete in
> the series that enable a platform. We also have the alpha_support
> option to protect us here, and CI to make sure ICL's incompleteness
> doesn't affect the other platforms.

Later in this series is a patch which fixes a bug in this patch. That
certainly needs to be addressed. ;)
-Chris
___
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: expose RCS topology to userspace

[Patchwork]

== Series Details ==

Series: drm/i915: expose RCS topology to userspace
URL   : https://patchwork.freedesktop.org/series/36793/
State : success

== Summary ==

Warning: bzip CI_DRM_3658/shard-glkb6/results22.json.bz2 wasn't in correct JSON 
format
Test perf:
Subgroup oa-exponents:
pass   -> FAIL   (shard-apl) fdo#102254
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252
Test pm_sseu:
Subgroup full-enable:
pass   -> FAIL   (shard-apl) fdo#104651
Test kms_flip:
Subgroup flip-vs-modeset-vs-hang:
dmesg-warn -> PASS   (shard-snb) fdo#103821
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623 +1
Test gem_eio:
Subgroup in-flight:
pass   -> DMESG-WARN (shard-snb) fdo#104058
Test gem_softpin:
Subgroup noreloc-s4:
dmesg-fail -> FAIL   (shard-snb) fdo#103375

fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#104651 https://bugs.freedesktop.org/show_bug.cgi?id=104651
fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375

shard-apltotal:2780 pass:1714 dwarn:1   dfail:0   fail:24  skip:1041 
time:14636s
shard-hswtotal:2772 pass:1714 dwarn:1   dfail:1   fail:13  skip:1041 
time:14887s
shard-snbtotal:2780 pass:1315 dwarn:2   dfail:0   fail:13  skip:1450 
time:8057s
Blacklisted hosts:
shard-kbltotal:2758 pass:1741 dwarn:79  dfail:5   fail:23  skip:909 
time:10708s

== Logs ==

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

Re: [Intel-gfx] [PATCH 0/8] ICP initial support

[Paulo Zanoni]

Em Qui, 2018-01-11 às 16:00 -0200, Paulo Zanoni escreveu:
> Hi
> 
> This series adds the initial support for ICP. No conflicts with the
> other
> series. Patches 1 and 2 are parts of other series that we've already
> been
> discussing on this mailing list, but I put them here so CI can do the
> right
> thing.
> 
> I have just re-reviewed all of Anusha's patches and my reviewed-by
> tags still
> stand, which means every patch on this series has a r-b tag. I'll let
> the series
> sit on the mailing list for a while before merging, just in case
> someone else
> has something to say.
> 
> The one thing missing for complete ICP support is the patch that adds
> the
> interrupts, but that requires code from other series (including the
> GEM one
> currently under review), so it will be sent later.


Series merged. Thanks everybody for the help.

> 
> Thanks,
> Paulo
> 
> Anusha Srivatsa (6):
>   drm/i915/icp: Introduce Ice Lake PCH
>   drm/i915/icp: Get/set proper Raw clock frequency on ICP
>   drm/i915/icp: Add Panel Power Sequencing Support
>   drm/i915/icp: Add backlight Support for ICP
>   drm/i915/icp: add ICP gmbus and gpio support
>   drm/i915/icp: Add the ID for ICL PCH - ICP
> 
> Rodrigo Vivi (2):
>   drm/i915/cnl: Add Port F definition.
>   drm/i915/icl: Add initial Icelake definitions.
> 
>  drivers/gpu/drm/i915/i915_drv.c  |  4 
>  drivers/gpu/drm/i915/i915_drv.h  |  5 +
>  drivers/gpu/drm/i915/i915_pci.c  | 13 +
>  drivers/gpu/drm/i915/i915_reg.h  |  9 -
>  drivers/gpu/drm/i915/intel_bios.c|  9 +
>  drivers/gpu/drm/i915/intel_cdclk.c   | 29
> ++--
>  drivers/gpu/drm/i915/intel_device_info.c |  1 +
>  drivers/gpu/drm/i915/intel_device_info.h |  2 ++
>  drivers/gpu/drm/i915/intel_display.h |  1 +
>  drivers/gpu/drm/i915/intel_dp.c  | 20 +--
>  drivers/gpu/drm/i915/intel_hdmi.c| 33
> 
>  drivers/gpu/drm/i915/intel_i2c.c | 17 ++--
>  drivers/gpu/drm/i915/intel_panel.c   |  2 +-
>  drivers/gpu/drm/i915/intel_vbt_defs.h|  2 ++
>  include/drm/i915_component.h |  3 +--
>  15 files changed, 136 insertions(+), 14 deletions(-)
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Implement display w/a #1143

[Rodrigo Vivi]

On Fri, Jan 19, 2018 at 06:45:49PM +, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Apparently SKL/KBL need some manual help to get the
> programmed HDMI vswing to stick. Implement the relevant
> workaround (display w/a #1143).
> 
> Note that the relevant chicken bits live in a transcoder register
> even though the bits affect a specific DDI port rather than a
> specific transcoder. Hence we must pick the correct transcoder
> register instance based on the port rather than based on the
> cpu_transcoder.
> 
> Also note that for completeness I included support for DDI A/E
> in the code even though we never have HDMI on those ports.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  8 ++--
>  drivers/gpu/drm/i915/intel_ddi.c | 42 
> 
>  2 files changed, 48 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 10e1269ad6af..2e6d0dc01dc7 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7012,8 +7012,12 @@ enum {
>  #define CHICKEN_TRANS_A 0x420c0
>  #define CHICKEN_TRANS_B 0x420c4
>  #define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A, 
> CHICKEN_TRANS_B)
> -#define PSR2_VSC_ENABLE_PROG_HEADER(1<<12)
> -#define PSR2_ADD_VERTICAL_LINE_COUNT   (1<<15)
> +#define  DDI_TRAINING_OVERRIDE_ENABLE(1<<19)
> +#define  DDI_TRAINING_OVERRIDE_VALUE (1<<18)
> +#define  DDIE_TRAINING_OVERRIDE_ENABLE   (1<<17) /* CHICKEN_TRANS_A only 
> */
> +#define  DDIE_TRAINING_OVERRIDE_VALUE(1<<16) /* CHICKEN_TRANS_A only 
> */

Wa on Bspec doesnt mention port E, although it makes sense to have...
maybe a WARN_ON if DDIE but not TRANS_A then?!

> +#define  PSR2_ADD_VERTICAL_LINE_COUNT   (1<<15)
> +#define  PSR2_VSC_ENABLE_PROG_HEADER(1<<12)
>  
>  #define DISP_ARB_CTL _MMIO(0x45000)
>  #define  DISP_FBC_MEMORY_WAKE(1<<31)
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 6260a882fbe4..7b1ab003279f 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2433,6 +2433,48 @@ static void intel_enable_ddi_hdmi(struct intel_encoder 
> *encoder,
> 
> crtc_state->hdmi_high_tmds_clock_ratio,
> crtc_state->hdmi_scrambling);
>  
> + /* Display WA #1143: skl,kbl */
> + if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {

on KBL, but not on CFL?! Strange... Art?

> + /*
> +  * For some reason these chicken bits have been
> +  * stuffed into a transcoder register, event though
> +  * the bits affect a specific DDI port rather than
> +  * a specific transcoder.
> +  */
> + static const enum transcoder port_to_transcoder[] = {
> + [PORT_A] = TRANSCODER_EDP,
> + [PORT_B] = TRANSCODER_A,
> + [PORT_C] = TRANSCODER_B,
> + [PORT_D] = TRANSCODER_C,
> + [PORT_E] = TRANSCODER_A,
> + };
> + enum transcoder transcoder = port_to_transcoder[port];
> + u32 val;
> +
> + val = I915_READ(CHICKEN_TRANS(transcoder));
> +
> + if (port == PORT_E)
> + val |= DDIE_TRAINING_OVERRIDE_ENABLE |
> + DDIE_TRAINING_OVERRIDE_VALUE;
> + else
> + val |= DDI_TRAINING_OVERRIDE_ENABLE |
> + DDI_TRAINING_OVERRIDE_VALUE;
> +
> + I915_WRITE(CHICKEN_TRANS(transcoder), val);
> + POSTING_READ(CHICKEN_TRANS(transcoder));
> +
> + udelay(1);
> +
> + if (port == PORT_E)
> + val &= ~(DDIE_TRAINING_OVERRIDE_ENABLE |
> +  DDIE_TRAINING_OVERRIDE_VALUE);
> + else
> + val &= ~(DDI_TRAINING_OVERRIDE_ENABLE |
> +  DDI_TRAINING_OVERRIDE_VALUE);
> +
> + I915_WRITE(CHICKEN_TRANS(transcoder), val);
> + }
> +
>   /* In HDMI/DVI mode, the port width, and swing/emphasis values
>* are ignored so nothing special needs to be done besides
>* enabling the port.
> -- 
> 2.13.6
> 
> ___
> 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 6/8] drm/i915/icp: Add backlight Support for ICP

[Rodrigo Vivi]

On Fri, Jan 19, 2018 at 06:48:12PM +, Paulo Zanoni wrote:
> From: Anusha Srivatsa 
> 
> ICP has two backlight controllers - similar to previous platforms like
> BXT -, but we only use one controller for now, so we can just reuse
> the CNP code.
> 
> v2: Remove the usage of ICP_SECOND_PPS_BACKLIGHT register.(Jani)
> Reuse CNP code since it is very similar.(Ville)
> v3 (from Paulo): Rebase.
> v4 (from Paulo): adjust commit message (James) and comment (Rodrigo).

thanks
x
Acked-by: Rodrigo Vivi 

> 
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: James Ausmus 
> Cc: Rodrigo Vivi 
> Reviewed-by: Paulo Zanoni 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_panel.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index fa6831f8c004..e702a6487aa9 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -1719,9 +1719,9 @@ cnp_setup_backlight(struct intel_connector *connector, 
> enum pipe unused)
>   u32 pwm_ctl, val;
>  
>   /*
> -  * CNP has the BXT implementation of backlight, but with only
> -  * one controller. Future platforms could have multiple controllers
> -  * so let's make this extensible and prepared for the future.
> +  * CNP has the BXT implementation of backlight, but with only one
> +  * controller. TODO: ICP has multiple controllers but we only use
> +  * controller 0 for now.
>*/
>   panel->backlight.controller = 0;
>  
> @@ -1865,7 +1865,7 @@ intel_panel_init_backlight_funcs(struct intel_panel 
> *panel)
>   panel->backlight.set = bxt_set_backlight;
>   panel->backlight.get = bxt_get_backlight;
>   panel->backlight.hz_to_pwm = bxt_hz_to_pwm;
> - } else if (HAS_PCH_CNP(dev_priv)) {
> + } else if (HAS_PCH_CNP(dev_priv) || HAS_PCH_ICP(dev_priv)) {
>   panel->backlight.setup = cnp_setup_backlight;
>   panel->backlight.enable = cnp_enable_backlight;
>   panel->backlight.disable = cnp_disable_backlight;
> -- 
> 2.14.3
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for ICP initial support (rev2)

[Patchwork]

== Series Details ==

Series: ICP initial support (rev2)
URL   : https://patchwork.freedesktop.org/series/36350/
State : success

== Summary ==

Series 36350v2 ICP initial support
https://patchwork.freedesktop.org/api/1.0/series/36350/revisions/2/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> PASS   (fi-elk-e7500) fdo#103989 +2

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:426s
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:383s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:524s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:293s
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:502s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:494s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:480s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:306s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:528s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:406s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:426s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:462s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:421s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:465s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:504s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:461s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:512s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:641s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:435s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:524s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:536s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:493s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:505s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:542s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:409s
Blacklisted hosts:
fi-cfl-s2total:288  pass:256  dwarn:0   dfail:0   fail:3   skip:26  
time:568s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:490s
fi-skl-guc   total:288  pass:221  dwarn:39  dfail:0   fail:0   skip:28  
time:419s

a0584e868ec718af8a385cbae61fee0b25bdfd22 drm-tip: 2018y-01m-19d-18h-21m-15s UTC 
integration manifest
fab9e398bf3d drm/i915/icp: Add the ID for ICL PCH - ICP
9ad3e0909344 drm/i915/icp: add ICP gmbus and gpio support
af6b3f70f539 drm/i915/icp: Add backlight Support for ICP
d71632a5960b drm/i915/icp: Add Panel Power Sequencing Support
428295d9ce61 drm/i915/icp: Get/set proper Raw clock frequency on ICP
8d623eefe66c drm/i915/icp: Introduce Ice Lake PCH
13193af7921c drm/i915/icl: Add initial Icelake definitions.
affa7c0aee2a drm/i915/cnl: Add Port F definition.

== Logs ==

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

Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

[Ausmus, James]

On Fri, Jan 19, 2018 at 10:48 AM, Paulo Zanoni 
wrote:
>
> From: Anusha Srivatsa 
>
> ICP has two backlight controllers - similar to previous platforms like
> BXT -, but we only use one controller for now, so we can just reuse
> the CNP code.
>
> v2: Remove the usage of ICP_SECOND_PPS_BACKLIGHT register.(Jani)
> Reuse CNP code since it is very similar.(Ville)
> v3 (from Paulo): Rebase.
> v4 (from Paulo): adjust commit message (James) and comment (Rodrigo).
>
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: James Ausmus 
> Cc: Rodrigo Vivi 
> Reviewed-by: Paulo Zanoni 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Paulo Zanoni 

Looks good, thanks!

Acked-by: James Ausmus 


>
> ---
>  drivers/gpu/drm/i915/intel_panel.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
> index fa6831f8c004..e702a6487aa9 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -1719,9 +1719,9 @@ cnp_setup_backlight(struct intel_connector
*connector, enum pipe unused)
> u32 pwm_ctl, val;
>
> /*
> -* CNP has the BXT implementation of backlight, but with only
> -* one controller. Future platforms could have multiple
controllers
> -* so let's make this extensible and prepared for the future.
> +* CNP has the BXT implementation of backlight, but with only one
> +* controller. TODO: ICP has multiple controllers but we only use
> +* controller 0 for now.
>  */
> panel->backlight.controller = 0;
>
> @@ -1865,7 +1865,7 @@ intel_panel_init_backlight_funcs(struct intel_panel
*panel)
> panel->backlight.set = bxt_set_backlight;
> panel->backlight.get = bxt_get_backlight;
> panel->backlight.hz_to_pwm = bxt_hz_to_pwm;
> -   } else if (HAS_PCH_CNP(dev_priv)) {
> +   } else if (HAS_PCH_CNP(dev_priv) || HAS_PCH_ICP(dev_priv)) {
> panel->backlight.setup = cnp_setup_backlight;
> panel->backlight.enable = cnp_enable_backlight;
> panel->backlight.disable = cnp_disable_backlight;
> --
> 2.14.3
>



--


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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Keep GuC log disabled by default

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Keep GuC log disabled by default
URL   : https://patchwork.freedesktop.org/series/36796/
State : failure

== Summary ==

Warning: bzip CI_DRM_3658/shard-glkb6/results22.json.bz2 wasn't in correct JSON 
format
Test pm_rps:
Subgroup reset:
pass   -> FAIL   (shard-apl) fdo#104218 +1
Test gem_exec_schedule:
Subgroup deep-vebox:
skip   -> FAIL   (shard-apl) fdo#102848
Test kms_flip:
Subgroup flip-vs-modeset-vs-hang:
dmesg-warn -> PASS   (shard-snb) fdo#103821
Test kms_cursor_crc:
Subgroup cursor-128x128-sliding:
pass   -> INCOMPLETE (shard-hsw)
Test perf:
Subgroup enable-disable:
pass   -> FAIL   (shard-apl) fdo#103715
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252
Test gem_linear_blits:
Subgroup normal:
skip   -> PASS   (shard-apl)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623

fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218
fdo#102848 https://bugs.freedesktop.org/show_bug.cgi?id=102848
fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-apltotal:2768 pass:1707 dwarn:1   dfail:0   fail:25  skip:1034 
time:14307s
shard-hswtotal:2741 pass:1689 dwarn:1   dfail:1   fail:13  skip:1034 
time:13978s
shard-snbtotal:2780 pass:1317 dwarn:1   dfail:1   fail:11  skip:1450 
time:8044s
Blacklisted hosts:
shard-kbltotal:2746 pass:1813 dwarn:1   dfail:1   fail:23  skip:906 
time:10428s

== Logs ==

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

[Intel-gfx] [PATCH v3] drm/i915/icl: Set graphics mode register for gen11

[Kelvin Gardiner]

This patch clears a single bit. The bit is 0 by default but expected not to be
set. Explicitly clearing the bit in this patch is intended to indicate some
thinking has occurred, and that we want this bit cleared and we are not just
excepting the default value.

v2 (from Paulo): fix indentation.
v3: Changed GEN check to >= 11. Corrected author name.

Signed-off-by: Kelvin Gardiner 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h  |  2 ++
 drivers/gpu/drm/i915/intel_lrc.c | 18 --
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 73c9c36..057f90e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2604,6 +2604,8 @@ enum i915_power_well_id {
 #define   GFX_FORWARD_VBLANK_ALWAYS(1<<5)
 #define   GFX_FORWARD_VBLANK_COND  (2<<5)
 
+#define   GEN11_GFX_DISABLE_LEGACY_MODE(1<<3)
+
 #define VLV_DISPLAY_BASE 0x18
 #define VLV_MIPI_BASE VLV_DISPLAY_BASE
 #define BXT_MIPI_BASE 0x6
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index dab988f..d4cc5c9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1500,8 +1500,22 @@ static void enable_execlists(struct intel_engine_cs 
*engine)
struct drm_i915_private *dev_priv = engine->i915;
 
I915_WRITE(RING_HWSTAM(engine->mmio_base), 0x);
-   I915_WRITE(RING_MODE_GEN7(engine),
-  _MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE));
+
+   /*
+* Make sure we're not enabling the new 12-deep CSB
+* FIFO as that requires a slightly updated handling
+* in the ctx switch irq. Since we're currently only
+* using only 2 elements of the enhanced execlists the
+* deeper FIFO it's not needed and it's not worth adding
+* more statements to the irq handler to support it.
+   */
+   if (INTEL_GEN(dev_priv) >= 11)
+   I915_WRITE(RING_MODE_GEN7(engine),
+  _MASKED_BIT_DISABLE(GEN11_GFX_DISABLE_LEGACY_MODE));
+   else
+   I915_WRITE(RING_MODE_GEN7(engine),
+  _MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE));
+
I915_WRITE(RING_HWS_PGA(engine->mmio_base),
   engine->status_page.ggtt_offset);
POSTING_READ(RING_HWS_PGA(engine->mmio_base));
-- 
1.9.1

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Implement display w/a #1143

[Patchwork]

== Series Details ==

Series: drm/i915: Implement display w/a #1143
URL   : https://patchwork.freedesktop.org/series/36813/
State : success

== Summary ==

Series 36813v1 drm/i915: Implement display w/a #1143
https://patchwork.freedesktop.org/api/1.0/series/36813/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:426s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:435s
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:511s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:294s
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:504s
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:483s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:306s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:528s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:406s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:422s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:460s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:424s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:466s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:508s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:458s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:640s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:447s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:519s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:532s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:489s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:438s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:532s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:403s
Blacklisted hosts:
fi-cfl-s2total:288  pass:256  dwarn:0   dfail:0   fail:3   skip:26  
time:564s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:485s
fi-skl-guc   total:288  pass:216  dwarn:44  dfail:0   fail:0   skip:28  
time:417s

fa43579841f4858ed082e779c5a45b829a6c99f4 drm-tip: 2018y-01m-19d-17h-26m-25s UTC 
integration manifest
c92cf75263e1 drm/i915: Implement display w/a #1143

== Logs ==

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

[Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

[Paulo Zanoni]

From: Anusha Srivatsa 

ICP has two backlight controllers - similar to previous platforms like
BXT -, but we only use one controller for now, so we can just reuse
the CNP code.

v2: Remove the usage of ICP_SECOND_PPS_BACKLIGHT register.(Jani)
Reuse CNP code since it is very similar.(Ville)
v3 (from Paulo): Rebase.
v4 (from Paulo): adjust commit message (James) and comment (Rodrigo).

Cc: Jani Nikula 
Cc: Ville Syrjala 
Cc: James Ausmus 
Cc: Rodrigo Vivi 
Reviewed-by: Paulo Zanoni 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_panel.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index fa6831f8c004..e702a6487aa9 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1719,9 +1719,9 @@ cnp_setup_backlight(struct intel_connector *connector, 
enum pipe unused)
u32 pwm_ctl, val;
 
/*
-* CNP has the BXT implementation of backlight, but with only
-* one controller. Future platforms could have multiple controllers
-* so let's make this extensible and prepared for the future.
+* CNP has the BXT implementation of backlight, but with only one
+* controller. TODO: ICP has multiple controllers but we only use
+* controller 0 for now.
 */
panel->backlight.controller = 0;
 
@@ -1865,7 +1865,7 @@ intel_panel_init_backlight_funcs(struct intel_panel 
*panel)
panel->backlight.set = bxt_set_backlight;
panel->backlight.get = bxt_get_backlight;
panel->backlight.hz_to_pwm = bxt_hz_to_pwm;
-   } else if (HAS_PCH_CNP(dev_priv)) {
+   } else if (HAS_PCH_CNP(dev_priv) || HAS_PCH_ICP(dev_priv)) {
panel->backlight.setup = cnp_setup_backlight;
panel->backlight.enable = cnp_enable_backlight;
panel->backlight.disable = cnp_disable_backlight;
-- 
2.14.3

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

[Intel-gfx] [PATCH] drm/i915: Implement display w/a #1143

[Ville Syrjala]

From: Ville Syrjälä 

Apparently SKL/KBL need some manual help to get the
programmed HDMI vswing to stick. Implement the relevant
workaround (display w/a #1143).

Note that the relevant chicken bits live in a transcoder register
even though the bits affect a specific DDI port rather than a
specific transcoder. Hence we must pick the correct transcoder
register instance based on the port rather than based on the
cpu_transcoder.

Also note that for completeness I included support for DDI A/E
in the code even though we never have HDMI on those ports.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h  |  8 ++--
 drivers/gpu/drm/i915/intel_ddi.c | 42 
 2 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 10e1269ad6af..2e6d0dc01dc7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7012,8 +7012,12 @@ enum {
 #define CHICKEN_TRANS_A 0x420c0
 #define CHICKEN_TRANS_B 0x420c4
 #define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A, 
CHICKEN_TRANS_B)
-#define PSR2_VSC_ENABLE_PROG_HEADER(1<<12)
-#define PSR2_ADD_VERTICAL_LINE_COUNT   (1<<15)
+#define  DDI_TRAINING_OVERRIDE_ENABLE  (1<<19)
+#define  DDI_TRAINING_OVERRIDE_VALUE   (1<<18)
+#define  DDIE_TRAINING_OVERRIDE_ENABLE (1<<17) /* CHICKEN_TRANS_A only */
+#define  DDIE_TRAINING_OVERRIDE_VALUE  (1<<16) /* CHICKEN_TRANS_A only */
+#define  PSR2_ADD_VERTICAL_LINE_COUNT   (1<<15)
+#define  PSR2_VSC_ENABLE_PROG_HEADER(1<<12)
 
 #define DISP_ARB_CTL   _MMIO(0x45000)
 #define  DISP_FBC_MEMORY_WAKE  (1<<31)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 6260a882fbe4..7b1ab003279f 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2433,6 +2433,48 @@ static void intel_enable_ddi_hdmi(struct intel_encoder 
*encoder,
  
crtc_state->hdmi_high_tmds_clock_ratio,
  crtc_state->hdmi_scrambling);
 
+   /* Display WA #1143: skl,kbl */
+   if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
+   /*
+* For some reason these chicken bits have been
+* stuffed into a transcoder register, event though
+* the bits affect a specific DDI port rather than
+* a specific transcoder.
+*/
+   static const enum transcoder port_to_transcoder[] = {
+   [PORT_A] = TRANSCODER_EDP,
+   [PORT_B] = TRANSCODER_A,
+   [PORT_C] = TRANSCODER_B,
+   [PORT_D] = TRANSCODER_C,
+   [PORT_E] = TRANSCODER_A,
+   };
+   enum transcoder transcoder = port_to_transcoder[port];
+   u32 val;
+
+   val = I915_READ(CHICKEN_TRANS(transcoder));
+
+   if (port == PORT_E)
+   val |= DDIE_TRAINING_OVERRIDE_ENABLE |
+   DDIE_TRAINING_OVERRIDE_VALUE;
+   else
+   val |= DDI_TRAINING_OVERRIDE_ENABLE |
+   DDI_TRAINING_OVERRIDE_VALUE;
+
+   I915_WRITE(CHICKEN_TRANS(transcoder), val);
+   POSTING_READ(CHICKEN_TRANS(transcoder));
+
+   udelay(1);
+
+   if (port == PORT_E)
+   val &= ~(DDIE_TRAINING_OVERRIDE_ENABLE |
+DDIE_TRAINING_OVERRIDE_VALUE);
+   else
+   val &= ~(DDI_TRAINING_OVERRIDE_ENABLE |
+DDI_TRAINING_OVERRIDE_VALUE);
+
+   I915_WRITE(CHICKEN_TRANS(transcoder), val);
+   }
+
/* In HDMI/DVI mode, the port width, and swing/emphasis values
 * are ignored so nothing special needs to be done besides
 * enabling the port.
-- 
2.13.6

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

Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

[Srivatsa, Anusha]

>-Original Message-
>From: Zanoni, Paulo R
>Sent: Friday, January 19, 2018 10:25 AM
>To: Vivi, Rodrigo ; Srivatsa, Anusha
>
>Cc: Ausmus, James ; Nikula, Jani
>; intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for 
>ICP
>
>Em Sex, 2018-01-19 às 09:56 -0800, Rodrigo Vivi escreveu:
>> On Fri, Jan 19, 2018 at 05:26:02PM +, Anusha Srivatsa wrote:
>> > On Fri, Jan 19, 2018 at 02:40:41PM -0200, Paulo Zanoni wrote:
>> > > Em Qui, 2018-01-11 às 15:57 -0800, Rodrigo Vivi escreveu:
>> > > > On Thu, Jan 11, 2018 at 09:48:57PM +, James Ausmus wrote:
>> > > > > On Thu, Jan 11, 2018 at 04:00:08PM -0200, Paulo Zanoni wrote:
>> > > > > > From: Anusha Srivatsa 
>> > > > > >
>> > > > > > ICP has two backlight controllers - similar to previous
>> > > > > > platforms like BXT.
>> > > > > >
>> > > > > > v2: Remove the usage of ICP_SECOND_PPS_BACKLIGHT
>> > > > > > register.(Jani)
>> > > > > > Reuse BXT code since it is very similar.(Ville)
>> > > > > >
>> > > > > > v3 (from Paulo): Rebase.
>> > > > > >
>> > > > > > Cc: Jani Nikula 
>> > > > > > Cc: Ville Syrjala 
>> > > > > > Reviewed-by: Paulo Zanoni 
>> > > > > > Signed-off-by: Anusha Srivatsa 
>> > > > > > Signed-off-by: Paulo Zanoni 
>> > > > > > ---
>> > > > > >  drivers/gpu/drm/i915/intel_panel.c | 2 +-
>> > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > > > > >
>> > > > > > diff --git a/drivers/gpu/drm/i915/intel_panel.c
>> > > > > > b/drivers/gpu/drm/i915/intel_panel.c
>> > > > > > index fa6831f8c004..ad80cca8c110 100644
>> > > > > > --- a/drivers/gpu/drm/i915/intel_panel.c
>> > > > > > +++ b/drivers/gpu/drm/i915/intel_panel.c
>> > > > > > @@ -1865,7 +1865,7 @@
>> > > > > > intel_panel_init_backlight_funcs(struct
>> > > > > > intel_panel *panel)
>> > > > > >panel->backlight.set = bxt_set_backlight;
>> > > > > >panel->backlight.get = bxt_get_backlight;
>> > > > > >panel->backlight.hz_to_pwm = bxt_hz_to_pwm;
>> > > > > > -  } else if (HAS_PCH_CNP(dev_priv)) {
>> > > > > > +  } else if (HAS_PCH_CNP(dev_priv) ||
>> > > > > > HAS_PCH_ICP(dev_priv)) {
>> > > > >
>> > > > > The commit message says reuse BXT, but the code says reuse CNP
>> > > > > - which one should it be?
>> > > >
>> > > > well,
>> > > > CNP is like BXT, but with only one controller.
>> > > > ICP is like BXT, including 2 controllers.
>> > > >
>> > > > I don't know if it makes more sense re-use the cnp or bxt
>> > > > functions
>> > > >
>> > > > But one way or another we have to address these lines from
>> > > > cnp_setup:
>> > > >
>> > > >  /*
>> > > >  * CNP has the BXT implementation of backlight, but with
>> > > > only
>> > > >  * one controller. Future platforms could have multiple
>> > > > controll\ ers
>> > > >  * so let's make this extensible and prepared for the
>> > > > future.
>> > > >  */
>> > > > panel->backlight.controller = 0;
>> > >
>> > > My understanding is that we're only using one of the controllers
>> > > on ICP on purpose, so we can perfectly reuse the CNP code.
>> > >
>> > > But I'll let Anusha comment on this.
>> >
>> > This is intentional. Commit message is trying to tell the similarity
>> > in backlight support. But we need to reuse CNP code ultimstely.
>>
>> So it is probably better to update this comment here explaining that
>> we know it has more than 1 controller but we intentionally only use
>> the '0' one.
>
>I think the cnp_setup_backlight comment is appropriate as-is because we're 
>still
>only using one controller for ICP. We should probably only update it if we 
>start
>using ICP's second controller (because we never tested controller 1 and we 
>don't
>know if the code is actually 100% prepared for the future). Do you have any
>specific suggestions on what to write here?

Will something like - "We are currently using only one of two backlight 
controllers on ICP. Hence, reuse the CNP code." Suffice?

Anusha 
>>
>> But my question now is why?
>
>Pretty much because there's no use for it for now.
>
>>
>> >
>> > Regards,
>> > Anusha
>> > > >
>> > > > >
>> > > > > >panel->backlight.setup =
>> > > > > > cnp_setup_backlight;
>> > > > > >panel->backlight.enable = cnp_enable_backlight;
>> > > > > >panel->backlight.disable = cnp_disable_backlight;
>> > > > > > --
>> > > > > > 2.14.3
>> > > > > >
>> > > > > > ___
>> > > > > > Intel-gfx mailing list
>> > > > > > Intel-gfx@lists.freedesktop.org
>> > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> > > > >
>> > > > > ___
>> > > > > Intel-gfx mailing list
>> > > > > 

Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

[Paulo Zanoni]

Em Sex, 2018-01-19 às 09:56 -0800, Rodrigo Vivi escreveu:
> On Fri, Jan 19, 2018 at 05:26:02PM +, Anusha Srivatsa wrote:
> > On Fri, Jan 19, 2018 at 02:40:41PM -0200, Paulo Zanoni wrote:
> > > Em Qui, 2018-01-11 às 15:57 -0800, Rodrigo Vivi escreveu:
> > > > On Thu, Jan 11, 2018 at 09:48:57PM +, James Ausmus wrote:
> > > > > On Thu, Jan 11, 2018 at 04:00:08PM -0200, Paulo Zanoni wrote:
> > > > > > From: Anusha Srivatsa 
> > > > > > 
> > > > > > ICP has two backlight controllers - similar to previous
> > > > > > platforms
> > > > > > like
> > > > > > BXT.
> > > > > > 
> > > > > > v2: Remove the usage of ICP_SECOND_PPS_BACKLIGHT
> > > > > > register.(Jani)
> > > > > > Reuse BXT code since it is very similar.(Ville)
> > > > > > 
> > > > > > v3 (from Paulo): Rebase.
> > > > > > 
> > > > > > Cc: Jani Nikula 
> > > > > > Cc: Ville Syrjala 
> > > > > > Reviewed-by: Paulo Zanoni 
> > > > > > Signed-off-by: Anusha Srivatsa 
> > > > > > Signed-off-by: Paulo Zanoni 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/intel_panel.c | 2 +-
> > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_panel.c
> > > > > > b/drivers/gpu/drm/i915/intel_panel.c
> > > > > > index fa6831f8c004..ad80cca8c110 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_panel.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > > > > > @@ -1865,7 +1865,7 @@
> > > > > > intel_panel_init_backlight_funcs(struct
> > > > > > intel_panel *panel)
> > > > > > panel->backlight.set = bxt_set_backlight;
> > > > > > panel->backlight.get = bxt_get_backlight;
> > > > > > panel->backlight.hz_to_pwm =
> > > > > > bxt_hz_to_pwm;
> > > > > > -   } else if (HAS_PCH_CNP(dev_priv)) {
> > > > > > +   } else if (HAS_PCH_CNP(dev_priv) ||
> > > > > > HAS_PCH_ICP(dev_priv)) {
> > > > > 
> > > > > The commit message says reuse BXT, but the code says reuse
> > > > > CNP -
> > > > > which
> > > > > one should it be?
> > > > 
> > > > well,
> > > > CNP is like BXT, but with only one controller.
> > > > ICP is like BXT, including 2 controllers.
> > > > 
> > > > I don't know if it makes more sense re-use the cnp or bxt
> > > > functions
> > > > 
> > > > But one way or another we have to address these lines from
> > > > cnp_setup:
> > > > 
> > > >  /*
> > > >  * CNP has the BXT implementation of backlight, but
> > > > with only
> > > >  * one controller. Future platforms could have multiple
> > > > controll\
> > > > ers
> > > >  * so let's make this extensible and prepared for the
> > > > future.
> > > >  */
> > > > panel->backlight.controller = 0;
> > > 
> > > My understanding is that we're only using one of the controllers
> > > on ICP
> > > on purpose, so we can perfectly reuse the CNP code.
> > > 
> > > But I'll let Anusha comment on this.
> > 
> > This is intentional. Commit message is trying to tell the
> > similarity 
> > in backlight support. But we need to reuse CNP code ultimstely.
> 
> So it is probably better to update this comment here
> explaining that we know it has more than 1 controller but
> we intentionally only use the '0' one.

I think the cnp_setup_backlight comment is appropriate as-is because
we're still only using one controller for ICP. We should probably only
update it if we start using ICP's second controller (because we never
tested controller 1 and we don't know if the code is actually 100%
prepared for the future). Do you have any specific suggestions on what
to write here?

> 
> But my question now is why?

Pretty much because there's no use for it for now.

> 
> > 
> > Regards,
> > Anusha 
> > > > 
> > > > > 
> > > > > > panel->backlight.setup =
> > > > > > cnp_setup_backlight;
> > > > > > panel->backlight.enable =
> > > > > > cnp_enable_backlight;
> > > > > > panel->backlight.disable =
> > > > > > cnp_disable_backlight;
> > > > > > --
> > > > > > 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
> > 
> > -- 
> > Anusha Srivatsa
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

[James Ausmus]

On Fri, Jan 19, 2018 at 09:26:02AM -0800, Anusha Srivatsa wrote:
> On Fri, Jan 19, 2018 at 02:40:41PM -0200, Paulo Zanoni wrote:
> > Em Qui, 2018-01-11 às 15:57 -0800, Rodrigo Vivi escreveu:
> > > On Thu, Jan 11, 2018 at 09:48:57PM +, James Ausmus wrote:
> > > > On Thu, Jan 11, 2018 at 04:00:08PM -0200, Paulo Zanoni wrote:
> > > > > From: Anusha Srivatsa 
> > > > > 
> > > > > ICP has two backlight controllers - similar to previous platforms
> > > > > like
> > > > > BXT.
> > > > > 
> > > > > v2: Remove the usage of ICP_SECOND_PPS_BACKLIGHT register.(Jani)
> > > > > Reuse BXT code since it is very similar.(Ville)
> > > > > 
> > > > > v3 (from Paulo): Rebase.
> > > > > 
> > > > > Cc: Jani Nikula 
> > > > > Cc: Ville Syrjala 
> > > > > Reviewed-by: Paulo Zanoni 
> > > > > Signed-off-by: Anusha Srivatsa 
> > > > > Signed-off-by: Paulo Zanoni 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_panel.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_panel.c
> > > > > b/drivers/gpu/drm/i915/intel_panel.c
> > > > > index fa6831f8c004..ad80cca8c110 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_panel.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > > > > @@ -1865,7 +1865,7 @@ intel_panel_init_backlight_funcs(struct
> > > > > intel_panel *panel)
> > > > >   panel->backlight.set = bxt_set_backlight;
> > > > >   panel->backlight.get = bxt_get_backlight;
> > > > >   panel->backlight.hz_to_pwm = bxt_hz_to_pwm;
> > > > > - } else if (HAS_PCH_CNP(dev_priv)) {
> > > > > + } else if (HAS_PCH_CNP(dev_priv) ||
> > > > > HAS_PCH_ICP(dev_priv)) {
> > > > 
> > > > The commit message says reuse BXT, but the code says reuse CNP -
> > > > which
> > > > one should it be?
> > > 
> > > well,
> > > CNP is like BXT, but with only one controller.
> > > ICP is like BXT, including 2 controllers.
> > > 
> > > I don't know if it makes more sense re-use the cnp or bxt functions
> > > 
> > > But one way or another we have to address these lines from cnp_setup:
> > > 
> > >  /*
> > >  * CNP has the BXT implementation of backlight, but with only
> > >  * one controller. Future platforms could have multiple
> > > controll\
> > > ers
> > >  * so let's make this extensible and prepared for the future.
> > >  */
> > > panel->backlight.controller = 0;
> > 
> > My understanding is that we're only using one of the controllers on ICP
> > on purpose, so we can perfectly reuse the CNP code.
> > 
> > But I'll let Anusha comment on this.
> 
> This is intentional. Commit message is trying to tell the similarity 
> in backlight support. But we need to reuse CNP code ultimstely.

OK - in that case, the commit message needs to get less confusing, as it
explicitly states that ICP is similar to BXT, and it explicitly states
that v2 changed the commit to reuse BXT code, but the actual code is
clearly using CNP code, and doesn't mention CNP (or the justification
for using CNP) anywhere. :)

Maybe explain that we're using CNP code intentionally, even though it
supports two BL controllers, and explain *why* we're ignoring the second
BL controller? I'm still not sure why that is myself :)

Thanks!

-James

> 
> Regards,
> Anusha 
> > > 
> > > > 
> > > > >   panel->backlight.setup = cnp_setup_backlight;
> > > > >   panel->backlight.enable = cnp_enable_backlight;
> > > > >   panel->backlight.disable =
> > > > > cnp_disable_backlight;
> > > > > --
> > > > > 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
> 
> -- 
> Anusha Srivatsa
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/27] drm/i915/icl: Interrupt handling

[Paulo Zanoni]

Em Sex, 2018-01-19 às 17:30 +, Tvrtko Ursulin escreveu:
> On 10/01/2018 10:16, Joonas Lahtinen wrote:
> > On Tue, 2018-01-09 at 21:23 -0200, Paulo Zanoni wrote:
> > > From: Tvrtko Ursulin 
> > > 
> > > v2: Rebase.
> > > 
> > > v3:
> > >* Remove DPF, it has been removed from SKL+.
> > >* Fix -internal rebase wrt. execlists interrupt handling.
> > > 
> > > v4: Rebase.
> > > 
> > > v5:
> > >* Updated for POR changes. (Daniele Ceraolo Spurio)
> > >* Merged with irq handling fixes by Daniele Ceraolo Spurio:
> > >* Simplify the code by using gen8_cs_irq_handler.
> > >* Fix interrupt handling for the upstream kernel.
> > > 
> > > v6:
> > >* Remove early bringup debug messages (Tvrtko)
> > >* Add NB about arbitrary spin wait timeout (Tvrtko)
> > > 
> > > v7 (from Paulo):
> > >* Don't try to write RO bits to registers.
> > >* Don't check for PCH types that don't exist. PCH interrupts
> > > are not
> > >  here yet.
> > > 
> > > Signed-off-by: Tvrtko Ursulin 
> > > Signed-off-by: Rodrigo Vivi 
> > > Signed-off-by: Daniele Ceraolo Spurio  > > l.com>
> > > Signed-off-by: Oscar Mateo 
> > > Signed-off-by: Paulo Zanoni 
> > 
> > 
> > 
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -415,6 +415,9 @@ void gen6_enable_rps_interrupts(struct
> > > drm_i915_private *dev_priv)
> > >   if (READ_ONCE(rps->interrupts_enabled))
> > >   return;
> > >   
> > > + if (WARN_ON_ONCE(IS_GEN11(dev_priv)))
> > > + return;
> > > +
> > >   spin_lock_irq(_priv->irq_lock);
> > >   WARN_ON_ONCE(rps->pm_iir);
> > >   WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &
> > > dev_priv->pm_rps_events);
> > > @@ -431,6 +434,9 @@ void gen6_disable_rps_interrupts(struct
> > > drm_i915_private *dev_priv)
> > >   if (!READ_ONCE(rps->interrupts_enabled))
> > >   return;
> > >   
> > > + if (WARN_ON_ONCE(IS_GEN11(dev_priv)))
> > > + return;
> > > +
> > 
> > These should be GEM_BUG_ON at most and should be the first thing in
> > function.
> 
> That would be a bit unfriendly when you are bringing up the codebase
> and 
> not all pices have been implemented yet. It gets removed later in
> the 
> series, or in a following series, whatever.
> 
> > >   spin_lock_irq(_priv->irq_lock);
> > >   rps->interrupts_enabled = false;
> > >   
> > > @@ -2751,6 +2757,131 @@ static void __fini_wedge(struct wedge_me
> > > *w)
> > >(W)->i915; 
> > >   \
> > >__fini_wedge((W)))
> > >   
> > > +static __always_inline void
> > > +gen11_cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
> > > +{
> > > + gen8_cs_irq_handler(engine, iir, 0);
> > > +}
> > > +
> > > +static irqreturn_t
> > > +gen11_gt_irq_handler(struct drm_i915_private *dev_priv, u32
> > > master_ctl)
> > 
> > This function could use some readability :)
> 
> Name or body?
> 
> > > +{
> > > + irqreturn_t ret = IRQ_NONE;
> > > + u16 irq[2][32];
> > > + u32 dw, ident;
> > > + unsigned long tmp;
> > > + unsigned int bank, bit, engine;
> > > + unsigned long wait_start, wait_end;
> > > +
> > > + memset(irq, 0, sizeof(irq));
> > > +
> > > + for (bank = 0; bank < 2; bank++) {
> > > + if (master_ctl & GEN11_GT_DW_IRQ(bank)) {
> > 
> > Invert condition and use continue;
> > 
> > > + dw =
> > > I915_READ_FW(GEN11_GT_INTR_DW(bank));
> > > + if (!dw)
> > > + DRM_ERROR("GT_INTR_DW%u
> > > blank!\n", bank);
> > 
> > Probably needs a more appropriate action, GEM_BUG_ON if we've never
> > seen this on HW.
> 
> To early to know. TBD.
> 
> > > + tmp = dw;
> > > + for_each_set_bit(bit, , 32) {
> > > + I915_WRITE_FW(GEN11_IIR_REG_SELE
> > > CTOR(bank), 1 << bit);
> > 
> > BIT(bit)
> > 
> > + newline here
> 
> Yes sir!
> 
> > 
> > > + wait_start = local_clock() >>
> > > 10;
> > > + /* NB: Specs do not specify how
> > > long to spin wait.
> > > +  * Taking 100us as an educated
> > > guess */
> > > + wait_end = wait_start + 100;
> > > + do {
> > > + ident =
> > > I915_READ_FW(GEN11_INTR_IDENTITY_REG(bank));
> > > + } while (!(ident &
> > > GEN11_INTR_DATA_VALID) &&
> > > +  !time_after((unsigned
> > > long)local_clock() >> 10, wait_end));
> > 
> > Uh oh, not a really nice thing to do in IRQ handler :( We should
> > probably look at some actual delay numbers and not do this.
> 
> Too early to know. TBD. Spec wants us to busy poll and doesn't
> specify 
> the timeout. Chris also complained and we chatted about this on IRC, 
> guess you 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Avoid leaking lpe audio platdev.data

[Patchwork]

== Series Details ==

Series: drm/i915: Avoid leaking lpe audio platdev.data
URL   : https://patchwork.freedesktop.org/series/35151/
State : failure

== Summary ==

Test perf:
Subgroup buffer-fill:
pass   -> FAIL   (shard-apl) fdo#103755
Subgroup enable-disable:
pass   -> FAIL   (shard-apl) fdo#103715
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#101623 +1
Test gem_tiled_swapping:
Subgroup non-threaded:
incomplete -> PASS   (shard-snb) fdo#104218 +1
Test kms_cursor_crc:
Subgroup cursor-128x128-sliding:
pass   -> INCOMPLETE (shard-hsw)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> SKIP   (shard-hsw) fdo#103375 +2
Subgroup read-crc-pipe-c-frame-sequence:
fail   -> PASS   (shard-apl) fdo#103481
Test kms_flip:
Subgroup vblank-vs-suspend-interruptible:
pass   -> INCOMPLETE (shard-hsw) fdo#100368
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047

fdo#103755 https://bugs.freedesktop.org/show_bug.cgi?id=103755
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:2780 pass:1713 dwarn:1   dfail:0   fail:25  skip:1041 
time:14555s
shard-hswtotal:2716 pass:1666 dwarn:1   dfail:1   fail:13  skip:1031 
time:13230s
shard-snbtotal:2780 pass:1316 dwarn:1   dfail:0   fail:13  skip:1450 
time:8035s
Blacklisted hosts:
shard-kbltotal:2758 pass:1824 dwarn:1   dfail:1   fail:23  skip:908 
time:10493s

== Logs ==

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

Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

[Rodrigo Vivi]

On Fri, Jan 19, 2018 at 05:26:02PM +, Anusha Srivatsa wrote:
> On Fri, Jan 19, 2018 at 02:40:41PM -0200, Paulo Zanoni wrote:
> > Em Qui, 2018-01-11 às 15:57 -0800, Rodrigo Vivi escreveu:
> > > On Thu, Jan 11, 2018 at 09:48:57PM +, James Ausmus wrote:
> > > > On Thu, Jan 11, 2018 at 04:00:08PM -0200, Paulo Zanoni wrote:
> > > > > From: Anusha Srivatsa 
> > > > > 
> > > > > ICP has two backlight controllers - similar to previous platforms
> > > > > like
> > > > > BXT.
> > > > > 
> > > > > v2: Remove the usage of ICP_SECOND_PPS_BACKLIGHT register.(Jani)
> > > > > Reuse BXT code since it is very similar.(Ville)
> > > > > 
> > > > > v3 (from Paulo): Rebase.
> > > > > 
> > > > > Cc: Jani Nikula 
> > > > > Cc: Ville Syrjala 
> > > > > Reviewed-by: Paulo Zanoni 
> > > > > Signed-off-by: Anusha Srivatsa 
> > > > > Signed-off-by: Paulo Zanoni 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_panel.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_panel.c
> > > > > b/drivers/gpu/drm/i915/intel_panel.c
> > > > > index fa6831f8c004..ad80cca8c110 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_panel.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > > > > @@ -1865,7 +1865,7 @@ intel_panel_init_backlight_funcs(struct
> > > > > intel_panel *panel)
> > > > >   panel->backlight.set = bxt_set_backlight;
> > > > >   panel->backlight.get = bxt_get_backlight;
> > > > >   panel->backlight.hz_to_pwm = bxt_hz_to_pwm;
> > > > > - } else if (HAS_PCH_CNP(dev_priv)) {
> > > > > + } else if (HAS_PCH_CNP(dev_priv) ||
> > > > > HAS_PCH_ICP(dev_priv)) {
> > > > 
> > > > The commit message says reuse BXT, but the code says reuse CNP -
> > > > which
> > > > one should it be?
> > > 
> > > well,
> > > CNP is like BXT, but with only one controller.
> > > ICP is like BXT, including 2 controllers.
> > > 
> > > I don't know if it makes more sense re-use the cnp or bxt functions
> > > 
> > > But one way or another we have to address these lines from cnp_setup:
> > > 
> > >  /*
> > >  * CNP has the BXT implementation of backlight, but with only
> > >  * one controller. Future platforms could have multiple
> > > controll\
> > > ers
> > >  * so let's make this extensible and prepared for the future.
> > >  */
> > > panel->backlight.controller = 0;
> > 
> > My understanding is that we're only using one of the controllers on ICP
> > on purpose, so we can perfectly reuse the CNP code.
> > 
> > But I'll let Anusha comment on this.
> 
> This is intentional. Commit message is trying to tell the similarity 
> in backlight support. But we need to reuse CNP code ultimstely.

So it is probably better to update this comment here
explaining that we know it has more than 1 controller but
we intentionally only use the '0' one.

But my question now is why?

> 
> Regards,
> Anusha 
> > > 
> > > > 
> > > > >   panel->backlight.setup = cnp_setup_backlight;
> > > > >   panel->backlight.enable = cnp_enable_backlight;
> > > > >   panel->backlight.disable =
> > > > > cnp_disable_backlight;
> > > > > --
> > > > > 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
> 
> -- 
> Anusha Srivatsa
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/27] drm/i915/icl: Interrupt handling

[Tvrtko Ursulin]

On 10/01/2018 10:16, Joonas Lahtinen wrote:

On Tue, 2018-01-09 at 21:23 -0200, Paulo Zanoni wrote:

From: Tvrtko Ursulin 

v2: Rebase.

v3:
   * Remove DPF, it has been removed from SKL+.
   * Fix -internal rebase wrt. execlists interrupt handling.

v4: Rebase.

v5:
   * Updated for POR changes. (Daniele Ceraolo Spurio)
   * Merged with irq handling fixes by Daniele Ceraolo Spurio:
   * Simplify the code by using gen8_cs_irq_handler.
   * Fix interrupt handling for the upstream kernel.

v6:
   * Remove early bringup debug messages (Tvrtko)
   * Add NB about arbitrary spin wait timeout (Tvrtko)

v7 (from Paulo):
   * Don't try to write RO bits to registers.
   * Don't check for PCH types that don't exist. PCH interrupts are not
 here yet.

Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Oscar Mateo 
Signed-off-by: Paulo Zanoni 





+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -415,6 +415,9 @@ void gen6_enable_rps_interrupts(struct drm_i915_private 
*dev_priv)
if (READ_ONCE(rps->interrupts_enabled))
return;
  
+	if (WARN_ON_ONCE(IS_GEN11(dev_priv)))

+   return;
+
spin_lock_irq(_priv->irq_lock);
WARN_ON_ONCE(rps->pm_iir);
WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) & 
dev_priv->pm_rps_events);
@@ -431,6 +434,9 @@ void gen6_disable_rps_interrupts(struct drm_i915_private 
*dev_priv)
if (!READ_ONCE(rps->interrupts_enabled))
return;
  
+	if (WARN_ON_ONCE(IS_GEN11(dev_priv)))

+   return;
+


These should be GEM_BUG_ON at most and should be the first thing in
function.


That would be a bit unfriendly when you are bringing up the codebase and 
not all pices have been implemented yet. It gets removed later in the 
series, or in a following series, whatever.



spin_lock_irq(_priv->irq_lock);
rps->interrupts_enabled = false;
  
@@ -2751,6 +2757,131 @@ static void __fini_wedge(struct wedge_me *w)

 (W)->i915;  \
 __fini_wedge((W)))
  
+static __always_inline void

+gen11_cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
+{
+   gen8_cs_irq_handler(engine, iir, 0);
+}
+
+static irqreturn_t
+gen11_gt_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)


This function could use some readability :)


Name or body?


+{
+   irqreturn_t ret = IRQ_NONE;
+   u16 irq[2][32];
+   u32 dw, ident;
+   unsigned long tmp;
+   unsigned int bank, bit, engine;
+   unsigned long wait_start, wait_end;
+
+   memset(irq, 0, sizeof(irq));
+
+   for (bank = 0; bank < 2; bank++) {
+   if (master_ctl & GEN11_GT_DW_IRQ(bank)) {


Invert condition and use continue;


+   dw = I915_READ_FW(GEN11_GT_INTR_DW(bank));
+   if (!dw)
+   DRM_ERROR("GT_INTR_DW%u blank!\n", bank);


Probably needs a more appropriate action, GEM_BUG_ON if we've never
seen this on HW.


To early to know. TBD.


+   tmp = dw;
+   for_each_set_bit(bit, , 32) {
+   I915_WRITE_FW(GEN11_IIR_REG_SELECTOR(bank), 1 
<< bit);


BIT(bit)

+ newline here


Yes sir!




+   wait_start = local_clock() >> 10;
+   /* NB: Specs do not specify how long to spin 
wait.
+* Taking 100us as an educated guess */
+   wait_end = wait_start + 100;
+   do {
+   ident = 
I915_READ_FW(GEN11_INTR_IDENTITY_REG(bank));
+   } while (!(ident & GEN11_INTR_DATA_VALID) &&
+!time_after((unsigned long)local_clock() 
>> 10, wait_end));


Uh oh, not a really nice thing to do in IRQ handler :( We should
probably look at some actual delay numbers and not do this.


Too early to know. TBD. Spec wants us to busy poll and doesn't specify 
the timeout. Chris also complained and we chatted about this on IRC, 
guess you missed this particular stream of conversation.



+
+   if (!(ident & GEN11_INTR_DATA_VALID))
+   DRM_ERROR("INTR_IDENTITY_REG%u:%u timed 
out!\n",
+ bank, bit);
+
+   irq[bank][bit] = ident & GEN11_INTR_ENGINE_MASK;
+   if (!irq[bank][bit])
+   DRM_ERROR("INTR_IDENTITY_REG%u:%u 
blank!\n",
+ bank, bit);


DRM_ERROR again seems like bit of an understatement for interrupt.


Precedent in "master 

Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

[Anusha Srivatsa]

On Fri, Jan 19, 2018 at 02:40:41PM -0200, Paulo Zanoni wrote:
> Em Qui, 2018-01-11 às 15:57 -0800, Rodrigo Vivi escreveu:
> > On Thu, Jan 11, 2018 at 09:48:57PM +, James Ausmus wrote:
> > > On Thu, Jan 11, 2018 at 04:00:08PM -0200, Paulo Zanoni wrote:
> > > > From: Anusha Srivatsa 
> > > > 
> > > > ICP has two backlight controllers - similar to previous platforms
> > > > like
> > > > BXT.
> > > > 
> > > > v2: Remove the usage of ICP_SECOND_PPS_BACKLIGHT register.(Jani)
> > > > Reuse BXT code since it is very similar.(Ville)
> > > > 
> > > > v3 (from Paulo): Rebase.
> > > > 
> > > > Cc: Jani Nikula 
> > > > Cc: Ville Syrjala 
> > > > Reviewed-by: Paulo Zanoni 
> > > > Signed-off-by: Anusha Srivatsa 
> > > > Signed-off-by: Paulo Zanoni 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_panel.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_panel.c
> > > > b/drivers/gpu/drm/i915/intel_panel.c
> > > > index fa6831f8c004..ad80cca8c110 100644
> > > > --- a/drivers/gpu/drm/i915/intel_panel.c
> > > > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > > > @@ -1865,7 +1865,7 @@ intel_panel_init_backlight_funcs(struct
> > > > intel_panel *panel)
> > > > panel->backlight.set = bxt_set_backlight;
> > > > panel->backlight.get = bxt_get_backlight;
> > > > panel->backlight.hz_to_pwm = bxt_hz_to_pwm;
> > > > -   } else if (HAS_PCH_CNP(dev_priv)) {
> > > > +   } else if (HAS_PCH_CNP(dev_priv) ||
> > > > HAS_PCH_ICP(dev_priv)) {
> > > 
> > > The commit message says reuse BXT, but the code says reuse CNP -
> > > which
> > > one should it be?
> > 
> > well,
> > CNP is like BXT, but with only one controller.
> > ICP is like BXT, including 2 controllers.
> > 
> > I don't know if it makes more sense re-use the cnp or bxt functions
> > 
> > But one way or another we have to address these lines from cnp_setup:
> > 
> >  /*
> >  * CNP has the BXT implementation of backlight, but with only
> >  * one controller. Future platforms could have multiple
> > controll\
> > ers
> >  * so let's make this extensible and prepared for the future.
> >  */
> > panel->backlight.controller = 0;
> 
> My understanding is that we're only using one of the controllers on ICP
> on purpose, so we can perfectly reuse the CNP code.
> 
> But I'll let Anusha comment on this.

This is intentional. Commit message is trying to tell the similarity 
in backlight support. But we need to reuse CNP code ultimstely.

Regards,
Anusha 
> > 
> > > 
> > > > panel->backlight.setup = cnp_setup_backlight;
> > > > panel->backlight.enable = cnp_enable_backlight;
> > > > panel->backlight.disable =
> > > > cnp_disable_backlight;
> > > > --
> > > > 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

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Downgrade incorrect engine constructor usage warnings to development

[Michel Thierry]

On 1/19/2018 2:00 AM, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Render engine constructor helpers must only be called from the render
engine constructors, but there is no need to burden the production
binaries with warnings which can only be triggered during development.

Signed-off-by: Tvrtko Ursulin 
Cc: Michel Thierry 
---
  drivers/gpu/drm/i915/intel_engine_cs.c | 3 ++-
  drivers/gpu/drm/i915/intel_lrc.c   | 2 +-
  2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index d572b18d39eb..da05d38ba000 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1389,7 +1389,8 @@ int init_workarounds_ring(struct intel_engine_cs *engine)
struct drm_i915_private *dev_priv = engine->i915;
int err;
  
-	WARN_ON(engine->id != RCS);

+   if (GEM_WARN_ON(engine->id != RCS))
+   return -EINVAL;
  
  	dev_priv->workarounds.count = 0;

dev_priv->workarounds.hw_whitelist_count[engine->id] = 0;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 24ce781d39b7..334d44d415ab 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1416,7 +1416,7 @@ static int intel_init_workaround_bb(struct 
intel_engine_cs *engine)
unsigned int i;
int ret;
  
-	if (WARN_ON(engine->id != RCS || !engine->scratch))

+   if (GEM_WARN_ON(engine->id != RCS || !engine->scratch))
return -EINVAL;
  
  	switch (INTEL_GEN(engine->i915)) {




As Chris said in patch 2/3, do you want to remove the !scratch check 
here too? Otherwise both patches are also


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

Re: [Intel-gfx] [RFC] perf: Allow fine-grained PMU access control

[Tvrtko Ursulin]

Hi,

On 19/01/2018 16:45, Peter Zijlstra wrote:

On Thu, Jan 18, 2018 at 06:40:07PM +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

For situations where sysadmins might want to allow different level of
of access control for different PMUs, we start creating per-PMU
perf_event_paranoid controls in sysfs.


You've completely and utterly failed to explain why.


On an abstract level, if there is a desire to decrease the security knob 
on one particular PMU provider, it is better to be able to do it just 
for the one, rather for the whole system.


On a more concrete level, we have customers who want to look at certain 
i915 metrics, most probably engine utilization or queue depth, in order 
to make load-balancing decisions. (The two would be roughly analogous to 
CPU usage and load.)


This data needs to be available to their userspaces dynamically and 
would be used to pick a best GPU engine (mostly analogous to a CPU core) 
to run a particular packet of work.


It would be impossible to run their product as root, and while one 
option could be to write a proxy daemon which would allow unprivileged 
queries, it is also a significant complication which introduces a time 
shift problem on the PMU data as well.


So my thinking was that a per-PMU paranoid control should not be a 
problematic concept in general. And my gut feeling anyway was that not 
all PMU providers are the same class data, security wise, which was 
another reason I thought per-PMU controls would be fine.


There is one more way of thinking about it, and that is that the access 
control could even be extended to be per-event, and not just per-PMU. 
That would allow registered PMUs to let the core know which counters are 
potentially security sensitive, and which are not.


I've sent another RFC along those lines some time ago, but afterwards 
I've changed my mind and thought the approach from this patch should be 
less controversial since it retains all control fully in the perf core 
and in the hands of sysadmins.


Regards,

Tvrtko


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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Per-context and per-client engine busyness (rev3)

[Patchwork]

== Series Details ==

Series: Per-context and per-client engine busyness (rev3)
URL   : https://patchwork.freedesktop.org/series/32645/
State : failure

== Summary ==

Series 32645v3 Per-context and per-client engine busyness
https://patchwork.freedesktop.org/api/1.0/series/32645/revisions/3/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test gem_exec_flush:
Subgroup basic-wb-prw-default:
pass   -> INCOMPLETE (fi-snb-2600)
Test gem_ringfill:
Subgroup basic-default-hang:
dmesg-warn -> PASS   (fi-pnv-d510) fdo#101600

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:435s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:428s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
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:275s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:526s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:526s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:532s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:473s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:278s
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:422s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:430s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:492s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:445s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:468s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:511s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:463s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:538s
fi-pnv-d510  total:288  pass:223  dwarn:0   dfail:0   fail:0   skip:65  
time:529s
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:524s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:575s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:509s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:500s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:59   pass:48   dwarn:0   dfail:0   fail:0   skip:10 
Blacklisted hosts:
fi-cfl-s2total:288  pass:256  dwarn:0   dfail:0   fail:3   skip:26  
time:610s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:506s
fi-skl-guc   total:288  pass:211  dwarn:48  dfail:0   fail:1   skip:28  
time:453s

fd10fae2b0f673861816511f99d4798d6b619b40 drm-tip: 2018y-01m-19d-14h-22m-15s UTC 
integration manifest
1d9909fd0965 drm/i915: Add sysfs toggle to enable per-client engine stats
45aee892c9ad drm/i915: Expose per-engine client busyness
813f0228546b drm/i915: Update client name on context create
9e245f148ad3 drm/i915: Expose list of clients in sysfs
1a6e191c83f8 drm/i915: Allow clients to query own per-engine busyness
01e95b47013e drm/i915: Track per-context engine busyness

== Logs ==

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

Re: [Intel-gfx] [RFC] perf: Allow fine-grained PMU access control

[Peter Zijlstra]

On Thu, Jan 18, 2018 at 06:40:07PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> For situations where sysadmins might want to allow different level of
> of access control for different PMUs, we start creating per-PMU
> perf_event_paranoid controls in sysfs.

You've completely and utterly failed to explain why.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

[Paulo Zanoni]

Em Qui, 2018-01-11 às 15:57 -0800, Rodrigo Vivi escreveu:
> On Thu, Jan 11, 2018 at 09:48:57PM +, James Ausmus wrote:
> > On Thu, Jan 11, 2018 at 04:00:08PM -0200, Paulo Zanoni wrote:
> > > From: Anusha Srivatsa 
> > > 
> > > ICP has two backlight controllers - similar to previous platforms
> > > like
> > > BXT.
> > > 
> > > v2: Remove the usage of ICP_SECOND_PPS_BACKLIGHT register.(Jani)
> > > Reuse BXT code since it is very similar.(Ville)
> > > 
> > > v3 (from Paulo): Rebase.
> > > 
> > > Cc: Jani Nikula 
> > > Cc: Ville Syrjala 
> > > Reviewed-by: Paulo Zanoni 
> > > Signed-off-by: Anusha Srivatsa 
> > > Signed-off-by: Paulo Zanoni 
> > > ---
> > >  drivers/gpu/drm/i915/intel_panel.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_panel.c
> > > b/drivers/gpu/drm/i915/intel_panel.c
> > > index fa6831f8c004..ad80cca8c110 100644
> > > --- a/drivers/gpu/drm/i915/intel_panel.c
> > > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > > @@ -1865,7 +1865,7 @@ intel_panel_init_backlight_funcs(struct
> > > intel_panel *panel)
> > >   panel->backlight.set = bxt_set_backlight;
> > >   panel->backlight.get = bxt_get_backlight;
> > >   panel->backlight.hz_to_pwm = bxt_hz_to_pwm;
> > > - } else if (HAS_PCH_CNP(dev_priv)) {
> > > + } else if (HAS_PCH_CNP(dev_priv) ||
> > > HAS_PCH_ICP(dev_priv)) {
> > 
> > The commit message says reuse BXT, but the code says reuse CNP -
> > which
> > one should it be?
> 
> well,
> CNP is like BXT, but with only one controller.
> ICP is like BXT, including 2 controllers.
> 
> I don't know if it makes more sense re-use the cnp or bxt functions
> 
> But one way or another we have to address these lines from cnp_setup:
> 
>  /*
>  * CNP has the BXT implementation of backlight, but with only
>  * one controller. Future platforms could have multiple
> controll\
> ers
>  * so let's make this extensible and prepared for the future.
>  */
> panel->backlight.controller = 0;

My understanding is that we're only using one of the controllers on ICP
on purpose, so we can perfectly reuse the CNP code.

But I'll let Anusha comment on this.

> 
> > 
> > >   panel->backlight.setup = cnp_setup_backlight;
> > >   panel->backlight.enable = cnp_enable_backlight;
> > >   panel->backlight.disable =
> > > cnp_disable_backlight;
> > > --
> > > 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v5 1/6] drm/i915: Track per-context engine busyness

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Some customers want to know how much of the GPU time are their clients
using in order to make dynamic load balancing decisions.

With the hooks already in place which track the overall engine busyness,
we can extend that slightly to split that time between contexts.

v2: Fix accounting for tail updates.
v3: Rebase.
v4: Mark currently running contexts as active on stats enable.
v5: Include some headers to fix the build.

Signed-off-by: Tvrtko Ursulin 
Cc: gordon.ke...@intel.com
---
 drivers/gpu/drm/i915/i915_gem_context.h |  8 ++
 drivers/gpu/drm/i915/intel_engine_cs.c  | 32 +
 drivers/gpu/drm/i915/intel_lrc.c| 14 +
 drivers/gpu/drm/i915/intel_ringbuffer.h | 50 +
 4 files changed, 93 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.h 
b/drivers/gpu/drm/i915/i915_gem_context.h
index 4bfb72f8e1cb..7f5eebb67167 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -29,6 +29,9 @@
 #include 
 #include 
 
+#include "i915_gem.h"
+#include "i915_gem_request.h"
+
 struct pid;
 
 struct drm_device;
@@ -157,6 +160,11 @@ struct i915_gem_context {
u32 *lrc_reg_state;
u64 lrc_desc;
int pin_count;
+   struct {
+   bool active;
+   ktime_t start;
+   ktime_t total;
+   } stats;
} engine[I915_NUM_ENGINES];
 
/** ring_size: size for allocating the per-engine ring buffer */
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index d572b18d39eb..9907ceedfa90 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1966,6 +1966,16 @@ int intel_enable_engine_stats(struct intel_engine_cs 
*engine)
 
engine->stats.enabled_at = ktime_get();
 
+   /* Mark currently running context as active. */
+   if (port_isset(port)) {
+   struct drm_i915_gem_request *req = port_request(port);
+   struct intel_context *ce =
+   >ctx->engine[engine->id];
+
+   ce->stats.start = engine->stats.enabled_at;
+   ce->stats.active = true;
+   }
+
/* XXX submission method oblivious? */
while (num_ports-- && port_isset(port)) {
engine->stats.active++;
@@ -2038,6 +2048,28 @@ void intel_disable_engine_stats(struct intel_engine_cs 
*engine)
spin_unlock_irqrestore(>stats.lock, flags);
 }
 
+ktime_t intel_context_engine_get_busy_time(struct i915_gem_context *ctx,
+  struct intel_engine_cs *engine)
+{
+   struct intel_context *ce;
+   unsigned long flags;
+   ktime_t total;
+
+   ce = >engine[engine->id];
+
+   spin_lock_irqsave(>stats.lock, flags);
+
+   total = ce->stats.total;
+
+   if (ce->stats.active)
+   total = ktime_add(total,
+ ktime_sub(ktime_get(), ce->stats.start));
+
+   spin_unlock_irqrestore(>stats.lock, flags);
+
+   return total;
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftests/mock_engine.c"
 #endif
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 24ce781d39b7..a82ad5da6090 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -380,16 +380,19 @@ execlists_context_status_change(struct 
drm_i915_gem_request *rq,
 }
 
 static inline void
-execlists_context_schedule_in(struct drm_i915_gem_request *rq)
+execlists_context_schedule_in(struct drm_i915_gem_request *rq,
+ unsigned int port)
 {
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
-   intel_engine_context_in(rq->engine);
+   intel_engine_context_in(rq->engine,
+   >ctx->engine[rq->engine->id],
+   port == 0);
 }
 
 static inline void
 execlists_context_schedule_out(struct drm_i915_gem_request *rq)
 {
-   intel_engine_context_out(rq->engine);
+   intel_engine_context_out(rq->engine, >ctx->engine[rq->engine->id]);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
 }
 
@@ -442,7 +445,7 @@ static void execlists_submit_ports(struct intel_engine_cs 
*engine)
if (rq) {
GEM_BUG_ON(count > !n);
if (!count++)
-   execlists_context_schedule_in(rq);
+   execlists_context_schedule_in(rq, n);
port_set([n], port_pack(rq, count));
desc = execlists_update_context(rq);

Re: [Intel-gfx] [PATCH v5] drm/i915/icl: Enhanced execution list support

[Daniele Ceraolo Spurio]

On 19/01/18 05:05, Mika Kuoppala wrote:

Daniele Ceraolo Spurio  writes:


From: Thomas Daniel 

Enhanced Execlists is an upgraded version of execlists which supports
up to 8 ports. The lrcs to be submitted are written to a submit queue,
which is then loaded on the HW. When writing to the ELSP register, the
lrcs are written cyclically in the queue from position 0 to position 7.
Alternatively, it is possible to write directly in the individual
positions of the queue using the ELSQ registers. To be able to re-use
all the existing code we're using the latter method and we're currently
limiting ourself to only using 2 elements.

The preemption flow is sligthly different with enhanced execlists, so
this patch turns preemption off temporarily for Gen11+ while we wait for
the new mechanism to land.

v2: Rebase.
v3: Switch from !IS_GEN11 to GEN < 11 (Daniele Ceraolo Spurio).
v4: Use the elsq registers instead of elsp. (Daniele Ceraolo Spurio)
v5: Reword commit, rename regs to be closer to specs, turn off
 preemption (Daniele), reuse engine->execlists.elsp (Chris)

Cc: Chris Wilson 
Signed-off-by: Thomas Daniel 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Daniele Ceraolo Spurio 


Was going to adopt this patch from Rodrigo but you were faster.

I choose to stash the elsq and use it as a gen11 vs rest toggle:

Relevant bits:

+static inline void write_port(struct intel_engine_execlists * const execlists,
+ unsigned int n,
+ u64 desc)
+{
+   if (execlists->elsq)
+   gen11_elsq_write(desc, n, execlists->elsq);
+   else
+   gen8_elsp_write(desc, execlists->elsp);
+}
+
+static inline void submit_ports(struct intel_engine_execlists * const 
execlists)
+{
+   /* for gen11+ we need to manually load the submit queue */
+   if (execlists->elsq) {
+   struct intel_engine_cs *engine =
+   container_of(execlists,
+struct intel_engine_cs,
+execlists);
+   struct drm_i915_private *dev_priv = engine->i915;
+
+   I915_WRITE_FW(RING_ELCR(engine), ELCR_LOAD);
+   }
+}
+



I was undecided about hiding the code in sub-functions because of the 
pre-emption path. There is no need in gen11 to inject a context to 
preempt to idle, so the inject_preempt function will be pre-gen11 only 
and therefore I'd prefer to keep a direct call to elsp_write there. IMHO 
it'd be cleaner to have similar code in both places, hence the 
open-coding. This said, I'd be happy to change it like you proposed if 
there is a general preference to abstract things a bit in the shared 
path even if the pre-emption path stays different.


Regarding using execlists->elsq as a toggle, I was thinking that we 
could have a device info flag instead, so we could use it even before 
setting execlists->elsq. Any preference on this?


Thanks,
Daniele

P.S. If you want to take over feel free to send an updated patch ;)


...
-Mika


---
  drivers/gpu/drm/i915/i915_drv.h |  5 -
  drivers/gpu/drm/i915/intel_lrc.c| 35 -
  drivers/gpu/drm/i915/intel_lrc.h|  3 +++
  drivers/gpu/drm/i915/intel_ringbuffer.h |  6 --
  4 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c42015b..3163543 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2738,8 +2738,11 @@ static inline unsigned int i915_sg_segment_size(void)
  
  #define HAS_LOGICAL_RING_CONTEXTS(dev_priv) \

((dev_priv)->info.has_logical_ring_contexts)
+
+/* XXX: Preemption disabled for Gen11+ until support for new flow lands */
  #define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
-   ((dev_priv)->info.has_logical_ring_preemption)
+   ((dev_priv)->info.has_logical_ring_preemption && \
+INTEL_GEN(dev_priv) < 11)
  
  #define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
  
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c

index ff25f20..67ad7c9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -428,11 +428,24 @@ static inline void elsp_write(u64 desc, u32 __iomem *elsp)
writel(lower_32_bits(desc), elsp);
  }
  
+static inline void elsqc_write(u64 desc, u32 __iomem *elsqc, u32 port)

+{
+   writel(lower_32_bits(desc), elsqc + port * 2);
+   writel(upper_32_bits(desc), elsqc + port * 2 + 1);
+}
+
  static void execlists_submit_ports(struct intel_engine_cs *engine)
  {
+   struct drm_i915_private *dev_priv = engine->i915;
struct execlist_port *port = engine->execlists.port;
unsigned int n;
  

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Track the number of times we have woken the GPU up

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Track the number of times we have 
woken the GPU up
URL   : https://patchwork.freedesktop.org/series/36802/
State : success

== Summary ==

Series 36802v1 series starting with [1/2] drm/i915: Track the number of times 
we have woken the GPU up
https://patchwork.freedesktop.org/api/1.0/series/36802/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test kms_chamelium:
Subgroup dp-crc-fast:
pass   -> DMESG-FAIL (fi-kbl-7500u) fdo#103841

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
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:429s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:432s
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:518s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:293s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:501s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:507s
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:482s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:306s
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:400s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:409s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:421s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:469s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:423s
fi-kbl-7500u total:288  pass:262  dwarn:1   dfail:1   fail:0   skip:24  
time:463s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:505s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:460s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:513s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:630s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:445s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:519s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:542s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:499s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:495s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:441s
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:403s
Blacklisted hosts:
fi-cfl-s2total:288  pass:256  dwarn:0   dfail:0   fail:3   skip:26  
time:562s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:491s
fi-skl-guc   total:288  pass:213  dwarn:47  dfail:0   fail:0   skip:28  
time:412s

fd10fae2b0f673861816511f99d4798d6b619b40 drm-tip: 2018y-01m-19d-14h-22m-15s UTC 
integration manifest
483d552db630 drm/i915: Shrink the GEM kmem_caches upon idling
a40e944809ae drm/i915: Track the number of times we have woken the GPU up

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7725/issues.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/i915: Shrink the request kmem_cache on allocation error

[Patchwork]

== Series Details ==

Series: drm/i915: Shrink the request kmem_cache on allocation error
URL   : https://patchwork.freedesktop.org/series/36800/
State : success

== Summary ==

Series 36800v1 drm/i915: Shrink the request kmem_cache on allocation error
https://patchwork.freedesktop.org/api/1.0/series/36800/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:429s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:438s
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:513s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:293s
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:503s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:497s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:485s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:304s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:525s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:403s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:406s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:421s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:469s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:425s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:464s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:503s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:459s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:636s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:437s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:517s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:535s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:501s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:511s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:443s
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:411s
Blacklisted hosts:
fi-cfl-s2total:288  pass:256  dwarn:0   dfail:0   fail:3   skip:26  
time:568s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:489s
fi-skl-guc   total:288  pass:213  dwarn:47  dfail:0   fail:0   skip:28  
time:415s

fd10fae2b0f673861816511f99d4798d6b619b40 drm-tip: 2018y-01m-19d-14h-22m-15s UTC 
integration manifest
b1ac8b3fa283 drm/i915: Shrink the request kmem_cache on allocation error

== Logs ==

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

Re: [Intel-gfx] [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP

[Imre Deak]

On Thu, Oct 12, 2017 at 12:13:38PM -0700, Manasi Navare wrote:
> In case of eDP because the panel has a fixed mode, the link rate
> and lane count at which it is trained corresponds to the link BW
> required to support the native resolution of the panel. In case of
> panles with lower resolutions where fewer lanes are hooked up internally,
> that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
> So it is pointless to fallback to lower link rate/lane count in case
> of link training failure on eDP connector since the lower link BW
> will not support the native resolution of the panel and we cannot
> prune the preferred mode on the eDP connector.
> 
> In case of Link training failure on the eDP panel, something is wrong
> in the HW internally and hence driver errors out with a loud
> and clear DRM_ERROR message.
> 
> v2:
> * Fix the DEBUG_ERROR and add {} in else (Ville Syrjala)
> 
> Cc: Clinton Taylor 
> Cc: Jim Bride 
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Dave Airlie 
> Cc: Daniel Vetter 
> Signed-off-by: Manasi Navare 
> Reviewed-by: Ville Syrjala 

This fell through the cracks, looks like it partially fixes
https://bugs.freedesktop.org/show_bug.cgi?id=103369

Why link training fails there is not clear.

> ---
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 26 +-
>  1 file changed, 17 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 05907fa..cf8fef8 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -328,14 +328,22 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
>   return;
>  
>   failure_handling:
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = 
> %d, lane count = %d",
> -   intel_connector->base.base.id,
> -   intel_connector->base.name,
> -   intel_dp->link_rate, intel_dp->lane_count);
> - if (!intel_dp_get_link_train_fallback_values(intel_dp,
> -  intel_dp->link_rate,
> -  intel_dp->lane_count))
> - /* Schedule a Hotplug Uevent to userspace to start modeset */
> - schedule_work(_connector->modeset_retry_work);
> + /* Dont fallback and prune modes if its eDP */
> + if (!intel_dp_is_edp(intel_dp)) {
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link 
> rate = %d, lane count = %d",
> +   intel_connector->base.base.id,
> +   intel_connector->base.name,
> +   intel_dp->link_rate, intel_dp->lane_count);
> + if (!intel_dp_get_link_train_fallback_values(intel_dp,
> +  
> intel_dp->link_rate,
> +  
> intel_dp->lane_count))
> + /* Schedule a Hotplug Uevent to userspace to start 
> modeset */
> + schedule_work(_connector->modeset_retry_work);
> + } else {
> + DRM_ERROR("[CONNECTOR:%d:%s] Link Training failed at link rate 
> = %d, lane count = %d",
> +   intel_connector->base.base.id,
> +   intel_connector->base.name,
> +   intel_dp->link_rate, intel_dp->lane_count);
> + }
>   return;
>  }
> -- 
> 2.1.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: failure for drm/i915: add support for specifying DMC firmware override by module param (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: add support for specifying DMC firmware override by module 
param (rev2)
URL   : https://patchwork.freedesktop.org/series/34157/
State : failure

== Summary ==

Test gem_eio:
Subgroup in-flight-suspend:
pass   -> FAIL   (shard-snb) fdo#103375
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#101623
Test gem_exec_schedule:
Subgroup reorder-wide-vebox:
fail   -> PASS   (shard-apl) fdo#102848
Test gem_pwrite_pread:
Subgroup uncached-copy-performance:
pass   -> INCOMPLETE (shard-hsw)
Test perf:
Subgroup buffer-fill:
pass   -> FAIL   (shard-apl) fdo#103755
Test kms_flip:
Subgroup vblank-vs-suspend:
pass   -> FAIL   (shard-apl) fdo#100368
Test kms_vblank:
Subgroup wait-forked-busy:
skip   -> PASS   (shard-snb)
Test kms_cursor_legacy:
Subgroup pipe-b-torture-move:
pass   -> INCOMPLETE (shard-hsw)

fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#102848 https://bugs.freedesktop.org/show_bug.cgi?id=102848
fdo#103755 https://bugs.freedesktop.org/show_bug.cgi?id=103755
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368

shard-apltotal:2753 pass:1714 dwarn:1   dfail:0   fail:23  skip:1015 
time:14077s
shard-hswtotal:2706 pass:1693 dwarn:1   dfail:0   fail:12  skip:997 
time:13451s
shard-snbtotal:2694 pass:1291 dwarn:1   dfail:0   fail:13  skip:1388 
time:7501s
Blacklisted hosts:
shard-kbltotal:2741 pass:1792 dwarn:40  dfail:1   fail:21  skip:886 
time:10354s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7718/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 drm/i915: Fix up the CCS code (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix up the CCS code (rev3)
URL   : https://patchwork.freedesktop.org/series/29308/
State : failure

== Summary ==

Applying: drm/i915: Add a comment exlaining CCS hsub/vsub
Applying: drm/i915: Nuke a pointless unreachable()
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/intel_display.c
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Applying: drm/i915: Add the missing Y/Yf modifiers for SKL+ sprites
error: Failed to merge in the changes.
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/intel_sprite.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_sprite.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_sprite.c
Patch failed at 0003 drm/i915: Add the missing Y/Yf modifiers for SKL+ sprites
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Per-context and per-client engine busyness (rev2)

[Patchwork]

== Series Details ==

Series: Per-context and per-client engine busyness (rev2)
URL   : https://patchwork.freedesktop.org/series/32645/
State : failure

== Summary ==

  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHK include/generated/bounds.h
  CHK include/generated/timeconst.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  DESCEND  objtool
  CHK scripts/mod/devicetable-offsets.h
  CHK include/generated/compile.h
  CC  init/version.o
  AR  init/built-in.o
  CC  arch/x86/kernel/early-quirks.o
  AR  arch/x86/kernel/built-in.o
  AR  arch/x86/built-in.o
  CC  kernel/sys.o
  CC  kernel/trace/trace.o
  AR  kernel/trace/built-in.o
  CC  kernel/module.o
  AR  kernel/built-in.o
  GZIPkernel/config_data.gz
  CHK kernel/config_data.h
  UPD kernel/config_data.h
  CC [M]  kernel/configs.o
  CC  drivers/base/firmware_class.o
  AR  drivers/base/built-in.o
  CC [M]  drivers/gpu/drm/i915/i915_drv.o
In file included from drivers/gpu/drm/i915/intel_ringbuffer.h:7:0,
 from drivers/gpu/drm/i915/intel_lrc.h:27,
 from drivers/gpu/drm/i915/i915_drv.h:63,
 from drivers/gpu/drm/i915/i915_drv.c:49:
drivers/gpu/drm/i915/i915_gem_context.h:166:11: error: ‘I915_NUM_ENGINES’ 
undeclared here (not in a function)
  } engine[I915_NUM_ENGINES];
   ^~~~
drivers/gpu/drm/i915/i915_gem_context.h: In function 
‘i915_gem_context_set_closed’:
drivers/gpu/drm/i915/i915_gem_context.h:209:2: error: implicit declaration of 
function ‘GEM_BUG_ON’ [-Werror=implicit-function-declaration]
  GEM_BUG_ON(i915_gem_context_is_closed(ctx));
  ^~
drivers/gpu/drm/i915/i915_gem_context.h: At top level:
drivers/gpu/drm/i915/i915_gem_context.h:282:32: error: ‘struct 
drm_i915_gem_request’ declared inside parameter list will not be visible 
outside of this definition or declaration [-Werror]
 int i915_switch_context(struct drm_i915_gem_request *req);
^~~~
cc1: all warnings being treated as errors
scripts/Makefile.build:310: recipe for target 'drivers/gpu/drm/i915/i915_drv.o' 
failed
make[4]: *** [drivers/gpu/drm/i915/i915_drv.o] Error 1
scripts/Makefile.build:569: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:569: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:569: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1018: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: expose RCS topology to userspace

[Patchwork]

== Series Details ==

Series: drm/i915: expose RCS topology to userspace
URL   : https://patchwork.freedesktop.org/series/36793/
State : success

== Summary ==

Series 36793v1 drm/i915: expose RCS topology to userspace
https://patchwork.freedesktop.org/api/1.0/series/36793/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (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:426s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:434s
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:514s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:294s
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:502s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:494s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:481s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:307s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:534s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:406s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:420s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:460s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:423s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:468s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:502s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:462s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:629s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:442s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:515s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:541s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:499s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:511s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:440s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:540s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:409s
Blacklisted hosts:
fi-cfl-s2total:288  pass:256  dwarn:0   dfail:0   fail:3   skip:26  
time:571s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:488s
fi-skl-guc   total:288  pass:213  dwarn:47  dfail:0   fail:0   skip:28  
time:411s

fd10fae2b0f673861816511f99d4798d6b619b40 drm-tip: 2018y-01m-19d-14h-22m-15s UTC 
integration manifest
57da52312dd1 drm/i915: expose rcs topology through query uAPI
c2fde81248c7 drm/i915: add query uAPI
5830b6271954 drm/i915: add rcs topology to error state
d92ef5526700 drm/i915/debugfs: add rcs topology entry
518c72b3aaf0 drm/i915/debugfs: reuse max slice/subslices already stored in sseu
e06f75172c63 drm/i915: store all subslice masks

== Logs ==

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

[Intel-gfx] [PATCH 2/2] drm/i915: Shrink the GEM kmem_caches upon idling

[Chris Wilson]

When we finally decide the gpu is idle, that is a good time to shrink
our kmem_caches.

v3: Defer until an rcu grace period after we idle.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 65 +
 1 file changed, 65 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7f0684ccc724..6a8fbcae835b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3341,12 +3341,59 @@ new_requests_since_last_retire(const struct 
drm_i915_private *i915)
work_pending(>gt.idle_work.work));
 }
 
+static void shrink_caches(struct drm_i915_private *i915)
+{
+   /*
+* kmem_cache_shrink() discards empty slabs and reorders partially
+* filled slabs to prioritise allocating from the mostly full slabs,
+* with the aim of reducing fragmentation.
+*/
+   kmem_cache_shrink(i915->priorities);
+   kmem_cache_shrink(i915->dependencies);
+   kmem_cache_shrink(i915->requests);
+   kmem_cache_shrink(i915->luts);
+   kmem_cache_shrink(i915->vmas);
+   kmem_cache_shrink(i915->objects);
+}
+
+struct sleep_rcu_work {
+   struct drm_i915_private *i915;
+   struct rcu_head rcu;
+   struct work_struct work;
+   u32 epoch;
+};
+
+static void __sleep_work(struct work_struct *work)
+{
+   struct sleep_rcu_work *s = container_of(work, typeof(*s), work);
+   struct drm_i915_private *i915 = s->i915;
+   u32 epoch = s->epoch;
+
+   kfree(s);
+   if (epoch == READ_ONCE(i915->gt.epoch))
+   shrink_caches(i915);
+}
+
+static void __sleep_rcu(struct rcu_head *rcu)
+{
+   struct sleep_rcu_work *s = container_of(rcu, typeof(*s), rcu);
+   struct drm_i915_private *i915 = s->i915;
+
+   if (s->epoch == READ_ONCE(i915->gt.epoch)) {
+   INIT_WORK(>work, __sleep_work);
+   queue_work(i915->wq, >work);
+   } else {
+   kfree(s);
+   }
+}
+
 static void
 i915_gem_idle_work_handler(struct work_struct *work)
 {
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), gt.idle_work.work);
bool rearm_hangcheck;
+   u32 epoch = 0;
ktime_t end;
 
if (!READ_ONCE(dev_priv->gt.awake))
@@ -3406,6 +3453,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
rearm_hangcheck = false;
+   epoch = dev_priv->gt.epoch;
 
if (INTEL_GEN(dev_priv) >= 6)
gen6_rps_idle(dev_priv);
@@ -3421,6 +3469,23 @@ i915_gem_idle_work_handler(struct work_struct *work)
GEM_BUG_ON(!dev_priv->gt.awake);
i915_queue_hangcheck(dev_priv);
}
+
+   /*
+* When we are idle, it is an opportune time to reap our caches.
+* However, we have many objects that utilise RCU and the ordered
+* i915->wq that this work is executing on. To try and flush any
+* pending frees now we are idle, we first wait for an RCU grace
+* period, and then queue a task (that will run last on the wq) to
+* shrink and re-optimize the caches.
+*/
+   if (epoch == READ_ONCE(dev_priv->gt.epoch)) {
+   struct sleep_rcu_work *s = kmalloc(sizeof(*s), GFP_KERNEL);
+   if (s) {
+   s->i915 = dev_priv;
+   s->epoch = epoch;
+   call_rcu(>rcu, __sleep_rcu);
+   }
+   }
 }
 
 void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file)
-- 
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: Track the number of times we have woken the GPU up

[Chris Wilson]

By counting the number of times we have woken up, we have a very simple
means of defining an epoch, which will come in handy if we want to
perform deferred tasks at the end of an epoch (i.e. while we are going
to sleep) without imposing on the next activity cycle.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 7 ---
 drivers/gpu/drm/i915/i915_drv.h | 5 +
 drivers/gpu/drm/i915/i915_gem_request.c | 1 +
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index cc659b4b2a45..1aac3ec7d14d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2717,7 +2717,8 @@ static int i915_runtime_pm_status(struct seq_file *m, 
void *unused)
if (!HAS_RUNTIME_PM(dev_priv))
seq_puts(m, "Runtime power management not supported\n");
 
-   seq_printf(m, "GPU idle: %s\n", yesno(!dev_priv->gt.awake));
+   seq_printf(m, "GPU idle: %s (epoch %d)\n",
+  yesno(!dev_priv->gt.awake), dev_priv->gt.epoch);
seq_printf(m, "IRQs disabled: %s\n",
   yesno(!intel_irqs_enabled(dev_priv)));
 #ifdef CONFIG_PM
@@ -3150,8 +3151,8 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
 
intel_runtime_pm_get(dev_priv);
 
-   seq_printf(m, "GT awake? %s\n",
-  yesno(dev_priv->gt.awake));
+   seq_printf(m, "GT awake? %s (epoch %d)\n",
+  yesno(dev_priv->gt.awake), dev_priv->gt.epoch);
seq_printf(m, "Global active requests: %d\n",
   dev_priv->gt.active_requests);
seq_printf(m, "CS timestamp frequency: %u kHz\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 317953484fec..98e8385d1bb0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2302,6 +2302,11 @@ struct drm_i915_private {
struct i915_gem_timeline global_timeline;
u32 active_requests;
 
+   /**
+* The number of times we have woken up.
+*/
+   u32 epoch;
+
/**
 * Is the GPU currently considered idle, or busy executing
 * userspace requests? Whilst idle, we allow runtime power
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index a0f451b4a4e8..f0fab070a3a0 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -274,6 +274,7 @@ static void mark_busy(struct drm_i915_private *i915)
intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
 
i915->gt.awake = true;
+   i915->gt.epoch++;
 
intel_enable_gt_powersave(i915);
i915_update_gfx_val(i915);
-- 
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 drm/i915/guc: Keep GuC log disabled by default

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Keep GuC log disabled by default
URL   : https://patchwork.freedesktop.org/series/36796/
State : success

== Summary ==

Series 36796v1 drm/i915/guc: Keep GuC log disabled by default
https://patchwork.freedesktop.org/api/1.0/series/36796/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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:426s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:437s
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:517s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:293s
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:504s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:495s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:482s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:304s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:529s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:398s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:407s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:426s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:473s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:424s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:467s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:501s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:465s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:626s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:441s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:516s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:533s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:493s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:499s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:438s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:401s
Blacklisted hosts:
fi-cfl-s2total:288  pass:256  dwarn:0   dfail:0   fail:3   skip:26  
time:557s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:485s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:420s

fd10fae2b0f673861816511f99d4798d6b619b40 drm-tip: 2018y-01m-19d-14h-22m-15s UTC 
integration manifest
7240e554a44b drm/i915/guc: Keep GuC log disabled by default

== Logs ==

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

Re: [Intel-gfx] [PATCH v10 6/6] drm/i915: expose rcs topology through query uAPI

[Lionel Landwerlin]

On 19/01/18 14:24, Tvrtko Ursulin wrote:


On 19/01/2018 13:22, Lionel Landwerlin wrote:

With the introduction of asymmetric slices in CNL, we cannot rely on
the previous SUBSLICE_MASK getparam to tell userspace what subslices
are available. Here we introduce a more detailed way of querying the
Gen's GPU topology that doesn't aggregate numbers.

This is essential for monitoring parts of the GPU with the OA unit,
because counters need to be normalized to the number of
EUs/subslices/slices. The current aggregated numbers like EU_TOTAL do
not gives us sufficient information.

As a bonus we can draw representations of the GPU :

 https://imgur.com/a/vuqpa

v2: Rename uapi struct s/_mask/_info/ (Tvrtko)
 Report max_slice/subslice/eus_per_subslice rather than strides 
(Tvrtko)

 Add uapi macros to read data from *_info structs (Tvrtko)

v3: Use !!(v & DRM_I915_BIT()) for uapi macros instead of custom 
shifts (Tvrtko)


v4: factorize query item writting (Tvrtko)
 tweak uapi struct/define names (Tvrtko)

v5: Replace ALIGN() macro (Chris)

v6: Updated uapi comments (Tvrtko)
 Moved flags != 0 checks into vfuncs (Tvrtko)

v7: Use access_ok() before copying anything, to avoid overflows (Chris)
 Switch BUG_ON() to GEM_WARN_ON() (Tvrtko)

v8: Tweak uapi comments style to match the coding style (Lionel)

Signed-off-by: Lionel Landwerlin 
Cc: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_query.c | 110 
++

  include/uapi/drm/i915_drm.h   |  71 
  2 files changed, 181 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c

index 5aa886313cf9..ff87ec8a321a 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -25,8 +25,118 @@
  #include "i915_drv.h"
  #include 

+static int copy_query_data(struct drm_i915_query_item *query_item,
+   const void *item_ptr, u32 item_length,
+   const void *data_ptr, u32 data_length)
+{
+    u32 total_length = item_length + data_length;
+
+    if (GEM_WARN_ON(add_overflows(item_length, data_length)))
+    return -EINVAL;
+
+    if (query_item->length == 0)
+    return total_length;
+
+    if (query_item->length < total_length)
+    return -EINVAL;
+
+    if (!access_ok(VERIFY_WRITE, u64_to_user_ptr(query_item->data_ptr),
+   total_length))
+    return -EFAULT;
+
+    if (__copy_to_user(u64_to_user_ptr(query_item->data_ptr),
+   item_ptr, item_length))
+    return -EFAULT;
+
+    if (__copy_to_user(u64_to_user_ptr(query_item->data_ptr + 
item_length),

+   data_ptr, data_length))
+    return -EFAULT;
+
+    return total_length;
+}
+
+static int query_slice_info(struct drm_i915_private *dev_priv,
+    struct drm_i915_query_item *query_item)
+{
+    const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+    struct drm_i915_query_slice_info slice_info;
+
+    if (query_item->flags != 0)
+    return -EINVAL;
+
+    if (sseu->max_slices == 0)
+    return -ENODEV;
+
+    /*
+ * If we ever change the internal slice mask data type, we'll 
need to

+ * update this function.
+ */
+    BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));
+
+    memset(_info, 0, sizeof(slice_info));
+    slice_info.max_slices = sseu->max_slices;
+
+    return copy_query_data(query_item, _info, sizeof(slice_info),
+   >slice_mask, sizeof(sseu->slice_mask));
+}
+
+static int query_subslice_info(struct drm_i915_private *dev_priv,
+   struct drm_i915_query_item *query_item)
+{
+    const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+    struct drm_i915_query_subslice_info subslice_info;
+    u32 data_length;
+
+    if (query_item->flags != 0)
+    return -EINVAL;
+
+    if (sseu->max_slices == 0)
+    return -ENODEV;
+
+    memset(_info, 0, sizeof(subslice_info));
+    subslice_info.max_slices = sseu->max_slices;
+    subslice_info.max_subslices = sseu->max_subslices;
+
+    data_length = subslice_info.max_slices *
+    DIV_ROUND_UP(subslice_info.max_subslices,
+ sizeof(sseu->subslice_mask[0]) * BITS_PER_BYTE);
+
+    return copy_query_data(query_item,
+   _info, sizeof(subslice_info),
+   sseu->subslice_mask, data_length);
+}
+
+static int query_eu_info(struct drm_i915_private *dev_priv,
+ struct drm_i915_query_item *query_item)
+{
+    const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+    struct drm_i915_query_eu_info eu_info;
+    u32 data_length;
+
+    if (query_item->flags != 0)
+    return -EINVAL;
+
+    if (sseu->max_slices == 0)
+    return -ENODEV;
+
+    memset(_info, 0, sizeof(eu_info));
+    eu_info.max_slices = sseu->max_slices;
+    eu_info.max_subslices = sseu->max_subslices;
+    eu_info.max_eus_per_subslice = 

[Intel-gfx] [CI] drm/i915: Shrink the request kmem_cache on allocation error

[Chris Wilson]

If we fail to allocate a new request, make sure we recover the pages
that are in the process of being freed by inserting an RCU barrier.

v2: Comment before the shrink and barrier in the error path.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 72bdc203716f..a0f451b4a4e8 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -696,6 +696,17 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
if (ret)
goto err_unreserve;
 
+   /*
+* We've forced the client to stall and catch up with whatever
+* backlog there might have been. As we are assuming that we
+* caused the mempressure, now is an opportune time to
+* recover as much memory from the request pool as is possible.
+* Having already penalized the client to stall, we spend
+* a little extra time to re-optimise page allocation.
+*/
+   kmem_cache_shrink(dev_priv->requests);
+   rcu_barrier(); /* Recover the TYPESAFE_BY_RCU pages */
+
req = kmem_cache_alloc(dev_priv->requests, GFP_KERNEL);
if (!req) {
ret = -ENOMEM;
-- 
2.15.1

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

[Intel-gfx] [PATCH v2 1/8] drm/i915: Add a comment exlaining CCS hsub/vsub

[Ville Syrjala]

From: Ville Syrjälä 

Let's document why we claim hsub==8,vsub==16 for CCS.

v2: Replace my explanation with Jason's

Cc: Daniel Vetter 
Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Cc: Daniel Stone 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 91f3c0a64596..8d0d5d8753c0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2387,6 +2387,20 @@ static unsigned int intel_fb_modifier_to_tiling(uint64_t 
fb_modifier)
}
 }
 
+/*
+ * From the Sky Lake PRM:
+ * "The Color Control Surface (CCS) contains the compression status of
+ *  the cache-line pairs. The compression state of the cache-line pair
+ *  is specified by 2 bits in the CCS. Each CCS cache-line represents
+ *  an area on the main surface of 16 x16 sets of 128 byte Y-tiled
+ *  cache-line-pairs. CCS is always Y tiled."
+ *
+ * Since cache line pairs refers to horizontally adjacent cache lines,
+ * each cache line in the CCS corresponds to an area of 32x16 cache
+ * lines on the main surface. Since each pixel is 4 bytes, this gives
+ * us a ratio of one byte in the CCS for each 8x16 pixels in the
+ * main surface.
+ */
 static const struct drm_format_info ccs_formats[] = {
{ .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 8, .vsub = 16, },
{ .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 8, .vsub = 16, },
-- 
2.13.6

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915: Downgrade incorrect engine constructor usage warnings to development

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915: Downgrade incorrect engine 
constructor usage warnings to development
URL   : https://patchwork.freedesktop.org/series/36771/
State : failure

== Summary ==

Test perf:
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-a:
skip   -> PASS   (shard-snb)
Test gem_tiled_swapping:
Subgroup non-threaded:
pass   -> INCOMPLETE (shard-snb) fdo#104218 +1
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
notrun -> INCOMPLETE (shard-hsw) fdo#103375
Test kms_flip:
Subgroup vblank-vs-dpms-suspend:
incomplete -> PASS   (shard-hsw) fdo#103540
Subgroup modeset-vs-vblank-race:
pass   -> FAIL   (shard-apl) fdo#103060
Subgroup vblank-vs-suspend:
pass   -> FAIL   (shard-apl) fdo#100368
Test drv_selftest:
Subgroup live_gtt:
incomplete -> PASS   (shard-apl) fdo#103927
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-pri-indfb-multidraw:
pass   -> FAIL   (shard-snb) fdo#103167 +1
Test kms_cursor_legacy:
Subgroup pipe-b-torture-move:
pass   -> INCOMPLETE (shard-hsw)

fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167

shard-apltotal:2753 pass:1714 dwarn:1   dfail:0   fail:23  skip:1015 
time:13977s
shard-hswtotal:2751 pass:1721 dwarn:1   dfail:0   fail:11  skip:1015 
time:13506s
shard-snbtotal:2694 pass:1292 dwarn:1   dfail:0   fail:11  skip:1389 
time:7461s
Blacklisted hosts:
shard-kbltotal:2741 pass:1831 dwarn:1   dfail:0   fail:22  skip:886 
time:10248s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7717/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 drm/i915: Avoid leaking lpe audio platdev.data

[Patchwork]

== Series Details ==

Series: drm/i915: Avoid leaking lpe audio platdev.data
URL   : https://patchwork.freedesktop.org/series/35151/
State : success

== Summary ==

Series 35151v1 drm/i915: Avoid leaking lpe audio platdev.data
https://patchwork.freedesktop.org/api/1.0/series/35151/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> FAIL   (fi-elk-e7500) fdo#103989 +1
incomplete -> PASS   (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:427s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
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:522s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:294s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:498s
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:495s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:482s
fi-elk-e7500 total:224  pass:167  dwarn:10  dfail:0   fail:1   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:305s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:527s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:398s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:405s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:420s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:474s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:422s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:464s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:501s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:456s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:634s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:443s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:518s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:534s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:499s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:494s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:441s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:552s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:405s
Blacklisted hosts:
fi-cfl-s2total:288  pass:256  dwarn:0   dfail:0   fail:3   skip:26  
time:564s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:486s
fi-skl-guc   total:288  pass:211  dwarn:49  dfail:0   fail:0   skip:28  
time:411s

50a3d9c6fd3ca92a68c2693440d16d3ffdf067ff drm-tip: 2018y-01m-19d-13h-39m-21s UTC 
integration manifest
47aa344a53a3 drm/i915: Avoid leaking lpe audio platdev.data

== Logs ==

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

Re: [Intel-gfx] [PATCH v10 6/6] drm/i915: expose rcs topology through query uAPI

[Tvrtko Ursulin]

On 19/01/2018 13:22, Lionel Landwerlin wrote:

With the introduction of asymmetric slices in CNL, we cannot rely on
the previous SUBSLICE_MASK getparam to tell userspace what subslices
are available. Here we introduce a more detailed way of querying the
Gen's GPU topology that doesn't aggregate numbers.

This is essential for monitoring parts of the GPU with the OA unit,
because counters need to be normalized to the number of
EUs/subslices/slices. The current aggregated numbers like EU_TOTAL do
not gives us sufficient information.

As a bonus we can draw representations of the GPU :

 https://imgur.com/a/vuqpa

v2: Rename uapi struct s/_mask/_info/ (Tvrtko)
 Report max_slice/subslice/eus_per_subslice rather than strides (Tvrtko)
 Add uapi macros to read data from *_info structs (Tvrtko)

v3: Use !!(v & DRM_I915_BIT()) for uapi macros instead of custom shifts (Tvrtko)

v4: factorize query item writting (Tvrtko)
 tweak uapi struct/define names (Tvrtko)

v5: Replace ALIGN() macro (Chris)

v6: Updated uapi comments (Tvrtko)
 Moved flags != 0 checks into vfuncs (Tvrtko)

v7: Use access_ok() before copying anything, to avoid overflows (Chris)
 Switch BUG_ON() to GEM_WARN_ON() (Tvrtko)

v8: Tweak uapi comments style to match the coding style (Lionel)

Signed-off-by: Lionel Landwerlin 
Cc: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_query.c | 110 ++
  include/uapi/drm/i915_drm.h   |  71 
  2 files changed, 181 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index 5aa886313cf9..ff87ec8a321a 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -25,8 +25,118 @@
  #include "i915_drv.h"
  #include 

+static int copy_query_data(struct drm_i915_query_item *query_item,
+  const void *item_ptr, u32 item_length,
+  const void *data_ptr, u32 data_length)
+{
+   u32 total_length = item_length + data_length;
+
+   if (GEM_WARN_ON(add_overflows(item_length, data_length)))
+   return -EINVAL;
+
+   if (query_item->length == 0)
+   return total_length;
+
+   if (query_item->length < total_length)
+   return -EINVAL;
+
+   if (!access_ok(VERIFY_WRITE, u64_to_user_ptr(query_item->data_ptr),
+  total_length))
+   return -EFAULT;
+
+   if (__copy_to_user(u64_to_user_ptr(query_item->data_ptr),
+  item_ptr, item_length))
+   return -EFAULT;
+
+   if (__copy_to_user(u64_to_user_ptr(query_item->data_ptr + item_length),
+  data_ptr, data_length))
+   return -EFAULT;
+
+   return total_length;
+}
+
+static int query_slice_info(struct drm_i915_private *dev_priv,
+   struct drm_i915_query_item *query_item)
+{
+   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+   struct drm_i915_query_slice_info slice_info;
+
+   if (query_item->flags != 0)
+   return -EINVAL;
+
+   if (sseu->max_slices == 0)
+   return -ENODEV;
+
+   /*
+* If we ever change the internal slice mask data type, we'll need to
+* update this function.
+*/
+   BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));
+
+   memset(_info, 0, sizeof(slice_info));
+   slice_info.max_slices = sseu->max_slices;
+
+   return copy_query_data(query_item, _info, sizeof(slice_info),
+  >slice_mask, sizeof(sseu->slice_mask));
+}
+
+static int query_subslice_info(struct drm_i915_private *dev_priv,
+  struct drm_i915_query_item *query_item)
+{
+   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+   struct drm_i915_query_subslice_info subslice_info;
+   u32 data_length;
+
+   if (query_item->flags != 0)
+   return -EINVAL;
+
+   if (sseu->max_slices == 0)
+   return -ENODEV;
+
+   memset(_info, 0, sizeof(subslice_info));
+   subslice_info.max_slices = sseu->max_slices;
+   subslice_info.max_subslices = sseu->max_subslices;
+
+   data_length = subslice_info.max_slices *
+   DIV_ROUND_UP(subslice_info.max_subslices,
+sizeof(sseu->subslice_mask[0]) * BITS_PER_BYTE);
+
+   return copy_query_data(query_item,
+  _info, sizeof(subslice_info),
+  sseu->subslice_mask, data_length);
+}
+
+static int query_eu_info(struct drm_i915_private *dev_priv,
+struct drm_i915_query_item *query_item)
+{
+   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+   struct drm_i915_query_eu_info eu_info;
+   u32 data_length;
+
+   if (query_item->flags != 0)
+   

Re: [Intel-gfx] [PATCH v2] drm/i915: Check for fused or unused pipes

[Jani Nikula]

On Mon, 18 Dec 2017, Mika Kahola  wrote:
> We may have fused or unused pipes in our system. Let's check that the pipe
> in question is within limits of accessible pipes. In case, that we are not
> able to access the pipe, we return early with a warning.
>
> v2: Rephrasing of the commit message (Jani)
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103206
> Reported-by: Thomas Gleixner 
> Tested-by: Jaswinder Singh Rajput 
> Suggested-by: Jani Nikula 
> Reviewed-by: Jani Nikula 
> Signed-off-by: Mika Kahola 

Pushed, thanks for the patch, sorry for the delay.

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/intel_audio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index f1502a0..522d54f 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -779,7 +779,7 @@ static struct intel_encoder *get_saved_enc(struct 
> drm_i915_private *dev_priv,
>  {
>   struct intel_encoder *encoder;
>  
> - if (WARN_ON(pipe >= INTEL_INFO(dev_priv)->num_pipes))
> + if (WARN_ON(pipe >= ARRAY_SIZE(dev_priv->av_enc_map)))
>   return NULL;
>  
>   /* MST */

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

Re: [Intel-gfx] [RFC] drm/i915/guc: Keep GuC log disabled by default

[Jani Nikula]

On Fri, 19 Jan 2018, Michał Winiarski  wrote:
> On Fri, Jan 19, 2018 at 12:49:26PM +, Michal Wajdeczko wrote:
>> It looks that GuC log functionality is not fully functional yet and
>> causes issues when enabled by auto(-1) modparam on debug builds.

This could use a better explanation. Now it seems like you're just
sweeping things under the carpet.

>> 
>> [   30.062893] ==
>> [   30.062894] WARNING: possible circular locking dependency detected
>> [   30.062895] 4.15.0-rc8-CI-CI_DRM_3648+ #1 Tainted: G U
>> [   30.062896] --
>> [   30.062897] debugfs_test/1268 is trying to acquire lock:
>> [   30.062898]  (>struct_mutex){+.+.}, at: [] 
>> i915_mutex_lock_interruptible+0x47/0x130 [i915]
>> [   30.062921]
>>but task is already holding lock:
>> [   30.062921]  (>mmap_sem){}, at: [] 
>> __do_page_fault+0x106/0x560
>> [   30.062924]
>>which lock already depends on the new lock.
>> 
>
> I'd leave the lockdep splat out of here, since that's just the tip of the
> iceberg :)
>
>> Fixes: 0ed87953532652 ("drm/i915/guc: Redefine guc_log_level modparam 
>> values")
>
> s/Fixes/References

References should generally reference URIs I think.

BR,
Jani.


>
> It allows us to get test results while we're fixing the logging issues, so:
>
> Reviewed-by: Michał Winiarski 
>
> -Michał
>
>> Signed-off-by: Michal Wajdeczko 
>> Cc: Chris Wilson 
>> Cc: Jani Saarinen 
>> Cc: Tomi Sarvela 
>> Cc: Marta Lofstedt 
>> Cc: Michal Winiarski 
>> ---
>>  drivers/gpu/drm/i915/i915_params.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_params.h 
>> b/drivers/gpu/drm/i915/i915_params.h
>> index c963603..430f5f9 100644
>> --- a/drivers/gpu/drm/i915/i915_params.h
>> +++ b/drivers/gpu/drm/i915/i915_params.h
>> @@ -48,7 +48,7 @@
>>  param(int, enable_ips, 1) \
>>  param(int, invert_brightness, 0) \
>>  param(int, enable_guc, 0) \
>> -param(int, guc_log_level, -1) \
>> +param(int, guc_log_level, 0) \
>>  param(char *, guc_firmware_path, NULL) \
>>  param(char *, huc_firmware_path, NULL) \
>>  param(int, mmio_debug, 0) \
>> -- 
>> 1.9.1
>> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: Avoid leaking lpe audio platdev.data

[Jani Nikula]

On Sat, 09 Dec 2017, Chris Wilson  wrote:
> The struct platform_device memdups the provided data pointer requiring
> us to free the template we construct during lpe_audio_platdev_create():
>
> unreferenced object 0x88026eafe400 (size 512):
>   comm "insmod", pid 6850, jiffies 4295060179 (age 22.300s)
>   hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>   backtrace:
> [<8e4a834c>] intel_audio_init+0x9/0x30 [i915]
> [<1360e195>] i915_driver_load+0x802/0x14e0 [i915]
> [] i915_pci_probe+0x29/0x70 [i915]
> [<16330ee5>] pci_device_probe+0x9c/0x120
> [<0257d054>] driver_probe_device+0x307/0x470
> [<9f0a6cb6>] __driver_attach+0x98/0xe0
> [<31b46e58>] bus_for_each_dev+0x57/0x80
> [<0e28239d>] bus_add_driver+0x1bd/0x260
> [] driver_register+0x52/0xc0
> [<5c6e23d4>] do_one_initcall+0x36/0x150
> [] do_init_module+0x56/0x1d7
> [] load_module+0x23c8/0x2910
> [<2b60bf61>] SyS_finit_module+0xb8/0xd0
> [<41cbad96>] entry_SYSCALL_64_fastpath+0x17/0x70
> [<9f1d37ab>] 0x
>
> Signed-off-by: Chris Wilson 
> Cc: Takashi Iwai 
> Cc: Pierre-Louis Bossart 
> Cc: Ville Syrjälä 

I queued this for re-testing.

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/intel_lpe_audio.c | 14 --
>  1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c 
> b/drivers/gpu/drm/i915/intel_lpe_audio.c
> index 3bf65288..0a2e1fea43fa 100644
> --- a/drivers/gpu/drm/i915/intel_lpe_audio.c
> +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
> @@ -74,7 +74,6 @@
>  static struct platform_device *
>  lpe_audio_platdev_create(struct drm_i915_private *dev_priv)
>  {
> - int ret;
>   struct drm_device *dev = _priv->drm;
>   struct platform_device_info pinfo = {};
>   struct resource *rsc;
> @@ -119,24 +118,19 @@ lpe_audio_platdev_create(struct drm_i915_private 
> *dev_priv)
>   spin_lock_init(>lpe_audio_slock);
>  
>   platdev = platform_device_register_full();
> + kfree(rsc);
> + kfree(pdata);
> +
>   if (IS_ERR(platdev)) {
> - ret = PTR_ERR(platdev);
>   DRM_ERROR("Failed to allocate LPE audio platform device\n");
> - goto err;
> + return platdev;
>   }
>  
> - kfree(rsc);
> -
>   pm_runtime_forbid(>dev);
>   pm_runtime_set_active(>dev);
>   pm_runtime_enable(>dev);
>  
>   return platdev;
> -
> -err:
> - kfree(rsc);
> - kfree(pdata);
> - return ERR_PTR(ret);
>  }
>  
>  static void lpe_audio_platdev_destroy(struct drm_i915_private *dev_priv)

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

Re: [Intel-gfx] [PATCH v5] drm/i915/icl: Enhanced execution list support

[Mika Kuoppala]

Daniele Ceraolo Spurio  writes:

> From: Thomas Daniel 
>
> Enhanced Execlists is an upgraded version of execlists which supports
> up to 8 ports. The lrcs to be submitted are written to a submit queue,
> which is then loaded on the HW. When writing to the ELSP register, the
> lrcs are written cyclically in the queue from position 0 to position 7.
> Alternatively, it is possible to write directly in the individual
> positions of the queue using the ELSQ registers. To be able to re-use
> all the existing code we're using the latter method and we're currently
> limiting ourself to only using 2 elements.
>
> The preemption flow is sligthly different with enhanced execlists, so
> this patch turns preemption off temporarily for Gen11+ while we wait for
> the new mechanism to land.
>
> v2: Rebase.
> v3: Switch from !IS_GEN11 to GEN < 11 (Daniele Ceraolo Spurio).
> v4: Use the elsq registers instead of elsp. (Daniele Ceraolo Spurio)
> v5: Reword commit, rename regs to be closer to specs, turn off
> preemption (Daniele), reuse engine->execlists.elsp (Chris)
>
> Cc: Chris Wilson 
> Signed-off-by: Thomas Daniel 
> Signed-off-by: Rodrigo Vivi 
> Signed-off-by: Daniele Ceraolo Spurio 

Was going to adopt this patch from Rodrigo but you were faster.

I choose to stash the elsq and use it as a gen11 vs rest toggle:

Relevant bits:

+static inline void write_port(struct intel_engine_execlists * const execlists,
+ unsigned int n,
+ u64 desc)
+{
+   if (execlists->elsq)
+   gen11_elsq_write(desc, n, execlists->elsq);
+   else
+   gen8_elsp_write(desc, execlists->elsp);
+}
+
+static inline void submit_ports(struct intel_engine_execlists * const 
execlists)
+{
+   /* for gen11+ we need to manually load the submit queue */
+   if (execlists->elsq) {
+   struct intel_engine_cs *engine =
+   container_of(execlists,
+struct intel_engine_cs,
+execlists);
+   struct drm_i915_private *dev_priv = engine->i915;
+
+   I915_WRITE_FW(RING_ELCR(engine), ELCR_LOAD);
+   }
+}
+

...
-Mika

> ---
>  drivers/gpu/drm/i915/i915_drv.h |  5 -
>  drivers/gpu/drm/i915/intel_lrc.c| 35 
> -
>  drivers/gpu/drm/i915/intel_lrc.h|  3 +++
>  drivers/gpu/drm/i915/intel_ringbuffer.h |  6 --
>  4 files changed, 41 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c42015b..3163543 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2738,8 +2738,11 @@ static inline unsigned int i915_sg_segment_size(void)
>  
>  #define HAS_LOGICAL_RING_CONTEXTS(dev_priv) \
>   ((dev_priv)->info.has_logical_ring_contexts)
> +
> +/* XXX: Preemption disabled for Gen11+ until support for new flow lands */
>  #define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
> - ((dev_priv)->info.has_logical_ring_preemption)
> + ((dev_priv)->info.has_logical_ring_preemption && \
> +  INTEL_GEN(dev_priv) < 11)
>  
>  #define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
>  
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index ff25f20..67ad7c9 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -428,11 +428,24 @@ static inline void elsp_write(u64 desc, u32 __iomem 
> *elsp)
>   writel(lower_32_bits(desc), elsp);
>  }
>  
> +static inline void elsqc_write(u64 desc, u32 __iomem *elsqc, u32 port)
> +{
> + writel(lower_32_bits(desc), elsqc + port * 2);
> + writel(upper_32_bits(desc), elsqc + port * 2 + 1);
> +}
> +
>  static void execlists_submit_ports(struct intel_engine_cs *engine)
>  {
> + struct drm_i915_private *dev_priv = engine->i915;
>   struct execlist_port *port = engine->execlists.port;
>   unsigned int n;
>  
> + /*
> +  * Gen11+ note: the submit queue is not cleared after being submitted
> +  * to the HW so we need to make sure we always clean it up. This is
> +  * currently ensured by the fact that we always write the same number
> +  * of elsq entries, keep this in mind before changing the loop below.
> +  */
>   for (n = execlists_num_ports(>execlists); n--; ) {
>   struct drm_i915_gem_request *rq;
>   unsigned int count;
> @@ -456,8 +469,16 @@ static void execlists_submit_ports(struct 
> intel_engine_cs *engine)
>   desc = 0;
>   }
>  
> - elsp_write(desc, engine->execlists.elsp);
> + if (INTEL_GEN(dev_priv) >= 11)
> + 

[Intel-gfx] [PATCH v10 2/6] drm/i915/debugfs: reuse max slice/subslices already stored in sseu

[Lionel Landwerlin]

Now that we have that information in topology fields, let's just reused it.

v2: Style tweaks (Tvrtko)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 27 +++
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 684551114965..e41a19b7d7bb 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4304,11 +4304,11 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 struct sseu_dev_info *sseu)
 {
const struct intel_device_info *info = INTEL_INFO(dev_priv);
-   int s_max = 6, ss_max = 4;
int s, ss;
-   u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2];
+   u32 s_reg[info->sseu.max_slices];
+   u32 eu_reg[2 * info->sseu.max_subslices], eu_mask[2];
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
/*
 * FIXME: Valid SS Mask respects the spec and read
 * only valid bits for those registers, excluding reserverd
@@ -4330,7 +4330,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 GEN9_PGCTL_SSB_EU210_ACK |
 GEN9_PGCTL_SSB_EU311_ACK;
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
continue;
@@ -4338,7 +4338,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
sseu->subslice_mask[s] = info->sseu.subslice_mask[s];
 
-   for (ss = 0; ss < ss_max; ss++) {
+   for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
 
if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss
@@ -4358,17 +4358,12 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 static void gen9_sseu_device_status(struct drm_i915_private *dev_priv,
struct sseu_dev_info *sseu)
 {
-   int s_max = 3, ss_max = 4;
+   const struct intel_device_info *info = INTEL_INFO(dev_priv);
int s, ss;
-   u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
-
-   /* BXT has a single slice and at most 3 subslices. */
-   if (IS_GEN9_LP(dev_priv)) {
-   s_max = 1;
-   ss_max = 3;
-   }
+   u32 s_reg[info->sseu.max_slices];
+   u32 eu_reg[2 * info->sseu.max_subslices], eu_mask[2];
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
s_reg[s] = I915_READ(GEN9_SLICE_PGCTL_ACK(s));
eu_reg[2*s] = I915_READ(GEN9_SS01_EU_PGCTL_ACK(s));
eu_reg[2*s + 1] = I915_READ(GEN9_SS23_EU_PGCTL_ACK(s));
@@ -4383,7 +4378,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
 GEN9_PGCTL_SSB_EU210_ACK |
 GEN9_PGCTL_SSB_EU311_ACK;
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
continue;
@@ -4394,7 +4389,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->subslice_mask[s] =
INTEL_INFO(dev_priv)->sseu.subslice_mask[s];
 
-   for (ss = 0; ss < ss_max; ss++) {
+   for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
 
if (IS_GEN9_LP(dev_priv)) {
-- 
2.15.1

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

[Intel-gfx] [PATCH 4/6] drm/i915: Update client name on context create

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Some clients have the DRM fd passed to them over a socket by the X server.

Grab the real client and pid when they create their first context and
update the exposed data for more useful enumeration.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h |  8 
 drivers/gpu/drm/i915/i915_gem.c |  4 ++--
 drivers/gpu/drm/i915/i915_gem_context.c | 15 +--
 3 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2414aa430f65..a2a883aaa59e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3398,6 +3398,14 @@ i915_gem_object_pin_to_display_plane(struct 
drm_i915_gem_object *obj,
 void i915_gem_object_unpin_from_display_plane(struct i915_vma *vma);
 int i915_gem_object_attach_phys(struct drm_i915_gem_object *obj,
int align);
+
+int
+i915_gem_add_client(struct drm_i915_private *i915,
+   struct drm_i915_file_private *file_priv,
+   struct task_struct *task,
+   unsigned int serial);
+void i915_gem_remove_client(struct drm_i915_file_private *file_priv);
+
 int i915_gem_open(struct drm_i915_private *i915, struct drm_file *file);
 void i915_gem_release(struct drm_device *dev, struct drm_file *file);
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3625c0d4b039..7fdd892aa32a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5538,7 +5538,7 @@ show_client_pid(struct device *kdev, struct 
device_attribute *attr, char *buf)
return snprintf(buf, PAGE_SIZE, "%u", file_priv->client_pid);
 }
 
-static int
+int
 i915_gem_add_client(struct drm_i915_private *i915,
struct drm_i915_file_private *file_priv,
struct task_struct *task,
@@ -5593,7 +5593,7 @@ i915_gem_add_client(struct drm_i915_private *i915,
return ret;
 }
 
-static void i915_gem_remove_client(struct drm_i915_file_private *file_priv)
+void i915_gem_remove_client(struct drm_i915_file_private *file_priv)
 {
sysfs_remove_file(file_priv->client_root,
  (struct attribute *)_priv->attr.pid);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 256800fb1a3b..0f828318a4f9 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -644,6 +644,7 @@ static bool client_is_banned(struct drm_i915_file_private 
*file_priv)
 int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
  struct drm_file *file)
 {
+   unsigned int pid = pid_nr(get_task_pid(current, PIDTYPE_PID));
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_i915_gem_context_create *args = data;
struct drm_i915_file_private *file_priv = file->driver_priv;
@@ -658,8 +659,7 @@ int i915_gem_context_create_ioctl(struct drm_device *dev, 
void *data,
 
if (client_is_banned(file_priv)) {
DRM_DEBUG("client %s[%d] banned from creating ctx\n",
- current->comm,
- pid_nr(get_task_pid(current, PIDTYPE_PID)));
+ current->comm, pid);
 
return -EIO;
}
@@ -668,6 +668,17 @@ int i915_gem_context_create_ioctl(struct drm_device *dev, 
void *data,
if (ret)
return ret;
 
+   if (file_priv->client_pid != pid) {
+   unsigned int id = file_priv->client_sysfs_id;
+
+   i915_gem_remove_client(file_priv);
+   ret = i915_gem_add_client(dev_priv, file_priv, current, id);
+   if (ret) {
+   mutex_unlock(>struct_mutex);
+   return ret;
+   }
+   }
+
ctx = i915_gem_create_context(dev_priv, file_priv);
mutex_unlock(>struct_mutex);
if (IS_ERR(ctx))
-- 
2.14.1

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

Re: [Intel-gfx] [RFC 6/6] drm/i915/pmu: Add running counter

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-19 11:45:24)
> 
> On 18/01/2018 11:57, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-01-18 10:41:36)
> >> From: Tvrtko Ursulin 
> >>
> >> We add a PMU counter to expose the number of requests currently executing
> >> on the GPU.
> >>
> >> This is useful to analyze the overall load of the system.
> >>
> >> Signed-off-by: Tvrtko Ursulin 
> > 
> > Ok, the split between queued (unmet dependencies),
> > submitted (met dependencies, ready for hw) and running (on hw) look good
> > to me. The usual slight inaccuracies that may arise due to trying to
> > sample across async hw + engines, but those should be minor. And the
> > counters seem very useful (at least for the trivial overlay).
> 
> Glad to hear positive feedback!
> 
> > The only suggestion I would make is perhaps
> > 
> >   engine->stats.unready_requests / requests_queued;
> >   engine->stats.requests_ready / requests_submitted;
> > 
> > (doesn't have to be stats, but I think we want a bit more verbosity
> > here).
> 
> Hm, what is that? You are suggesting some relative stats? Exposed as 
> another counter? It can be calculated in userspace easily.

Just trying to think of better names than engine->queued.
I like 'stats' as it says "this is not part of the normal engine
management, but some auxiliary information we tracked for user
convenience"; then I was just trying to think of a more apropos name
than 'queued'. I definitely think we want to let the reader know what's
queued :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/6] drm/i915: Allow clients to query own per-engine busyness

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Some customers want to know how much of the GPU time are their clients
using in order to make dynamic load balancing decisions.

With the accounting infrastructure in place in the previous patch, we add
a new context param (I915_CONTEXT_GET_ENGINE_BUSY) which takes a class and
instance of an engine for which the client would like to know its
utilization.

Utilization is reported as monotonically increasing number of nano-
seconds the engine spent executing jobs belonging to this context.

v2:
 * Use intel_context_engine_get_busy_time.
 * Refactor to only use struct_mutex while initially enabling engine
   stats.

v3:
 * Fix stats enabling.

Signed-off-by: Tvrtko Ursulin 
Cc: gordon.ke...@intel.com
---
 drivers/gpu/drm/i915/i915_gem_context.c | 41 ++---
 drivers/gpu/drm/i915/i915_gem_context.h |  1 +
 include/uapi/drm/i915_drm.h | 11 -
 3 files changed, 49 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 648e7536ff51..256800fb1a3b 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -126,6 +126,9 @@ static void i915_gem_context_free(struct i915_gem_context 
*ctx)
for (i = 0; i < I915_NUM_ENGINES; i++) {
struct intel_context *ce = >engine[i];
 
+   if (ce->stats.enabled)
+   intel_disable_engine_stats(ctx->i915->engine[i]);
+
if (!ce->state)
continue;
 
@@ -713,7 +716,10 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
 {
struct drm_i915_file_private *file_priv = file->driver_priv;
struct drm_i915_gem_context_param *args = data;
+   struct drm_i915_private *i915 = to_i915(dev);
+   struct intel_engine_cs *engine;
struct i915_gem_context *ctx;
+   struct intel_context *ce;
int ret = 0;
 
ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
@@ -731,10 +737,10 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
case I915_CONTEXT_PARAM_GTT_SIZE:
if (ctx->ppgtt)
args->value = ctx->ppgtt->base.total;
-   else if (to_i915(dev)->mm.aliasing_ppgtt)
-   args->value = 
to_i915(dev)->mm.aliasing_ppgtt->base.total;
+   else if (i915->mm.aliasing_ppgtt)
+   args->value = i915->mm.aliasing_ppgtt->base.total;
else
-   args->value = to_i915(dev)->ggtt.base.total;
+   args->value = i915->ggtt.base.total;
break;
case I915_CONTEXT_PARAM_NO_ERROR_CAPTURE:
args->value = i915_gem_context_no_error_capture(ctx);
@@ -745,6 +751,34 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
case I915_CONTEXT_PARAM_PRIORITY:
args->value = ctx->priority;
break;
+   case I915_CONTEXT_GET_ENGINE_BUSY:
+   engine = intel_engine_lookup_user(i915, args->class,
+ args->instance);
+   if (!engine) {
+   ret = -EINVAL;
+   break;
+   }
+
+   ce = >engine[engine->id];
+   if (!READ_ONCE(ce->stats.enabled)) {
+   ret = i915_mutex_lock_interruptible(dev);
+   if (!ret)
+   break;
+
+   if (!ce->stats.enabled) {
+   ret = intel_enable_engine_stats(engine);
+   if (!ret)
+   break;
+   ce->stats.enabled = true;
+   }
+
+   mutex_unlock(>struct_mutex);
+   }
+
+   args->value =
+   ktime_to_ns(intel_context_engine_get_busy_time(ctx,
+  engine));
+   break;
default:
ret = -EINVAL;
break;
@@ -820,6 +854,7 @@ int i915_gem_context_setparam_ioctl(struct drm_device *dev, 
void *data,
}
break;
 
+   case I915_CONTEXT_GET_ENGINE_BUSY:
default:
ret = -EINVAL;
break;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h 
b/drivers/gpu/drm/i915/i915_gem_context.h
index 0ce8b9bf0f32..2312967a5890 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -158,6 +158,7 @@ struct i915_gem_context {
u64 lrc_desc;
int pin_count;
struct {
+   bool enabled;
bool active;

[Intel-gfx] [PATCH 6/6] drm/i915: Add sysfs toggle to enable per-client engine stats

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

By default we are not collecting any per-engine and per-context
statistcs.

Add a new sysfs toggle to enable this facility:

$ echo 1 >/sys/class/drm/card0/clients/enable_stats

v2: Rebase.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h   |  2 ++
 drivers/gpu/drm/i915/i915_sysfs.c | 72 +++
 2 files changed, 74 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a96cfdfcba03..63f96e8fe3b7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2361,6 +2361,8 @@ struct drm_i915_private {
 
struct kobject *clients_root;
atomic_t client_serial;
+   struct device_attribute client_stats_attr;
+   bool client_stats_enabled;
 
/*
 * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index ae875c8686a3..f250547af1ef 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -570,9 +570,67 @@ static void i915_setup_error_capture(struct device *kdev) 
{}
 static void i915_teardown_error_capture(struct device *kdev) {}
 #endif
 
+static ssize_t
+show_client_stats(struct device *kdev, struct device_attribute *attr, char 
*buf)
+{
+   struct drm_i915_private *i915 =
+   container_of(attr, struct drm_i915_private, client_stats_attr);
+
+   return snprintf(buf, PAGE_SIZE, "%u\n", i915->client_stats_enabled);
+}
+
+static ssize_t
+store_client_stats(struct device *kdev, struct device_attribute *attr,
+  const char *buf, size_t count)
+{
+   struct drm_i915_private *i915 =
+   container_of(attr, struct drm_i915_private, client_stats_attr);
+   bool disable = false;
+   bool enable = false;
+   bool val = false;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+   int ret;
+
+/* Use RCS as proxy for all engines. */
+   if (!intel_engine_supports_stats(i915->engine[RCS]))
+   return -EINVAL;
+
+   ret = kstrtobool(buf, );
+   if (ret)
+   return ret;
+
+   ret = i915_mutex_lock_interruptible(>drm);
+   if (ret)
+   return ret;
+
+   if (val && !i915->client_stats_enabled)
+   enable = true;
+   else if (!val && i915->client_stats_enabled)
+   disable = true;
+
+   if (!enable && !disable)
+   goto out;
+
+   for_each_engine(engine, i915, id) {
+   if (enable)
+   WARN_ON_ONCE(intel_enable_engine_stats(engine));
+   else if (disable)
+   intel_disable_engine_stats(engine);
+   }
+
+   i915->client_stats_enabled = val;
+
+out:
+   mutex_unlock(>drm.struct_mutex);
+
+   return count;
+}
+
 void i915_setup_sysfs(struct drm_i915_private *dev_priv)
 {
struct device *kdev = dev_priv->drm.primary->kdev;
+   struct device_attribute *attr;
int ret;
 
dev_priv->clients_root =
@@ -580,6 +638,17 @@ void i915_setup_sysfs(struct drm_i915_private *dev_priv)
if (!dev_priv->clients_root)
DRM_ERROR("Per-client sysfs setup failed\n");
 
+   attr = _priv->client_stats_attr;
+   attr->attr.name = "enable_stats";
+   attr->attr.mode = 0664;
+   attr->show = show_client_stats;
+   attr->store = store_client_stats;
+
+   ret = sysfs_create_file(dev_priv->clients_root,
+   (struct attribute *)attr);
+   if (ret)
+   DRM_ERROR("Per-client sysfs setup failed! (%d)\n", ret);
+
 #ifdef CONFIG_PM
if (HAS_RC6(dev_priv)) {
ret = sysfs_merge_group(>kobj,
@@ -641,6 +710,9 @@ void i915_teardown_sysfs(struct drm_i915_private *dev_priv)
sysfs_unmerge_group(>kobj, _attr_group);
 #endif
 
+   sysfs_remove_file(dev_priv->clients_root,
+ (struct attribute *)_priv->client_stats_attr);
+
if (dev_priv->clients_root)
kobject_put(dev_priv->clients_root);
 }
-- 
2.14.1

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

[Intel-gfx] [PATCH v2 0/6] Per-context and per-client engine busyness

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

I have sent this as part of a larger series back in October '17.

First part of it is implementing a customer requirement to be able to query
engine utilization on their own contexts. This is done in patch 2, which falls
under the standard open source userspace requirements etc.

The rest of the series implements per-client engine utilization stats, something
which I think is quite interesting and missing from our stack at the moment. And
in fact, in the latest other OS update I have noticed they actually can expose
this statistics.

I have prototyped a simple top-like utility which can show you the overall
engine stats (data coming from recently merged PMU), and then using the sysfs
API from this series a sorted breakdown of currently running clients. Output of
that looks like this:

  rcs0:  88.89% busy (  0.27 qd),   0.00% wait,   0.00% sema
  bcs0:  27.50% busy (  0.00 qd),   0.00% wait,   0.00% sema
  vcs0:  86.75% busy (  0.00 qd),   0.00% wait,   0.00% sema
 vecs0:   0.00% busy (  0.00 qd),   0.00% wait,   0.00% sema

 gem_wsim[ 21806]:  rcs0:  43.18%  bcs0:  27.52%  vcs0:  86.80%  vecs0: 
  0.00%
 Xorg[ 21451]:  rcs0:  33.60%  bcs0:   0.00%  vcs0:   0.00%  vecs0: 
  0.00%
  chromium-browse[ 21670]:  rcs0:  12.16%  bcs0:   0.00%  vcs0:   0.00%  vecs0: 
  0.00%
 Xorg[ 21451]:  rcs0:   0.00%  bcs0:   0.00%  vcs0:   0.00%  vecs0: 
  0.00%
xfwm4[ 21506]:  rcs0:   0.00%  bcs0:   0.00%  vcs0:   0.00%  vecs0: 
  0.00%

Patch series needs some more work, for instance the summation of busyness per-
client is not the most efficient, standard debugging and so, but seems to work
reasonably well so far.

What is also possible to do on top of this series, is to extend our current PMU
interface to allow per-task profiling via perf tool as well. I have started
implementing that at one point and could go back to it.

Tvrtko Ursulin (6):
  drm/i915: Track per-context engine busyness
  drm/i915: Allow clients to query own per-engine busyness
  drm/i915: Expose list of clients in sysfs
  drm/i915: Update client name on context create
  drm/i915: Expose per-engine client busyness
  drm/i915: Add sysfs toggle to enable per-client engine stats

 drivers/gpu/drm/i915/i915_drv.h |  24 +
 drivers/gpu/drm/i915/i915_gem.c | 178 ++--
 drivers/gpu/drm/i915/i915_gem_context.c |  56 +-
 drivers/gpu/drm/i915/i915_gem_context.h |   6 ++
 drivers/gpu/drm/i915/i915_sysfs.c   |  80 ++
 drivers/gpu/drm/i915/intel_engine_cs.c  |  32 ++
 drivers/gpu/drm/i915/intel_lrc.c|  14 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.h |  50 +++--
 include/uapi/drm/i915_drm.h |  11 +-
 9 files changed, 427 insertions(+), 24 deletions(-)

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

[Intel-gfx] [PATCH 1/6] drm/i915: Track per-context engine busyness

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Some customers want to know how much of the GPU time are their clients
using in order to make dynamic load balancing decisions.

With the hooks already in place which track the overall engine busyness,
we can extend that slightly to split that time between contexts.

v2: Fix accounting for tail updates.
v3: Rebase.
v4: Mark currently running contexts as active on stats enable.

Signed-off-by: Tvrtko Ursulin 
Cc: gordon.ke...@intel.com
---
 drivers/gpu/drm/i915/i915_gem_context.h |  5 
 drivers/gpu/drm/i915/intel_engine_cs.c  | 32 +
 drivers/gpu/drm/i915/intel_lrc.c| 14 +
 drivers/gpu/drm/i915/intel_ringbuffer.h | 50 +
 4 files changed, 90 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.h 
b/drivers/gpu/drm/i915/i915_gem_context.h
index 4bfb72f8e1cb..0ce8b9bf0f32 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -157,6 +157,11 @@ struct i915_gem_context {
u32 *lrc_reg_state;
u64 lrc_desc;
int pin_count;
+   struct {
+   bool active;
+   ktime_t start;
+   ktime_t total;
+   } stats;
} engine[I915_NUM_ENGINES];
 
/** ring_size: size for allocating the per-engine ring buffer */
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index d572b18d39eb..9907ceedfa90 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1966,6 +1966,16 @@ int intel_enable_engine_stats(struct intel_engine_cs 
*engine)
 
engine->stats.enabled_at = ktime_get();
 
+   /* Mark currently running context as active. */
+   if (port_isset(port)) {
+   struct drm_i915_gem_request *req = port_request(port);
+   struct intel_context *ce =
+   >ctx->engine[engine->id];
+
+   ce->stats.start = engine->stats.enabled_at;
+   ce->stats.active = true;
+   }
+
/* XXX submission method oblivious? */
while (num_ports-- && port_isset(port)) {
engine->stats.active++;
@@ -2038,6 +2048,28 @@ void intel_disable_engine_stats(struct intel_engine_cs 
*engine)
spin_unlock_irqrestore(>stats.lock, flags);
 }
 
+ktime_t intel_context_engine_get_busy_time(struct i915_gem_context *ctx,
+  struct intel_engine_cs *engine)
+{
+   struct intel_context *ce;
+   unsigned long flags;
+   ktime_t total;
+
+   ce = >engine[engine->id];
+
+   spin_lock_irqsave(>stats.lock, flags);
+
+   total = ce->stats.total;
+
+   if (ce->stats.active)
+   total = ktime_add(total,
+ ktime_sub(ktime_get(), ce->stats.start));
+
+   spin_unlock_irqrestore(>stats.lock, flags);
+
+   return total;
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftests/mock_engine.c"
 #endif
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 24ce781d39b7..a82ad5da6090 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -380,16 +380,19 @@ execlists_context_status_change(struct 
drm_i915_gem_request *rq,
 }
 
 static inline void
-execlists_context_schedule_in(struct drm_i915_gem_request *rq)
+execlists_context_schedule_in(struct drm_i915_gem_request *rq,
+ unsigned int port)
 {
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
-   intel_engine_context_in(rq->engine);
+   intel_engine_context_in(rq->engine,
+   >ctx->engine[rq->engine->id],
+   port == 0);
 }
 
 static inline void
 execlists_context_schedule_out(struct drm_i915_gem_request *rq)
 {
-   intel_engine_context_out(rq->engine);
+   intel_engine_context_out(rq->engine, >ctx->engine[rq->engine->id]);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
 }
 
@@ -442,7 +445,7 @@ static void execlists_submit_ports(struct intel_engine_cs 
*engine)
if (rq) {
GEM_BUG_ON(count > !n);
if (!count++)
-   execlists_context_schedule_in(rq);
+   execlists_context_schedule_in(rq, n);
port_set([n], port_pack(rq, count));
desc = execlists_update_context(rq);
GEM_DEBUG_EXEC(port[n].context_id = 
upper_32_bits(desc));
@@ -703,7 +706,8 @@ execlists_cancel_port_requests(struct 
intel_engine_execlists * const execlists)
struct