Re: [Intel-gfx] [PATCH 2/8] drm/i915/xehp: CCS shares the render reset domain
On 08/09/2021 21:23, Matt Roper wrote: On Wed, Sep 08, 2021 at 11:07:07AM +0100, Tvrtko Ursulin wrote: On 07/09/2021 18:19, Matt Roper wrote: The reset domain is shared between render and all compute engines, so resetting one will affect the others. Note: Before performing a reset on an RCS or CCS engine, the GuC will attempt to preempt-to-idle the other non-hung RCS/CCS engines to avoid impacting other clients (since some shared modules will be reset). If other engines are executing non-preemptable workloads, the impact is unavoidable and some work may be lost. Since here it talks about engine reset, should this patch add warning if same is attempted by i915 on a GuC platform - to document it is not Did you mean "on a *non* GuC platform" here? We aren't going to have compute engine support on any platforms where GuC submission isn't the default operating model, so the only way to get compute engines + execlist submission is to force an override via module parameters (e.g., enable_guc=0). Doing so will taint the kernel, so I think the current consensus from offline discussion is that the user has already put themselves into a configuration where it's easier than usual to shoot themselves in the foot; it's not too much different than the kind of trouble a user could get themselves into if they loaded the driver with hangcheck disabled or something. Yes I meant non GuC. :) Okay..ish, although I think an explicit warn would still be better. Because it is one thing to taint and another to actively allow something which we know cannot work. Unless we could hide the CCS engine until GuC gets loaded, which would make i915.enable_guc=0 safe. Hm.. should be doable actually to skip intel_engine_add_user in the engine init phase and do the CCS ones after GuC has been loaded. Would that make sense? Regards, Tvrtko implemented/supported? Or perhaps later in the series, or future series works better. Reviewed-by: Tvrtko Ursulin Regards, Tvrtko Bspec: 52549 Original-patch-by: Michel Thierry Cc: Tvrtko Ursulin Cc: Vinay Belgaumkar Signed-off-by: Daniele Ceraolo Spurio Signed-off-by: Aravind Iddamsetty Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_reset.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c index 91200c43951f..30598c1d070c 100644 --- a/drivers/gpu/drm/i915/gt/intel_reset.c +++ b/drivers/gpu/drm/i915/gt/intel_reset.c @@ -507,6 +507,10 @@ static int gen11_reset_engines(struct intel_gt *gt, [VECS1] = GEN11_GRDOM_VECS2, [VECS2] = GEN11_GRDOM_VECS3, [VECS3] = GEN11_GRDOM_VECS4, + [CCS0] = GEN11_GRDOM_RENDER, + [CCS1] = GEN11_GRDOM_RENDER, + [CCS2] = GEN11_GRDOM_RENDER, + [CCS3] = GEN11_GRDOM_RENDER, }; struct intel_engine_cs *engine; intel_engine_mask_t tmp;
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915: rename debugfs_gt files (rev2)
== Series Details == Series: series starting with [1/4] drm/i915: rename debugfs_gt files (rev2) URL : https://patchwork.freedesktop.org/series/94489/ State : warning == Summary == $ dim checkpatch origin/drm-tip 432bfa5f078a drm/i915: rename debugfs_gt files -:168: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #168: rename from drivers/gpu/drm/i915/gt/debugfs_gt.c total: 0 errors, 1 warnings, 0 checks, 340 lines checked 3a81fa262389 drm/i915: rename debugfs_engines files -:33: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #33: deleted file mode 100644 total: 0 errors, 1 warnings, 0 checks, 66 lines checked 51f63f32325f drm/i915: rename debugfs_gt_pm files -:33: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #33: deleted file mode 100644 total: 0 errors, 1 warnings, 0 checks, 68 lines checked 10a81e9deb43 drm/i915: deduplicate frequency dump on debugfs
[Intel-gfx] [PATCH v2] kernel/locking: Add context to ww_mutex_trylock.
Op 09-09-2021 om 10:22 schreef Peter Zijlstra:
> On Thu, Sep 09, 2021 at 07:38:06AM +0200, Maarten Lankhorst wrote:
>
>>> You'll need a similar hunk in ww_rt_mutex.c
>> What tree has that file?
> Linus' tree should have it. Per commit:
>
> f8635d509d80 ("locking/ww_mutex: Implement rtmutex based ww_mutex API
> functions")
Ah yeah, it seems the drm integration tree missed it.
I only compile tested it against PREEMPT_RT, though it seems locking_selftests
and fs/inode.c don't build correctly for me.
Improved patch below.
Also hopefully addressed Daniel's concerns.
---8<--
>From d7e867f26b7e2553b0e5b9b5b87a284467b85846 Mon Sep 17 00:00:00 2001
From: Maarten Lankhorst
Date: Fri, 3 Sep 2021 10:59:49 +0200
Subject: [PATCH] kernel/locking: Add context to ww_mutex_trylock, v2.
i915 will soon gain an eviction path that trylock a whole lot of locks
for eviction, getting dmesg failures like below:
BUG: MAX_LOCK_DEPTH too low!
turning off the locking correctness validator.
depth: 48 max: 48!
48 locks held by i915_selftest/5776:
#0: 888101a79240 (>mutex){}-{3:3}, at: __driver_attach+0x88/0x160
#1: c99778c0 (reservation_ww_class_acquire){+.+.}-{0:0}, at:
i915_vma_pin.constprop.63+0x39/0x1b0 [i915]
#2: 88800cf74de8 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
i915_vma_pin.constprop.63+0x5f/0x1b0 [i915]
#3: 88810c7f9e38 (>mutex/1){+.+.}-{3:3}, at:
i915_vma_pin_ww+0x1c4/0x9d0 [i915]
#4: 88810bad5768 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
i915_gem_evict_something+0x110/0x860 [i915]
#5: 88810bad60e8 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
i915_gem_evict_something+0x110/0x860 [i915]
...
#46: 88811964d768 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
i915_gem_evict_something+0x110/0x860 [i915]
#47: 88811964e0e8 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
i915_gem_evict_something+0x110/0x860 [i915]
INFO: lockdep is turned off.
Fixing eviction to nest into ww_class_acquire is a high priority,
but it requires a rework of the entire driver, which can only be
done one step at a time.
As an intermediate solution, add an acquire context to ww_mutex_trylock,
which allows us to do proper nesting annotations on the trylocks, making
the above lockdep splat disappear.
This is also useful in regulator_lock_nested, which may avoid dropping
regulator_nesting_mutex in the uncontended path, so use it there.
TTM may be another user for this, where we could lock a buffer in a
fastpath with list locks held, without dropping all locks we hold.
Changes since v1:
- Rebase on top of the ww_rt_mutex rework.
- Add extern to ww_mutex_trylock header definition.
- Expand commit message slightly.
Signed-off-by: Maarten Lankhorst
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
Cc: Waiman Long
Cc: Boqun Feng
Cc: Liam Girdwood
Cc: Mark Brown
Cc: linux-ker...@vger.kernel.org
---
drivers/gpu/drm/drm_modeset_lock.c | 2 +-
drivers/regulator/core.c | 2 +-
include/linux/dma-resv.h | 2 +-
include/linux/ww_mutex.h | 15 +-
kernel/locking/mutex.c | 38 +
kernel/locking/test-ww_mutex.c | 86 ++
kernel/locking/ww_rt_mutex.c | 12 +
lib/locking-selftest.c | 2 +-
8 files changed, 121 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index fcfe1a03c4a1..bf8a6e823a15 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -248,7 +248,7 @@ static inline int modeset_lock(struct drm_modeset_lock
*lock,
if (ctx->trylock_only) {
lockdep_assert_held(>ww_ctx);
- if (!ww_mutex_trylock(>mutex))
+ if (!ww_mutex_trylock(>mutex, NULL))
return -EBUSY;
else
return 0;
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index ca6caba8a191..f4d441b1a8bf 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -145,7 +145,7 @@ static inline int regulator_lock_nested(struct
regulator_dev *rdev,
mutex_lock(_nesting_mutex);
- if (ww_ctx || !ww_mutex_trylock(>mutex)) {
+ if (!ww_mutex_trylock(>mutex, ww_ctx)) {
if (rdev->mutex_owner == current)
rdev->ref_cnt++;
else
diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
index 9100dd3dc21f..5de7956818a5 100644
--- a/include/linux/dma-resv.h
+++ b/include/linux/dma-resv.h
@@ -262,7 +262,7 @@ static inline int dma_resv_lock_slow_interruptible(struct
dma_resv *obj,
*/
static inline bool __must_check dma_resv_trylock(struct dma_resv *obj)
{
- return ww_mutex_trylock(>lock);
+ return ww_mutex_trylock(>lock, NULL);
}
/**
diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h
index 29db736af86d..bb763085479a 100644
--- a/include/linux/ww_mutex.h
+++
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: rename debugfs_gt files (rev2)
== Series Details ==
Series: series starting with [1/4] drm/i915: rename debugfs_gt files (rev2)
URL : https://patchwork.freedesktop.org/series/94489/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10565 -> Patchwork_20998
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20998/index.html
Known issues
Here are the changes found in Patchwork_20998 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u: NOTRUN -> [SKIP][1] ([fdo#109271]) +27 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20998/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
* igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u: NOTRUN -> [WARN][2] ([i915#3718])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20998/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827]) +8
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20998/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
Possible fixes
* igt@i915_selftest@live@gt_pm:
- {fi-jsl-1}: [DMESG-FAIL][4] ([i915#1886]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20998/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#3718]: https://gitlab.freedesktop.org/drm/intel/issues/3718
Participating hosts (47 -> 38)
--
Missing(9): fi-ilk-m540 bat-adls-5 bat-dg1-6 fi-tgl-1115g4 fi-bsw-cyan
bat-adlp-4 fi-ctg-p8600 fi-bdw-samus bat-jsl-1
Build changes
-
* Linux: CI_DRM_10565 -> Patchwork_20998
CI-20190529: 20190529
CI_DRM_10565: 8c3cd60dcfa81a649b14f0705eb5e5c9336f1881 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6201: be0d02ff0775235ead63ccb1e3a1e8c10f0209cf @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20998: 10a81e9deb43c47a8324b3f8aee2efe8c2c7bdbe @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
10a81e9deb43 drm/i915: deduplicate frequency dump on debugfs
51f63f32325f drm/i915: rename debugfs_gt_pm files
3a81fa262389 drm/i915: rename debugfs_engines files
432bfa5f078a drm/i915: rename debugfs_gt files
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20998/index.html
Re: [Intel-gfx] [PATCH] kernel/locking: Add context to ww_mutex_trylock.
On Thu, Sep 09, 2021 at 07:38:06AM +0200, Maarten Lankhorst wrote:
> > You'll need a similar hunk in ww_rt_mutex.c
>
> What tree has that file?
Linus' tree should have it. Per commit:
f8635d509d80 ("locking/ww_mutex: Implement rtmutex based ww_mutex API
functions")
Re: [Intel-gfx] [PATCH 00/23] i915/display: split and constify vtable (v3)
Hi, > -Original Message- > From: Intel-gfx On Behalf Of Dave > Airlie > Sent: torstai 9. syyskuuta 2021 4.53 > To: intel-gfx@lists.freedesktop.org > Cc: jani.nik...@linux.intel.com > Subject: [Intel-gfx] [PATCH 00/23] i915/display: split and constify vtable > (v3) > > (v3 just adds some missing ,) > > Details below, I've taken all the review feedback (thanks Jani). > I added 3 patches moving to wrappers before refactoring, and one other patch > is > unreviewed (07) but the main comment was wanting the wrappers. > > Jani if you are happy with the final 4 patches can you land this series, I > don't think I > have drm-intel commit rights. Not right Jani to answer but in my view CI in not healthy at all if looking from: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20995/index.html? See taints in the boot. > > v1: > This is orthogonal to my display ptr refactoring and should probably be > applied first. > > The display funcs vtable was a bit of mess, lots of intermixing of internal > display > functionality and interfaces to watermarks/irqs. > > It's also considered not great security practice to leave writeable function > pointers > around for exploits to get into. > > This series attempts to address both problems, first there are a few > cleanups, then it > splits the function table into multiple pieces. > Some of the splits might be bikesheds but I think we should apply first and > merge > things later if there is good reason. > > The second half converts all the vtables to static const structs, I've used > macros in > some of them to make it less messy, the cdclk one is probably the worst one. > > v2: > Added some patches adding wrappers around things before refactoring them as > suggested by Jani. > Fixed up all struct names as suggested by Jani. > Added s-o-b lines > Added commit msgs. > > v3: > added missing , (Jani) > > Dave. >
Re: [Intel-gfx] [PATCH v7 15/17] drm/i915/pxp: add pxp debugfs
I dont see any issues except a couple of nits.
Reviewed-by : Alan Previn
...alan
On Fri, 2021-08-27 at 18:27 -0700, Daniele Ceraolo Spurio wrote:
> 2 debugfs files, one to query the current status of the pxp session and one
> to trigger an invalidation for testing.
>
> Signed-off-by: Daniele Ceraolo Spurio
> ---
> drivers/gpu/drm/i915/Makefile| 1 +
> drivers/gpu/drm/i915/gt/debugfs_gt.c | 2 +
> drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 78
> drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h | 21 ++
> 4 files changed, 102 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 6f6cbbe98b96..9a44d6f01e3b 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -284,6 +284,7 @@ i915-y += i915_perf.o
> i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp.o \
> pxp/intel_pxp_cmd.o \
> + pxp/intel_pxp_debugfs.o \
> pxp/intel_pxp_irq.o \
> pxp/intel_pxp_pm.o \
> pxp/intel_pxp_session.o \
> diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt.c
> b/drivers/gpu/drm/i915/gt/debugfs_gt.c
> index 591eb60785db..c27847ddb796 100644
> --- a/drivers/gpu/drm/i915/gt/debugfs_gt.c
> +++ b/drivers/gpu/drm/i915/gt/debugfs_gt.c
> @@ -9,6 +9,7 @@
> #include "debugfs_gt.h"
> #include "debugfs_gt_pm.h"
> #include "intel_sseu_debugfs.h"
> +#include "pxp/intel_pxp_debugfs.h"
> #include "uc/intel_uc_debugfs.h"
> #include "i915_drv.h"
>
> @@ -28,6 +29,7 @@ void debugfs_gt_register(struct intel_gt *gt)
> intel_sseu_debugfs_register(gt, root);
>
> intel_uc_debugfs_register(>uc, root);
> + intel_pxp_debugfs_register(>pxp, root);
> }
>
> void intel_gt_debugfs_register_files(struct dentry *root,
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> new file mode 100644
> index ..a26e4396ba6c
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> @@ -0,0 +1,78 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2021 Intel Corporation
> + */
> +
> +#include
> +#include
> +
> +#include "gt/debugfs_gt.h"
> +#include "pxp/intel_pxp.h"
> +#include "pxp/intel_pxp_irq.h"
> +#include "i915_drv.h"
> +
> +static int pxp_info_show(struct seq_file *m, void *data)
> +{
> + struct intel_pxp *pxp = m->private;
> + struct drm_printer p = drm_seq_file_printer(m);
> + bool enabled = intel_pxp_is_enabled(pxp);
> +
> + if (!enabled) {
> + drm_printf(, "pxp disabled\n");
> + return 0;
> + }
> +
> + drm_printf(, "active: %s\n", yesno(intel_pxp_is_active(pxp)));
> + drm_printf(, "instance counter: %u\n", pxp->key_instance);
> +
> + return 0;
> +}
> +DEFINE_GT_DEBUGFS_ATTRIBUTE(pxp_info);
> +
> +static int pxp_inval_get(void *data, u64 *val)
> +{
> + /* nothing to read */
> + return -EPERM;
> +}
> +
> +static int pxp_inval_set(void *data, u64 val)
> +{
> + struct intel_pxp *pxp = data;
> + struct intel_gt *gt = pxp_to_gt(pxp);
> +
> + if (!intel_pxp_is_active(pxp))
> + return -ENODEV;
> +
> + /* simulate an invalidation interrupt */
> + spin_lock_irq(>irq_lock);
> + intel_pxp_irq_handler(pxp,
> GEN12_DISPLAY_PXP_STATE_TERMINATED_INTERRUPT);
> + spin_unlock_irq(>irq_lock);
> +
> + if (!wait_for_completion_timeout(>termination,
> + msecs_to_jiffies(100)))
> + return -ETIMEDOUT;
> +
> + return 0;
> +}
> +
> +DEFINE_SIMPLE_ATTRIBUTE(pxp_inval_fops, pxp_inval_get, pxp_inval_set,
> "%llx\n");
> +void intel_pxp_debugfs_register(struct intel_pxp *pxp, struct dentry
> *gt_root)
> +{
> + static const struct debugfs_gt_file files[] = {
> + { "info", _info_fops, NULL },
> + { "invalidate", _inval_fops, NULL },
NIT only: consider naming to "invalidate_display" or "display_inval" since we
are using this to trigger
display pxp teardown specific irq code path.
> + };
> + struct dentry *root;
> +
> + if (!gt_root)
> + return;
> +
> + if (!HAS_PXP((pxp_to_gt(pxp)->i915)))
> + return;
> +
> + root = debugfs_create_dir("pxp", gt_root);
> + if (IS_ERR(root))
> + return;
> +
> + intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), pxp);
> +}
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h
> new file mode 100644
> index ..3b7454d838e9
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2020 Intel Corporation
NIT - 2021
> + */
> +
> +#ifndef __INTEL_PXP_DEBUGFS_H__
> +#define __INTEL_PXP_DEBUGFS_H__
> +
> +struct intel_pxp;
> +struct
Re: [Intel-gfx] [PATCH v2] drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup
On 08/09/2021 18:06, Daniel Vetter wrote: On Thu, Sep 02, 2021 at 04:01:40PM +0100, Tvrtko Ursulin wrote: On 02/09/2021 15:33, Daniel Vetter wrote: On Tue, Aug 31, 2021 at 02:18:15PM +0100, Tvrtko Ursulin wrote: On 31/08/2021 13:43, Daniel Vetter wrote: On Tue, Aug 31, 2021 at 10:15:03AM +0100, Tvrtko Ursulin wrote: On 30/08/2021 09:26, Daniel Vetter wrote: On Fri, Aug 27, 2021 at 03:44:42PM +0100, Tvrtko Ursulin wrote: On 27/08/2021 15:39, Tvrtko Ursulin wrote: From: Tvrtko Ursulin In short this makes i915 work for hybrid setups (DRI_PRIME=1 with Mesa) when rendering is done on Intel dgfx and scanout/composition on Intel igfx. Before this patch the driver was not quite ready for that setup, mainly because it was able to emit a semaphore wait between the two GPUs, which results in deadlocks because semaphore target location in HWSP is neither shared between the two, nor mapped in both GGTT spaces. To fix it the patch adds an additional check to a couple of relevant code paths in order to prevent using semaphores for inter-engine synchronisation between different driver instances. Patch also moves singly used i915_gem_object_last_write_engine to be private in its only calling unit (debugfs), while modifying it to only show activity belonging to the respective driver instance. What remains in this problem space is the question of the GEM busy ioctl. We have a somewhat ambigous comment there saying only status of native fences will be reported, which could be interpreted as either i915, or native to the drm fd. For now I have decided to leave that as is, meaning any i915 instance activity continues to be reported. v2: * Avoid adding rq->i915. (Chris) Signed-off-by: Tvrtko Ursulin Can't we just delete semaphore code and done? - GuC won't have it - media team benchmarked on top of softpin media driver, found no difference You have S-curve for saturated workloads or something else? How thorough and which media team I guess. From memory it was a nice win for some benchmarks (non-saturated ones), but as I have told you previously, we haven't been putting numbers in commit messages since it wasn't allowed. I may be able to dig out some more details if I went trawling through GEM channel IRC logs, although probably not the actual numbers since those were usually on pastebin. Or you go an talk with Chris since he probably remembers more details. Or you just decide you don't care and remove it. I wouldn't do that without putting the complete story in writing, but it's your call after all. Media has also changed, they're not using relocations anymore. Meaning you think it changes the benchmarking story? When coupled with removal of GPU relocations then possibly yes. Unless there's solid data performance tuning of any kind that gets in the way simply needs to be removed. Yes this is radical, but the codebase is in a state to require this. So either way we'd need to rebenchmark this if it's really required. Also Therefore can you share what benchmarks have been done or is it secret? As said, I think the non-saturated case was the more interesting one here. if we really need this code still someone needs to fix the design, the current code is making layering violations an art form. Anyway, without the debugfs churn it is more or less two line patch to fix igfx + dgfx hybrid setup. So while mulling it over this could go in. I'd just refine it to use a GGTT check instead of GT. And unless DG1 ends up being GuC only. The minimal robust fix here is imo to stop us from upcasting dma_fence to i915_request if it's not for our device. Not sprinkle code here into the semaphore code. We shouldn't even get this far with foreign fences. Device check does not work for multi-tile. It was one of my earlier attempts before I realized the problem. You'll see v3 which I think handles all the cases. There is no hw semaphores on multi-tile. You mean because of GuC? Okay, there may not be after bringup has been done. In which case an assert is needed somewhere just in case, if you are adamant not to accept this fix. It may indeed not matter hugely outside of the current transition period since I spotted patches to enable GuC on DG1. But then again it is trivial and fixes current pains for more than just me. But there _is_ a lot more going on than just hw semaphores that spawn driver instances. Like priority boosting, clock boosting, and all kinds of other things. I really dont' think it's very robust if we play whack-a-mole here with things leaking. You mean span not spawn? I audited those and they looks good to me. AFAIR scheduling was in fact designed with a global lock just so that works. Plus the cases you mention end up not holding pointers to "foreign" instances anyway, they just do priority inheritance. Which is probably nice not to lose if not unavoidable. Yup span. I just think the defensive approach is better, especially since we're planning to rework the
[Intel-gfx] [PULL] drm-misc-next-fixes
drm-misc-next-fixes-2021-09-09: drm-misc-next-fixes for v5.15: - Make some dma-buf config options depend on DMA_SHARED_BUFFER. - Handle multiplication overflow of fbdev xres/yres in the core. The following changes since commit efcefc7127290e7e9fa98dea029163ad8eda8fb3: drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource (2021-08-31 10:48:26 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2021-09-09 for you to fetch changes up to 8c28051cdcbe9dfcec6bd0a4709d67a09df6edae: fbmem: don't allow too huge resolutions (2021-09-08 18:52:04 +0200) drm-misc-next-fixes for v5.15: - Make some dma-buf config options depend on DMA_SHARED_BUFFER. - Handle multiplication overflow of fbdev xres/yres in the core. Geert Uytterhoeven (3): dma-buf: DMABUF_MOVE_NOTIFY should depend on DMA_SHARED_BUFFER dma-buf: DMABUF_DEBUG should depend on DMA_SHARED_BUFFER dma-buf: DMABUF_SYSFS_STATS should depend on DMA_SHARED_BUFFER Tetsuo Handa (1): fbmem: don't allow too huge resolutions drivers/dma-buf/Kconfig | 4 +++- drivers/video/fbdev/core/fbmem.c | 6 ++ 2 files changed, 9 insertions(+), 1 deletion(-)
Re: [Intel-gfx] [PULL] drm-misc-fixes
On Thu, Sep 9, 2021 at 5:35 AM Dave Airlie wrote: > > On Thu, 9 Sept 2021 at 03:44, Thomas Zimmermann wrote: > > > > Hi Dave and Daniel, > > > > here's this week's PR for drm-misc-fixes. One patch is a potential deadlock > > in TTM, the other enables an additional plane in kmb. I'm slightly unhappy > > that the latter one ended up in -fixes as it's not a bugfix AFAICT. > > To avoid messy merge window, I'm not pulling this until after rc1 > unless there is some major reason? Christian misplaced a ttm fix, so we really want this. Maybe cherry-pick to drm-next and then drm-misc-fixes gets rebased instead. And yeah I dunno what do with our conflicts around merge window, maybe we're letting trees diverge a bit too much. -Daniel > > the current drm-next doesn't have v5.14 in it, and the merge is rather > ugly right now. > > (maybe I should always pull it in before sending to Linus to avoid > this in future). > > Dave. -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/hdcp: HDCP2.2 MST dock fixes (rev8)
On 2021-08-30 at 21:11:29 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/hdcp: HDCP2.2 MST dock fixes (rev8) > URL : https://patchwork.freedesktop.org/series/93570/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_10537_full -> Patchwork_20921_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_20921_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_20921_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. > > > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_20921_full: > > ### Piglit changes ### > > Possible regressions > > * spec@!opengl 3.0@required-renderbuffer-attachment-formats (NEW): > - pig-glk-j5005: NOTRUN -> [INCOMPLETE][1] +2 similar issues >[1]: None Above failures not related to HDCP failures. Pushed the series to drm-intel-next. Thanks for patch. Br, Anshuman Gupta. > > > New tests > - > > New tests have been introduced between CI_DRM_10537_full and > Patchwork_20921_full: > > ### New Piglit tests (3) ### > > * spec@!opengl 3.0@render-integer: > - Statuses : 1 incomplete(s) > - Exec time: [0.0] s > > * spec@!opengl 3.0@required-renderbuffer-attachment-formats: > - Statuses : 1 incomplete(s) > - Exec time: [0.0] s > > * spec@!opengl 3.0@required-sized-texture-formats: > - Statuses : 1 incomplete(s) > - Exec time: [0.0] s > > > > Known issues > > > Here are the changes found in Patchwork_20921_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_create@create-massive: > - shard-snb: NOTRUN -> [DMESG-WARN][2] ([i915#3002]) >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-snb5/igt@gem_cre...@create-massive.html > > * igt@gem_ctx_isolation@preservation-s3@vcs0: > - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-apl6/igt@gem_ctx_isolation@preservation...@vcs0.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-apl2/igt@gem_ctx_isolation@preservation...@vcs0.html > > * igt@gem_ctx_persistence@smoketest: > - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +5 > similar issues >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-snb6/igt@gem_ctx_persiste...@smoketest.html > > * igt@gem_eio@in-flight-contexts-immediate: > - shard-iclb: [PASS][6] -> [TIMEOUT][7] ([i915#3070]) >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-iclb3/igt@gem_...@in-flight-contexts-immediate.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-iclb2/igt@gem_...@in-flight-contexts-immediate.html > > * igt@gem_eio@unwedge-stress: > - shard-tglb: [PASS][8] -> [TIMEOUT][9] ([i915#2369] / > [i915#3063] / [i915#3648]) >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-tglb8/igt@gem_...@unwedge-stress.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-tglb2/igt@gem_...@unwedge-stress.html > - shard-snb: NOTRUN -> [FAIL][10] ([i915#3354]) >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-snb5/igt@gem_...@unwedge-stress.html > > * igt@gem_exec_fair@basic-deadline: > - shard-apl: NOTRUN -> [FAIL][11] ([i915#2846]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-apl6/igt@gem_exec_f...@basic-deadline.html > > * igt@gem_exec_fair@basic-none-vip@rcs0: > - shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar > issue >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-tglb6/igt@gem_exec_fair@basic-none-...@rcs0.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-tglb6/igt@gem_exec_fair@basic-none-...@rcs0.html > > * igt@gem_exec_fair@basic-pace-share@rcs0: > - shard-glk: [PASS][14] -> [FAIL][15] ([i915#2842]) +1 similar > issue >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html > > * igt@gem_exec_fair@basic-pace@vecs0: > - shard-iclb: [PASS][16] -> [FAIL][17] ([i915#2842]) >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-iclb8/igt@gem_exec_fair@basic-p...@vecs0.html >[17]: >
Re: [Intel-gfx] [PATCH 03/23] drm/i915/wm: provide wrappers around watermark vfuncs calls
On Thu, 09 Sep 2021, Dave Airlie wrote:
> From: Dave Airlie
>
> This moves one wrapper from the pm->display side, and creates
> wrappers for all the others, this should simplify things later.
>
> One thing to note is that the code checks the existance of some
> of these ptrs, so the wrappers are a bit complicated by that.
I like moving the complications within the wrappers to make the overall
code tidier.
A bug crept in, see inline.
>
> Suggested by Jani.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 187 ---
> drivers/gpu/drm/i915/intel_pm.c | 39
> drivers/gpu/drm/i915/intel_pm.h | 1 -
> 3 files changed, 123 insertions(+), 104 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index e62f8317cbda..3d8afa9f3237 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -126,6 +126,101 @@ static void ilk_pfit_enable(const struct
> intel_crtc_state *crtc_state);
> static void intel_modeset_setup_hw_state(struct drm_device *dev,
>struct drm_modeset_acquire_ctx *ctx);
>
> +
> +/**
> + * intel_update_watermarks - update FIFO watermark values based on current
> modes
> + * @crtc: the #intel_crtc on which to compute the WM
> + *
> + * Calculate watermark values for the various WM regs based on current mode
> + * and plane configuration.
> + *
> + * There are several cases to deal with here:
> + * - normal (i.e. non-self-refresh)
> + * - self-refresh (SR) mode
> + * - lines are large relative to FIFO size (buffer can hold up to 2)
> + * - lines are small relative to FIFO size (buffer can hold more than 2
> + * lines), so need to account for TLB latency
> + *
> + * The normal calculation is:
> + * watermark = dotclock * bytes per pixel * latency
> + * where latency is platform & configuration dependent (we assume pessimal
> + * values here).
> + *
> + * The SR calculation is:
> + * watermark = (trunc(latency/line time)+1) * surface width *
> + * bytes per pixel
> + * where
> + * line time = htotal / dotclock
> + * surface width = hdisplay for normal plane and 64 for cursor
> + * and latency is assumed to be high, as above.
> + *
> + * The final value programmed to the register should always be rounded up,
> + * and include an extra 2 entries to account for clock crossings.
> + *
> + * We don't use the sprite, so we can ignore that. And on Crestline we have
> + * to set the non-SR watermarks to 8.
> + */
> +static void intel_update_watermarks(struct drm_i915_private *dev_priv)
> +{
> + if (dev_priv->display.update_wm)
> + dev_priv->display.update_wm(dev_priv);
> +}
> +
> +static int intel_compute_pipe_wm(struct intel_atomic_state *state,
> + struct intel_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + if (dev_priv->display.compute_pipe_wm)
> + return dev_priv->display.compute_pipe_wm(state, crtc);
> + return 0;
> +}
> +
> +static int intel_compute_intermediate_wm(struct intel_atomic_state *state,
> + struct intel_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + if (drm_WARN_ON(_priv->drm,
> + !dev_priv->display.compute_pipe_wm))
> + return 0;
> + if (dev_priv->display.compute_pipe_wm)
> + return dev_priv->display.compute_intermediate_wm(state, crtc);
> + return 0;
The original code warns if compute_intermediate_wm is set without
compute_pipe_wm.
This one warns unconditionally and then probably copy-paste fail in the
call, checking for compute_pipe_wm and then calling
compute_intermediate_wm.
With that fixed,
Reviewed-by: Jani Nikula
And the v2 can be a reply to this one patch.
PS. A follow-up might move the warn from the wrapper to the end of
intel_init_pm() with the condition
compute_intermediate_wm && !compute_pipe_wm
There's no point in "gracefully" warning and handling this every single
call in the wrapper, when it's an initialization error. Might just use
nop_funcs there. Anyway, let's not extend this series any more.
> +}
> +
> +static bool intel_initial_watermarks(struct intel_atomic_state *state,
> + struct intel_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + if (dev_priv->display.initial_watermarks) {
> + dev_priv->display.initial_watermarks(state, crtc);
> + return true;
> + }
> + return false;
> +}
> +
> +static void intel_atomic_update_watermarks(struct intel_atomic_state *state,
> +struct intel_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv =
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915: rename debugfs_gt files (rev2)
== Series Details ==
Series: series starting with [1/4] drm/i915: rename debugfs_gt files (rev2)
URL : https://patchwork.freedesktop.org/series/94489/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10565_full -> Patchwork_20998_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_20998_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20998_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_20998_full:
### IGT changes ###
Possible regressions
* igt@gem_exec_suspend@basic-s3:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-tglb1/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20998/shard-tglb7/igt@gem_exec_susp...@basic-s3.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs:
- shard-iclb: [PASS][3] -> [SKIP][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-iclb6/igt@kms_flip_scaled_...@flip-32bpp-ytile-to-32bpp-ytileccs.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20998/shard-iclb2/igt@kms_flip_scaled_...@flip-32bpp-ytile-to-32bpp-ytileccs.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_eio@hibernate:
- {shard-rkl}:[TIMEOUT][5] ([i915#3811]) -> [FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-rkl-5/igt@gem_...@hibernate.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20998/shard-rkl-2/igt@gem_...@hibernate.html
Known issues
Here are the changes found in Patchwork_20998_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@smoketest:
- shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20998/shard-snb2/igt@gem_ctx_persiste...@smoketest.html
* igt@gem_eio@in-flight-contexts-10ms:
- shard-iclb: [PASS][8] -> [TIMEOUT][9] ([i915#3070])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-iclb4/igt@gem_...@in-flight-contexts-10ms.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20998/shard-iclb5/igt@gem_...@in-flight-contexts-10ms.html
* igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][10] -> [TIMEOUT][11] ([i915#2369] /
[i915#3063] / [i915#3648])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-tglb3/igt@gem_...@unwedge-stress.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20998/shard-tglb1/igt@gem_...@unwedge-stress.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-glk: [PASS][12] -> [FAIL][13] ([i915#2842])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-glk2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20998/shard-glk2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl: [PASS][14] -> [FAIL][15] ([i915#2842]) +1 similar
issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-kbl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20998/shard-kbl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs1:
- shard-tglb: [PASS][16] -> [FAIL][17] ([i915#2842]) +1 similar
issue
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-tglb3/igt@gem_exec_fair@basic-p...@vcs1.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20998/shard-tglb3/igt@gem_exec_fair@basic-p...@vcs1.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl: [PASS][18] -> [SKIP][19] ([fdo#109271])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20998/shard-kbl3/igt@gem_exec_fair@basic-p...@vecs0.html
* igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- shard-snb: NOTRUN -> [SKIP][20] ([fdo#109271]) +397 similar
issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20998/shard-snb2/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html
* igt@gem_exec_gttfill@all:
- shard-glk: [PASS][21] -> [DMESG-WARN][22] ([i915#118] /
[i915#95]) +1 similar issue
[21]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use Transparent Hugepages when IOMMU is enabled (rev3)
== Series Details ==
Series: drm/i915: Use Transparent Hugepages when IOMMU is enabled (rev3)
URL : https://patchwork.freedesktop.org/series/93122/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10565_full -> Patchwork_21000_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_21000_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_mmap_offset@clear:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/shard-rkl-5/igt@gem_mmap_off...@clear.html
Known issues
Here are the changes found in Patchwork_21000_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-skl: NOTRUN -> [INCOMPLETE][2] ([i915#198])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/shard-skl3/igt@gem_ctx_isolation@preservation...@rcs0.html
* igt@gem_ctx_persistence@smoketest:
- shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +1
similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/shard-snb5/igt@gem_ctx_persiste...@smoketest.html
* igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][4] -> [TIMEOUT][5] ([i915#2369] / [i915#3063]
/ [i915#3648])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-tglb3/igt@gem_...@unwedge-stress.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/shard-tglb1/igt@gem_...@unwedge-stress.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-glk: [PASS][6] -> [FAIL][7] ([i915#2842])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-glk2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/shard-glk3/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][8] ([i915#2842])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html
- shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs1.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) +2 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-tglb8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_render_copy@linear-to-vebox-y-tiled:
- shard-glk: NOTRUN -> [SKIP][13] ([fdo#109271]) +3 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/shard-glk8/igt@gem_render_c...@linear-to-vebox-y-tiled.html
- shard-iclb: NOTRUN -> [SKIP][14] ([i915#768])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/shard-iclb8/igt@gem_render_c...@linear-to-vebox-y-tiled.html
* igt@gem_userptr_blits@dmabuf-unsync:
- shard-tglb: NOTRUN -> [SKIP][15] ([i915#3297])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/shard-tglb6/igt@gem_userptr_bl...@dmabuf-unsync.html
- shard-iclb: NOTRUN -> [SKIP][16] ([i915#3297])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/shard-iclb8/igt@gem_userptr_bl...@dmabuf-unsync.html
* igt@gem_userptr_blits@input-checking:
- shard-apl: NOTRUN -> [DMESG-WARN][17] ([i915#3002]) +1 similar
issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/shard-apl3/igt@gem_userptr_bl...@input-checking.html
- shard-snb: NOTRUN -> [DMESG-WARN][18] ([i915#3002])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/shard-snb2/igt@gem_userptr_bl...@input-checking.html
* igt@gen9_exec_parse@allowed-single:
- shard-skl: [PASS][19] -> [DMESG-WARN][20] ([i915#1436] /
[i915#716])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-skl7/igt@gen9_exec_pa...@allowed-single.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/shard-skl9/igt@gen9_exec_pa...@allowed-single.html
* igt@i915_pm_rpm@system-suspend:
- shard-tglb: [PASS][21] -> [INCOMPLETE][22] ([i915#2411] /
[i915#456]) +1 similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-tglb8/igt@i915_pm_...@system-suspend.html
[22]:
Re: [Intel-gfx] [PATCH] drm/i915/gt: Add separate MOCS table for Gen12 devices other than TGL/RKL
On Thu, Sep 09, 2021 at 05:39:26PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 09, 2021 at 07:29:33AM -0700, Matt Roper wrote:
> > On Thu, Sep 09, 2021 at 04:58:50PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 07, 2021 at 11:19:29AM -0700, Matt Roper wrote:
> > > > On Tue, Sep 07, 2021 at 08:41:06PM +0300, Ville Syrjälä wrote:
> > > > > On Tue, Sep 07, 2021 at 10:27:28AM -0700, Matt Roper wrote:
> > > > > > On Tue, Sep 07, 2021 at 10:46:39PM +0530, Ayaz A Siddiqui wrote:
> > > > > > > MOCS table of TGL/RKL has MOCS[1] set to L3_UC.
> > > > > > > While for other gen12 devices we need to set MOCS[1] as L3_WB,
> > > > > > > So adding a new MOCS table for other gen 12 devices eg. ADL.
> > > > > > >
> > > > > > > Fixes: cfbe5291a189 ("drm/i915/gt: Initialize unused MOCS entries
> > > > > > > with device specific values")
> > > > > > > Cc: Matt Roper
> > > > > > > Signed-off-by: Ayaz A Siddiqui
> > > > > >
> > > > > > Yep, we overlooked that the TGL table still had an explicit entry
> > > > > > for
> > > > > > I915_MOCS_PTE and wasn't just using an implicit 'unused_entries'
> > > > > > lookup
> > > > > > for MOCS[1]. The new table is the same as the TGL table, just with
> > > > > > I915_MOCS_PTE (1) removed.
> > > > >
> > > > > And just how are people planning on handling display cacheability
> > > > > control without a PTE MOCS entry? Is Mesa/etc. already making all
> > > > > external bos uncached on these platforms just in case we might
> > > > > scan out said bo?
> > > >
> > > > MOCS entry 1 has never been considered a valid MOCS table entry on gen12
> > > > platforms (despite the old #define, it's not actually related to PTE,
> > > > display, etc. anymore).
> > >
> > > So can someone finally explain to me how we're supposed to cache
> > > anything that might become a scanout buffer later (eg. window system
> > > buffers)? Or are we just making everything like that UC now, and is
> > > everyone happy with that? Is userspace actually following that?
> >
> > Table entry #1 has never had anything to do with scanout on gen12+. I
> > would assume that UMDs are either using the display entry in the MOCS
> > table (which is 61 on gen12+) or some other UC entry.
>
> If 61 is meant to to be the new PTE entry wy hasn't it been defines as
> such in the code? And I know for a fact that userspace (Mesa) is not
There is no "PTE" entry anymore. But 61 is already documented as
"displayable" in both the spec and the code:
/* HW Special Case (Displayable) */
MOCS_ENTRY(61,
> using entry 61. I think there is a massive communication gap here
> where everyone just seems to assume the other side is doing something.
>
> Could someone actually come up with a clear abi definition for this
> and get all the stakeholders to sign off on it?
The agreement between the i915 team, various userspace teams, Windows
driver team, hardware architects, software architects, and bspec writers
was just completed; that's what triggered the kernel updates here (and
I'm guessing is triggering similar work on the UMD side). It's also why
we held off on removing the force_probe flag on ADL until now since we
couldn't consider enablement of the platform complete until the
agreement and definitions here was finalized.
Matt
>
> --
> Ville Syrjälä
> Intel
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
Re: [Intel-gfx] [PATCH] drm/i915/gt: Add separate MOCS table for Gen12 devices other than TGL/RKL
On Thu, Sep 09, 2021 at 08:00:02AM -0700, Matt Roper wrote:
> On Thu, Sep 09, 2021 at 05:39:26PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 09, 2021 at 07:29:33AM -0700, Matt Roper wrote:
> > > On Thu, Sep 09, 2021 at 04:58:50PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Sep 07, 2021 at 11:19:29AM -0700, Matt Roper wrote:
> > > > > On Tue, Sep 07, 2021 at 08:41:06PM +0300, Ville Syrjälä wrote:
> > > > > > On Tue, Sep 07, 2021 at 10:27:28AM -0700, Matt Roper wrote:
> > > > > > > On Tue, Sep 07, 2021 at 10:46:39PM +0530, Ayaz A Siddiqui wrote:
> > > > > > > > MOCS table of TGL/RKL has MOCS[1] set to L3_UC.
> > > > > > > > While for other gen12 devices we need to set MOCS[1] as L3_WB,
> > > > > > > > So adding a new MOCS table for other gen 12 devices eg. ADL.
> > > > > > > >
> > > > > > > > Fixes: cfbe5291a189 ("drm/i915/gt: Initialize unused MOCS
> > > > > > > > entries with device specific values")
> > > > > > > > Cc: Matt Roper
> > > > > > > > Signed-off-by: Ayaz A Siddiqui
> > > > > > >
> > > > > > > Yep, we overlooked that the TGL table still had an explicit entry
> > > > > > > for
> > > > > > > I915_MOCS_PTE and wasn't just using an implicit 'unused_entries'
> > > > > > > lookup
> > > > > > > for MOCS[1]. The new table is the same as the TGL table, just
> > > > > > > with
> > > > > > > I915_MOCS_PTE (1) removed.
> > > > > >
> > > > > > And just how are people planning on handling display cacheability
> > > > > > control without a PTE MOCS entry? Is Mesa/etc. already making all
> > > > > > external bos uncached on these platforms just in case we might
> > > > > > scan out said bo?
> > > > >
> > > > > MOCS entry 1 has never been considered a valid MOCS table entry on
> > > > > gen12
> > > > > platforms (despite the old #define, it's not actually related to PTE,
> > > > > display, etc. anymore).
> > > >
> > > > So can someone finally explain to me how we're supposed to cache
> > > > anything that might become a scanout buffer later (eg. window system
> > > > buffers)? Or are we just making everything like that UC now, and is
> > > > everyone happy with that? Is userspace actually following that?
> > >
> > > Table entry #1 has never had anything to do with scanout on gen12+. I
> > > would assume that UMDs are either using the display entry in the MOCS
> > > table (which is 61 on gen12+) or some other UC entry.
> >
> > If 61 is meant to to be the new PTE entry wy hasn't it been defines as
> > such in the code? And I know for a fact that userspace (Mesa) is not
>
> There is no "PTE" entry anymore. But 61 is already documented as
> "displayable" in both the spec and the code:
>
> /* HW Special Case (Displayable) */
>
> MOCS_ENTRY(61,
Why is it called a "HW special case"? I don't think there's any hw
magic in there?
And why aren't we setting it to PTE to get some cacheability for
window back buffers and such?
>
> > using entry 61. I think there is a massive communication gap here
> > where everyone just seems to assume the other side is doing something.
> >
> > Could someone actually come up with a clear abi definition for this
> > and get all the stakeholders to sign off on it?
>
> The agreement between the i915 team, various userspace teams, Windows
> driver team, hardware architects, software architects, and bspec writers
> was just completed; that's what triggered the kernel updates here (and
> I'm guessing is triggering similar work on the UMD side). It's also why
> we held off on removing the force_probe flag on ADL until now since we
> couldn't consider enablement of the platform complete until the
> agreement and definitions here was finalized.
Can we get that agreement visible on the mailing list? Since MOCS is
abi I don't see why we shouldn't follow the normal abi rules for these,
ie. post to dri-devel, get acks from relevant people, links to agreed
userspace changes, etc.
--
Ville Syrjälä
Intel
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable GuC submission by default on DG1 (rev4)
== Series Details ==
Series: Enable GuC submission by default on DG1 (rev4)
URL : https://patchwork.freedesktop.org/series/93325/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b2951b760586 drm/i915: Do not define vma on stack
60923cb16879 drm/i915/guc: put all guc objects in lmem when available
921371699ce0 drm/i915/guc: Add DG1 GuC / HuC firmware defs
11a547556597 drm/i915/guc: Enable GuC submission by default on DG1
8201803a4cca Me: Allow relocs on DG1 for CI
-:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
-:19: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 1 errors, 1 warnings, 0 checks, 8 lines checked
c999fb206dc0 Me: Workaround LMEM blow up
-:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
-:19: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 1 errors, 1 warnings, 0 checks, 8 lines checked
e76c7801ac7b Me: Dump GuC log to dmesg on SLPC load failure
-:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
-:17: CHECK:SPACING: No space is necessary after a cast
#17: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c:267:
+(intel_engine_mask_t) ~0U);
-:56: WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message
#56: FILE: drivers/gpu/drm/i915/i915_gpu_error.c:1999:
+ if (!buf) {
+ drm_err(>drm, "Failed to allocate buffer for error
capture!\n");
-:68: WARNING:LINE_SPACING: Missing a blank line after declarations
#68: FILE: drivers/gpu/drm/i915/i915_gpu_error.c:2011:
+ ssize_t got = i915_gpu_coredump_copy_to_buffer(error, buf,
pos_err, buf_size - 1);
+ if (got <= 0)
-:91: CHECK:BRACES: braces {} should be used on all arms of this statement
#91: FILE: drivers/gpu/drm/i915/i915_gpu_error.c:2034:
+ if (count > MAX_CHUNK) {
[...]
+ } else
[...]
-:97: WARNING:LINE_SPACING: Missing a blank line after declarations
#97: FILE: drivers/gpu/drm/i915/i915_gpu_error.c:2040:
+ char chr = ptr[pos];
+ ptr[pos] = 0;
-:104: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#104: FILE: drivers/gpu/drm/i915/i915_gpu_error.c:2047:
+ drm_info(>drm, "Capture
%c%s%c\n", tag[0], ptr2, tag[1]);
-:107: CHECK:BRACES: Unbalanced braces around else statement
#107: FILE: drivers/gpu/drm/i915/i915_gpu_error.c:2050:
+ } else
-:139: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 1 errors, 5 warnings, 3 checks, 118 lines checked
9fb951546c18 drm/i915: Get PM ref before accessing HW register
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dp: dp 2.0 enabling prep work (rev3)
== Series Details == Series: drm/i915/dp: dp 2.0 enabling prep work (rev3) URL : https://patchwork.freedesktop.org/series/93800/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10565_full -> Patchwork_21002_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21002_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21002_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21002_full: ### IGT changes ### Possible regressions * igt@kms_cursor_legacy@cursor-vs-flip-legacy: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-skl1/igt@kms_cursor_leg...@cursor-vs-flip-legacy.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21002/shard-skl5/igt@kms_cursor_leg...@cursor-vs-flip-legacy.html * igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile: - shard-iclb: [PASS][3] -> [SKIP][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-iclb7/igt@kms_flip_scaled_...@flip-32bpp-ytileccs-to-64bpp-ytile.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21002/shard-iclb2/igt@kms_flip_scaled_...@flip-32bpp-ytileccs-to-64bpp-ytile.html * igt@kms_plane@plane-panning-bottom-right-suspend@pipe-b-planes: - shard-tglb: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-tglb8/igt@kms_plane@plane-panning-bottom-right-susp...@pipe-b-planes.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21002/shard-tglb7/igt@kms_plane@plane-panning-bottom-right-susp...@pipe-b-planes.html Known issues Here are the changes found in Patchwork_21002_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@smoketest: - shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21002/shard-snb5/igt@gem_ctx_persiste...@smoketest.html - shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2896]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-tglb2/igt@gem_ctx_persiste...@smoketest.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21002/shard-tglb2/igt@gem_ctx_persiste...@smoketest.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][10] -> [TIMEOUT][11] ([i915#2369] / [i915#3063] / [i915#3648]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-tglb3/igt@gem_...@unwedge-stress.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21002/shard-tglb2/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842]) +2 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-tglb8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21002/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-snb: NOTRUN -> [SKIP][14] ([fdo#109271]) +397 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21002/shard-snb6/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html * igt@gem_exec_whisper@basic-contexts-forked-all: - shard-glk: [PASS][15] -> [DMESG-WARN][16] ([i915#118] / [i915#95]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-glk8/igt@gem_exec_whis...@basic-contexts-forked-all.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21002/shard-glk2/igt@gem_exec_whis...@basic-contexts-forked-all.html * igt@gem_mmap_gtt@cpuset-big-copy-odd: - shard-iclb: [PASS][17] -> [FAIL][18] ([i915#307]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-iclb5/igt@gem_mmap_...@cpuset-big-copy-odd.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21002/shard-iclb3/igt@gem_mmap_...@cpuset-big-copy-odd.html * igt@gem_render_copy@linear-to-vebox-y-tiled: - shard-glk: NOTRUN -> [SKIP][19] ([fdo#109271]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21002/shard-glk7/igt@gem_render_c...@linear-to-vebox-y-tiled.html - shard-iclb: NOTRUN -> [SKIP][20] ([i915#768]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21002/shard-iclb8/igt@gem_render_c...@linear-to-vebox-y-tiled.html * igt@gem_userptr_blits@dmabuf-unsync: - shard-tglb: NOTRUN -> [SKIP][21] ([i915#3297]) [21]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable GuC submission by default on DG1 (rev4)
== Series Details == Series: Enable GuC submission by default on DG1 (rev4) URL : https://patchwork.freedesktop.org/series/93325/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' -
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dp: dp 2.0 enabling prep work (rev3)
== Series Details == Series: drm/i915/dp: dp 2.0 enabling prep work (rev3) URL : https://patchwork.freedesktop.org/series/93800/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
Re: [Intel-gfx] [PATCH] drm/i915/gt: Add separate MOCS table for Gen12 devices other than TGL/RKL
On Tue, Sep 07, 2021 at 11:19:29AM -0700, Matt Roper wrote:
> On Tue, Sep 07, 2021 at 08:41:06PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 07, 2021 at 10:27:28AM -0700, Matt Roper wrote:
> > > On Tue, Sep 07, 2021 at 10:46:39PM +0530, Ayaz A Siddiqui wrote:
> > > > MOCS table of TGL/RKL has MOCS[1] set to L3_UC.
> > > > While for other gen12 devices we need to set MOCS[1] as L3_WB,
> > > > So adding a new MOCS table for other gen 12 devices eg. ADL.
> > > >
> > > > Fixes: cfbe5291a189 ("drm/i915/gt: Initialize unused MOCS entries with
> > > > device specific values")
> > > > Cc: Matt Roper
> > > > Signed-off-by: Ayaz A Siddiqui
> > >
> > > Yep, we overlooked that the TGL table still had an explicit entry for
> > > I915_MOCS_PTE and wasn't just using an implicit 'unused_entries' lookup
> > > for MOCS[1]. The new table is the same as the TGL table, just with
> > > I915_MOCS_PTE (1) removed.
> >
> > And just how are people planning on handling display cacheability
> > control without a PTE MOCS entry? Is Mesa/etc. already making all
> > external bos uncached on these platforms just in case we might
> > scan out said bo?
>
> MOCS entry 1 has never been considered a valid MOCS table entry on gen12
> platforms (despite the old #define, it's not actually related to PTE,
> display, etc. anymore).
So can someone finally explain to me how we're supposed to cache
anything that might become a scanout buffer later (eg. window system
buffers)? Or are we just making everything like that UC now, and is
everyone happy with that? Is userspace actually following that?
We can't just randomly change this stuff in the kernel since it's an
abi. Userspace has to be in sync.
> Userspace shouldn't be using entry 1, since its
> settings are officially undefined, but because we had already defined a
> value for it in the driver on our production gen12 platforms (TGL/RKL),
> we can't change that value now without an ABI break; we just have to
> leave it be on TGL/RKL.
>
> Any userspace trying to use entry 1 on gen12 (or any other undocumented
> table entry) is still buggy and should still be updated. For the gen12
> platforms going forward (ADL-S, ADL-P, and anything else that shows up
> in the future) we can just follow the guidance of setting all
> invalid/unused entries as L3 cached from day 1.
>
>
> Matt
>
> >
> > >
> > > Looks good to me,
> > >
> > > Reviewed-by: Matt Roper
> > >
> > >
> > > > ---
> > > > drivers/gpu/drm/i915/gt/intel_mocs.c | 41 +---
> > > > 1 file changed, 37 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
> > > > b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > > > index e96afd7beb49..c8d289b00de4 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > > > @@ -315,6 +315,35 @@ static const struct drm_i915_mocs_entry
> > > > dg1_mocs_table[] = {
> > > > MOCS_ENTRY(63, 0, L3_1_UC),
> > > > };
> > > >
> > > > +static const struct drm_i915_mocs_entry gen12_mocs_table[] = {
> > > > +
> > > > + GEN11_MOCS_ENTRIES,
> > > > + /* Implicitly enable L1 - HDC:L1 + L3 + LLC */
> > > > + MOCS_ENTRY(48,
> > > > + LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> > > > + L3_3_WB),
> > > > + /* Implicitly enable L1 - HDC:L1 + L3 */
> > > > + MOCS_ENTRY(49,
> > > > + LE_1_UC | LE_TC_1_LLC,
> > > > + L3_3_WB),
> > > > + /* Implicitly enable L1 - HDC:L1 + LLC */
> > > > + MOCS_ENTRY(50,
> > > > + LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> > > > + L3_1_UC),
> > > > + /* Implicitly enable L1 - HDC:L1 */
> > > > + MOCS_ENTRY(51,
> > > > + LE_1_UC | LE_TC_1_LLC,
> > > > + L3_1_UC),
> > > > + /* HW Special Case (CCS) */
> > > > + MOCS_ENTRY(60,
> > > > + LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> > > > + L3_1_UC),
> > > > + /* HW Special Case (Displayable) */
> > > > + MOCS_ENTRY(61,
> > > > + LE_1_UC | LE_TC_1_LLC,
> > > > + L3_3_WB),
> > > > +};
> > > > +
> > > > enum {
> > > > HAS_GLOBAL_MOCS = BIT(0),
> > > > HAS_ENGINE_MOCS = BIT(1),
> > > > @@ -351,14 +380,18 @@ static unsigned int get_mocs_settings(const
> > > > struct drm_i915_private *i915,
> > > > table->n_entries = GEN9_NUM_MOCS_ENTRIES;
> > > > table->uc_index = 1;
> > > > table->unused_entries_index = 5;
> > > > - } else if (GRAPHICS_VER(i915) >= 12) {
> > > > + } else if (IS_TIGERLAKE(i915) || IS_ROCKETLAKE(i915)) {
> > > > + /* For TGL/RKL, Can't be changed now for ABI reasons */
> > > > table->size = ARRAY_SIZE(tgl_mocs_table);
> > > > table->table = tgl_mocs_table;
> > > > table->n_entries = GEN9_NUM_MOCS_ENTRIES;
Re: [Intel-gfx] [PATCH] drm/i915/request: fix early tracepoints
On 08/09/2021 18:38, Daniel Vetter wrote:
On Fri, Sep 03, 2021 at 12:24:05PM +0100, Matthew Auld wrote:
Currently we blow up in trace_dma_fence_init, when calling into
get_driver_name or get_timeline_name, since both the engine and context
might be NULL(or contain some garbage address) in the case of newly
allocated slab objects via the request ctor. Note that we also use
SLAB_TYPESAFE_BY_RCU here, which allows requests to be immediately
freed, but delay freeing the underlying page by an RCU grace period.
With this scheme requests can be re-allocated, at the same time as they
are also being read by some lockless RCU lookup mechanism.
One possible fix, since we don't yet have a fully initialised request
when in the ctor, is just setting the context/engine as NULL and adding
some extra handling in get_driver_name etc. And since the ctor is only
called for new slab objects(i.e allocate new page and call the ctor for
each object) it's safe to reset the context/engine prior to calling into
dma_fence_init, since we can be certain that no one is doing an RCU
lookup which might depend on peeking at the engine/context, like in
active_engine(), since the object can't yet be externally visible.
In the recycled case(which might also be externally visible) the request
refcount always transitions from 0->1 after we set the context/engine
etc, which should ensure it's valid to dereference the engine for
example, when doing an RCU list-walk, so long as we can also increment
the refcount first. If the refcount is already zero, then the request is
considered complete/released. If it's non-zero, then the request might
be in the process of being re-allocated, or potentially still in flight,
however after successfully incrementing the refcount, it's possible to
carefully inspect the request state, to determine if the request is
still what we were looking for. Note that all externally visible
requests returned to the cache must have zero refcount.
The commit message here is a bit confusing, since you start out with
describing a solution that you're not actually implementing it. I usually
do this by putting alternate solutions at the bottom, starting with "An
alternate solution would be ..." or so.
And then closing with why we don't do that, here it would be that we do
no longer have a need for these partially set up i915_requests, and
therefore just reverting that complication is the simplest solution.
An alternative fix then is to instead move the dma_fence_init out from
the request ctor. Originally this was how it was done, but it was moved
in:
commit 855e39e65cfc33a73724f1cc644ffc5754864a20
Author: Chris Wilson
Date: Mon Feb 3 09:41:48 2020 +
drm/i915: Initialise basic fence before acquiring seqno
where it looks like intel_timeline_get_seqno() relied on some of the
rq->fence state, but that is no longer the case since:
commit 12ca695d2c1ed26b2dcbb528b42813bd0f216cfc
Author: Maarten Lankhorst
Date: Tue Mar 23 16:49:50 2021 +0100
drm/i915: Do not share hwsp across contexts any more, v8.
intel_timeline_get_seqno() could also be cleaned up slightly by dropping
the request argument.
Moving dma_fence_init back out of the ctor, should ensure we have enough
of the request initialised in case of trace_dma_fence_init.
Functionally this should be the same, and is effectively what we were
already open coding before, except now we also assign the fence->lock
and fence->ops, but since these are invariant for recycled
requests(which might be externally visible), and will therefore already
hold the same value, it shouldn't matter. We still leave the
spin_lock_init() in the ctor, since we can't re-init the rq->lock in
case it is already held.
Holding rq->lock without having a full reference to it sounds like really
bad taste. I think it would be good to have a (kerneldoc) comment next to
i915_request.lock about this, with a FIXME. But separate patch.
Sorry, I guess I just meant that we can't blindly move the lock_init()
i.e if for some unknown reason we moved it out from the ctor then it
needs to go before the ref transitions from 0->1. Touching rq->lock
should require the full ref. I'll reword.
Fixes: 855e39e65cfc ("drm/i915: Initialise basic fence before acquiring seqno")
Signed-off-by: Matthew Auld
Cc: Michael Mason
Cc: Daniel Vetter
With the commit message restructured a bit, and assuming this one actually
works:
Reviewed-by: Daniel Vetter
But I'm really not confident :-(
-Daniel
---
drivers/gpu/drm/i915/i915_request.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index ce446716d092..79da5eca60af 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -829,8 +829,6 @@ static void __i915_request_ctor(void *arg)
i915_sw_fence_init(>submit, submit_notify);
i915_sw_fence_init(>semaphore, semaphore_notify);
-
Re: [Intel-gfx] [PATCH v3 02/13] drm/dp: use more of the extended receiver cap
I thought I remembered an issue with this but looked up the previous emails,
and it looks like that this change actually should be safe!
Signed-off-by: Lyude Paul
On Thu, 2021-09-09 at 15:51 +0300, Jani Nikula wrote:
> Extend the use of extended receiver cap at 0x2200 to cover
> MAIN_LINK_CHANNEL_CODING_CAP in 0x2206, in case an implementation hides
> the DP 2.0 128b/132b channel encoding cap.
>
> v2: Extend to DP_RECEIVER_CAP_SIZE (Ville)
>
> Cc: Lyude Paul
> Cc: dri-de...@lists.freedesktop.org
> Cc: Manasi Navare
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_dp_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c
> index 9b2a2961fca8..2e74b02ed96b 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -608,7 +608,7 @@ static u8 drm_dp_downstream_port_count(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
> static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
> u8 dpcd[DP_RECEIVER_CAP_SIZE])
> {
> - u8 dpcd_ext[6];
> + u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
> int ret;
>
> /*
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [Intel-gfx] [PATCH 03/21] drm/i915/wm: move the update watermark wrapper to display side.
On Thu, Sep 09, 2021 at 06:40:59AM +1000, Dave Airlie wrote: > On Wed, 8 Sept 2021 at 19:33, Jani Nikula wrote: > > > > On Wed, 08 Sep 2021, Dave Airlie wrote: > > > From: Dave Airlie > > > > > > A vague goal is to have the vfunc table be the api between > > > wm and display, not having direction function calls cross > > > the boundary. > > > > > > This aligns the legacy update_wm with the newer vfuncs. > > > > > > The comment probably needs to live somewhere else, it seems > > > like it should live in the pm side though not the display side, > > > but I brought it along for the ride. > > > --- > > > drivers/gpu/drm/i915/display/intel_display.c | 40 > > > drivers/gpu/drm/i915/intel_pm.c | 39 --- > > > drivers/gpu/drm/i915/intel_pm.h | 1 - > > > 3 files changed, 40 insertions(+), 40 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > > > b/drivers/gpu/drm/i915/display/intel_display.c > > > index d95283bf2631..b495371c1889 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c > > > > We haven't been axing stuff out of intel_display.c so we could add > > somethign else back! ;) > > > > A new file for watermarks or display pm? Ville? We need multiple files. But I've been hoping to land more watermark refactoring first so I'd not have to rebase tons of stuff across massive code motion patches. Unfortunatley review for that stuff is hard to come by. Regarding the .update_wm() hook in particular, it's just an ancient thing that is not meant to exist once all the wm code gets atomized. So no real point in polishing it any further in its current form IMO. > > The main reason I landed it there, was because all the other calls to > the wm funcs are in intel_display, and this wrapper is very small and > ends up being a static, the comment on the other hand, I've no idea > where it should have landed. > > Dave. -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH] drm/i915/gt: Add separate MOCS table for Gen12 devices other than TGL/RKL
On Thu, Sep 09, 2021 at 04:58:50PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 07, 2021 at 11:19:29AM -0700, Matt Roper wrote:
> > On Tue, Sep 07, 2021 at 08:41:06PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 07, 2021 at 10:27:28AM -0700, Matt Roper wrote:
> > > > On Tue, Sep 07, 2021 at 10:46:39PM +0530, Ayaz A Siddiqui wrote:
> > > > > MOCS table of TGL/RKL has MOCS[1] set to L3_UC.
> > > > > While for other gen12 devices we need to set MOCS[1] as L3_WB,
> > > > > So adding a new MOCS table for other gen 12 devices eg. ADL.
> > > > >
> > > > > Fixes: cfbe5291a189 ("drm/i915/gt: Initialize unused MOCS entries
> > > > > with device specific values")
> > > > > Cc: Matt Roper
> > > > > Signed-off-by: Ayaz A Siddiqui
> > > >
> > > > Yep, we overlooked that the TGL table still had an explicit entry for
> > > > I915_MOCS_PTE and wasn't just using an implicit 'unused_entries' lookup
> > > > for MOCS[1]. The new table is the same as the TGL table, just with
> > > > I915_MOCS_PTE (1) removed.
> > >
> > > And just how are people planning on handling display cacheability
> > > control without a PTE MOCS entry? Is Mesa/etc. already making all
> > > external bos uncached on these platforms just in case we might
> > > scan out said bo?
> >
> > MOCS entry 1 has never been considered a valid MOCS table entry on gen12
> > platforms (despite the old #define, it's not actually related to PTE,
> > display, etc. anymore).
>
> So can someone finally explain to me how we're supposed to cache
> anything that might become a scanout buffer later (eg. window system
> buffers)? Or are we just making everything like that UC now, and is
> everyone happy with that? Is userspace actually following that?
Table entry #1 has never had anything to do with scanout on gen12+. I
would assume that UMDs are either using the display entry in the MOCS
table (which is 61 on gen12+) or some other UC entry. If they weren't
properly updated and are still trying to use gen11 MOCS tables, then
they'll continue to work on TGL/RKL (we're not making any changes
there), but they'll just never run properly on the upcoming platforms
like ADL until the userspace enablement of the platform is completed.
>
> We can't just randomly change this stuff in the kernel since it's an
> abi. Userspace has to be in sync.
That's exactly why we're making this change. We need to get this right
_before_ it becomes established as ABI on upcoming platforms. We missed
the boat for TGL/RKL, which is why we're stuck with the "wrong" value in
invalid table entry #1 forever. But the platforms that haven't
established a behavior as pre-existing ABI yet need to be handled
correctly right from the beginning. ABI means we can't change the
behavior of a specific platform between kernel releases; it doesn't mean
that new platform B has to reproduce all the mistakes of old platform A
too. If buggy userspace happened to work by accident on TGL/RKL, that
doesn't mean that it has to accidentally work on ADL hardware too.
Matt
>
> > Userspace shouldn't be using entry 1, since its
> > settings are officially undefined, but because we had already defined a
> > value for it in the driver on our production gen12 platforms (TGL/RKL),
> > we can't change that value now without an ABI break; we just have to
> > leave it be on TGL/RKL.
> >
> > Any userspace trying to use entry 1 on gen12 (or any other undocumented
> > table entry) is still buggy and should still be updated. For the gen12
> > platforms going forward (ADL-S, ADL-P, and anything else that shows up
> > in the future) we can just follow the guidance of setting all
> > invalid/unused entries as L3 cached from day 1.
> >
> >
> > Matt
> >
> > >
> > > >
> > > > Looks good to me,
> > > >
> > > > Reviewed-by: Matt Roper
> > > >
> > > >
> > > > > ---
> > > > > drivers/gpu/drm/i915/gt/intel_mocs.c | 41
> > > > > +---
> > > > > 1 file changed, 37 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
> > > > > b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > > > > index e96afd7beb49..c8d289b00de4 100644
> > > > > --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> > > > > +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > > > > @@ -315,6 +315,35 @@ static const struct drm_i915_mocs_entry
> > > > > dg1_mocs_table[] = {
> > > > > MOCS_ENTRY(63, 0, L3_1_UC),
> > > > > };
> > > > >
> > > > > +static const struct drm_i915_mocs_entry gen12_mocs_table[] = {
> > > > > +
> > > > > + GEN11_MOCS_ENTRIES,
> > > > > + /* Implicitly enable L1 - HDC:L1 + L3 + LLC */
> > > > > + MOCS_ENTRY(48,
> > > > > +LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> > > > > +L3_3_WB),
> > > > > + /* Implicitly enable L1 - HDC:L1 + L3 */
> > > > > + MOCS_ENTRY(49,
> > > > > +LE_1_UC | LE_TC_1_LLC,
> > > > > +L3_3_WB),
> > > > > + /* Implicitly enable L1 - HDC:L1 + LLC */
> > > > > + MOCS_ENTRY(50,
Re: [Intel-gfx] [PATCH v5] drm/i915: Use Transparent Hugepages when IOMMU is enabled
On Thu, Sep 09, 2021 at 12:44:48PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Usage of Transparent Hugepages was disabled in 9987da4b5dcf
> ("drm/i915: Disable THP until we have a GPU read BW W/A"), but since it
> appears majority of performance regressions reported with an enabled IOMMU
> can be almost eliminated by turning them on, lets just do that.
>
> To err on the side of safety we keep the current default in cases where
> IOMMU is not active, and only when it is default to the "huge=within_size"
> mode. Although there probably would be wins to enable them throughout,
> more extensive testing across benchmarks and platforms would need to be
> done.
>
> With the patch and IOMMU enabled my local testing on a small Skylake part
> shows OglVSTangent regression being reduced from ~14% (IOMMU on versus
> IOMMU off) to ~2% (same comparison but with THP on).
>
> More detailed testing done in the below referenced Gitlab issue by Eero:
>
> Skylake GT4e:
>
> Performance drops from enabling IOMMU:
>
> 30-35% SynMark CSDof
> 20-25% Unigine Heaven, MemBW GPU write, SynMark VSTangent
> ~20% GLB Egypt (1/2 screen window)
> 10-15% GLB T-Rex (1/2 screen window)
> 8-10% GfxBench T-Rex, MemBW GPU blit
> 7-8% SynMark DeferredAA + TerrainFly* + ZBuffer
> 6-7% GfxBench Manhattan 3.0 + 3.1, SynMark TexMem128 & CSCloth
> 5-6% GfxBench CarChase, Unigine Valley
> 3-5% GfxBench Vulkan & GL AztecRuins + ALU2, MemBW GPU texture,
> SynMark Fill*, Deferred, TerrainPan*
> 1-2% Most of the other tests
>
> With the patch drops become:
>
> 20-25% SynMark TexMem*
> 15-20% GLB Egypt (1/2 screen window)
> 10-15% GLB T-Rex (1/2 screen window)
> 4-7% GfxBench T-Rex, GpuTest Triangle
> 1-8% GfxBench ALU2 (offscreen 1%, onscreen 8%)
> 3% GfxBench Manhattan 3.0, SynMark CSDof
> 2-3% Unigine Heaven + Valley, MemBW GPU texture
> 1-3 GfxBench Manhattan 3.1 + CarChase + Vulkan & GL AztecRuins
>
> Broxton:
>
> Performance drops from IOMMU, without patch:
>
> 30% MemBW GPU write
> 25% SynMark ZBuffer + Fill*
> 20% MemBW GPU blit
> 15% MemBW GPU blend, GpuTest Triangle
> 10-15% MemBW GPU texture
> 10% GLB Egypt, Unigine Heaven (had hangs), SynMark TerrainFly*
> 7-9% GLB T-Rex, GfxBench Manhattan 3.0 + T-Rex,
> SynMark Deferred* + TexMem*
> 6-8% GfxBench CarChase, Unigine Valley,
> SynMark CSCloth + ShMapVsm + TerrainPan*
> 5-6% GfxBench Manhattan 3.1 + GL AztecRuins,
> SynMark CSDof + TexFilterTri
> 2-4% GfxBench ALU2, SynMark DrvRes + GSCloth + ShMapPcf + Batch[0-5] +
> TexFilterAniso, GpuTest GiMark + 32-bit Julia
>
> And with patch:
>
> 15-20% MemBW GPU texture
> 10% SynMark TexMem*
> 8-9% GLB Egypt (1/2 screen window)
> 4-5% GLB T-Rex (1/2 screen window)
> 3-6% GfxBench Manhattan 3.0, GpuTest FurMark,
> SynMark Deferred + TexFilterTri
> 3-4% GfxBench Manhattan 3.1 + T-Rex, SynMark VSInstancing
> 2-4% GpuTest Triangle, SynMark DeferredAA
> 2-3% Unigine Heaven + Valley
> 1-3% SynMark Terrain*
> 1-2% GfxBench CarChase, SynMark TexFilterAniso + ZBuffer
>
> Tigerlake-H:
>
> 20-25% MemBW GPU texture
> 15-20% GpuTest Triangle
> 13-15% SynMark TerrainFly* + DeferredAA + HdrBloom
> 8-10% GfxBench Manhattan 3.1, SynMark TerrainPan* + DrvRes
> 6-7% GfxBench Manhattan 3.0, SynMark TexMem*
> 4-8% GLB onscreen Fill + T-Rex + Egypt (more in onscreen than
> offscreen versions of T-Rex/Egypt)
> 4-6% GfxBench CarChase + GLES AztecRuins + ALU2, GpuTest 32-bit Julia,
> SynMark CSDof + DrvState
> 3-5% GfxBench T-Rex + Egypt, Unigine Heaven + Valley, GpuTest Plot3D
> 1-7% Media tests
> 2-3% MemBW GPU blit
> 1-3% Most of the rest of 3D tests
>
> With the patch:
>
> 6-8% MemBW GPU blend => the only regression in these tests (compared
> to IOMMU without THP)
> 4-6% SynMark DrvState (not impacted) + HdrBloom (improved)
> 3-4% GLB T-Rex
> ~3% GLB Egypt, SynMark DrvRes
> 1-3% GfxBench T-Rex + Egypt, SynMark TexFilterTri
> 1-2% GfxBench CarChase + GLES AztecRuins, Unigine Valley,
> GpuTest Triangle
> ~1% GfxBench Manhattan 3.0/3.1, Unigine Heaven
>
> Perf of several tests actually improved with IOMMU + THP, compared to no
> IOMMU / no THP:
>
> 10-15% SynMark Batch[0-3]
> 5-10% MemBW GPU texture, SynMark ShMapVsm
> 3-4% SynMark Fill* + Geom*
> 2-3% SynMark TexMem512 + CSCloth
> 1-2% SynMark TexMem128 + DeferredAA
>
> As a summary across all platforms, these are the benchmarks where enabling
> THP on top of IOMMU enabled brings regressions:
>
> * Skylake GT4e:
>20-25% SynMark TexMem*
>(whereas all MemBW GPU tests either improve or are not affected)
>
> * Broxton J4205:
>7% MemBW GPU texture
>2-3% SynMark TexMem*
>
> * Tigerlake-H:
>7% MemBW GPU blend
>
> Other benchmarks show either
Re: [Intel-gfx] [PATCH v3 02/13] drm/dp: use more of the extended receiver cap
…whoops, that was supposed to be:
Reviewed-by: Lyude Paul
On Thu, 2021-09-09 at 12:18 -0400, Lyude Paul wrote:
> I thought I remembered an issue with this but looked up the previous emails,
> and it looks like that this change actually should be safe!
>
> Signed-off-by: Lyude Paul
>
> On Thu, 2021-09-09 at 15:51 +0300, Jani Nikula wrote:
> > Extend the use of extended receiver cap at 0x2200 to cover
> > MAIN_LINK_CHANNEL_CODING_CAP in 0x2206, in case an implementation hides
> > the DP 2.0 128b/132b channel encoding cap.
> >
> > v2: Extend to DP_RECEIVER_CAP_SIZE (Ville)
> >
> > Cc: Lyude Paul
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: Manasi Navare
> > Cc: Ville Syrjälä
> > Signed-off-by: Jani Nikula
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 9b2a2961fca8..2e74b02ed96b 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -608,7 +608,7 @@ static u8 drm_dp_downstream_port_count(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE])
> > static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
> > u8 dpcd[DP_RECEIVER_CAP_SIZE])
> > {
> > - u8 dpcd_ext[6];
> > + u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
> > int ret;
> >
> > /*
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dp: dp 2.0 enabling prep work (rev3)
== Series Details ==
Series: drm/i915/dp: dp 2.0 enabling prep work (rev3)
URL : https://patchwork.freedesktop.org/series/93800/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a3665dc8b3d2 drm/dp: add DP 2.0 UHBR link rate and bw code conversions
68ec9d98ee90 drm/dp: use more of the extended receiver cap
48940950af3c drm/dp: add LTTPR DP 2.0 DPCD addresses
a2c94be7e9b9 drm/dp: add helper for extracting adjust 128b/132b TX FFE preset
c762623aaaba drm/i915/dg2: add DG2+ TRANS_DDI_FUNC_CTL DP 2.0 128b/132b mode
e99cd06140c4 drm/i915/dp: add helper for checking for UHBR link rate
9334d33d2624 drm/i915/dp: use 128b/132b TPS2 for UHBR+ link rates
13bcc2d6e808 drm/i915/dp: select 128b/132b channel encoding for UHBR rates
1fc3c6d399c1 drm/i915/dg2: configure TRANS_DP2_CTL for DP 2.0
23ec558b7af4 drm/i915/dp: add HAS_DP20 macro
fcf2455de71f drm/i915/dg2: use 128b/132b transcoder DDI mode
5a7810bd5e6f drm/i915/dg2: configure TRANS_DP2_VFREQ{HIGH, LOW} for 128b/132b
c586238887e7 drm/i915/dg2: update link training for 128b/132b
-:27: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or
return
#27: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:1404:
+ return intel_dp->train_set[0] & DP_TX_FFE_PRESET_VALUE_MASK;
+ } else {
total: 0 errors, 1 warnings, 0 checks, 139 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: dp 2.0 enabling prep work (rev3)
== Series Details ==
Series: drm/i915/dp: dp 2.0 enabling prep work (rev3)
URL : https://patchwork.freedesktop.org/series/93800/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10565 -> Patchwork_21002
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21002/index.html
Known issues
Here are the changes found in Patchwork_21002 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u: NOTRUN -> [SKIP][1] ([fdo#109271]) +27 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21002/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
* igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u: NOTRUN -> [WARN][2] ([i915#3718])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21002/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#2868])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21002/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21002/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
Possible fixes
* igt@i915_selftest@live@gt_pm:
- {fi-jsl-1}: [DMESG-FAIL][6] ([i915#1886]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21002/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2868]: https://gitlab.freedesktop.org/drm/intel/issues/2868
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#3718]: https://gitlab.freedesktop.org/drm/intel/issues/3718
Participating hosts (47 -> 39)
--
Missing(8): fi-ilk-m540 bat-adls-5 bat-dg1-6 fi-bsw-cyan bat-adlp-4
fi-ctg-p8600 fi-bdw-samus bat-jsl-1
Build changes
-
* Linux: CI_DRM_10565 -> Patchwork_21002
CI-20190529: 20190529
CI_DRM_10565: 8c3cd60dcfa81a649b14f0705eb5e5c9336f1881 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6201: be0d02ff0775235ead63ccb1e3a1e8c10f0209cf @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_21002: c586238887e774ccaf7b7d0dc0e690696c6e410d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
c586238887e7 drm/i915/dg2: update link training for 128b/132b
5a7810bd5e6f drm/i915/dg2: configure TRANS_DP2_VFREQ{HIGH, LOW} for 128b/132b
fcf2455de71f drm/i915/dg2: use 128b/132b transcoder DDI mode
23ec558b7af4 drm/i915/dp: add HAS_DP20 macro
1fc3c6d399c1 drm/i915/dg2: configure TRANS_DP2_CTL for DP 2.0
13bcc2d6e808 drm/i915/dp: select 128b/132b channel encoding for UHBR rates
9334d33d2624 drm/i915/dp: use 128b/132b TPS2 for UHBR+ link rates
e99cd06140c4 drm/i915/dp: add helper for checking for UHBR link rate
c762623aaaba drm/i915/dg2: add DG2+ TRANS_DDI_FUNC_CTL DP 2.0 128b/132b mode
a2c94be7e9b9 drm/dp: add helper for extracting adjust 128b/132b TX FFE preset
48940950af3c drm/dp: add LTTPR DP 2.0 DPCD addresses
68ec9d98ee90 drm/dp: use more of the extended receiver cap
a3665dc8b3d2 drm/dp: add DP 2.0 UHBR link rate and bw code conversions
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21002/index.html
Re: [Intel-gfx] [PATCH] drm/i915/gt: Add separate MOCS table for Gen12 devices other than TGL/RKL
On Thu, Sep 09, 2021 at 07:29:33AM -0700, Matt Roper wrote:
> On Thu, Sep 09, 2021 at 04:58:50PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 07, 2021 at 11:19:29AM -0700, Matt Roper wrote:
> > > On Tue, Sep 07, 2021 at 08:41:06PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Sep 07, 2021 at 10:27:28AM -0700, Matt Roper wrote:
> > > > > On Tue, Sep 07, 2021 at 10:46:39PM +0530, Ayaz A Siddiqui wrote:
> > > > > > MOCS table of TGL/RKL has MOCS[1] set to L3_UC.
> > > > > > While for other gen12 devices we need to set MOCS[1] as L3_WB,
> > > > > > So adding a new MOCS table for other gen 12 devices eg. ADL.
> > > > > >
> > > > > > Fixes: cfbe5291a189 ("drm/i915/gt: Initialize unused MOCS entries
> > > > > > with device specific values")
> > > > > > Cc: Matt Roper
> > > > > > Signed-off-by: Ayaz A Siddiqui
> > > > >
> > > > > Yep, we overlooked that the TGL table still had an explicit entry for
> > > > > I915_MOCS_PTE and wasn't just using an implicit 'unused_entries'
> > > > > lookup
> > > > > for MOCS[1]. The new table is the same as the TGL table, just with
> > > > > I915_MOCS_PTE (1) removed.
> > > >
> > > > And just how are people planning on handling display cacheability
> > > > control without a PTE MOCS entry? Is Mesa/etc. already making all
> > > > external bos uncached on these platforms just in case we might
> > > > scan out said bo?
> > >
> > > MOCS entry 1 has never been considered a valid MOCS table entry on gen12
> > > platforms (despite the old #define, it's not actually related to PTE,
> > > display, etc. anymore).
> >
> > So can someone finally explain to me how we're supposed to cache
> > anything that might become a scanout buffer later (eg. window system
> > buffers)? Or are we just making everything like that UC now, and is
> > everyone happy with that? Is userspace actually following that?
>
> Table entry #1 has never had anything to do with scanout on gen12+. I
> would assume that UMDs are either using the display entry in the MOCS
> table (which is 61 on gen12+) or some other UC entry.
If 61 is meant to to be the new PTE entry wy hasn't it been defines as
such in the code? And I know for a fact that userspace (Mesa) is not
using entry 61. I think there is a massive communication gap here
where everyone just seems to assume the other side is doing something.
Could someone actually come up with a clear abi definition for this
and get all the stakeholders to sign off on it?
--
Ville Syrjälä
Intel
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Introduce Intel PXP (rev6)
== Series Details ==
Series: drm/i915: Introduce Intel PXP (rev6)
URL : https://patchwork.freedesktop.org/series/90503/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10565 -> Patchwork_21001
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/index.html
Known issues
Here are the changes found in Patchwork_21001 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u: NOTRUN -> [SKIP][1] ([fdo#109271]) +27 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
* igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u: NOTRUN -> [WARN][2] ([i915#3718])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][3] -> [INCOMPLETE][4] ([i915#3921])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
Possible fixes
* igt@i915_selftest@live@gt_pm:
- {fi-jsl-1}: [DMESG-FAIL][6] ([i915#1886]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#3718]: https://gitlab.freedesktop.org/drm/intel/issues/3718
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
Participating hosts (47 -> 39)
--
Missing(8): fi-ilk-m540 bat-adls-5 bat-dg1-6 fi-bsw-cyan bat-adlp-4
fi-ctg-p8600 fi-bdw-samus bat-jsl-1
Build changes
-
* Linux: CI_DRM_10565 -> Patchwork_21001
CI-20190529: 20190529
CI_DRM_10565: 8c3cd60dcfa81a649b14f0705eb5e5c9336f1881 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6201: be0d02ff0775235ead63ccb1e3a1e8c10f0209cf @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_21001: 9f43a759224fd9b8cc3116ab3b3ab97d72791e01 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
9f43a759224f drm/i915/pxp: enable PXP for integrated Gen12
0863fbc2021b drm/i915/pxp: add PXP documentation
f9652eddefaa drm/i915/pxp: add pxp debugfs
87c269e251cd drm/i915/pxp: black pixels on pxp disabled
48584fd7f1e0 drm/i915/pxp: Add plane decryption support
61274982b95b drm/i915/pxp: Enable PXP power management
5f170f70a91c drm/i915/pxp: start the arb session on demand
f2ea2f8e1f45 drm/i915/pxp: interfaces for using protected objects
8098ad3734e4 drm/i915/pxp: Implement PXP irq handler
10e6202ef0ff drm/i915/pxp: Implement arb session teardown
6c57836d2dda drm/i915/pxp: Create the arbitrary session after boot
cc2086cc202f drm/i915/pxp: set KCR reg init
ce029c5228f4 drm/i915/pxp: Implement funcs to create the TEE channel
32d2a598f087 drm/i915/pxp: allocate a vcs context for pxp usage
95ad0c8a1ff6 drm/i915/pxp: define PXP device flag and kconfig
48b326460b6f mei: pxp: export pavp client to me client bus
4b04867d778d drm/i915/pxp: Define PXP component interface
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/index.html
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Introduce Intel PXP (rev6)
== Series Details == Series: drm/i915: Introduce Intel PXP (rev6) URL : https://patchwork.freedesktop.org/series/90503/ State : success == Summary == CI Bug Log - changes from CI_DRM_10565_full -> Patchwork_21001_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_21001_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/shard-apl3/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@smoketest: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +1 similar issue [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/shard-snb5/igt@gem_ctx_persiste...@smoketest.html * igt@gem_eio@suspend: - shard-tglb: [PASS][3] -> [DMESG-WARN][4] ([i915#2867]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-tglb3/igt@gem_...@suspend.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/shard-tglb7/igt@gem_...@suspend.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][5] -> [TIMEOUT][6] ([i915#2369] / [i915#3063] / [i915#3648]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-tglb3/igt@gem_...@unwedge-stress.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/shard-tglb8/igt@gem_...@unwedge-stress.html - shard-iclb: [PASS][7] -> [TIMEOUT][8] ([i915#2369] / [i915#2481] / [i915#3070]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-iclb2/igt@gem_...@unwedge-stress.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/shard-iclb8/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/shard-tglb2/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/shard-kbl1/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_whisper@basic-contexts-forked-all: - shard-glk: [PASS][14] -> [DMESG-WARN][15] ([i915#118] / [i915#95]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-glk8/igt@gem_exec_whis...@basic-contexts-forked-all.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/shard-glk7/igt@gem_exec_whis...@basic-contexts-forked-all.html * igt@gem_render_copy@linear-to-vebox-y-tiled: - shard-glk: NOTRUN -> [SKIP][16] ([fdo#109271]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/shard-glk2/igt@gem_render_c...@linear-to-vebox-y-tiled.html * igt@gem_userptr_blits@dmabuf-unsync: - shard-tglb: NOTRUN -> [SKIP][17] ([i915#3297]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/shard-tglb7/igt@gem_userptr_bl...@dmabuf-unsync.html - shard-iclb: NOTRUN -> [SKIP][18] ([i915#3297]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/shard-iclb4/igt@gem_userptr_bl...@dmabuf-unsync.html * igt@gen9_exec_parse@allowed-single: - shard-glk: [PASS][19] -> [DMESG-WARN][20] ([i915#1436] / [i915#716]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-glk6/igt@gen9_exec_pa...@allowed-single.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/shard-glk9/igt@gen9_exec_pa...@allowed-single.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][21] -> [FAIL][22] ([i915#454]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-iclb2/igt@i915_pm...@dc6-psr.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/shard-iclb8/igt@i915_pm...@dc6-psr.html * igt@kms_async_flips@alternate-sync-async-flip: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#2521]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-skl5/igt@kms_async_fl...@alternate-sync-async-flip.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21001/shard-skl3/igt@kms_async_fl...@alternate-sync-async-flip.html * igt@kms_big_fb@yf-tiled-64bpp-rotate-90: - shard-iclb:
[Intel-gfx] [PATCH v8 13/17] drm/i915/pxp: Add plane decryption support
From: Anshuman Gupta
Add support to enable/disable PLANE_SURF Decryption Request bit.
It requires only to enable plane decryption support when following
condition met.
1. PXP session is enabled.
2. Buffer object is protected.
v2:
- Used gen fb obj user_flags instead gem_object_metadata. [Krishna]
v3:
- intel_pxp_gem_object_status() API changes.
v4: use intel_pxp_is_active (Daniele)
v5: rebase and use the new protected object status checker (Daniele)
v6: used plane state for plane_decryption to handle async flip
as suggested by Ville.
v7: check pxp session while plane decrypt state computation. [Ville]
removed pointless code. [Ville]
v8 (Daniele): update PXP check
v9: move decrypt check after icl_check_nv12_planes() when overlays
have fb set (Juston)
v10 (Daniele): update PXP check again to match rework in earlier patches and
don't consider protection valid if the object has not been used in an
execbuf beforehand.
Cc: Bommu Krishnaiah
Cc: Huang Sean Z
Cc: Gaurav Kumar
Cc: Ville Syrjälä
Signed-off-by: Anshuman Gupta
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Juston Li
Reviewed-by: Rodrigo Vivi
Reviewed-by: Uma Shankar #v9
---
drivers/gpu/drm/i915/display/intel_display.c | 26 +++
.../drm/i915/display/intel_display_types.h| 3 +++
.../drm/i915/display/skl_universal_plane.c| 15 ---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp.c | 9 ---
drivers/gpu/drm/i915/pxp/intel_pxp.h | 7 +++--
7 files changed, 54 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 134c792e1dbd..d472a2e4cb7c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -71,6 +71,8 @@
#include "gt/intel_rps.h"
#include "gt/gen8_ppgtt.h"
+#include "pxp/intel_pxp.h"
+
#include "g4x_dp.h"
#include "g4x_hdmi.h"
#include "i915_drv.h"
@@ -8994,13 +8996,23 @@ static int intel_bigjoiner_add_affected_planes(struct
intel_atomic_state *state)
return 0;
}
+static bool bo_has_valid_encryption(struct drm_i915_gem_object *obj)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+
+ return intel_pxp_key_check(>gt.pxp, obj, false) == 0;
+}
+
static int intel_atomic_check_planes(struct intel_atomic_state *state)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
struct intel_crtc_state *old_crtc_state, *new_crtc_state;
struct intel_plane_state *plane_state;
struct intel_plane *plane;
+ struct intel_plane_state *new_plane_state;
+ struct intel_plane_state *old_plane_state;
struct intel_crtc *crtc;
+ const struct drm_framebuffer *fb;
int i, ret;
ret = icl_add_linked_planes(state);
@@ -9048,6 +9060,16 @@ static int intel_atomic_check_planes(struct
intel_atomic_state *state)
return ret;
}
+ for_each_new_intel_plane_in_state(state, plane, plane_state, i) {
+ new_plane_state = intel_atomic_get_new_plane_state(state,
plane);
+ old_plane_state = intel_atomic_get_old_plane_state(state,
plane);
+ fb = new_plane_state->hw.fb;
+ if (fb)
+ new_plane_state->decrypt =
bo_has_valid_encryption(intel_fb_obj(fb));
+ else
+ new_plane_state->decrypt = old_plane_state->decrypt;
+ }
+
return 0;
}
@@ -9334,6 +9356,10 @@ static int intel_atomic_check_async(struct
intel_atomic_state *state)
drm_dbg_kms(>drm, "Color range cannot be changed
in async flip\n");
return -EINVAL;
}
+
+ /* plane decryption is allow to change only in synchronous
flips */
+ if (old_plane_state->decrypt != new_plane_state->decrypt)
+ return -EINVAL;
}
return 0;
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index c7bcf9183447..6d4ea1d5bf7b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -629,6 +629,9 @@ struct intel_plane_state {
struct intel_fb_view view;
+ /* Plane pxp decryption state */
+ bool decrypt;
+
/* plane control register */
u32 ctl;
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 724e7b04f3b6..55e3f093b951 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -18,6 +18,7 @@
#include "intel_sprite.h"
#include "skl_scaler.h"
#include "skl_universal_plane.h"
+#include "pxp/intel_pxp.h"
static
[Intel-gfx] [PATCH v8 10/17] drm/i915/pxp: interfaces for using protected objects
This api allow user mode to create protected buffers and to mark
contexts as making use of such objects. Only when using contexts
marked in such a way is the execution guaranteed to work as expected.
Contexts can only be marked as using protected content at creation time
(i.e. the parameter is immutable) and they must be both bannable and not
recoverable. Given that the protected session gets invalidated on
suspend, contexts created this way hold a runtime pm wakeref until
they're either destroyed or invalidated.
All protected objects and contexts will be considered invalid when the
PXP session is destroyed and all new submissions using them will be
rejected. All intel contexts within the invalidated gem contexts will be
marked banned. Userspace can detect that an invalidation has occurred via
the RESET_STATS ioctl, where we report it the same way as a ban due to a
hang.
v5: squash patches, rebase on proto_ctx, update kerneldoc
v6: rebase on obj create_ext changes
v7: Use session counter to check if an object it valid, hold wakeref in
context, don't add a new flag to RESET_STATS (Daniel)
v8: don't increase guilty count for contexts banned during pxp
invalidation (Rodrigo)
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Bommu Krishnaiah
Cc: Rodrigo Vivi
Cc: Chris Wilson
Cc: Lionel Landwerlin
Cc: Jason Ekstrand
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 98 ---
drivers/gpu/drm/i915/gem/i915_gem_context.h | 6 ++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 28 ++
drivers/gpu/drm/i915/gem/i915_gem_create.c| 72 ++
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 18
drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 +
drivers/gpu/drm/i915/gem/i915_gem_object.h| 6 ++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 8 ++
.../gpu/drm/i915/gem/selftests/mock_context.c | 4 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 77 +++
drivers/gpu/drm/i915/pxp/intel_pxp.h | 12 +++
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 6 ++
drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 9 ++
include/uapi/drm/i915_drm.h | 52 +-
14 files changed, 362 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c2ab0e22db0a..8d2d4dbdab7c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -77,6 +77,8 @@
#include "gt/intel_gpu_commands.h"
#include "gt/intel_ring.h"
+#include "pxp/intel_pxp.h"
+
#include "i915_gem_context.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
@@ -186,10 +188,13 @@ static int validate_priority(struct drm_i915_private
*i915,
return 0;
}
-static void proto_context_close(struct i915_gem_proto_context *pc)
+static void proto_context_close(struct drm_i915_private *i915,
+ struct i915_gem_proto_context *pc)
{
int i;
+ if (pc->pxp_wakeref)
+ intel_runtime_pm_put(>runtime_pm, pc->pxp_wakeref);
if (pc->vm)
i915_vm_put(pc->vm);
if (pc->user_engines) {
@@ -241,6 +246,33 @@ static int proto_context_set_persistence(struct
drm_i915_private *i915,
return 0;
}
+static int proto_context_set_protected(struct drm_i915_private *i915,
+ struct i915_gem_proto_context *pc,
+ bool protected)
+{
+ int ret = 0;
+
+ if (!intel_pxp_is_enabled(>gt.pxp)) {
+ ret = -ENODEV;
+ } else if (!protected) {
+ pc->uses_protected_content = false;
+ } else if ((pc->user_flags & BIT(UCONTEXT_RECOVERABLE)) ||
+ !(pc->user_flags & BIT(UCONTEXT_BANNABLE))) {
+ ret = -EPERM;
+ } else {
+ pc->uses_protected_content = true;
+
+ /*
+* protected context usage requires the PXP session to be up,
+* which in turn requires the device to be active.
+*/
+ pc->pxp_wakeref = intel_runtime_pm_get(>runtime_pm);
+ ret = intel_pxp_wait_for_arb_start(>gt.pxp);
+ }
+
+ return ret;
+}
+
static struct i915_gem_proto_context *
proto_context_create(struct drm_i915_private *i915, unsigned int flags)
{
@@ -269,7 +301,7 @@ proto_context_create(struct drm_i915_private *i915,
unsigned int flags)
return pc;
proto_close:
- proto_context_close(pc);
+ proto_context_close(i915, pc);
return err;
}
@@ -693,6 +725,8 @@ static int set_proto_ctx_param(struct drm_i915_file_private
*fpriv,
ret = -EPERM;
else if (args->value)
pc->user_flags |= BIT(UCONTEXT_BANNABLE);
+ else if (pc->uses_protected_content)
+ ret = -EPERM;
else
[Intel-gfx] [PATCH v8 14/17] drm/i915/pxp: black pixels on pxp disabled
From: Anshuman Gupta
When protected sufaces has flipped and pxp session is disabled,
display black pixels by using plane color CTM correction.
v2:
- Display black pixels in async flip too.
v3:
- Removed the black pixels logic for async flip. [Ville]
- Used plane state to force black pixels. [Ville]
v4 (Daniele): update pxp_is_borked check.
v5: rebase on top of v9 plane decryption moving the decrypt check
(Juston)
Cc: Ville Syrjälä
Cc: Gaurav Kumar
Cc: Shankar Uma
Signed-off-by: Anshuman Gupta
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Juston Li
Reviewed-by: Rodrigo Vivi
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_display.c | 12 -
.../drm/i915/display/intel_display_types.h| 3 ++
.../drm/i915/display/skl_universal_plane.c| 36 ++-
drivers/gpu/drm/i915/i915_reg.h | 46 +++
4 files changed, 94 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index d472a2e4cb7c..6d41d1c568d2 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9003,6 +9003,11 @@ static bool bo_has_valid_encryption(struct
drm_i915_gem_object *obj)
return intel_pxp_key_check(>gt.pxp, obj, false) == 0;
}
+static bool pxp_is_borked(struct drm_i915_gem_object *obj)
+{
+ return i915_gem_object_is_protected(obj) &&
!bo_has_valid_encryption(obj);
+}
+
static int intel_atomic_check_planes(struct intel_atomic_state *state)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
@@ -9064,10 +9069,13 @@ static int intel_atomic_check_planes(struct
intel_atomic_state *state)
new_plane_state = intel_atomic_get_new_plane_state(state,
plane);
old_plane_state = intel_atomic_get_old_plane_state(state,
plane);
fb = new_plane_state->hw.fb;
- if (fb)
+ if (fb) {
new_plane_state->decrypt =
bo_has_valid_encryption(intel_fb_obj(fb));
- else
+ new_plane_state->force_black =
pxp_is_borked(intel_fb_obj(fb));
+ } else {
new_plane_state->decrypt = old_plane_state->decrypt;
+ new_plane_state->force_black =
old_plane_state->force_black;
+ }
}
return 0;
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 6d4ea1d5bf7b..05d2e6676387 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -632,6 +632,9 @@ struct intel_plane_state {
/* Plane pxp decryption state */
bool decrypt;
+ /* Plane state to display black pixels when pxp is borked */
+ bool force_black;
+
/* plane control register */
u32 ctl;
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 55e3f093b951..c4adcb3e12b3 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -1002,6 +1002,33 @@ static u32 skl_surf_address(const struct
intel_plane_state *plane_state,
}
}
+static void intel_load_plane_csc_black(struct intel_plane *intel_plane)
+{
+ struct drm_i915_private *dev_priv = to_i915(intel_plane->base.dev);
+ enum pipe pipe = intel_plane->pipe;
+ enum plane_id plane = intel_plane->id;
+ u16 postoff = 0;
+
+ drm_dbg_kms(_priv->drm, "plane color CTM to black %s:%d\n",
+ intel_plane->base.name, plane);
+ intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 0), 0);
+ intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 1), 0);
+
+ intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 2), 0);
+ intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 3), 0);
+
+ intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 4), 0);
+ intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 5), 0);
+
+ intel_de_write_fw(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 0), 0);
+ intel_de_write_fw(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 1), 0);
+ intel_de_write_fw(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 2), 0);
+
+ intel_de_write_fw(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 0), postoff);
+ intel_de_write_fw(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 1), postoff);
+ intel_de_write_fw(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 2), postoff);
+}
+
static void
skl_program_plane(struct intel_plane *plane,
const struct intel_crtc_state *crtc_state,
@@ -1115,14 +1142,21 @@ skl_program_plane(struct intel_plane *plane,
*/
intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), plane_ctl);
plane_surf =
[Intel-gfx] [PATCH v8 12/17] drm/i915/pxp: Enable PXP power management
From: "Huang, Sean Z"
During the power event S3+ sleep/resume, hardware will lose all the
encryption keys for every hardware session, even though the
session state might still be marked as alive after resume. Therefore,
we should consider the session as dead on suspend and invalidate all the
objects. The session will be automatically restarted on the first
protected submission on resume.
v2: runtime suspend also invalidates the keys
v3: fix return codes, simplify rpm ops (Chris), use the new worker func
v4: invalidate the objects on suspend, don't re-create the arb sesson on
resume (delayed to first submission).
v5: move irq changes back to irq patch (Rodrigo)
Signed-off-by: Huang, Sean Z
Signed-off-by: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gt/intel_gt_pm.c| 15 +++-
drivers/gpu/drm/i915/i915_drv.c | 2 +
drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 40
drivers/gpu/drm/i915/pxp/intel_pxp_pm.h | 23 +++
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 38 ++-
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 9 +
8 files changed, 118 insertions(+), 11 deletions(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b22b8c195bb8..366e82cec44d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -286,6 +286,7 @@ i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp.o \
pxp/intel_pxp_cmd.o \
pxp/intel_pxp_irq.o \
+ pxp/intel_pxp_pm.o \
pxp/intel_pxp_session.o \
pxp/intel_pxp_tee.o
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index dea8e2479897..0fd1acab68c0 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -18,6 +18,7 @@
#include "intel_rc6.h"
#include "intel_rps.h"
#include "intel_wakeref.h"
+#include "pxp/intel_pxp_pm.h"
static void user_forcewake(struct intel_gt *gt, bool suspend)
{
@@ -262,6 +263,8 @@ int intel_gt_resume(struct intel_gt *gt)
intel_uc_resume(>uc);
+ intel_pxp_resume(>pxp);
+
user_forcewake(gt, false);
out_fw:
@@ -296,6 +299,7 @@ void intel_gt_suspend_prepare(struct intel_gt *gt)
user_forcewake(gt, true);
wait_for_suspend(gt);
+ intel_pxp_suspend(>pxp);
intel_uc_suspend(>uc);
}
@@ -346,6 +350,7 @@ void intel_gt_suspend_late(struct intel_gt *gt)
void intel_gt_runtime_suspend(struct intel_gt *gt)
{
+ intel_pxp_suspend(>pxp);
intel_uc_runtime_suspend(>uc);
GT_TRACE(gt, "\n");
@@ -353,11 +358,19 @@ void intel_gt_runtime_suspend(struct intel_gt *gt)
int intel_gt_runtime_resume(struct intel_gt *gt)
{
+ int ret;
+
GT_TRACE(gt, "\n");
intel_gt_init_swizzling(gt);
intel_ggtt_restore_fences(gt->ggtt);
- return intel_uc_runtime_resume(>uc);
+ ret = intel_uc_runtime_resume(>uc);
+ if (ret)
+ return ret;
+
+ intel_pxp_resume(>pxp);
+
+ return 0;
}
static ktime_t __intel_gt_get_awake_time(const struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 59fb4c710c8c..d5bcc70a22d4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -67,6 +67,8 @@
#include "gt/intel_gt_pm.h"
#include "gt/intel_rc6.h"
+#include "pxp/intel_pxp_pm.h"
+
#include "i915_debugfs.h"
#include "i915_drv.h"
#include "i915_ioc32.h"
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
index 340f20d130a8..9e5847c653f2 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
@@ -9,6 +9,7 @@
#include "gt/intel_gt_irq.h"
#include "i915_irq.h"
#include "i915_reg.h"
+#include "intel_runtime_pm.h"
/**
* intel_pxp_irq_handler - Handles PXP interrupts.
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
new file mode 100644
index ..4507756b2977
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2020 Intel Corporation.
+ */
+
+#include "intel_pxp.h"
+#include "intel_pxp_irq.h"
+#include "intel_pxp_pm.h"
+#include "intel_pxp_session.h"
+
+void intel_pxp_suspend(struct intel_pxp *pxp)
+{
+ if (!intel_pxp_is_enabled(pxp))
+ return;
+
+ pxp->arb_is_valid = false;
+
+ /* invalidate protected objects */
+ intel_pxp_invalidate(pxp);
+
+ intel_pxp_fini_hw(pxp);
+
+ pxp->hw_state_invalidated = false;
+}
+
+void intel_pxp_resume(struct intel_pxp
[Intel-gfx] [PATCH v8 15/17] drm/i915/pxp: add pxp debugfs
2 debugfs files, one to query the current status of the pxp session and one
to trigger an invalidation for testing.
v2: rename debugfs, fix date (Alan)
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by : Alan Previn
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gt/debugfs_gt.c | 2 +
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 78
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h | 21 ++
4 files changed, 102 insertions(+)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 366e82cec44d..b46474ee1a1f 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -285,6 +285,7 @@ i915-y += i915_perf.o
i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp.o \
pxp/intel_pxp_cmd.o \
+ pxp/intel_pxp_debugfs.o \
pxp/intel_pxp_irq.o \
pxp/intel_pxp_pm.o \
pxp/intel_pxp_session.o \
diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt.c
b/drivers/gpu/drm/i915/gt/debugfs_gt.c
index 591eb60785db..c27847ddb796 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt.c
@@ -9,6 +9,7 @@
#include "debugfs_gt.h"
#include "debugfs_gt_pm.h"
#include "intel_sseu_debugfs.h"
+#include "pxp/intel_pxp_debugfs.h"
#include "uc/intel_uc_debugfs.h"
#include "i915_drv.h"
@@ -28,6 +29,7 @@ void debugfs_gt_register(struct intel_gt *gt)
intel_sseu_debugfs_register(gt, root);
intel_uc_debugfs_register(>uc, root);
+ intel_pxp_debugfs_register(>pxp, root);
}
void intel_gt_debugfs_register_files(struct dentry *root,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
new file mode 100644
index ..cbb1853676cc
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include
+#include
+
+#include "gt/debugfs_gt.h"
+#include "pxp/intel_pxp.h"
+#include "pxp/intel_pxp_irq.h"
+#include "i915_drv.h"
+
+static int pxp_info_show(struct seq_file *m, void *data)
+{
+ struct intel_pxp *pxp = m->private;
+ struct drm_printer p = drm_seq_file_printer(m);
+ bool enabled = intel_pxp_is_enabled(pxp);
+
+ if (!enabled) {
+ drm_printf(, "pxp disabled\n");
+ return 0;
+ }
+
+ drm_printf(, "active: %s\n", yesno(intel_pxp_is_active(pxp)));
+ drm_printf(, "instance counter: %u\n", pxp->key_instance);
+
+ return 0;
+}
+DEFINE_GT_DEBUGFS_ATTRIBUTE(pxp_info);
+
+static int pxp_terminate_get(void *data, u64 *val)
+{
+ /* nothing to read */
+ return -EPERM;
+}
+
+static int pxp_terminate_set(void *data, u64 val)
+{
+ struct intel_pxp *pxp = data;
+ struct intel_gt *gt = pxp_to_gt(pxp);
+
+ if (!intel_pxp_is_active(pxp))
+ return -ENODEV;
+
+ /* simulate a termination interrupt */
+ spin_lock_irq(>irq_lock);
+ intel_pxp_irq_handler(pxp,
GEN12_DISPLAY_PXP_STATE_TERMINATED_INTERRUPT);
+ spin_unlock_irq(>irq_lock);
+
+ if (!wait_for_completion_timeout(>termination,
+msecs_to_jiffies(100)))
+ return -ETIMEDOUT;
+
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(pxp_terminate_fops, pxp_terminate_get,
pxp_terminate_set, "%llx\n");
+void intel_pxp_debugfs_register(struct intel_pxp *pxp, struct dentry *gt_root)
+{
+ static const struct debugfs_gt_file files[] = {
+ { "info", _info_fops, NULL },
+ { "terminate_state", _terminate_fops, NULL },
+ };
+ struct dentry *root;
+
+ if (!gt_root)
+ return;
+
+ if (!HAS_PXP((pxp_to_gt(pxp)->i915)))
+ return;
+
+ root = debugfs_create_dir("pxp", gt_root);
+ if (IS_ERR(root))
+ return;
+
+ intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), pxp);
+}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h
new file mode 100644
index ..7e0c3d2f5d7e
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#ifndef __INTEL_PXP_DEBUGFS_H__
+#define __INTEL_PXP_DEBUGFS_H__
+
+struct intel_pxp;
+struct dentry;
+
+#ifdef CONFIG_DRM_I915_PXP
+void intel_pxp_debugfs_register(struct intel_pxp *pxp, struct dentry *root);
+#else
+static inline void
+intel_pxp_debugfs_register(struct intel_pxp *pxp, struct dentry *root)
+{
+}
+#endif
+
+#endif /* __INTEL_PXP_DEBUGFS_H__ */
--
2.25.1
[Intel-gfx] [PATCH v8 16/17] drm/i915/pxp: add PXP documentation
Now that all the pieces are in place we can add a description of how the
feature works. Also modify the comments in struct intel_pxp into
kerneldoc.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Daniel Vetter
Cc: Rodrigo Vivi
---
Documentation/gpu/i915.rst | 8
drivers/gpu/drm/i915/pxp/intel_pxp.c | 28 +
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 47 --
3 files changed, 71 insertions(+), 12 deletions(-)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 101dde3eb1ea..78ecb9d5ec20 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -471,6 +471,14 @@ Object Tiling IOCTLs
.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_tiling.c
:doc: buffer object tiling
+Protected Objects
+-
+
+.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp.c
+ :doc: PXP
+
+.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_types.h
+
Microcontrollers
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index d8815e91e091..4e095a9a9f07 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -11,6 +11,34 @@
#include "gt/intel_context.h"
#include "i915_drv.h"
+/**
+ * DOC: PXP
+ *
+ * PXP (Protected Xe Path) is a Gen12+ feature that allows execution and
+ * flip to display of protected (i.e. encrypted) objects. The SW support is
+ * enabled via the CONFIG_DRM_I915_PXP kconfig.
+ *
+ * Some of the PXP setup operations are performed by the Management Engine,
+ * which is handled by the mei driver; communication between i915 and mei is
+ * performed via the mei_pxp component module.
+ *
+ * Objects can opt-in to PXP encryption at creation time via the
+ * I915_GEM_CREATE_EXT_PROTECTED_CONTENT create_ext flag. For objects to be
+ * correctly protected they must be used in conjunction with a context created
+ * with the I915_CONTEXT_PARAM_PROTECTED_CONTENT flag. See the documentation
+ * of those two uapi flags for details and restrictions.
+ *
+ * Protected objects are tied to a pxp session; currently we only support one
+ * session, which i915 manages and whose index is available in the uapi
+ * (I915_PROTECTED_CONTENT_DEFAULT_SESSION) for use in instructions targeting
+ * protected objects.
+ * The session is invalidated by the HW when certain events occur (e.g.
+ * suspend/resume). When this happens, all the objects that were used with the
+ * session are marked as invalid and all contexts marked as using protected
+ * content are banned. Any further attempt at using them in an execbuf call is
+ * rejected, while flips are converted to black frames.
+ */
+
/* KCR register definitions */
#define KCR_INIT _MMIO(0x320f0)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
index ae24064bb57e..73ef7d1754e1 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
@@ -16,42 +16,65 @@
struct intel_context;
struct i915_pxp_component;
+/**
+ * struct intel_pxp - pxp state
+ */
struct intel_pxp {
+ /**
+* @pxp_component: i915_pxp_component struct of the bound mei_pxp
+* module. Only set and cleared inside component bind/unbind functions,
+* which are protected by _mutex.
+*/
struct i915_pxp_component *pxp_component;
+ /**
+* @pxp_component_added: track if the pxp component has been added.
+* Set and cleared in tee init and fini functions respectively.
+*/
bool pxp_component_added;
+ /** @ce: kernel-owned context used for PXP operations */
struct intel_context *ce;
- /*
+ /** @arb_mutex: protects arb session start */
+ struct mutex arb_mutex;
+ /**
+* @arb_is_valid: tracks arb session status.
* After a teardown, the arb session can still be in play on the HW
* even if the keys are gone, so we can't rely on the HW state of the
* session to know if it's valid and need to track the status in SW.
*/
- struct mutex arb_mutex; /* protects arb session start */
bool arb_is_valid;
- /*
-* Keep track of which key instance we're on, so we can use it to
-* determine if an object was created using the current key or a
+ /**
+* @key_instance: tracks which key instance we're on, so we can use it
+* to determine if an object was created using the current key or a
* previous one.
*/
u32 key_instance;
- struct mutex tee_mutex; /* protects the tee channel binding */
+ /** @tee_mutex: protects the tee channel binding and messaging. */
+ struct mutex tee_mutex;
- /*
-* If the HW perceives an attack on the integrity of the encryption it
-* will invalidate the keys and expect SW to re-initialize the session.
-* We keep track of
[Intel-gfx] [PATCH v8 11/17] drm/i915/pxp: start the arb session on demand
Now that we can handle destruction and re-creation of the arb session,
we can postpone the start of the session to the first submission that
requires it, to avoid keeping it running with no user.
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 37 +---
drivers/gpu/drm/i915/pxp/intel_pxp.h | 5 +--
drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 6 ++--
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 10 +-
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 2 ++
7 files changed, 37 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 8d2d4dbdab7c..eef3acd99467 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -267,7 +267,9 @@ static int proto_context_set_protected(struct
drm_i915_private *i915,
* which in turn requires the device to be active.
*/
pc->pxp_wakeref = intel_runtime_pm_get(>runtime_pm);
- ret = intel_pxp_wait_for_arb_start(>gt.pxp);
+
+ if (!intel_pxp_is_active(>gt.pxp))
+ ret = intel_pxp_start(>gt.pxp);
}
return ret;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 08fd440a4622..c4d17e22e9cd 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -79,6 +79,7 @@ void intel_pxp_init(struct intel_pxp *pxp)
init_completion(>termination);
complete_all(>termination);
+ mutex_init(>arb_mutex);
INIT_WORK(>session_work, intel_pxp_session_work);
ret = create_vcs_context(pxp);
@@ -115,7 +116,7 @@ void intel_pxp_mark_termination_in_progress(struct
intel_pxp *pxp)
reinit_completion(>termination);
}
-static void intel_pxp_queue_termination(struct intel_pxp *pxp)
+static void pxp_queue_termination(struct intel_pxp *pxp)
{
struct intel_gt *gt = pxp_to_gt(pxp);
@@ -134,31 +135,41 @@ static void intel_pxp_queue_termination(struct intel_pxp
*pxp)
* the arb session is restarted from the irq work when we receive the
* termination completion interrupt
*/
-int intel_pxp_wait_for_arb_start(struct intel_pxp *pxp)
+int intel_pxp_start(struct intel_pxp *pxp)
{
+ int ret = 0;
+
if (!intel_pxp_is_enabled(pxp))
- return 0;
+ return -ENODEV;
+
+ mutex_lock(>arb_mutex);
+
+ if (pxp->arb_is_valid)
+ goto unlock;
+
+ pxp_queue_termination(pxp);
if (!wait_for_completion_timeout(>termination,
-msecs_to_jiffies(100)))
- return -ETIMEDOUT;
+ msecs_to_jiffies(100))) {
+ ret = -ETIMEDOUT;
+ goto unlock;
+ }
+
+ /* make sure the compiler doesn't optimize the double access */
+ barrier();
if (!pxp->arb_is_valid)
- return -EIO;
+ ret = -EIO;
- return 0;
+unlock:
+ mutex_unlock(>arb_mutex);
+ return ret;
}
void intel_pxp_init_hw(struct intel_pxp *pxp)
{
kcr_pxp_enable(pxp_to_gt(pxp));
intel_pxp_irq_enable(pxp);
-
- /*
-* the session could've been attacked while we weren't loaded, so
-* handle it as if it was and re-create it.
-*/
- intel_pxp_queue_termination(pxp);
}
void intel_pxp_fini_hw(struct intel_pxp *pxp)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index f942bdd2af0c..424fe00a91fb 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -34,7 +34,8 @@ void intel_pxp_init_hw(struct intel_pxp *pxp);
void intel_pxp_fini_hw(struct intel_pxp *pxp);
void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
-int intel_pxp_wait_for_arb_start(struct intel_pxp *pxp);
+
+int intel_pxp_start(struct intel_pxp *pxp);
int intel_pxp_key_check(struct intel_pxp *pxp, struct drm_i915_gem_object
*obj);
@@ -48,7 +49,7 @@ static inline void intel_pxp_fini(struct intel_pxp *pxp)
{
}
-static inline int intel_pxp_wait_for_arb_start(struct intel_pxp *pxp)
+static inline int intel_pxp_start(struct intel_pxp *pxp)
{
return -ENODEV;
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
index 46eca1e81b9b..340f20d130a8 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
@@ -31,7 +31,7 @@ void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
GEN12_DISPLAY_APP_TERMINATED_PER_FW_REQ_INTERRUPT)) {
/* immediately mark PXP as inactive on termination */
[Intel-gfx] [PATCH v8 17/17] drm/i915/pxp: enable PXP for integrated Gen12
Note that discrete cards can support PXP as well, but we haven't tested
on those yet so keeping it disabled for now.
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index d4a6a9dcf182..169837de395d 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -865,6 +865,7 @@ static const struct intel_device_info jsl_info = {
}, \
TGL_CURSOR_OFFSETS, \
.has_global_mocs = 1, \
+ .has_pxp = 1, \
.display.has_dsb = 1
static const struct intel_device_info tgl_info = {
@@ -891,6 +892,7 @@ static const struct intel_device_info rkl_info = {
#define DGFX_FEATURES \
.memory_regions = REGION_SMEM | REGION_LMEM | REGION_STOLEN_LMEM, \
.has_llc = 0, \
+ .has_pxp = 0, \
.has_snoop = 1, \
.is_dgfx = 1
--
2.25.1
[Intel-gfx] [PATCH v8 07/17] drm/i915/pxp: Create the arbitrary session after boot
From: "Huang, Sean Z"
Create the arbitrary session, with the fixed session id 0xf, after
system boot, for the case that application allocates the protected
buffer without establishing any protection session. Because the
hardware requires at least one alive session for protected buffer
creation. This arbitrary session will need to be re-created after
teardown or power event because hardware encryption key won't be
valid after such cases.
The session ID is exposed as part of the uapi so it can be used as part
of userspace commands.
v2: use gt->uncore->rpm (Chris)
v3: s/arb_is_in_play/arb_is_valid (Chris), move set-up to the new
init_hw function
v4: move interface defs to separate header, set arb_is valid to false
on fini (Rodrigo)
v5: handle async component binding
Signed-off-by: Huang, Sean Z
Signed-off-by: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp.c | 7 ++
drivers/gpu/drm/i915/pxp/intel_pxp.h | 5 ++
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 74
drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 15
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 87 +++
drivers/gpu/drm/i915/pxp/intel_pxp_tee.h | 3 +
.../drm/i915/pxp/intel_pxp_tee_interface.h| 37
drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 10 +++
include/uapi/drm/i915_drm.h | 3 +
10 files changed, 242 insertions(+)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_session.c
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_session.h
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d39bd0cefc64..405e04f4dd59 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -284,6 +284,7 @@ i915-y += i915_perf.o
# Protected execution platform (PXP) support
i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp.o \
+ pxp/intel_pxp_session.o \
pxp/intel_pxp_tee.o
# Post-mortem debug and GPU hang state capture
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 66a98feb33ab..e1370f323126 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -3,6 +3,7 @@
* Copyright(c) 2020 Intel Corporation.
*/
#include "intel_pxp.h"
+#include "intel_pxp_session.h"
#include "intel_pxp_tee.h"
#include "gt/intel_context.h"
#include "i915_drv.h"
@@ -65,6 +66,8 @@ void intel_pxp_init(struct intel_pxp *pxp)
if (!HAS_PXP(gt->i915))
return;
+ mutex_init(>tee_mutex);
+
ret = create_vcs_context(pxp);
if (ret)
return;
@@ -86,6 +89,8 @@ void intel_pxp_fini(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return;
+ pxp->arb_is_valid = false;
+
intel_pxp_tee_component_fini(pxp);
destroy_vcs_context(pxp);
@@ -94,6 +99,8 @@ void intel_pxp_fini(struct intel_pxp *pxp)
void intel_pxp_init_hw(struct intel_pxp *pxp)
{
kcr_pxp_enable(pxp_to_gt(pxp));
+
+ intel_pxp_create_arb_session(pxp);
}
void intel_pxp_fini_hw(struct intel_pxp *pxp)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 5427c3b28aa9..8eeb65af78b1 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -19,6 +19,11 @@ static inline bool intel_pxp_is_enabled(const struct
intel_pxp *pxp)
return pxp->ce;
}
+static inline bool intel_pxp_is_active(const struct intel_pxp *pxp)
+{
+ return pxp->arb_is_valid;
+}
+
#ifdef CONFIG_DRM_I915_PXP
void intel_pxp_init(struct intel_pxp *pxp);
void intel_pxp_fini(struct intel_pxp *pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
new file mode 100644
index ..3331868f354c
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2020, Intel Corporation. All rights reserved.
+ */
+
+#include "drm/i915_drm.h"
+#include "i915_drv.h"
+
+#include "intel_pxp.h"
+#include "intel_pxp_session.h"
+#include "intel_pxp_tee.h"
+#include "intel_pxp_types.h"
+
+#define ARB_SESSION I915_PROTECTED_CONTENT_DEFAULT_SESSION /* shorter define */
+
+#define GEN12_KCR_SIP _MMIO(0x32260) /* KCR hwdrm session in play 0-31 */
+
+static bool intel_pxp_session_is_in_play(struct intel_pxp *pxp, u32 id)
+{
+ struct intel_gt *gt = pxp_to_gt(pxp);
+ intel_wakeref_t wakeref;
+ u32 sip = 0;
+
+ with_intel_runtime_pm(gt->uncore->rpm, wakeref)
+ sip = intel_uncore_read(gt->uncore, GEN12_KCR_SIP);
+
+ return sip & BIT(id);
+}
+
+static int pxp_wait_for_session_state(struct intel_pxp *pxp, u32 id, bool
[Intel-gfx] [PATCH v8 08/17] drm/i915/pxp: Implement arb session teardown
From: "Huang, Sean Z"
Teardown is triggered when the display topology changes and no
long meets the secure playback requirement, and hardware trashes
all the encryption keys for display. Additionally, we want to emit a
teardown operation to make sure we're clean on boot and resume
v2: emit in the ring, use high prio request (Chris)
v3: better defines, stalling flush, cleaned up and renamed submission
funcs (Chris)
Signed-off-by: Huang, Sean Z
Signed-off-by: Daniele Ceraolo Spurio
Cc: Chris Wilson
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 22 ++-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 7 +-
drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c | 141 +++
drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h | 15 ++
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 29
drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 1 +
7 files changed, 212 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 405e04f4dd59..4fb663de344d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -284,6 +284,7 @@ i915-y += i915_perf.o
# Protected execution platform (PXP) support
i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp.o \
+ pxp/intel_pxp_cmd.o \
pxp/intel_pxp_session.o \
pxp/intel_pxp_tee.o
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index 1c3af0fc0456..ec2a0a566c40 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -28,10 +28,13 @@
#define INSTR_26_TO_24_MASK0x700
#define INSTR_26_TO_24_SHIFT 24
+#define __INSTR(client) ((client) << INSTR_CLIENT_SHIFT)
+
/*
* Memory interface instructions used by the kernel
*/
-#define MI_INSTR(opcode, flags) (((opcode) << 23) | (flags))
+#define MI_INSTR(opcode, flags) \
+ (__INSTR(INSTR_MI_CLIENT) | (opcode) << 23 | (flags))
/* Many MI commands use bit 22 of the header dword for GGTT vs PPGTT */
#define MI_GLOBAL_GTT(1<<22)
@@ -57,6 +60,7 @@
#define MI_SUSPEND_FLUSH MI_INSTR(0x0b, 0)
#define MI_SUSPEND_FLUSH_EN (1<<0)
#define MI_SET_APPID MI_INSTR(0x0e, 0)
+#define MI_SET_APPID_SESSION_ID(x) ((x) << 0)
#define MI_OVERLAY_FLIPMI_INSTR(0x11, 0)
#define MI_OVERLAY_CONTINUE (0x0<<21)
#define MI_OVERLAY_ON(0x1<<21)
@@ -146,6 +150,7 @@
#define MI_STORE_REGISTER_MEM_GEN8 MI_INSTR(0x24, 2)
#define MI_SRM_LRM_GLOBAL_GTT(1<<22)
#define MI_FLUSH_DWMI_INSTR(0x26, 1) /* for GEN6 */
+#define MI_FLUSH_DW_PROTECTED_MEM_EN (1<<22)
#define MI_FLUSH_DW_STORE_INDEX (1<<21)
#define MI_INVALIDATE_TLB(1<<18)
#define MI_FLUSH_DW_OP_STOREDW (1<<14)
@@ -272,6 +277,19 @@
#define MI_MATH_REG_ZF 0x32
#define MI_MATH_REG_CF 0x33
+/*
+ * Media instructions used by the kernel
+ */
+#define MEDIA_INSTR(pipe, op, sub_op, flags) \
+ (__INSTR(INSTR_RC_CLIENT) | (pipe) << INSTR_SUBCLIENT_SHIFT | \
+ (op) << INSTR_26_TO_24_SHIFT | (sub_op) << 16 | (flags))
+
+#define MFX_WAIT MEDIA_INSTR(1, 0, 0, 0)
+#define MFX_WAIT_DW0_MFX_SYNC_CONTROL_FLAGREG_BIT(8)
+#define MFX_WAIT_DW0_PXP_SYNC_CONTROL_FLAGREG_BIT(9)
+
+#define CRYPTO_KEY_EXCHANGEMEDIA_INSTR(2, 6, 9, 0)
+
/*
* Commands used only by the command parser
*/
@@ -328,8 +346,6 @@
#define GFX_OP_3DSTATE_BINDING_TABLE_EDIT_PS \
((0x3<<29)|(0x3<<27)|(0x0<<24)|(0x47<<16))
-#define MFX_WAIT ((0x3<<29)|(0x1<<27)|(0x0<<16))
-
#define COLOR_BLT ((0x2<<29)|(0x40<<22))
#define SRC_COPY_BLT ((0x2<<29)|(0x43<<22))
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index e1370f323126..26176d43a02d 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -98,9 +98,14 @@ void intel_pxp_fini(struct intel_pxp *pxp)
void intel_pxp_init_hw(struct intel_pxp *pxp)
{
+ int ret;
+
kcr_pxp_enable(pxp_to_gt(pxp));
- intel_pxp_create_arb_session(pxp);
+ /* always emit a full termination to clean the state */
+ ret = intel_pxp_terminate_arb_session_and_global(pxp);
+ if (!ret)
+ intel_pxp_create_arb_session(pxp);
}
void intel_pxp_fini_hw(struct intel_pxp *pxp)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
new file mode 100644
index ..80678dafde15
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2020, Intel Corporation. All rights reserved.
+ */
+
[Intel-gfx] [PATCH v8 06/17] drm/i915/pxp: set KCR reg init
The setting is required by hardware to allow us doing further protection
operation such as sending commands to GPU or TEE. The register needs to
be re-programmed on resume, so for simplicitly we bundle the programming
with the component binding, which is automatically called on resume.
Further HW set-up operations will be added in the same location in
follow-up patches, so get ready for them by using a couple of
init/fini_hw wrappers instead of calling the KCR funcs directly.
v3: move programming to component binding function, rework commit msg
Signed-off-by: Huang, Sean Z
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/pxp/intel_pxp.c | 27
drivers/gpu/drm/i915/pxp/intel_pxp.h | 3 +++
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 5 +
3 files changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 400deaea2d8a..66a98feb33ab 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -7,6 +7,24 @@
#include "gt/intel_context.h"
#include "i915_drv.h"
+/* KCR register definitions */
+#define KCR_INIT _MMIO(0x320f0)
+
+/* Setting KCR Init bit is required after system boot */
+#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+
+static void kcr_pxp_enable(struct intel_gt *gt)
+{
+ intel_uncore_write(gt->uncore, KCR_INIT,
+
_MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+}
+
+static void kcr_pxp_disable(struct intel_gt *gt)
+{
+ intel_uncore_write(gt->uncore, KCR_INIT,
+
_MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+}
+
static int create_vcs_context(struct intel_pxp *pxp)
{
static struct lock_class_key pxp_lock;
@@ -71,5 +89,14 @@ void intel_pxp_fini(struct intel_pxp *pxp)
intel_pxp_tee_component_fini(pxp);
destroy_vcs_context(pxp);
+}
+
+void intel_pxp_init_hw(struct intel_pxp *pxp)
+{
+ kcr_pxp_enable(pxp_to_gt(pxp));
+}
+void intel_pxp_fini_hw(struct intel_pxp *pxp)
+{
+ kcr_pxp_disable(pxp_to_gt(pxp));
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index e87550fb9821..5427c3b28aa9 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -22,6 +22,9 @@ static inline bool intel_pxp_is_enabled(const struct
intel_pxp *pxp)
#ifdef CONFIG_DRM_I915_PXP
void intel_pxp_init(struct intel_pxp *pxp);
void intel_pxp_fini(struct intel_pxp *pxp);
+
+void intel_pxp_init_hw(struct intel_pxp *pxp);
+void intel_pxp_fini_hw(struct intel_pxp *pxp);
#else
static inline void intel_pxp_init(struct intel_pxp *pxp)
{
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index f1d8de832653..0c0c7946e6a0 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -33,6 +33,9 @@ static int i915_pxp_tee_component_bind(struct device
*i915_kdev,
pxp->pxp_component = data;
pxp->pxp_component->tee_dev = tee_kdev;
+ /* the component is required to fully start the PXP HW */
+ intel_pxp_init_hw(pxp);
+
return 0;
}
@@ -41,6 +44,8 @@ static void i915_pxp_tee_component_unbind(struct device
*i915_kdev,
{
struct intel_pxp *pxp = i915_dev_to_pxp(i915_kdev);
+ intel_pxp_fini_hw(pxp);
+
pxp->pxp_component = NULL;
}
--
2.25.1
[Intel-gfx] [PATCH v8 09/17] drm/i915/pxp: Implement PXP irq handler
From: "Huang, Sean Z"
The HW will generate a teardown interrupt when session termination is
required, which requires i915 to submit a terminating batch. Once the HW
is done with the termination it will generate another interrupt, at
which point it is safe to re-create the session.
Since the termination and re-creation flow is something we want to
trigger from the driver as well, use a common work function that can be
called both from the irq handler and from the driver set-up flows, which
has the addded benefit of allowing us to skip any extra locks because
the work itself serializes the operations.
v2: use struct completion instead of bool (Chris)
v3: drop locks, clean up functions and improve comments (Chris),
move to common work function.
v4: improve comments, simplify wait logic (Rodrigo)
v5: unconditionally set interrupts, rename state_attacked var (Rodrigo)
Signed-off-by: Huang, Sean Z
Signed-off-by: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 7 ++
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp.c | 66 +++--
drivers/gpu/drm/i915/pxp/intel_pxp.h | 8 ++
drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 99
drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 32 +++
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 54 ++-
drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 5 +-
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 8 +-
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 18
11 files changed, 283 insertions(+), 16 deletions(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4fb663de344d..b22b8c195bb8 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -285,6 +285,7 @@ i915-y += i915_perf.o
i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp.o \
pxp/intel_pxp_cmd.o \
+ pxp/intel_pxp_irq.o \
pxp/intel_pxp_session.o \
pxp/intel_pxp_tee.o
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index b2de83be4d97..699a74582d32 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -13,6 +13,7 @@
#include "intel_lrc_reg.h"
#include "intel_uncore.h"
#include "intel_rps.h"
+#include "pxp/intel_pxp_irq.h"
static void guc_irq_handler(struct intel_guc *guc, u16 iir)
{
@@ -64,6 +65,9 @@ gen11_other_irq_handler(struct intel_gt *gt, const u8
instance,
if (instance == OTHER_GTPM_INSTANCE)
return gen11_rps_irq_handler(>rps, iir);
+ if (instance == OTHER_KCR_INSTANCE)
+ return intel_pxp_irq_handler(>pxp, iir);
+
WARN_ONCE(1, "unhandled other interrupt instance=0x%x, iir=0x%x\n",
instance, iir);
}
@@ -196,6 +200,9 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
intel_uncore_write(uncore, GEN11_GPM_WGBOXPERF_INTR_MASK, ~0);
intel_uncore_write(uncore, GEN11_GUC_SG_INTR_ENABLE, 0);
intel_uncore_write(uncore, GEN11_GUC_SG_INTR_MASK, ~0);
+
+ intel_uncore_write(uncore, GEN11_CRYPTO_RSVD_INTR_ENABLE, 0);
+ intel_uncore_write(uncore, GEN11_CRYPTO_RSVD_INTR_MASK, ~0);
}
void gen11_gt_irq_postinstall(struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c2853cc005ee..84bc884bd474 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8117,6 +8117,7 @@ enum {
/* irq instances for OTHER_CLASS */
#define OTHER_GUC_INSTANCE 0
#define OTHER_GTPM_INSTANCE1
+#define OTHER_KCR_INSTANCE 4
#define GEN11_INTR_IDENTITY_REG(x) _MMIO(0x190060 + ((x) * 4))
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 26176d43a02d..b0c7edc10cc3 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -2,7 +2,9 @@
/*
* Copyright(c) 2020 Intel Corporation.
*/
+#include
#include "intel_pxp.h"
+#include "intel_pxp_irq.h"
#include "intel_pxp_session.h"
#include "intel_pxp_tee.h"
#include "gt/intel_context.h"
@@ -68,6 +70,16 @@ void intel_pxp_init(struct intel_pxp *pxp)
mutex_init(>tee_mutex);
+ /*
+* we'll use the completion to check if there is a termination pending,
+* so we start it as completed and we reinit it when a termination
+* is triggered.
+*/
+ init_completion(>termination);
+ complete_all(>termination);
+
+ INIT_WORK(>session_work, intel_pxp_session_work);
+
ret = create_vcs_context(pxp);
if (ret)
return;
@@ -96,19 +108,61 @@ void intel_pxp_fini(struct intel_pxp *pxp)
[Intel-gfx] [PATCH v8 04/17] drm/i915/pxp: allocate a vcs context for pxp usage
The context is required to send the session termination commands to the
VCS, which will be implemented in a follow-up patch. We can also use the
presence of the context as a check of pxp initialization completion.
v2: use perma-pinned context (Chris)
v3: rename pinned_context functions (Chris)
v4: split export of pinned_context functions to a separate patch (Rodrigo)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Chris Wilson
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/Makefile | 4 ++
drivers/gpu/drm/i915/gt/intel_engine.h | 2 +
drivers/gpu/drm/i915/gt/intel_gt.c | 5 ++
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++
drivers/gpu/drm/i915/pxp/intel_pxp.c | 62 ++
drivers/gpu/drm/i915/pxp/intel_pxp.h | 35
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 15 ++
7 files changed, 126 insertions(+)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.c
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.h
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_types.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index c36c8a4f0716..23f5bc268962 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -281,6 +281,10 @@ i915-y += \
i915-y += i915_perf.o
+# Protected execution platform (PXP) support
+i915-$(CONFIG_DRM_I915_PXP) += \
+ pxp/intel_pxp.o
+
# Post-mortem debug and GPU hang state capture
i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
i915-$(CONFIG_DRM_I915_SELFTEST) += \
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 87579affb952..eed4634c08cd 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -175,6 +175,8 @@ intel_write_status_page(struct intel_engine_cs *engine, int
reg, u32 value)
#define I915_GEM_HWS_SEQNO 0x40
#define I915_GEM_HWS_SEQNO_ADDR(I915_GEM_HWS_SEQNO *
sizeof(u32))
#define I915_GEM_HWS_MIGRATE (0x42 * sizeof(u32))
+#define I915_GEM_HWS_PXP 0x60
+#define I915_GEM_HWS_PXP_ADDR (I915_GEM_HWS_PXP * sizeof(u32))
#define I915_GEM_HWS_SCRATCH 0x80
#define I915_HWS_CSB_BUF0_INDEX0x10
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 2aeaae036a6f..da30919b7e99 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -21,6 +21,7 @@
#include "intel_uncore.h"
#include "intel_pm.h"
#include "shmem_utils.h"
+#include "pxp/intel_pxp.h"
void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
{
@@ -712,6 +713,8 @@ int intel_gt_init(struct intel_gt *gt)
intel_migrate_init(>migrate, gt);
+ intel_pxp_init(>pxp);
+
goto out_fw;
err_gt:
__intel_gt_disable(gt);
@@ -747,6 +750,8 @@ void intel_gt_driver_unregister(struct intel_gt *gt)
intel_rps_driver_unregister(>rps);
+ intel_pxp_fini(>pxp);
+
/*
* Upon unregistering the device to prevent any new users, cancel
* all in-flight requests so that we can quickly unbind the active
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 6fdcde64c180..8001a61f42e5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -26,6 +26,7 @@
#include "intel_rps_types.h"
#include "intel_migrate_types.h"
#include "intel_wakeref.h"
+#include "pxp/intel_pxp_types.h"
struct drm_i915_private;
struct i915_ggtt;
@@ -196,6 +197,8 @@ struct intel_gt {
struct {
u8 uc_index;
} mocs;
+
+ struct intel_pxp pxp;
};
enum intel_gt_scratch_field {
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
new file mode 100644
index ..7b2053902146
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2020 Intel Corporation.
+ */
+#include "intel_pxp.h"
+#include "gt/intel_context.h"
+#include "i915_drv.h"
+
+static int create_vcs_context(struct intel_pxp *pxp)
+{
+ static struct lock_class_key pxp_lock;
+ struct intel_gt *gt = pxp_to_gt(pxp);
+ struct intel_engine_cs *engine;
+ struct intel_context *ce;
+
+ /*
+* Find the first VCS engine present. We're guaranteed there is one
+* if we're in this function due to the check in has_pxp
+*/
+ for (engine = gt->engine_class[VIDEO_DECODE_CLASS][0]; !engine;
engine++);
+ GEM_BUG_ON(!engine || engine->class != VIDEO_DECODE_CLASS);
+
+ ce = intel_engine_create_pinned_context(engine, engine->gt->vm, SZ_4K,
+ I915_GEM_HWS_PXP_ADDR,
+ _lock, "pxp_context");
+ if (IS_ERR(ce)) {
+
[Intel-gfx] [PATCH v8 05/17] drm/i915/pxp: Implement funcs to create the TEE channel
From: "Huang, Sean Z"
Implement the funcs to create the TEE channel, so kernel can
send the TEE commands directly to TEE for creating the arbitrary
(default) session.
v2: fix locking, don't pollute dev_priv (Chris)
v3: wait for mei PXP component to be bound.
v4: drop the wait, as the component might be bound after i915 load
completes. We'll instead check when sending a tee message.
v5: fix an issue with mei_pxp module removal
v6: don't use fetch_and_zero in fini (Rodrigo)
Signed-off-by: Huang, Sean Z
Signed-off-by: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 13
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 79 ++
drivers/gpu/drm/i915/pxp/intel_pxp_tee.h | 14
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 6 ++
5 files changed, 114 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 23f5bc268962..d39bd0cefc64 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -283,7 +283,8 @@ i915-y += i915_perf.o
# Protected execution platform (PXP) support
i915-$(CONFIG_DRM_I915_PXP) += \
- pxp/intel_pxp.o
+ pxp/intel_pxp.o \
+ pxp/intel_pxp_tee.o
# Post-mortem debug and GPU hang state capture
i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 7b2053902146..400deaea2d8a 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -3,6 +3,7 @@
* Copyright(c) 2020 Intel Corporation.
*/
#include "intel_pxp.h"
+#include "intel_pxp_tee.h"
#include "gt/intel_context.h"
#include "i915_drv.h"
@@ -50,7 +51,16 @@ void intel_pxp_init(struct intel_pxp *pxp)
if (ret)
return;
+ ret = intel_pxp_tee_component_init(pxp);
+ if (ret)
+ goto out_context;
+
drm_info(>i915->drm, "Protected Xe Path (PXP) protected content
support initialized\n");
+
+ return;
+
+out_context:
+ destroy_vcs_context(pxp);
}
void intel_pxp_fini(struct intel_pxp *pxp)
@@ -58,5 +68,8 @@ void intel_pxp_fini(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return;
+ intel_pxp_tee_component_fini(pxp);
+
destroy_vcs_context(pxp);
+
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
new file mode 100644
index ..f1d8de832653
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2020 Intel Corporation.
+ */
+
+#include
+#include "drm/i915_pxp_tee_interface.h"
+#include "drm/i915_component.h"
+#include "i915_drv.h"
+#include "intel_pxp.h"
+#include "intel_pxp_tee.h"
+
+static inline struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev)
+{
+ return _to_i915(i915_kdev)->gt.pxp;
+}
+
+/**
+ * i915_pxp_tee_component_bind - bind function to pass the function pointers
to pxp_tee
+ * @i915_kdev: pointer to i915 kernel device
+ * @tee_kdev: pointer to tee kernel device
+ * @data: pointer to pxp_tee_master containing the function pointers
+ *
+ * This bind function is called during the system boot or resume from system
sleep.
+ *
+ * Return: return 0 if successful.
+ */
+static int i915_pxp_tee_component_bind(struct device *i915_kdev,
+ struct device *tee_kdev, void *data)
+{
+ struct intel_pxp *pxp = i915_dev_to_pxp(i915_kdev);
+
+ pxp->pxp_component = data;
+ pxp->pxp_component->tee_dev = tee_kdev;
+
+ return 0;
+}
+
+static void i915_pxp_tee_component_unbind(struct device *i915_kdev,
+ struct device *tee_kdev, void *data)
+{
+ struct intel_pxp *pxp = i915_dev_to_pxp(i915_kdev);
+
+ pxp->pxp_component = NULL;
+}
+
+static const struct component_ops i915_pxp_tee_component_ops = {
+ .bind = i915_pxp_tee_component_bind,
+ .unbind = i915_pxp_tee_component_unbind,
+};
+
+int intel_pxp_tee_component_init(struct intel_pxp *pxp)
+{
+ int ret;
+ struct intel_gt *gt = pxp_to_gt(pxp);
+ struct drm_i915_private *i915 = gt->i915;
+
+ ret = component_add_typed(i915->drm.dev, _pxp_tee_component_ops,
+ I915_COMPONENT_PXP);
+ if (ret < 0) {
+ drm_err(>drm, "Failed to add PXP component (%d)\n", ret);
+ return ret;
+ }
+
+ pxp->pxp_component_added = true;
+
+ return 0;
+}
+
+void intel_pxp_tee_component_fini(struct intel_pxp *pxp)
+{
+ struct drm_i915_private *i915 = pxp_to_gt(pxp)->i915;
+
+ if (!pxp->pxp_component_added)
+ return;
+
+
[Intel-gfx] [PATCH v8 02/17] mei: pxp: export pavp client to me client bus
From: Vitaly Lubart
Export PAVP client to work with i915 driver,
for binding it uses kernel component framework.
v2:drop debug prints, refactor match code to match mei_hdcp (Tomas)
Signed-off-by: Vitaly Lubart
Signed-off-by: Tomas Winkler
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Rodrigo Vivi
---
drivers/misc/mei/Kconfig | 2 +
drivers/misc/mei/Makefile | 1 +
drivers/misc/mei/pxp/Kconfig | 13 ++
drivers/misc/mei/pxp/Makefile | 7 +
drivers/misc/mei/pxp/mei_pxp.c | 229 +
drivers/misc/mei/pxp/mei_pxp.h | 18 +++
6 files changed, 270 insertions(+)
create mode 100644 drivers/misc/mei/pxp/Kconfig
create mode 100644 drivers/misc/mei/pxp/Makefile
create mode 100644 drivers/misc/mei/pxp/mei_pxp.c
create mode 100644 drivers/misc/mei/pxp/mei_pxp.h
diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig
index f5fd5b786607..0e0bcd0da852 100644
--- a/drivers/misc/mei/Kconfig
+++ b/drivers/misc/mei/Kconfig
@@ -47,3 +47,5 @@ config INTEL_MEI_TXE
Intel Bay Trail
source "drivers/misc/mei/hdcp/Kconfig"
+source "drivers/misc/mei/pxp/Kconfig"
+
diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile
index f1c76f7ee804..d8e5165917f2 100644
--- a/drivers/misc/mei/Makefile
+++ b/drivers/misc/mei/Makefile
@@ -26,3 +26,4 @@ mei-$(CONFIG_EVENT_TRACING) += mei-trace.o
CFLAGS_mei-trace.o = -I$(src)
obj-$(CONFIG_INTEL_MEI_HDCP) += hdcp/
+obj-$(CONFIG_INTEL_MEI_PXP) += pxp/
diff --git a/drivers/misc/mei/pxp/Kconfig b/drivers/misc/mei/pxp/Kconfig
new file mode 100644
index ..4029b96afc04
--- /dev/null
+++ b/drivers/misc/mei/pxp/Kconfig
@@ -0,0 +1,13 @@
+
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2020, Intel Corporation. All rights reserved.
+#
+config INTEL_MEI_PXP
+ tristate "Intel PXP services of ME Interface"
+ select INTEL_MEI_ME
+ depends on DRM_I915
+ help
+ MEI Support for PXP Services on Intel platforms.
+
+ Enables the ME FW services required for PXP support through
+ I915 display driver of Intel.
diff --git a/drivers/misc/mei/pxp/Makefile b/drivers/misc/mei/pxp/Makefile
new file mode 100644
index ..0329950d5794
--- /dev/null
+++ b/drivers/misc/mei/pxp/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Copyright (c) 2020, Intel Corporation. All rights reserved.
+#
+# Makefile - PXP client driver for Intel MEI Bus Driver.
+
+obj-$(CONFIG_INTEL_MEI_PXP) += mei_pxp.o
diff --git a/drivers/misc/mei/pxp/mei_pxp.c b/drivers/misc/mei/pxp/mei_pxp.c
new file mode 100644
index ..f7380d387bab
--- /dev/null
+++ b/drivers/misc/mei/pxp/mei_pxp.c
@@ -0,0 +1,229 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright © 2020 - 2021 Intel Corporation
+ */
+
+/**
+ * DOC: MEI_PXP Client Driver
+ *
+ * The mei_pxp driver acts as a translation layer between PXP
+ * protocol implementer (I915) and ME FW by translating PXP
+ * negotiation messages to ME FW command payloads and vice versa.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mei_pxp.h"
+
+/**
+ * mei_pxp_send_message() - Sends a PXP message to ME FW.
+ * @dev: device corresponding to the mei_cl_device
+ * @message: a message buffer to send
+ * @size: size of the message
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_pxp_send_message(struct device *dev, const void *message, size_t size)
+{
+ struct mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !message)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(dev);
+
+ /* temporary drop const qualifier till the API is fixed */
+ byte = mei_cldev_send(cldev, (u8 *)message, size);
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ return 0;
+}
+
+/**
+ * mei_pxp_receive_message() - Receives a PXP message from ME FW.
+ * @dev: device corresponding to the mei_cl_device
+ * @buffer: a message buffer to contain the received message
+ * @size: size of the buffer
+ * Return: bytes sent on Success, <0 on Failure
+ */
+static int
+mei_pxp_receive_message(struct device *dev, void *buffer, size_t size)
+{
+ struct mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !buffer)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(dev);
+
+ byte = mei_cldev_recv(cldev, buffer, size);
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+ return byte;
+ }
+
+ return byte;
+}
+
+static const struct i915_pxp_component_ops mei_pxp_ops = {
+ .owner = THIS_MODULE,
+ .send = mei_pxp_send_message,
+ .recv = mei_pxp_receive_message,
+};
+
+static int mei_component_master_bind(struct device *dev)
+{
+ struct mei_cl_device *cldev = to_mei_cl_device(dev);
+ struct i915_pxp_component *comp_master =
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Introduce Intel PXP (rev6)
== Series Details == Series: drm/i915: Introduce Intel PXP (rev6) URL : https://patchwork.freedesktop.org/series/90503/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: Introduce Intel PXP (rev6)
== Series Details == Series: drm/i915: Introduce Intel PXP (rev6) URL : https://patchwork.freedesktop.org/series/90503/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./include/uapi/drm/i915_drm.h:1876: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
[Intel-gfx] [PATCH v3 09/13] drm/i915/dg2: configure TRANS_DP2_CTL for DP 2.0
Set the DP 2.0 128b/132b channel encoding for UHBR rates.
v2: Fix UHBR port clock check, use intel_dp_is_uhbr()
Bspec: 54128
Reviewed-by: Manasi Navare # v1
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_ddi.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 2361f48537b5..a7b7e4fafcb3 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -408,6 +408,20 @@ static u32 bdw_trans_port_sync_master_select(enum
transcoder master_transcoder)
return master_transcoder + 1;
}
+static void
+intel_ddi_config_transcoder_dp2(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
+ u32 val = 0;
+
+ if (intel_dp_is_uhbr(crtc_state))
+ val = TRANS_DP2_128B132B_CHANNEL_CODING;
+
+ intel_de_write(i915, TRANS_DP2_CTL(cpu_transcoder), val);
+}
+
/*
* Returns the TRANS_DDI_FUNC_CTL value based on CRTC state.
*
@@ -2376,7 +2390,8 @@ static void dg2_ddi_pre_enable_dp(struct
intel_atomic_state *state,
*/
intel_ddi_enable_pipe_clock(encoder, crtc_state);
- /* 5.b Not relevant to i915 for now */
+ /* 5.b Configure transcoder for DP 2.0 128b/132b */
+ intel_ddi_config_transcoder_dp2(encoder, crtc_state);
/*
* 5.c Configure TRANS_DDI_FUNC_CTL DDI Select, DDI Mode Select & MST
--
2.30.2
[Intel-gfx] [PATCH v3 11/13] drm/i915/dg2: use 128b/132b transcoder DDI mode
128b/132b has a separate transcoder DDI mode, which also requires the
MST transport select to be set. Note that we'll use DP MST also for
single-stream 128b/132b.
Having the FDI and 128b/132b modes share the register mode value
complicates things a bit.
v2:
- Use HAS_DP20 abstraction for 128b/132b mode (Ville)
- Use intel_dp_is_uhbr() helper
Bspec: 50493
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_ddi.c | 27 ++--
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index a7b7e4fafcb3..d2b96b2efdfe 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -506,7 +506,10 @@ intel_ddi_transcoder_func_reg_val_get(struct intel_encoder
*encoder,
temp |= TRANS_DDI_MODE_SELECT_FDI_OR_128B132B;
temp |= (crtc_state->fdi_lanes - 1) << 1;
} else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)) {
- temp |= TRANS_DDI_MODE_SELECT_DP_MST;
+ if (intel_dp_is_uhbr(crtc_state))
+ temp |= TRANS_DDI_MODE_SELECT_FDI_OR_128B132B;
+ else
+ temp |= TRANS_DDI_MODE_SELECT_DP_MST;
temp |= DDI_PORT_WIDTH(crtc_state->lane_count);
if (DISPLAY_VER(dev_priv) >= 12) {
@@ -694,7 +697,12 @@ bool intel_ddi_connector_get_hw_state(struct
intel_connector *intel_connector)
break;
case TRANS_DDI_MODE_SELECT_FDI_OR_128B132B:
- ret = type == DRM_MODE_CONNECTOR_VGA;
+ if (HAS_DP20(dev_priv))
+ /* 128b/132b */
+ ret = false;
+ else
+ /* FDI */
+ ret = type == DRM_MODE_CONNECTOR_VGA;
break;
default:
@@ -781,8 +789,9 @@ static void intel_ddi_get_encoder_pipes(struct
intel_encoder *encoder,
if ((tmp & port_mask) != ddi_select)
continue;
- if ((tmp & TRANS_DDI_MODE_SELECT_MASK) ==
- TRANS_DDI_MODE_SELECT_DP_MST)
+ if ((tmp & TRANS_DDI_MODE_SELECT_MASK) ==
TRANS_DDI_MODE_SELECT_DP_MST ||
+ (HAS_DP20(dev_priv) &&
+(tmp & TRANS_DDI_MODE_SELECT_MASK) ==
TRANS_DDI_MODE_SELECT_FDI_OR_128B132B))
mst_pipe_mask |= BIT(p);
*pipe_mask |= BIT(p);
@@ -3573,9 +3582,6 @@ static void intel_ddi_read_func_ctl(struct intel_encoder
*encoder,
pipe_config->output_types |= BIT(INTEL_OUTPUT_HDMI);
pipe_config->lane_count = 4;
break;
- case TRANS_DDI_MODE_SELECT_FDI_OR_128B132B:
- pipe_config->output_types |= BIT(INTEL_OUTPUT_ANALOG);
- break;
case TRANS_DDI_MODE_SELECT_DP_SST:
if (encoder->type == INTEL_OUTPUT_EDP)
pipe_config->output_types |= BIT(INTEL_OUTPUT_EDP);
@@ -3604,6 +3610,13 @@ static void intel_ddi_read_func_ctl(struct intel_encoder
*encoder,
pipe_config->infoframes.enable |=
intel_hdmi_infoframes_enabled(encoder,
pipe_config);
break;
+ case TRANS_DDI_MODE_SELECT_FDI_OR_128B132B:
+ if (!HAS_DP20(dev_priv)) {
+ /* FDI */
+ pipe_config->output_types |= BIT(INTEL_OUTPUT_ANALOG);
+ break;
+ }
+ fallthrough; /* 128b/132b */
case TRANS_DDI_MODE_SELECT_DP_MST:
pipe_config->output_types |= BIT(INTEL_OUTPUT_DP_MST);
pipe_config->lane_count =
--
2.30.2
[Intel-gfx] [PATCH v3 12/13] drm/i915/dg2: configure TRANS_DP2_VFREQ{HIGH, LOW} for 128b/132b
There's a new register pair for 128b/132b mode where you need to set the
pixel clock in Hz.
v2: Fix UHBR rate check, use intel_dp_is_uhbr() helper
Bspec: 54128
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index d104441344c0..97af19fd9780 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -550,6 +550,17 @@ static void intel_mst_enable_dp(struct intel_atomic_state
*state,
clear_act_sent(encoder, pipe_config);
+ if (intel_dp_is_uhbr(pipe_config)) {
+ const struct drm_display_mode *adjusted_mode =
+ _config->hw.adjusted_mode;
+ u64 crtc_clock_hz = KHz(adjusted_mode->crtc_clock);
+
+ intel_de_write(dev_priv,
TRANS_DP2_VFREQHIGH(pipe_config->cpu_transcoder),
+ TRANS_DP2_VFREQ_PIXEL_CLOCK(crtc_clock_hz >>
24));
+ intel_de_write(dev_priv,
TRANS_DP2_VFREQLOW(pipe_config->cpu_transcoder),
+ TRANS_DP2_VFREQ_PIXEL_CLOCK(crtc_clock_hz &
0xff));
+ }
+
intel_ddi_enable_transcoder_func(encoder, pipe_config);
intel_de_rmw(dev_priv, TRANS_DDI_FUNC_CTL(trans), 0,
--
2.30.2
[Intel-gfx] [PATCH v3 06/13] drm/i915/dp: add helper for checking for UHBR link rate
Helpful abstraction to avoid duplication.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 6 ++
drivers/gpu/drm/i915/display/intel_dp.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index d28bd8c4a8a5..d189d95e4450 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -115,6 +115,12 @@ bool intel_dp_is_edp(struct intel_dp *intel_dp)
static void intel_dp_unset_edid(struct intel_dp *intel_dp);
static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 dsc_max_bpc);
+/* Is link rate UHBR and thus 128b/132b? */
+bool intel_dp_is_uhbr(const struct intel_crtc_state *crtc_state)
+{
+ return crtc_state->port_clock >= 100;
+}
+
/* update sink rates from dpcd */
static void intel_dp_set_sink_rates(struct intel_dp *intel_dp)
{
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index a28fff286c21..94b568704b22 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -58,6 +58,7 @@ int intel_dp_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state);
bool intel_dp_is_edp(struct intel_dp *intel_dp);
+bool intel_dp_is_uhbr(const struct intel_crtc_state *crtc_state);
bool intel_dp_is_port_edp(struct drm_i915_private *dev_priv, enum port port);
enum irqreturn intel_dp_hpd_pulse(struct intel_digital_port *dig_port,
bool long_hpd);
--
2.30.2
[Intel-gfx] [PATCH v3 07/13] drm/i915/dp: use 128b/132b TPS2 for UHBR+ link rates
128b/132b channel encoding has separate TPS1 and TPS2, although the DPCD
register values coincide with 8b/10b TPS1 and TPS2 values. Use 128b/132b
TPS2 for channel equalization.
v2: Use intel_dp_is_uhbr
Reviewed-by: Manasi Navare # v1
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 508a514c5e37..36b35239da83 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -602,9 +602,9 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp,
}
/*
- * Pick training pattern for channel equalization. Training pattern 4 for HBR3
- * or for 1.4 devices that support it, training Pattern 3 for HBR2
- * or 1.2 devices that support it, Training Pattern 2 otherwise.
+ * Pick Training Pattern Sequence (TPS) for channel equalization. 128b/132b
TPS2
+ * for UHBR+, TPS4 for HBR3 or for 1.4 devices that support it, TPS3 for HBR2
or
+ * 1.2 devices that support it, TPS2 otherwise.
*/
static u32 intel_dp_training_pattern(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
@@ -612,6 +612,10 @@ static u32 intel_dp_training_pattern(struct intel_dp
*intel_dp,
{
bool source_tps3, sink_tps3, source_tps4, sink_tps4;
+ /* UHBR+ use separate 128b/132b TPS2 */
+ if (intel_dp_is_uhbr(crtc_state))
+ return DP_TRAINING_PATTERN_2;
+
/*
* Intel platforms that support HBR3 also support TPS4. It is mandatory
* for all downstream devices that support HBR3. There are no known eDP
--
2.30.2
[Intel-gfx] [PATCH v3 10/13] drm/i915/dp: add HAS_DP20 macro
Let's abstract the DP 2.0 feature. Initially just DG2. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_drv.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 37c1ca266bcd..14416bd789b6 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1641,6 +1641,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, #define HAS_IPS(dev_priv) (IS_HSW_ULT(dev_priv) || IS_BROADWELL(dev_priv)) #define HAS_DP_MST(dev_priv) (INTEL_INFO(dev_priv)->display.has_dp_mst) +#define HAS_DP20(dev_priv) (IS_DG2(dev_priv)) #define HAS_CDCLK_CRAWL(dev_priv) (INTEL_INFO(dev_priv)->display.has_cdclk_crawl) #define HAS_DDI(dev_priv) (INTEL_INFO(dev_priv)->display.has_ddi) -- 2.30.2
[Intel-gfx] [PATCH v3 08/13] drm/i915/dp: select 128b/132b channel encoding for UHBR rates
UHBR rates and 128b/132b channel encoding go hand in hand. v2: Fix check for >= UHBR rates using intel_dp_is_uhbr() (Ville) Reviewed-by: Manasi Navare # v1 Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_dp_link_training.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c index 36b35239da83..4f116cd32846 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c @@ -495,7 +495,8 @@ intel_dp_prepare_link_train(struct intel_dp *intel_dp, _select, 1); link_config[0] = crtc_state->vrr.enable ? DP_MSA_TIMING_PAR_IGNORE_EN : 0; - link_config[1] = DP_SET_ANSI_8B10B; + link_config[1] = intel_dp_is_uhbr(crtc_state) ? + DP_SET_ANSI_128B132B : DP_SET_ANSI_8B10B; drm_dp_dpcd_write(_dp->aux, DP_DOWNSPREAD_CTRL, link_config, 2); intel_dp->DP |= DP_PORT_EN; -- 2.30.2
[Intel-gfx] [PATCH v3 13/13] drm/i915/dg2: update link training for 128b/132b
The 128b/132b channel coding link training uses more straightforward TX
FFE preset values.
v2: Fix UHBR rate checks, use intel_dp_is_uhbr() helper
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_ddi.c | 13 ++-
.../drm/i915/display/intel_dp_link_training.c | 86 +--
2 files changed, 70 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index d2b96b2efdfe..5805bdd6e1f2 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1398,11 +1398,16 @@ static int translate_signal_level(struct intel_dp
*intel_dp,
static int intel_ddi_dp_level(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state)
{
- u8 train_set = intel_dp->train_set[0];
- u8 signal_levels = train_set & (DP_TRAIN_VOLTAGE_SWING_MASK |
- DP_TRAIN_PRE_EMPHASIS_MASK);
+ if (intel_dp_is_uhbr(crtc_state)) {
+ /* FIXME: We'll want independent presets for each lane. */
+ return intel_dp->train_set[0] & DP_TX_FFE_PRESET_VALUE_MASK;
+ } else {
+ u8 train_set = intel_dp->train_set[0];
+ u8 signal_levels = train_set & (DP_TRAIN_VOLTAGE_SWING_MASK |
+ DP_TRAIN_PRE_EMPHASIS_MASK);
- return translate_signal_level(intel_dp, signal_levels);
+ return translate_signal_level(intel_dp, signal_levels);
+ }
}
static void
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 4f116cd32846..c10f165d1aa2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -301,6 +301,24 @@ static u8 intel_dp_phy_preemph_max(struct intel_dp
*intel_dp,
return preemph_max;
}
+static void intel_dp_128b132b_adjust_train(struct intel_dp *intel_dp,
+ const struct intel_crtc_state
*crtc_state,
+ const u8
link_status[DP_LINK_STATUS_SIZE])
+{
+ int lane;
+ u8 tx_ffe = 0;
+
+ /*
+* FIXME: We'll want independent presets for each lane. See also
+* intel_ddi_dp_level() and intel_snps_phy_ddi_vswing_sequence().
+*/
+ for (lane = 0; lane < crtc_state->lane_count; lane++)
+ tx_ffe = max(tx_ffe,
drm_dp_get_adjust_tx_ffe_preset(link_status, lane));
+
+ for (lane = 0; lane < crtc_state->lane_count; lane++)
+ intel_dp->train_set[lane] = tx_ffe;
+}
+
void
intel_dp_get_adjust_train(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
@@ -313,6 +331,11 @@ intel_dp_get_adjust_train(struct intel_dp *intel_dp,
u8 voltage_max;
u8 preemph_max;
+ if (intel_dp_is_uhbr(crtc_state)) {
+ intel_dp_128b132b_adjust_train(intel_dp, crtc_state,
link_status);
+ return;
+ }
+
for (lane = 0; lane < crtc_state->lane_count; lane++) {
v = max(v, drm_dp_get_adjust_request_voltage(link_status,
lane));
p = max(p, drm_dp_get_adjust_request_pre_emphasis(link_status,
lane));
@@ -402,14 +425,21 @@ void intel_dp_set_signal_levels(struct intel_dp *intel_dp,
u8 train_set = intel_dp->train_set[0];
char phy_name[10];
- drm_dbg_kms(_priv->drm, "Using vswing level %d%s, pre-emphasis
level %d%s, at %s\n",
- train_set & DP_TRAIN_VOLTAGE_SWING_MASK,
- train_set & DP_TRAIN_MAX_SWING_REACHED ? " (max)" : "",
- (train_set & DP_TRAIN_PRE_EMPHASIS_MASK) >>
- DP_TRAIN_PRE_EMPHASIS_SHIFT,
- train_set & DP_TRAIN_MAX_PRE_EMPHASIS_REACHED ?
- " (max)" : "",
- intel_dp_phy_name(dp_phy, phy_name, sizeof(phy_name)));
+ if (intel_dp_is_uhbr(crtc_state)) {
+ /* FIXME: We'll want independent presets for each lane. */
+ drm_dbg_kms(_priv->drm, "%s: Using 128b/132b TX FFE preset
%u\n",
+ intel_dp_phy_name(dp_phy, phy_name,
sizeof(phy_name)),
+ train_set & DP_TX_FFE_PRESET_VALUE_MASK);
+ } else {
+ drm_dbg_kms(_priv->drm, "%s: Using 8b/10b vswing level
%d%s, pre-emphasis level %d%s\n",
+ intel_dp_phy_name(dp_phy, phy_name,
sizeof(phy_name)),
+ train_set & DP_TRAIN_VOLTAGE_SWING_MASK,
+ train_set & DP_TRAIN_MAX_SWING_REACHED ? " (max)" :
"",
+ (train_set & DP_TRAIN_PRE_EMPHASIS_MASK) >>
+ DP_TRAIN_PRE_EMPHASIS_SHIFT,
+ train_set & DP_TRAIN_MAX_PRE_EMPHASIS_REACHED ?
+
Re: [Intel-gfx] [BUG - BISECTED] display not detected anymore
Hi Ville,
> > > > ef79d62b5ce5 ("drm/i915: Encapsulate dbuf state handling harder")
> > > >
> > > > With that commit the display is not detected anymore, one commit
> > > > before that it still works. So this one seems to be broken.
> > > >
> > > > Ville, Stanislav, any idea how to fix this?
> > > >
> > > > commit ef79d62b5ce53851901d6c1d21b74cbb9e27219b
> > > > Author: Ville Syrjälä
> > > > Date: Fri Jan 22 22:56:32 2021 +0200
> > > >
> > > > drm/i915: Encapsulate dbuf state handling harder
> > >
> > > That has nothing to do with display detection, so very mysterious.
> > >
> > > Please file a bug at https://gitlab.freedesktop.org/drm/intel/issues/new
> > > boot with drm.debug=0xe with both good and bad kernels and attach the
> > > dmesg from both to the bug.
> >
> > Everything (hopefully) provided here:
> > https://gitlab.freedesktop.org/drm/intel/-/issues/4013
> >
> > Please let me know if you need more, or if I can help otherwise to
> > resolve this.
>
> Did you have any time to look into this already?
How do we proceed with this? Saying that this is either "very
mysterious" or "very strange" won't fix the regression. :)
Thanks,
Heiko
[Intel-gfx] [PATCH v8 00/17] drm/i915: Introduce Intel PXP
PXP (Protected Xe Path) is an i915 component, available on GEN12+, that helps to establish the hardware protected session and manage the status of the alive software session, as well as its life cycle. The main change from v7 is that we no longer increase the guilty count when a context is banned due to PXP invalidation Tested with: https://patchwork.freedesktop.org/series/87570/ Cc: Gaurav Kumar Cc: Chris Wilson Cc: Rodrigo Vivi Cc: Joonas Lahtinen Cc: Juston Li Cc: Alan Previn Cc: Lionel Landwerlin Cc: Jason Ekstrand Cc: Daniel Vetter Anshuman Gupta (2): drm/i915/pxp: Add plane decryption support drm/i915/pxp: black pixels on pxp disabled Daniele Ceraolo Spurio (9): drm/i915/pxp: Define PXP component interface drm/i915/pxp: define PXP device flag and kconfig drm/i915/pxp: allocate a vcs context for pxp usage drm/i915/pxp: set KCR reg init drm/i915/pxp: interfaces for using protected objects drm/i915/pxp: start the arb session on demand drm/i915/pxp: add pxp debugfs drm/i915/pxp: add PXP documentation drm/i915/pxp: enable PXP for integrated Gen12 Huang, Sean Z (5): drm/i915/pxp: Implement funcs to create the TEE channel drm/i915/pxp: Create the arbitrary session after boot drm/i915/pxp: Implement arb session teardown drm/i915/pxp: Implement PXP irq handler drm/i915/pxp: Enable PXP power management Vitaly Lubart (1): mei: pxp: export pavp client to me client bus Documentation/gpu/i915.rst| 8 + drivers/gpu/drm/i915/Kconfig | 11 + drivers/gpu/drm/i915/Makefile | 10 + drivers/gpu/drm/i915/display/intel_display.c | 34 +++ .../drm/i915/display/intel_display_types.h| 6 + .../drm/i915/display/skl_universal_plane.c| 49 ++- drivers/gpu/drm/i915/gem/i915_gem_context.c | 100 +- drivers/gpu/drm/i915/gem/i915_gem_context.h | 6 + .../gpu/drm/i915/gem/i915_gem_context_types.h | 28 ++ drivers/gpu/drm/i915/gem/i915_gem_create.c| 72 +++-- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 18 ++ drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 + drivers/gpu/drm/i915/gem/i915_gem_object.h| 6 + .../gpu/drm/i915/gem/i915_gem_object_types.h | 8 + .../gpu/drm/i915/gem/selftests/mock_context.c | 4 +- drivers/gpu/drm/i915/gt/debugfs_gt.c | 2 + drivers/gpu/drm/i915/gt/intel_engine.h| 2 + drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 22 +- drivers/gpu/drm/i915/gt/intel_gt.c| 5 + drivers/gpu/drm/i915/gt/intel_gt_irq.c| 7 + drivers/gpu/drm/i915/gt/intel_gt_pm.c | 15 +- drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 + drivers/gpu/drm/i915/i915_drv.c | 2 + drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_pci.c | 2 + drivers/gpu/drm/i915/i915_reg.h | 48 +++ drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/pxp/intel_pxp.c | 287 ++ drivers/gpu/drm/i915/pxp/intel_pxp.h | 67 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c | 141 + drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h | 15 + drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 78 + drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h | 21 ++ drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 100 ++ drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 32 ++ drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 40 +++ drivers/gpu/drm/i915/pxp/intel_pxp_pm.h | 23 ++ drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 175 +++ drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 15 + drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 172 +++ drivers/gpu/drm/i915/pxp/intel_pxp_tee.h | 17 ++ .../drm/i915/pxp/intel_pxp_tee_interface.h| 37 +++ drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 83 + drivers/misc/mei/Kconfig | 2 + drivers/misc/mei/Makefile | 1 + drivers/misc/mei/pxp/Kconfig | 13 + drivers/misc/mei/pxp/Makefile | 7 + drivers/misc/mei/pxp/mei_pxp.c| 229 ++ drivers/misc/mei/pxp/mei_pxp.h| 18 ++ include/drm/i915_component.h | 1 + include/drm/i915_pxp_tee_interface.h | 42 +++ include/uapi/drm/i915_drm.h | 55 +++- 52 files changed, 2102 insertions(+), 42 deletions(-) create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.h create mode 100644
[Intel-gfx] [PATCH v8 01/17] drm/i915/pxp: Define PXP component interface
This will be used for communication between the i915 driver and the mei
one. Defining it in a stand-alone patch to avoid circualr dependedencies
between the patches modifying the 2 drivers.
Split out from an original patch from Huang, Sean Z
v2: rename the component struct (Rodrigo)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
---
include/drm/i915_component.h | 1 +
include/drm/i915_pxp_tee_interface.h | 42
2 files changed, 43 insertions(+)
create mode 100644 include/drm/i915_pxp_tee_interface.h
diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
index 55c3b123581b..c1e2a43d2d1e 100644
--- a/include/drm/i915_component.h
+++ b/include/drm/i915_component.h
@@ -29,6 +29,7 @@
enum i915_component_type {
I915_COMPONENT_AUDIO = 1,
I915_COMPONENT_HDCP,
+ I915_COMPONENT_PXP
};
/* MAX_PORT is the number of port
diff --git a/include/drm/i915_pxp_tee_interface.h
b/include/drm/i915_pxp_tee_interface.h
new file mode 100644
index ..af593ec64469
--- /dev/null
+++ b/include/drm/i915_pxp_tee_interface.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#ifndef _I915_PXP_TEE_INTERFACE_H_
+#define _I915_PXP_TEE_INTERFACE_H_
+
+#include
+#include
+
+/**
+ * struct i915_pxp_component_ops - ops for PXP services.
+ * @owner: Module providing the ops
+ * @send: sends data to PXP
+ * @receive: receives data from PXP
+ */
+struct i915_pxp_component_ops {
+ /**
+* @owner: owner of the module provding the ops
+*/
+ struct module *owner;
+
+ int (*send)(struct device *dev, const void *message, size_t size);
+ int (*recv)(struct device *dev, void *buffer, size_t size);
+};
+
+/**
+ * struct i915_pxp_component - Used for communication between i915 and TEE
+ * drivers for the PXP services
+ * @tee_dev: device that provide the PXP service from TEE Bus.
+ * @pxp_ops: Ops implemented by TEE driver, used by i915 driver.
+ */
+struct i915_pxp_component {
+ struct device *tee_dev;
+ const struct i915_pxp_component_ops *ops;
+
+ /* To protect the above members. */
+ struct mutex mutex;
+};
+
+#endif /* _I915_TEE_PXP_INTERFACE_H_ */
--
2.25.1
[Intel-gfx] [PATCH v8 03/17] drm/i915/pxp: define PXP device flag and kconfig
Ahead of the PXP implementation, define the relevant define flag and
kconfig option.
v2: flip kconfig default to N. Some machines have IFWIs that do not
support PXP, so we need it to be an opt-in until we add support to query
the caps from the mei device.
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/Kconfig | 11 +++
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/intel_device_info.h | 1 +
3 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index f960f5d7664e..5987c3d5d9fb 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -131,6 +131,17 @@ config DRM_I915_GVT_KVMGT
Choose this option if you want to enable KVMGT support for
Intel GVT-g.
+config DRM_I915_PXP
+ bool "Enable Intel PXP support for Intel Gen12+ platform"
+ depends on DRM_I915
+ depends on INTEL_MEI && INTEL_MEI_PXP
+ default n
+ help
+ PXP (Protected Xe Path) is an i915 component, available on GEN12+
+ GPUs, that helps to establish the hardware protected session and
+ manage the status of the alive software session, as well as its life
+ cycle.
+
menu "drm/i915 Debugging"
depends on DRM_I915
depends on EXPERT
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 37c1ca266bcd..447a248f14aa 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1678,6 +1678,9 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_GLOBAL_MOCS_REGISTERS(dev_priv)
(INTEL_INFO(dev_priv)->has_global_mocs)
+#define HAS_PXP(dev_priv) (IS_ENABLED(CONFIG_DRM_I915_PXP) && \
+ INTEL_INFO(dev_priv)->has_pxp) && \
+ VDBOX_MASK(_priv->gt)
#define HAS_GMCH(dev_priv) (INTEL_INFO(dev_priv)->display.has_gmch)
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index d328bb95c49b..8e6f48d1eb7b 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -133,6 +133,7 @@ enum intel_ppgtt_type {
func(has_logical_ring_elsq); \
func(has_mslices); \
func(has_pooled_eu); \
+ func(has_pxp); \
func(has_rc6); \
func(has_rc6p); \
func(has_rps); \
--
2.25.1
[Intel-gfx] [PATCH v3 00/13] drm/i915/dp: dp 2.0 enabling prep work
v3 of https://patchwork.freedesktop.org/series/93800/ with minor tweaks
and the already merged patches obviously dropped.
Jani Nikula (13):
drm/dp: add DP 2.0 UHBR link rate and bw code conversions
drm/dp: use more of the extended receiver cap
drm/dp: add LTTPR DP 2.0 DPCD addresses
drm/dp: add helper for extracting adjust 128b/132b TX FFE preset
drm/i915/dg2: add DG2+ TRANS_DDI_FUNC_CTL DP 2.0 128b/132b mode
drm/i915/dp: add helper for checking for UHBR link rate
drm/i915/dp: use 128b/132b TPS2 for UHBR+ link rates
drm/i915/dp: select 128b/132b channel encoding for UHBR rates
drm/i915/dg2: configure TRANS_DP2_CTL for DP 2.0
drm/i915/dp: add HAS_DP20 macro
drm/i915/dg2: use 128b/132b transcoder DDI mode
drm/i915/dg2: configure TRANS_DP2_VFREQ{HIGH,LOW} for 128b/132b
drm/i915/dg2: update link training for 128b/132b
drivers/gpu/drm/drm_dp_helper.c | 42 +++-
drivers/gpu/drm/i915/display/intel_ddi.c | 61 +---
drivers/gpu/drm/i915/display/intel_dp.c | 6 ++
drivers/gpu/drm/i915/display/intel_dp.h | 1 +
.../drm/i915/display/intel_dp_link_training.c | 99 +--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 11 +++
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 2 +-
include/drm/drm_dp_helper.h | 6 ++
9 files changed, 180 insertions(+), 49 deletions(-)
--
2.30.2
[Intel-gfx] [PATCH v3 04/13] drm/dp: add helper for extracting adjust 128b/132b TX FFE preset
The DP 2.0 128b/132b channel coding uses TX FFE presets instead of
vswing and pre-emphasis.
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c | 14 ++
include/drm/drm_dp_helper.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 2e74b02ed96b..4d0d1e8e51fa 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -130,6 +130,20 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
link_status[DP_LINK_STATUS_SI
}
EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
+/* DP 2.0 128b/132b */
+u8 drm_dp_get_adjust_tx_ffe_preset(const u8 link_status[DP_LINK_STATUS_SIZE],
+ int lane)
+{
+ int i = DP_ADJUST_REQUEST_LANE0_1 + (lane >> 1);
+ int s = ((lane & 1) ?
+DP_ADJUST_TX_FFE_PRESET_LANE1_SHIFT :
+DP_ADJUST_TX_FFE_PRESET_LANE0_SHIFT);
+ u8 l = dp_link_status(link_status, i);
+
+ return (l >> s) & 0xf;
+}
+EXPORT_SYMBOL(drm_dp_get_adjust_tx_ffe_preset);
+
u8 drm_dp_get_adjust_request_post_cursor(const u8
link_status[DP_LINK_STATUS_SIZE],
unsigned int lane)
{
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index f3a61341011d..3ee0b3ffb8a5 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1494,6 +1494,8 @@ u8 drm_dp_get_adjust_request_voltage(const u8
link_status[DP_LINK_STATUS_SIZE],
int lane);
u8 drm_dp_get_adjust_request_pre_emphasis(const u8
link_status[DP_LINK_STATUS_SIZE],
int lane);
+u8 drm_dp_get_adjust_tx_ffe_preset(const u8 link_status[DP_LINK_STATUS_SIZE],
+ int lane);
u8 drm_dp_get_adjust_request_post_cursor(const u8
link_status[DP_LINK_STATUS_SIZE],
unsigned int lane);
--
2.30.2
[Intel-gfx] [PATCH v3 03/13] drm/dp: add LTTPR DP 2.0 DPCD addresses
DP 2.0 brings some new DPCD addresses for PHY repeaters.
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Manasi Navare
Signed-off-by: Jani Nikula
---
include/drm/drm_dp_helper.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 1d5b3dbb6e56..f3a61341011d 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1319,6 +1319,10 @@ struct drm_panel;
#define DP_MAX_LANE_COUNT_PHY_REPEATER 0xf0004 /* 1.4a */
#define DP_Repeater_FEC_CAPABILITY 0xf0004 /* 1.4 */
#define DP_PHY_REPEATER_EXTENDED_WAIT_TIMEOUT 0xf0005 /* 1.4a */
+#define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xf0006 /* 2.0 */
+# define DP_PHY_REPEATER_128B132B_SUPPORTED(1 << 0)
+/* See DP_128B132B_SUPPORTED_LINK_RATES for values */
+#define DP_PHY_REPEATER_128B132B_RATES 0xf0007 /* 2.0 */
enum drm_dp_phy {
DP_PHY_DPRX,
--
2.30.2
[Intel-gfx] [PATCH v3 01/13] drm/dp: add DP 2.0 UHBR link rate and bw code conversions
The bw code equals link_rate / 0.27 Gbps only for 8b/10b link
rates. Handle DP 2.0 UHBR rates as special cases, though this is not
pretty.
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 6d0f2c447f3b..9b2a2961fca8 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -207,15 +207,33 @@ EXPORT_SYMBOL(drm_dp_lttpr_link_train_channel_eq_delay);
u8 drm_dp_link_rate_to_bw_code(int link_rate)
{
- /* Spec says link_bw = link_rate / 0.27Gbps */
- return link_rate / 27000;
+ switch (link_rate) {
+ case 100:
+ return DP_LINK_BW_10;
+ case 135:
+ return DP_LINK_BW_13_5;
+ case 200:
+ return DP_LINK_BW_20;
+ default:
+ /* Spec says link_bw = link_rate / 0.27Gbps */
+ return link_rate / 27000;
+ }
}
EXPORT_SYMBOL(drm_dp_link_rate_to_bw_code);
int drm_dp_bw_code_to_link_rate(u8 link_bw)
{
- /* Spec says link_rate = link_bw * 0.27Gbps */
- return link_bw * 27000;
+ switch (link_bw) {
+ case DP_LINK_BW_10:
+ return 100;
+ case DP_LINK_BW_13_5:
+ return 135;
+ case DP_LINK_BW_20:
+ return 200;
+ default:
+ /* Spec says link_rate = link_bw * 0.27Gbps */
+ return link_bw * 27000;
+ }
}
EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate);
--
2.30.2
[Intel-gfx] [PATCH v3 02/13] drm/dp: use more of the extended receiver cap
Extend the use of extended receiver cap at 0x2200 to cover
MAIN_LINK_CHANNEL_CODING_CAP in 0x2206, in case an implementation hides
the DP 2.0 128b/132b channel encoding cap.
v2: Extend to DP_RECEIVER_CAP_SIZE (Ville)
Cc: Lyude Paul
Cc: dri-de...@lists.freedesktop.org
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 9b2a2961fca8..2e74b02ed96b 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -608,7 +608,7 @@ static u8 drm_dp_downstream_port_count(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
u8 dpcd[DP_RECEIVER_CAP_SIZE])
{
- u8 dpcd_ext[6];
+ u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
int ret;
/*
--
2.30.2
[Intel-gfx] [PATCH v3 05/13] drm/i915/dg2: add DG2+ TRANS_DDI_FUNC_CTL DP 2.0 128b/132b mode
Unfortunately, the DP 2.0 128b/132b DDI mode selection in the register
conflicts with FDI. Since we have to deal with both meanings in the same
code, for different platforms, clarify the macro name so we don't
forget.
Bspec: 50493
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_ddi.c | 6 +++---
drivers/gpu/drm/i915/i915_reg.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 23ef291f7b30..2361f48537b5 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -489,7 +489,7 @@ intel_ddi_transcoder_func_reg_val_get(struct intel_encoder
*encoder,
if (crtc_state->hdmi_high_tmds_clock_ratio)
temp |= TRANS_DDI_HIGH_TMDS_CHAR_RATE;
} else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_ANALOG)) {
- temp |= TRANS_DDI_MODE_SELECT_FDI;
+ temp |= TRANS_DDI_MODE_SELECT_FDI_OR_128B132B;
temp |= (crtc_state->fdi_lanes - 1) << 1;
} else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)) {
temp |= TRANS_DDI_MODE_SELECT_DP_MST;
@@ -679,7 +679,7 @@ bool intel_ddi_connector_get_hw_state(struct
intel_connector *intel_connector)
ret = false;
break;
- case TRANS_DDI_MODE_SELECT_FDI:
+ case TRANS_DDI_MODE_SELECT_FDI_OR_128B132B:
ret = type == DRM_MODE_CONNECTOR_VGA;
break;
@@ -3558,7 +3558,7 @@ static void intel_ddi_read_func_ctl(struct intel_encoder
*encoder,
pipe_config->output_types |= BIT(INTEL_OUTPUT_HDMI);
pipe_config->lane_count = 4;
break;
- case TRANS_DDI_MODE_SELECT_FDI:
+ case TRANS_DDI_MODE_SELECT_FDI_OR_128B132B:
pipe_config->output_types |= BIT(INTEL_OUTPUT_ANALOG);
break;
case TRANS_DDI_MODE_SELECT_DP_SST:
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c2853cc005ee..03a94389c514 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10202,7 +10202,7 @@ enum skl_power_gate {
#define TRANS_DDI_MODE_SELECT_DVI (1 << 24)
#define TRANS_DDI_MODE_SELECT_DP_SST (2 << 24)
#define TRANS_DDI_MODE_SELECT_DP_MST (3 << 24)
-#define TRANS_DDI_MODE_SELECT_FDI (4 << 24)
+#define TRANS_DDI_MODE_SELECT_FDI_OR_128B132B (4 << 24)
#define TRANS_DDI_BPC_MASK(7 << 20)
#define TRANS_DDI_BPC_8 (0 << 20)
#define TRANS_DDI_BPC_10 (1 << 20)
--
2.30.2
[Intel-gfx] [PATCH v5] drm/i915: Use Transparent Hugepages when IOMMU is enabled
From: Tvrtko Ursulin
Usage of Transparent Hugepages was disabled in 9987da4b5dcf
("drm/i915: Disable THP until we have a GPU read BW W/A"), but since it
appears majority of performance regressions reported with an enabled IOMMU
can be almost eliminated by turning them on, lets just do that.
To err on the side of safety we keep the current default in cases where
IOMMU is not active, and only when it is default to the "huge=within_size"
mode. Although there probably would be wins to enable them throughout,
more extensive testing across benchmarks and platforms would need to be
done.
With the patch and IOMMU enabled my local testing on a small Skylake part
shows OglVSTangent regression being reduced from ~14% (IOMMU on versus
IOMMU off) to ~2% (same comparison but with THP on).
More detailed testing done in the below referenced Gitlab issue by Eero:
Skylake GT4e:
Performance drops from enabling IOMMU:
30-35% SynMark CSDof
20-25% Unigine Heaven, MemBW GPU write, SynMark VSTangent
~20% GLB Egypt (1/2 screen window)
10-15% GLB T-Rex (1/2 screen window)
8-10% GfxBench T-Rex, MemBW GPU blit
7-8% SynMark DeferredAA + TerrainFly* + ZBuffer
6-7% GfxBench Manhattan 3.0 + 3.1, SynMark TexMem128 & CSCloth
5-6% GfxBench CarChase, Unigine Valley
3-5% GfxBench Vulkan & GL AztecRuins + ALU2, MemBW GPU texture,
SynMark Fill*, Deferred, TerrainPan*
1-2% Most of the other tests
With the patch drops become:
20-25% SynMark TexMem*
15-20% GLB Egypt (1/2 screen window)
10-15% GLB T-Rex (1/2 screen window)
4-7% GfxBench T-Rex, GpuTest Triangle
1-8% GfxBench ALU2 (offscreen 1%, onscreen 8%)
3% GfxBench Manhattan 3.0, SynMark CSDof
2-3% Unigine Heaven + Valley, MemBW GPU texture
1-3 GfxBench Manhattan 3.1 + CarChase + Vulkan & GL AztecRuins
Broxton:
Performance drops from IOMMU, without patch:
30% MemBW GPU write
25% SynMark ZBuffer + Fill*
20% MemBW GPU blit
15% MemBW GPU blend, GpuTest Triangle
10-15% MemBW GPU texture
10% GLB Egypt, Unigine Heaven (had hangs), SynMark TerrainFly*
7-9% GLB T-Rex, GfxBench Manhattan 3.0 + T-Rex,
SynMark Deferred* + TexMem*
6-8% GfxBench CarChase, Unigine Valley,
SynMark CSCloth + ShMapVsm + TerrainPan*
5-6% GfxBench Manhattan 3.1 + GL AztecRuins,
SynMark CSDof + TexFilterTri
2-4% GfxBench ALU2, SynMark DrvRes + GSCloth + ShMapPcf + Batch[0-5] +
TexFilterAniso, GpuTest GiMark + 32-bit Julia
And with patch:
15-20% MemBW GPU texture
10% SynMark TexMem*
8-9% GLB Egypt (1/2 screen window)
4-5% GLB T-Rex (1/2 screen window)
3-6% GfxBench Manhattan 3.0, GpuTest FurMark,
SynMark Deferred + TexFilterTri
3-4% GfxBench Manhattan 3.1 + T-Rex, SynMark VSInstancing
2-4% GpuTest Triangle, SynMark DeferredAA
2-3% Unigine Heaven + Valley
1-3% SynMark Terrain*
1-2% GfxBench CarChase, SynMark TexFilterAniso + ZBuffer
Tigerlake-H:
20-25% MemBW GPU texture
15-20% GpuTest Triangle
13-15% SynMark TerrainFly* + DeferredAA + HdrBloom
8-10% GfxBench Manhattan 3.1, SynMark TerrainPan* + DrvRes
6-7% GfxBench Manhattan 3.0, SynMark TexMem*
4-8% GLB onscreen Fill + T-Rex + Egypt (more in onscreen than
offscreen versions of T-Rex/Egypt)
4-6% GfxBench CarChase + GLES AztecRuins + ALU2, GpuTest 32-bit Julia,
SynMark CSDof + DrvState
3-5% GfxBench T-Rex + Egypt, Unigine Heaven + Valley, GpuTest Plot3D
1-7% Media tests
2-3% MemBW GPU blit
1-3% Most of the rest of 3D tests
With the patch:
6-8% MemBW GPU blend => the only regression in these tests (compared
to IOMMU without THP)
4-6% SynMark DrvState (not impacted) + HdrBloom (improved)
3-4% GLB T-Rex
~3% GLB Egypt, SynMark DrvRes
1-3% GfxBench T-Rex + Egypt, SynMark TexFilterTri
1-2% GfxBench CarChase + GLES AztecRuins, Unigine Valley,
GpuTest Triangle
~1% GfxBench Manhattan 3.0/3.1, Unigine Heaven
Perf of several tests actually improved with IOMMU + THP, compared to no
IOMMU / no THP:
10-15% SynMark Batch[0-3]
5-10% MemBW GPU texture, SynMark ShMapVsm
3-4% SynMark Fill* + Geom*
2-3% SynMark TexMem512 + CSCloth
1-2% SynMark TexMem128 + DeferredAA
As a summary across all platforms, these are the benchmarks where enabling
THP on top of IOMMU enabled brings regressions:
* Skylake GT4e:
20-25% SynMark TexMem*
(whereas all MemBW GPU tests either improve or are not affected)
* Broxton J4205:
7% MemBW GPU texture
2-3% SynMark TexMem*
* Tigerlake-H:
7% MemBW GPU blend
Other benchmarks show either lowering of regressions or improvements.
v2:
* Add Kconfig dependency to transparent hugepages and some help text.
* Move to helper for easier handling of kernel build options.
v3:
* Drop Kconfig. (Daniel)
v4:
* Add some benchmark results to commit message.
v5:
* Add explicit regression summary to commit message. (Eero)
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Introduce Intel PXP (rev6)
== Series Details == Series: drm/i915: Introduce Intel PXP (rev6) URL : https://patchwork.freedesktop.org/series/90503/ State : warning == Summary == $ dim checkpatch origin/drm-tip 4b04867d778d drm/i915/pxp: Define PXP component interface -:31: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #31: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 49 lines checked 48b326460b6f mei: pxp: export pavp client to me client bus -:36: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #36: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 276 lines checked 95ad0c8a1ff6 drm/i915/pxp: define PXP device flag and kconfig -:46: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #46: FILE: drivers/gpu/drm/i915/i915_drv.h:1681: +#define HAS_PXP(dev_priv) (IS_ENABLED(CONFIG_DRM_I915_PXP) && \ + INTEL_INFO(dev_priv)->has_pxp) && \ + VDBOX_MASK(_priv->gt) -:46: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible side-effects? #46: FILE: drivers/gpu/drm/i915/i915_drv.h:1681: +#define HAS_PXP(dev_priv) (IS_ENABLED(CONFIG_DRM_I915_PXP) && \ + INTEL_INFO(dev_priv)->has_pxp) && \ + VDBOX_MASK(_priv->gt) total: 1 errors, 0 warnings, 1 checks, 33 lines checked 32d2a598f087 drm/i915/pxp: allocate a vcs context for pxp usage -:98: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #98: new file mode 100644 -:122: ERROR:TRAILING_STATEMENTS: trailing statements should be on next line #122: FILE: drivers/gpu/drm/i915/pxp/intel_pxp.c:20: + for (engine = gt->engine_class[VIDEO_DECODE_CLASS][0]; !engine; engine++); total: 1 errors, 1 warnings, 0 checks, 168 lines checked ce029c5228f4 drm/i915/pxp: Implement funcs to create the TEE channel -:78: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #78: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 148 lines checked cc2086cc202f drm/i915/pxp: set KCR reg init 6c57836d2dda drm/i915/pxp: Create the arbitrary session after boot -:98: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #98: new file mode 100644 -:383: CHECK:LINE_SPACING: Please don't use multiple blank lines #383: FILE: drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h:36: + + total: 0 errors, 1 warnings, 1 checks, 337 lines checked 10e6202ef0ff drm/i915/pxp: Implement arb session teardown -:63: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #63: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:153: +#define MI_FLUSH_DW_PROTECTED_MEM_EN (1<<22) ^ -:117: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #117: new file mode 100644 total: 0 errors, 1 warnings, 1 checks, 283 lines checked 8098ad3734e4 drm/i915/pxp: Implement PXP irq handler -:211: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #211: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 423 lines checked f2ea2f8e1f45 drm/i915/pxp: interfaces for using protected objects 5f170f70a91c drm/i915/pxp: start the arb session on demand 61274982b95b drm/i915/pxp: Enable PXP power management -:121: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #121: new file mode 100644 -:189: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #189: FILE: drivers/gpu/drm/i915/pxp/intel_pxp_pm.h:18: +} +static inline void intel_pxp_resume(struct intel_pxp *pxp) total: 0 errors, 1 warnings, 1 checks, 232 lines checked 48584fd7f1e0 drm/i915/pxp: Add plane decryption support -:36: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #36: v10 (Daniele): update PXP check again to match rework in earlier patches and total: 0 errors, 1 warnings, 0 checks, 155 lines checked 87c269e251cd drm/i915/pxp: black pixels on pxp disabled -:169: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible side-effects? #169: FILE: drivers/gpu/drm/i915/i915_reg.h:11411: +#define PLANE_CSC_COEFF(pipe, plane, index)_MMIO_PLANE(plane, \ + _PLANE_CSC_RY_GY_1(pipe) + (index) * 4, \ + _PLANE_CSC_RY_GY_2(pipe) + (index) * 4) -:169: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'index' - possible side-effects? #169: FILE: drivers/gpu/drm/i915/i915_reg.h:11411: +#define PLANE_CSC_COEFF(pipe, plane, index)_MMIO_PLANE(plane, \ + _PLANE_CSC_RY_GY_1(pipe) + (index) * 4, \ +
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use Transparent Hugepages when IOMMU is enabled (rev3)
== Series Details ==
Series: drm/i915: Use Transparent Hugepages when IOMMU is enabled (rev3)
URL : https://patchwork.freedesktop.org/series/93122/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10565 -> Patchwork_21000
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/index.html
Known issues
Here are the changes found in Patchwork_21000 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u: NOTRUN -> [SKIP][1] ([fdo#109271]) +27 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
* igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u: NOTRUN -> [WARN][2] ([i915#3718])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-soraka: [PASS][3] -> [INCOMPLETE][4] ([i915#155])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4: [PASS][5] -> [FAIL][6] ([i915#1888])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
* igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#3958])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][9] -> [INCOMPLETE][10] ([i915#3921])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@late_gt_pm:
- fi-bsw-n3050: [PASS][11] -> [DMESG-FAIL][12] ([i915#2927] /
[i915#3428])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-bsw-n3050/igt@i915_selftest@live@late_gt_pm.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/fi-bsw-n3050/igt@i915_selftest@live@late_gt_pm.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
* igt@runner@aborted:
- fi-bsw-n3050: NOTRUN -> [FAIL][14] ([fdo#109271] / [i915#1436] /
[i915#3428])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/fi-bsw-n3050/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@gt_pm:
- {fi-jsl-1}: [DMESG-FAIL][15] ([i915#1886]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21000/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#2927]: https://gitlab.freedesktop.org/drm/intel/issues/2927
[i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
[i915#3718]: https://gitlab.freedesktop.org/drm/intel/issues/3718
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#3958]: https://gitlab.freedesktop.org/drm/intel/issues/3958
Participating hosts (47 -> 39)
--
Missing(8): fi-ilk-m540 bat-adls-5 bat-dg1-6 fi-bsw-cyan bat-adlp-4
fi-ctg-p8600 fi-bdw-samus bat-jsl-1
Build changes
-
* Linux: CI_DRM_10565 -> Patchwork_21000
CI-20190529: 20190529
CI_DRM_10565: 8c3cd60dcfa81a649b14f0705eb5e5c9336f1881 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6201: be0d02ff0775235ead63ccb1e3a1e8c10f0209cf @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_21000: 50ce004fa7ce24ff0060bacd17288ba912c1f5d8 @
[Intel-gfx] ✗ Fi.CI.BUILD: failure for kernel/locking: Add context to ww_mutex_trylock. (rev2)
== Series Details == Series: kernel/locking: Add context to ww_mutex_trylock. (rev2) URL : https://patchwork.freedesktop.org/series/94437/ State : failure == Summary == Patch is empty. 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".
Re: [Intel-gfx] [PATCH v7 15/17] drm/i915/pxp: add pxp debugfs
On 9/9/2021 1:17 AM, Teres Alexis, Alan Previn wrote:
I dont see any issues except a couple of nits.
Reviewed-by : Alan Previn
...alan
On Fri, 2021-08-27 at 18:27 -0700, Daniele Ceraolo Spurio wrote:
2 debugfs files, one to query the current status of the pxp session and one
to trigger an invalidation for testing.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gt/debugfs_gt.c | 2 +
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 78
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h | 21 ++
4 files changed, 102 insertions(+)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6f6cbbe98b96..9a44d6f01e3b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -284,6 +284,7 @@ i915-y += i915_perf.o
i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp.o \
pxp/intel_pxp_cmd.o \
+ pxp/intel_pxp_debugfs.o \
pxp/intel_pxp_irq.o \
pxp/intel_pxp_pm.o \
pxp/intel_pxp_session.o \
diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt.c
b/drivers/gpu/drm/i915/gt/debugfs_gt.c
index 591eb60785db..c27847ddb796 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt.c
@@ -9,6 +9,7 @@
#include "debugfs_gt.h"
#include "debugfs_gt_pm.h"
#include "intel_sseu_debugfs.h"
+#include "pxp/intel_pxp_debugfs.h"
#include "uc/intel_uc_debugfs.h"
#include "i915_drv.h"
@@ -28,6 +29,7 @@ void debugfs_gt_register(struct intel_gt *gt)
intel_sseu_debugfs_register(gt, root);
intel_uc_debugfs_register(>uc, root);
+ intel_pxp_debugfs_register(>pxp, root);
}
void intel_gt_debugfs_register_files(struct dentry *root,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
new file mode 100644
index ..a26e4396ba6c
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include
+#include
+
+#include "gt/debugfs_gt.h"
+#include "pxp/intel_pxp.h"
+#include "pxp/intel_pxp_irq.h"
+#include "i915_drv.h"
+
+static int pxp_info_show(struct seq_file *m, void *data)
+{
+ struct intel_pxp *pxp = m->private;
+ struct drm_printer p = drm_seq_file_printer(m);
+ bool enabled = intel_pxp_is_enabled(pxp);
+
+ if (!enabled) {
+ drm_printf(, "pxp disabled\n");
+ return 0;
+ }
+
+ drm_printf(, "active: %s\n", yesno(intel_pxp_is_active(pxp)));
+ drm_printf(, "instance counter: %u\n", pxp->key_instance);
+
+ return 0;
+}
+DEFINE_GT_DEBUGFS_ATTRIBUTE(pxp_info);
+
+static int pxp_inval_get(void *data, u64 *val)
+{
+ /* nothing to read */
+ return -EPERM;
+}
+
+static int pxp_inval_set(void *data, u64 val)
+{
+ struct intel_pxp *pxp = data;
+ struct intel_gt *gt = pxp_to_gt(pxp);
+
+ if (!intel_pxp_is_active(pxp))
+ return -ENODEV;
+
+ /* simulate an invalidation interrupt */
+ spin_lock_irq(>irq_lock);
+ intel_pxp_irq_handler(pxp,
GEN12_DISPLAY_PXP_STATE_TERMINATED_INTERRUPT);
+ spin_unlock_irq(>irq_lock);
+
+ if (!wait_for_completion_timeout(>termination,
+msecs_to_jiffies(100)))
+ return -ETIMEDOUT;
+
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(pxp_inval_fops, pxp_inval_get, pxp_inval_set,
"%llx\n");
+void intel_pxp_debugfs_register(struct intel_pxp *pxp, struct dentry *gt_root)
+{
+ static const struct debugfs_gt_file files[] = {
+ { "info", _info_fops, NULL },
+ { "invalidate", _inval_fops, NULL },
NIT only: consider naming to "invalidate_display" or "display_inval" since we
are using this to trigger
display pxp teardown specific irq code path.
I went with "terminate_state", because the termination interrupt can
come from the display but can also come from the ME and we handle both
in the same way. What we want to test is the termination path that we
enter when a termination interrupt is received, we don't really care who
the source of the interrupt is.
Daniele
+ };
+ struct dentry *root;
+
+ if (!gt_root)
+ return;
+
+ if (!HAS_PXP((pxp_to_gt(pxp)->i915)))
+ return;
+
+ root = debugfs_create_dir("pxp", gt_root);
+ if (IS_ERR(root))
+ return;
+
+ intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), pxp);
+}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h
new file mode 100644
index ..3b7454d838e9
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h
@@ -0,0 +1,21
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Use Transparent Hugepages when IOMMU is enabled (rev3)
== Series Details ==
Series: drm/i915: Use Transparent Hugepages when IOMMU is enabled (rev3)
URL : https://patchwork.freedesktop.org/series/93122/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
50ce004fa7ce drm/i915: Use Transparent Hugepages when IOMMU is enabled
-:6: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 9987da4b5dcf ("drm/i915: Disable
THP until we have a GPU read BW W/A")'
#6:
Usage of Transparent Hugepages was disabled in 9987da4b5dcf
-:149: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit
<12+ chars of sha1> ("")' - ie: 'commit b901bb89324a
("drm/i915/gemfs: enable THP")'
#149:
References: b901bb89324a ("drm/i915/gemfs: enable THP")
-:150: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#150:
References: 9987da4b5dcf ("drm/i915: Disable THP until we have a GPU read BW
W/A")
-:150: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit
<12+ chars of sha1> ("")' - ie: 'commit 9987da4b5dcf ("drm/i915:
Disable THP until we have a GPU read BW W/A")'
#150:
References: 9987da4b5dcf ("drm/i915: Disable THP until we have a GPU read BW
W/A")
-:196: WARNING:STATIC_CONST_CHAR_ARRAY: static char array declaration should
probably be static const char
#196: FILE: drivers/gpu/drm/i915/gem/i915_gemfs.c:36:
+ static char huge_opt[] = "huge=within_size"; /* r/w */
total: 3 errors, 2 warnings, 0 checks, 42 lines checked
Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Add fetch of hwconfig table
On Thu, Sep 02, 2021 at 05:53:32PM -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Implement support for fetching the hardware description table from the
> GuC. The call is made twice - once without a destination buffer to
> query the size and then a second time to fill in the buffer.
>
> Note that the table is only available on ADL-P and later platforms.
>
> Cc: Michal Wajdeczko
> Signed-off-by: Rodrigo Vivi
> Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 +
> .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 4 +
> drivers/gpu/drm/i915/gt/uc/intel_guc.c| 3 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 +
> .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 156 ++
> .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.h | 19 +++
> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 +
> 8 files changed, 191 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
> create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index c01518f86c5f..68bc90ff873b 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -191,6 +191,7 @@ i915-y += gt/uc/intel_uc.o \
> gt/uc/intel_guc_rc.o \
> gt/uc/intel_guc_slpc.o \
> gt/uc/intel_guc_submission.o \
> + gt/uc/intel_guc_hwconfig.o \
> gt/uc/intel_huc.o \
> gt/uc/intel_huc_debugfs.o \
> gt/uc/intel_huc_fw.o
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> index 8ff58aff..72fd492b726a 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> @@ -137,6 +137,7 @@ enum intel_guc_action {
> INTEL_GUC_ACTION_ENGINE_FAILURE_NOTIFICATION = 0x1009,
> INTEL_GUC_ACTION_SETUP_PC_GUCRC = 0x3004,
> INTEL_GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
> + INTEL_GUC_ACTION_GET_HWCONFIG = 0x4100,
> INTEL_GUC_ACTION_REGISTER_CONTEXT = 0x4502,
> INTEL_GUC_ACTION_DEREGISTER_CONTEXT = 0x4503,
> INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER = 0x4505,
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
> b/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
> index 488b6061ee89..f9e2a6aaef4a 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
> @@ -8,6 +8,10 @@
>
> enum intel_guc_response_status {
> INTEL_GUC_RESPONSE_STATUS_SUCCESS = 0x0,
> + INTEL_GUC_RESPONSE_NOT_SUPPORTED = 0x20,
> + INTEL_GUC_RESPONSE_NO_ATTRIBUTE_TABLE = 0x201,
> + INTEL_GUC_RESPONSE_NO_DECRYPTION_KEY = 0x202,
> + INTEL_GUC_RESPONSE_DECRYPTION_FAILED = 0x204,
> INTEL_GUC_RESPONSE_STATUS_GENERIC_FAIL = 0xF000,
> };
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> index fbfcae727d7f..82c0ce0090c6 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -422,13 +422,14 @@ int intel_guc_send_mmio(struct intel_guc *guc, const
> u32 *request, u32 len,
> /*
>* No GuC command should ever take longer than 10ms.
>* Fast commands should still complete in 10us.
> + * Except for the hwconfig table query, which takes ~50ms.
>*/
> ret = __intel_wait_for_register_fw(uncore,
> guc_send_reg(guc, 0),
> GUC_HXG_MSG_0_ORIGIN,
> FIELD_PREP(GUC_HXG_MSG_0_ORIGIN,
> GUC_HXG_ORIGIN_GUC),
> -10, 10, );
> +10, 100, );
> if (unlikely(ret)) {
> timeout:
> drm_err(>drm, "mmio request %#x: no reply %x\n",
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> index 2e27fe59786b..66c00033fea1 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> @@ -13,6 +13,7 @@
> #include "intel_guc_fw.h"
> #include "intel_guc_fwif.h"
> #include "intel_guc_ct.h"
> +#include "intel_guc_hwconfig.h"
> #include "intel_guc_log.h"
> #include "intel_guc_reg.h"
> #include "intel_guc_slpc_types.h"
> @@ -32,6 +33,7 @@ struct intel_guc {
> struct intel_guc_log log;
> struct intel_guc_ct ct;
> struct intel_guc_slpc slpc;
> + struct intel_guc_hwconfig hwconfig;
>
> /* Global engine used to submit requests to GuC */
> struct i915_sched_engine *sched_engine;
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
>
[Intel-gfx] [PATCH 06/23] drm/i915/guc: Workaround reset G2H is received after schedule done G2H
If the context is reset as a result of the request cancellation the
context reset G2H is received after schedule disable done G2H which is
the wrong order. The schedule disable done G2H release the waiting
request cancellation code which resubmits the context. This races
with the context reset G2H which also wants to resubmit the context but
in this case it really should be a NOP as request cancellation code owns
the resubmit. Use some clever tricks of checking the context state to
seal this race until the GuC firmware is fixed.
v2:
(Checkpatch)
- Fix typos
v3:
(Daniele)
- State that is a bug in the GuC firmware
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew Brost
Cc:
Reviewed-by: Daniele Ceraolo Spurio
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 41 ---
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 31bbfe5479ae..f9e3725b94c1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -833,17 +833,33 @@ __unwind_incomplete_requests(struct intel_context *ce)
static void __guc_reset_context(struct intel_context *ce, bool stalled)
{
struct i915_request *rq;
+ unsigned long flags;
u32 head;
+ bool skip = false;
intel_context_get(ce);
/*
-* GuC will implicitly mark the context as non-schedulable
-* when it sends the reset notification. Make sure our state
-* reflects this change. The context will be marked enabled
-* on resubmission.
+* GuC will implicitly mark the context as non-schedulable when it sends
+* the reset notification. Make sure our state reflects this change. The
+* context will be marked enabled on resubmission.
+*
+* XXX: If the context is reset as a result of the request cancellation
+* this G2H is received after the schedule disable complete G2H which is
+* wrong as this creates a race between the request cancellation code
+* re-submitting the context and this G2H handler. This is a bug in the
+* GuC but can be worked around in the meantime but converting this to a
+* NOP if a pending enable is in flight as this indicates that a request
+* cancellation has occurred.
*/
- clr_context_enabled(ce);
+ spin_lock_irqsave(>guc_state.lock, flags);
+ if (likely(!context_pending_enable(ce)))
+ clr_context_enabled(ce);
+ else
+ skip = true;
+ spin_unlock_irqrestore(>guc_state.lock, flags);
+ if (unlikely(skip))
+ goto out_put;
rq = intel_context_find_active_request(ce);
if (!rq) {
@@ -862,6 +878,7 @@ static void __guc_reset_context(struct intel_context *ce,
bool stalled)
out_replay:
guc_reset_state(ce, head, stalled);
__unwind_incomplete_requests(ce);
+out_put:
intel_context_put(ce);
}
@@ -1598,6 +1615,13 @@ static void guc_context_cancel_request(struct
intel_context *ce,
guc_reset_state(ce, intel_ring_wrap(ce->ring, rq->head),
true);
}
+
+ /*
+* XXX: Racey if context is reset, see comment in
+* __guc_reset_context().
+*/
+ flush_work(_to_guc(ce)->ct.requests.worker);
+
guc_context_unblock(ce);
}
}
@@ -2712,7 +2736,12 @@ static void guc_handle_context_reset(struct intel_guc
*guc,
{
trace_intel_context_reset(ce);
- if (likely(!intel_context_is_banned(ce))) {
+ /*
+* XXX: Racey if request cancellation has occurred, see comment in
+* __guc_reset_context().
+*/
+ if (likely(!intel_context_is_banned(ce) &&
+ !context_blocked(ce))) {
capture_error_state(guc, ce);
guc_context_replay(ce);
}
--
2.32.0
[Intel-gfx] [PATCH 00/23] Clean up GuC CI failures, simplify locking, and kernel DOC
Daniel Vetter pointed out that locking in the GuC submission code was overly complicated, let's clean this up a bit before introducing more features in the GuC submission backend. Also fix some CI failures, port fixes from our internal tree, and add a few more selftests for coverage. Lastly, add some kernel DOC explaining how the GuC submission backend works. v2: Fix logic error in 'Workaround reset G2H is received after schedule done G2H', don't propagate errors to dependent fences in execlists submissiom, resolve checkpatch issues, resend to correct lists v3: Fix issue kicking tasklet, drop guc_active, fix ref counting in xarray, add guc_id sub structure, drop inline fuctions, and various other cleanup suggested by Daniel v4: Address Daniele's feedback, rebase to tip, resend for CI v5 [Daniele taking over while Matt is out]: drop patches 8 and 27 for now (not critical, Matt will update and resend when he's back), address review comments, improve kerneldoc. Also move all code related to busy loop to patch 2 so we have a standalone fix. v6: Drop allocate of error capture in nowait context, drop flushing of work queue (will get respun individually). Signed-off-by: Matthew Brost Signed-off-by: Daniele Ceraolo Spurio #v5 Matthew Brost (23): drm/i915/guc: Fix blocked context accounting drm/i915/guc: Fix outstanding G2H accounting drm/i915/guc: Unwind context requests in reverse order drm/i915/guc: Don't drop ce->guc_active.lock when unwinding context drm/i915/guc: Process all G2H message at once in work queue drm/i915/guc: Workaround reset G2H is received after schedule done G2H Revert "drm/i915/gt: Propagate change in error status to children on unhold" drm/i915/guc: Kick tasklet after queuing a request drm/i915/guc: Don't enable scheduling on a banned context, guc_id invalid, not registered drm/i915/guc: Copy whole golden context, set engine state size of subset drm/i915/selftests: Add initial GuC selftest for scrubbing lost G2H drm/i915/guc: Take context ref when cancelling request drm/i915/guc: Don't touch guc_state.sched_state without a lock drm/i915/guc: Reset LRC descriptor if register returns -ENODEV drm/i915/guc: Release submit fence from an irq_work drm/i915/guc: Move guc_blocked fence to struct guc_state drm/i915/guc: Rework and simplify locking drm/i915/guc: Proper xarray usage for contexts_lookup drm/i915/guc: Drop pin count check trick between sched_disable and re-pin drm/i915/guc: Move GuC priority fields in context under guc_active drm/i915/guc: Move fields protected by guc->contexts_lock into sub structure drm/i915/guc: Drop guc_active move everything into guc_state drm/i915/guc: Add GuC kernel doc Documentation/gpu/i915.rst| 2 + drivers/gpu/drm/i915/gt/intel_context.c | 19 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 80 +- .../drm/i915/gt/intel_execlists_submission.c | 4 - drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 6 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h| 75 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 26 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 904 +++--- drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 127 +++ drivers/gpu/drm/i915/i915_request.h | 26 +- drivers/gpu/drm/i915/i915_trace.h | 12 +- .../drm/i915/selftests/i915_live_selftests.h | 1 + .../i915/selftests/intel_scheduler_helpers.c | 12 + .../i915/selftests/intel_scheduler_helpers.h | 2 + 15 files changed, 872 insertions(+), 430 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/uc/selftest_guc.c -- 2.32.0
[Intel-gfx] [PATCH 03/23] drm/i915/guc: Unwind context requests in reverse order
When unwinding requests on a reset context, if other requests in the
context are in the priority list the requests could be resubmitted out
of seqno order. Traverse the list of active requests in reverse and
append to the head of the priority list to fix this.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
Cc:
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index aff5dd247a88..0c1e6b465fba 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -806,9 +806,9 @@ __unwind_incomplete_requests(struct intel_context *ce)
spin_lock_irqsave(_engine->lock, flags);
spin_lock(>guc_active.lock);
- list_for_each_entry_safe(rq, rn,
->guc_active.requests,
-sched.link) {
+ list_for_each_entry_safe_reverse(rq, rn,
+>guc_active.requests,
+sched.link) {
if (i915_request_completed(rq))
continue;
@@ -825,7 +825,7 @@ __unwind_incomplete_requests(struct intel_context *ce)
}
GEM_BUG_ON(i915_sched_engine_is_empty(sched_engine));
- list_add_tail(>sched.link, pl);
+ list_add(>sched.link, pl);
set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
spin_lock(>guc_active.lock);
--
2.32.0
[Intel-gfx] [PATCH 04/23] drm/i915/guc: Don't drop ce->guc_active.lock when unwinding context
Don't drop ce->guc_active.lock when unwinding a context after reset.
At one point we had to drop this because of a lock inversion but that is
no longer the case. It is much safer to hold the lock so let's do that.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
Cc:
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0c1e6b465fba..31bbfe5479ae 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -813,8 +813,6 @@ __unwind_incomplete_requests(struct intel_context *ce)
continue;
list_del_init(>sched.link);
- spin_unlock(>guc_active.lock);
-
__i915_request_unsubmit(rq);
/* Push the request back into the queue for later resubmission.
*/
@@ -827,8 +825,6 @@ __unwind_incomplete_requests(struct intel_context *ce)
list_add(>sched.link, pl);
set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
-
- spin_lock(>guc_active.lock);
}
spin_unlock(>guc_active.lock);
spin_unlock_irqrestore(_engine->lock, flags);
--
2.32.0
[Intel-gfx] [PATCH 13/23] drm/i915/guc: Don't touch guc_state.sched_state without a lock
Before we did some clever tricks to not use the a lock when touching
guc_state.sched_state in certain cases. Don't do that, enforce the use
of the lock.
v2:
(kernel test robo )
- Add __maybe_unused to sched_state_is_init()
v3: rebase after the unused code path removal has been moved to an
earlier patch.
Signed-off-by: Matthew Brost
Reported-by: kernel test robot
Reviewed-by: Daniele Ceraolo Spurio
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 22 ++-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index e036a171ff17..ca73128d7b4d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -151,11 +151,23 @@ static inline void clr_context_registered(struct
intel_context *ce)
static inline void init_sched_state(struct intel_context *ce)
{
- /* Only should be called from guc_lrc_desc_pin() */
+ lockdep_assert_held(>guc_state.lock);
atomic_set(>guc_sched_state_no_lock, 0);
ce->guc_state.sched_state &= SCHED_STATE_BLOCKED_MASK;
}
+__maybe_unused
+static bool sched_state_is_init(struct intel_context *ce)
+{
+ /*
+* XXX: Kernel contexts can have SCHED_STATE_NO_LOCK_REGISTERED after
+* suspend.
+*/
+ return !(atomic_read(>guc_sched_state_no_lock) &
+~SCHED_STATE_NO_LOCK_REGISTERED) &&
+ !(ce->guc_state.sched_state &= ~SCHED_STATE_BLOCKED_MASK);
+}
+
static inline bool
context_wait_for_deregister_to_register(struct intel_context *ce)
{
@@ -166,7 +178,7 @@ context_wait_for_deregister_to_register(struct
intel_context *ce)
static inline void
set_context_wait_for_deregister_to_register(struct intel_context *ce)
{
- /* Only should be called from guc_lrc_desc_pin() without lock */
+ lockdep_assert_held(>guc_state.lock);
ce->guc_state.sched_state |=
SCHED_STATE_WAIT_FOR_DEREGISTER_TO_REGISTER;
}
@@ -607,9 +619,7 @@ static void scrub_guc_desc_for_outstanding_g2h(struct
intel_guc *guc)
bool pending_disable, pending_enable, deregister, destroyed, banned;
xa_for_each(>context_lookup, index, ce) {
- /* Flush context */
spin_lock_irqsave(>guc_state.lock, flags);
- spin_unlock_irqrestore(>guc_state.lock, flags);
/*
* Once we are at this point submission_disabled() is guaranteed
@@ -625,6 +635,8 @@ static void scrub_guc_desc_for_outstanding_g2h(struct
intel_guc *guc)
banned = context_banned(ce);
init_sched_state(ce);
+ spin_unlock_irqrestore(>guc_state.lock, flags);
+
if (pending_enable || destroyed || deregister) {
decr_outstanding_submission_g2h(guc);
if (deregister)
@@ -1324,6 +1336,7 @@ static int guc_lrc_desc_pin(struct intel_context *ce,
bool loop)
int ret = 0;
GEM_BUG_ON(!engine->mask);
+ GEM_BUG_ON(!sched_state_is_init(ce));
/*
* Ensure LRC + CT vmas are is same region as write barrier is done
@@ -1352,7 +1365,6 @@ static int guc_lrc_desc_pin(struct intel_context *ce,
bool loop)
desc->priority = ce->guc_prio;
desc->context_flags = CONTEXT_REGISTRATION_FLAG_KMD;
guc_context_policy_init(engine, desc);
- init_sched_state(ce);
/*
* The context_lookup xarray is used to determine if the hardware
--
2.32.0
[Intel-gfx] [PATCH 01/23] drm/i915/guc: Fix blocked context accounting
Prior to this patch the blocked context counter was cleared on
init_sched_state (used during registering a context & resets) which is
incorrect. This state needs to be persistent or the counter can read the
incorrect value resulting in scheduling never getting enabled again.
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew Brost
Reviewed-by: Daniel Vetter
Cc:
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 87d8dc8f51b9..69faa39da178 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -152,7 +152,7 @@ static inline void init_sched_state(struct intel_context
*ce)
{
/* Only should be called from guc_lrc_desc_pin() */
atomic_set(>guc_sched_state_no_lock, 0);
- ce->guc_state.sched_state = 0;
+ ce->guc_state.sched_state &= SCHED_STATE_BLOCKED_MASK;
}
static inline bool
--
2.32.0
[Intel-gfx] [PATCH 05/23] drm/i915/guc: Process all G2H message at once in work queue
Rather than processing 1 G2H at a time and re-queuing the work queue if
more messages exist, process all the G2H in a single pass of the work
queue.
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
Cc: Daniel Vetter
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 22b4733b55e2..20c710a74498 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -1042,9 +1042,9 @@ static void ct_incoming_request_worker_func(struct
work_struct *w)
container_of(w, struct intel_guc_ct, requests.worker);
bool done;
- done = ct_process_incoming_requests(ct);
- if (!done)
- queue_work(system_unbound_wq, >requests.worker);
+ do {
+ done = ct_process_incoming_requests(ct);
+ } while (!done);
}
static int ct_handle_event(struct intel_guc_ct *ct, struct ct_incoming_msg
*request)
--
2.32.0
[Intel-gfx] ✓ Fi.CI.BAT: success for Enable GuC submission by default on DG1 (rev4)
== Series Details ==
Series: Enable GuC submission by default on DG1 (rev4)
URL : https://patchwork.freedesktop.org/series/93325/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10565 -> Patchwork_21003
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21003/index.html
Known issues
Here are the changes found in Patchwork_21003 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u: NOTRUN -> [SKIP][1] ([fdo#109271]) +27 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21003/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
* igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u: NOTRUN -> [WARN][2] ([i915#3718])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21003/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827]) +8
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21003/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
Possible fixes
* igt@i915_selftest@live@gt_pm:
- {fi-jsl-1}: [DMESG-FAIL][4] ([i915#1886]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21003/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#3718]: https://gitlab.freedesktop.org/drm/intel/issues/3718
Participating hosts (47 -> 39)
--
Missing(8): fi-ilk-m540 bat-adls-5 bat-dg1-6 fi-bsw-cyan bat-adlp-4
fi-ctg-p8600 fi-bdw-samus bat-jsl-1
Build changes
-
* Linux: CI_DRM_10565 -> Patchwork_21003
CI-20190529: 20190529
CI_DRM_10565: 8c3cd60dcfa81a649b14f0705eb5e5c9336f1881 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6201: be0d02ff0775235ead63ccb1e3a1e8c10f0209cf @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_21003: 9fb951546c18f2195d202fa2fc7a252614ddd2f6 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
9fb951546c18 drm/i915: Get PM ref before accessing HW register
e76c7801ac7b Me: Dump GuC log to dmesg on SLPC load failure
c999fb206dc0 Me: Workaround LMEM blow up
8201803a4cca Me: Allow relocs on DG1 for CI
11a547556597 drm/i915/guc: Enable GuC submission by default on DG1
921371699ce0 drm/i915/guc: Add DG1 GuC / HuC firmware defs
60923cb16879 drm/i915/guc: put all guc objects in lmem when available
b2951b760586 drm/i915: Do not define vma on stack
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21003/index.html
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Clean up GuC CI failures, simplify locking, and kernel DOC (rev11)
== Series Details ==
Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev11)
URL : https://patchwork.freedesktop.org/series/93704/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
deb17f151cef drm/i915/guc: Fix blocked context accounting
7b4cd4d6bb36 drm/i915/guc: Fix outstanding G2H accounting
ea81f9db116d drm/i915/guc: Unwind context requests in reverse order
a6990f6f2a54 drm/i915/guc: Don't drop ce->guc_active.lock when unwinding context
31c0bfa6a01d drm/i915/guc: Process all G2H message at once in work queue
5f8dae15114c drm/i915/guc: Workaround reset G2H is received after schedule done
G2H
0a9d7cef0e5a Revert "drm/i915/gt: Propagate change in error status to children
on unhold"
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 3761baae908a ("Revert "drm/i915:
Propagate errors on awaiting already signaled fences"")'
#8:
from one client ending up in another. In commit 3761baae908a ("Revert
-:27: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#27:
References: '3761baae908a ("Revert "drm/i915: Propagate errors on awaiting
already signaled fences"")'
total: 1 errors, 1 warnings, 0 checks, 10 lines checked
f9567c78788e drm/i915/guc: Kick tasklet after queuing a request
-:8: WARNING:TYPO_SPELLING: 'inteface' may be misspelled - perhaps 'interface'?
#8:
Fixes: 3a4cdf1982f0 ("drm/i915/guc: Implement GuC context operations for new
inteface")
total: 0 errors, 1 warnings, 0 checks, 7 lines checked
501532c37b64 drm/i915/guc: Don't enable scheduling on a banned context, guc_id
invalid, not registered
69005a00e8aa drm/i915/guc: Copy whole golden context, set engine state size of
subset
e56171c3dd6b drm/i915/selftests: Add initial GuC selftest for scrubbing lost G2H
-:108: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#108:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 233 lines checked
8a8cf43913a0 drm/i915/guc: Take context ref when cancelling request
1e192098087d drm/i915/guc: Don't touch guc_state.sched_state without a lock
dbef2fc197c8 drm/i915/guc: Reset LRC descriptor if register returns -ENODEV
5db9a3bcd282 drm/i915/guc: Release submit fence from an irq_work
a469ee468f89 drm/i915/guc: Move guc_blocked fence to struct guc_state
86fe44af0f11 drm/i915/guc: Rework and simplify locking
e9666ec08fe7 drm/i915/guc: Proper xarray usage for contexts_lookup
a75af0fb3825 drm/i915/guc: Drop pin count check trick between sched_disable and
re-pin
eded4f6781e4 drm/i915/guc: Move GuC priority fields in context under guc_active
f51ccdbc1d50 drm/i915/guc: Move fields protected by guc->contexts_lock into sub
structure
93b6576f14c0 drm/i915/guc: Drop guc_active move everything into guc_state
e4747b33f311 drm/i915/guc: Add GuC kernel doc
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Clean up GuC CI failures, simplify locking, and kernel DOC (rev11)
== Series Details == Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev11) URL : https://patchwork.freedesktop.org/series/93704/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y
[Intel-gfx] ✓ Fi.CI.BAT: success for Clean up GuC CI failures, simplify locking, and kernel DOC (rev11)
== Series Details ==
Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev11)
URL : https://patchwork.freedesktop.org/series/93704/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10565 -> Patchwork_21004
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21004/index.html
New tests
-
New tests have been introduced between CI_DRM_10565 and Patchwork_21004:
### New IGT tests (1) ###
* igt@i915_selftest@live@guc:
- Statuses : 34 pass(s)
- Exec time: [0.43, 5.04] s
Known issues
Here are the changes found in Patchwork_21004 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u: NOTRUN -> [SKIP][1] ([fdo#109271]) +27 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21004/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
* igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u: NOTRUN -> [WARN][2] ([i915#3718])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21004/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827]) +8
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21004/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
Possible fixes
* igt@i915_selftest@live@gt_pm:
- {fi-jsl-1}: [DMESG-FAIL][4] ([i915#1886]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21004/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#3718]: https://gitlab.freedesktop.org/drm/intel/issues/3718
Participating hosts (47 -> 38)
--
Missing(9): fi-ilk-m540 bat-adls-5 bat-dg1-6 fi-bsw-cyan bat-adlp-4
fi-ctg-p8600 fi-bsw-kefka fi-bdw-samus bat-jsl-1
Build changes
-
* Linux: CI_DRM_10565 -> Patchwork_21004
CI-20190529: 20190529
CI_DRM_10565: 8c3cd60dcfa81a649b14f0705eb5e5c9336f1881 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6201: be0d02ff0775235ead63ccb1e3a1e8c10f0209cf @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_21004: e4747b33f311a3ec2567422f23945daef7a6588d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e4747b33f311 drm/i915/guc: Add GuC kernel doc
93b6576f14c0 drm/i915/guc: Drop guc_active move everything into guc_state
f51ccdbc1d50 drm/i915/guc: Move fields protected by guc->contexts_lock into sub
structure
eded4f6781e4 drm/i915/guc: Move GuC priority fields in context under guc_active
a75af0fb3825 drm/i915/guc: Drop pin count check trick between sched_disable and
re-pin
e9666ec08fe7 drm/i915/guc: Proper xarray usage for contexts_lookup
86fe44af0f11 drm/i915/guc: Rework and simplify locking
a469ee468f89 drm/i915/guc: Move guc_blocked fence to struct guc_state
5db9a3bcd282 drm/i915/guc: Release submit fence from an irq_work
dbef2fc197c8 drm/i915/guc: Reset LRC descriptor if register returns -ENODEV
1e192098087d drm/i915/guc: Don't touch guc_state.sched_state without a lock
8a8cf43913a0 drm/i915/guc: Take context ref when cancelling request
e56171c3dd6b drm/i915/selftests: Add initial GuC selftest for scrubbing lost G2H
69005a00e8aa drm/i915/guc: Copy whole golden context, set engine state size of
subset
501532c37b64 drm/i915/guc: Don't enable scheduling on a banned context, guc_id
invalid, not registered
f9567c78788e drm/i915/guc: Kick tasklet after queuing a request
0a9d7cef0e5a Revert "drm/i915/gt: Propagate change in error status to children
on unhold"
5f8dae15114c drm/i915/guc: Workaround reset G2H is received after schedule done
G2H
31c0bfa6a01d drm/i915/guc: Process all G2H message at once in work queue
a6990f6f2a54 drm/i915/guc: Don't drop ce->guc_active.lock when unwinding context
ea81f9db116d drm/i915/guc: Unwind context requests in reverse order
7b4cd4d6bb36 drm/i915/guc: Fix outstanding G2H accounting
deb17f151cef drm/i915/guc: Fix blocked context accounting
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21004/index.html
Re: [Intel-gfx] [PATCH] drm/i915/gt: Add separate MOCS table for Gen12 devices other than TGL/RKL
On Thu, Sep 09, 2021 at 08:42:15PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 09, 2021 at 10:15:56AM -0700, Matt Roper wrote:
> > On Thu, Sep 09, 2021 at 06:09:55PM +0300, Ville Syrjälä wrote:
> > > On Thu, Sep 09, 2021 at 08:00:02AM -0700, Matt Roper wrote:
> > > > On Thu, Sep 09, 2021 at 05:39:26PM +0300, Ville Syrjälä wrote:
> > > > > On Thu, Sep 09, 2021 at 07:29:33AM -0700, Matt Roper wrote:
> > > > > > On Thu, Sep 09, 2021 at 04:58:50PM +0300, Ville Syrjälä wrote:
> > > > > > > On Tue, Sep 07, 2021 at 11:19:29AM -0700, Matt Roper wrote:
> > > > > > > > On Tue, Sep 07, 2021 at 08:41:06PM +0300, Ville Syrjälä wrote:
> > > > > > > > > On Tue, Sep 07, 2021 at 10:27:28AM -0700, Matt Roper wrote:
> > > > > > > > > > On Tue, Sep 07, 2021 at 10:46:39PM +0530, Ayaz A Siddiqui
> > > > > > > > > > wrote:
> > > > > > > > > > > MOCS table of TGL/RKL has MOCS[1] set to L3_UC.
> > > > > > > > > > > While for other gen12 devices we need to set MOCS[1] as
> > > > > > > > > > > L3_WB,
> > > > > > > > > > > So adding a new MOCS table for other gen 12 devices eg.
> > > > > > > > > > > ADL.
> > > > > > > > > > >
> > > > > > > > > > > Fixes: cfbe5291a189 ("drm/i915/gt: Initialize unused MOCS
> > > > > > > > > > > entries with device specific values")
> > > > > > > > > > > Cc: Matt Roper
> > > > > > > > > > > Signed-off-by: Ayaz A Siddiqui
> > > > > > > > > >
> > > > > > > > > > Yep, we overlooked that the TGL table still had an explicit
> > > > > > > > > > entry for
> > > > > > > > > > I915_MOCS_PTE and wasn't just using an implicit
> > > > > > > > > > 'unused_entries' lookup
> > > > > > > > > > for MOCS[1]. The new table is the same as the TGL table,
> > > > > > > > > > just with
> > > > > > > > > > I915_MOCS_PTE (1) removed.
> > > > > > > > >
> > > > > > > > > And just how are people planning on handling display
> > > > > > > > > cacheability
> > > > > > > > > control without a PTE MOCS entry? Is Mesa/etc. already making
> > > > > > > > > all
> > > > > > > > > external bos uncached on these platforms just in case we might
> > > > > > > > > scan out said bo?
> > > > > > > >
> > > > > > > > MOCS entry 1 has never been considered a valid MOCS table entry
> > > > > > > > on gen12
> > > > > > > > platforms (despite the old #define, it's not actually related
> > > > > > > > to PTE,
> > > > > > > > display, etc. anymore).
> > > > > > >
> > > > > > > So can someone finally explain to me how we're supposed to cache
> > > > > > > anything that might become a scanout buffer later (eg. window
> > > > > > > system
> > > > > > > buffers)? Or are we just making everything like that UC now, and
> > > > > > > is
> > > > > > > everyone happy with that? Is userspace actually following that?
> > > > > >
> > > > > > Table entry #1 has never had anything to do with scanout on gen12+.
> > > > > > I
> > > > > > would assume that UMDs are either using the display entry in the
> > > > > > MOCS
> > > > > > table (which is 61 on gen12+) or some other UC entry.
> > > > >
> > > > > If 61 is meant to to be the new PTE entry wy hasn't it been defines as
> > > > > such in the code? And I know for a fact that userspace (Mesa) is not
> > > >
> > > > There is no "PTE" entry anymore. But 61 is already documented as
> > > > "displayable" in both the spec and the code:
> > > >
> > > > /* HW Special Case (Displayable) */
> > > >
> > > > MOCS_ENTRY(61,
> > >
> > > Why is it called a "HW special case"? I don't think there's any hw
> > > magic in there?
> > >
> > > And why aren't we setting it to PTE to get some cacheability for
> > > window back buffers and such?
> >
> > Who is "we" here?
>
> We who care about the performance of the system.
>
> > The MOCS table is a pre-defined set of per-platform
> > magic numbers. The software teams don't get to decide what the values
> > are, we just program the hardware with the per-platform numbers that
> > have been agreed upon as part of a platform-wide stack (everything from
> > low-level firmware to high level userspace should be working from the
> > same table, defined in the bspec).
>
> The magic numbers must be based on something. If that something is
> purely Windows behaviour/performance then we might be shooting
> ourselves in the foot here.
That's not how MOCS works. The MOCS tables define every meaningful
combination of settings somewhere in the table. The *types* of settings
that can be expressed change from platform to platform (e.g.,
"PAGETABLE" setting simply doesn't exist anymore hardware-wise) so the
tables themselves differ between platforms and you may need to use
different indices to get the same behavior between platforms. But if
you're actually paying attention to the tables and choosing the right
entries, you're not going to leave any performance on the table.
>
> >
> > Once we know what the per-platform magic numbers are, we're supposed to
> > pick the table entry that
Re: [Intel-gfx] [PATCH 2/2] drm/i915/uapi: Add query for hwconfig table
On Thu, Sep 02, 2021 at 05:53:33PM -0700, john.c.harri...@intel.com wrote:
> From: Rodrigo Vivi
>
> GuC contains a consolidated table with a bunch of information about the
> current device.
>
> Previously, this information was spread and hardcoded to all the components
> including GuC, i915 and various UMDs. The goal here is to consolidate
> the data into GuC in a way that all interested components can grab the
> very latest and synchronized information using a simple query.
>
> As per most of the other queries, this one can be called twice.
> Once with item.length=0 to determine the exact buffer size, then
> allocate the user memory and call it again for to retrieve the
> table data. For example:
> struct drm_i915_query_item item = {
> .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
> };
> query.items_ptr = (int64_t)
> query.num_items = 1;
>
> ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>
> if (item.length <= 0)
> return -ENOENT;
>
> data = malloc(item.length);
> item.data_ptr = (int64_t)
> ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>
> // Parse the data as appropriate...
>
> The returned array is a simple and flexible KLV (Key/Length/Value)
> formatted table. For example, it could be just:
> enum device_attr {
> ATTR_SOME_VALUE = 0,
> ATTR_SOME_MASK = 1,
> };
>
> static const u32 hwconfig[] = {
> ATTR_SOME_VALUE,
> 1, // Value Length in DWords
> 8, // Value
>
> ATTR_SOME_MASK,
> 3,
> 0x00, 0x, 0xFF00,
> };
>
> The attribute ids are defined in a hardware spec.
>
> Cc: Tvrtko Ursulin
> Cc: Kenneth Graunke
> Cc: Michal Wajdeczko
> Cc: Slawomir Milczarek
> Signed-off-by: Rodrigo Vivi
> Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/i915_query.c | 23 +++
> include/uapi/drm/i915_drm.h | 1 +
> 2 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_query.c
> b/drivers/gpu/drm/i915/i915_query.c
> index 5e2b909827f4..96989a37453c 100644
> --- a/drivers/gpu/drm/i915/i915_query.c
> +++ b/drivers/gpu/drm/i915/i915_query.c
> @@ -477,12 +477,35 @@ static int query_memregion_info(struct drm_i915_private
> *i915,
> return total_length;
> }
>
> +static int query_hwconfig_table(struct drm_i915_private *i915,
> + struct drm_i915_query_item *query_item)
> +{
> + struct intel_gt *gt = >gt;
> + struct intel_guc_hwconfig *hwconfig = >uc.guc.hwconfig;
> +
> + if (!hwconfig->size || !hwconfig->ptr)
> + return -ENODEV;
> +
> + if (query_item->length == 0)
> + return hwconfig->size;
> +
> + if (query_item->length < hwconfig->size)
> + return -EINVAL;
> +
> + if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
> + hwconfig->ptr, hwconfig->size))
> + return -EFAULT;
> +
> + return hwconfig->size;
> +}
> +
> static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
> struct drm_i915_query_item *query_item)
> = {
> query_topology_info,
> query_engine_info,
> query_perf_config,
> query_memregion_info,
> + query_hwconfig_table,
> };
>
> int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file
> *file)
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index bde5860b3686..a1281f35b190 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -2499,6 +2499,7 @@ struct drm_i915_query_item {
> #define DRM_I915_QUERY_ENGINE_INFO 2
> #define DRM_I915_QUERY_PERF_CONFIG 3
> #define DRM_I915_QUERY_MEMORY_REGIONS 4
> +#define DRM_I915_QUERY_HWCONFIG_TABLE 5
> /* Must be kept compact -- no holes and well documented */
>
> /**
> --
> 2.25.1
>
[Intel-gfx] ✗ Fi.CI.IGT: failure for Enable GuC submission by default on DG1 (rev4)
== Series Details == Series: Enable GuC submission by default on DG1 (rev4) URL : https://patchwork.freedesktop.org/series/93325/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10565_full -> Patchwork_21003_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21003_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21003_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21003_full: ### IGT changes ### Possible regressions * igt@kms_atomic@plane-cursor-legacy: - shard-iclb: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-iclb4/igt@kms_ato...@plane-cursor-legacy.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21003/shard-iclb2/igt@kms_ato...@plane-cursor-legacy.html * igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile: - shard-iclb: [PASS][3] -> [SKIP][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-iclb7/igt@kms_flip_scaled_...@flip-32bpp-ytileccs-to-64bpp-ytile.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21003/shard-iclb2/igt@kms_flip_scaled_...@flip-32bpp-ytileccs-to-64bpp-ytile.html Known issues Here are the changes found in Patchwork_21003_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][5] ([i915#3002]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21003/shard-apl7/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@idempotent: - shard-snb: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21003/shard-snb5/igt@gem_ctx_persiste...@idempotent.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][7] -> [TIMEOUT][8] ([i915#2369] / [i915#3063] / [i915#3648]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-tglb3/igt@gem_...@unwedge-stress.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21003/shard-tglb1/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-tglb8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21003/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_render_copy@linear-to-vebox-y-tiled: - shard-glk: NOTRUN -> [SKIP][11] ([fdo#109271]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21003/shard-glk3/igt@gem_render_c...@linear-to-vebox-y-tiled.html * igt@gem_userptr_blits@dmabuf-unsync: - shard-tglb: NOTRUN -> [SKIP][12] ([i915#3297]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21003/shard-tglb7/igt@gem_userptr_bl...@dmabuf-unsync.html - shard-iclb: NOTRUN -> [SKIP][13] ([i915#3297]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21003/shard-iclb1/igt@gem_userptr_bl...@dmabuf-unsync.html * igt@gem_userptr_blits@input-checking: - shard-snb: NOTRUN -> [DMESG-WARN][14] ([i915#3002]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21003/shard-snb5/igt@gem_userptr_bl...@input-checking.html * igt@i915_pm_dc@dc6-dpms: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#454]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/shard-iclb4/igt@i915_pm...@dc6-dpms.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21003/shard-iclb3/igt@i915_pm...@dc6-dpms.html * igt@kms_big_fb@yf-tiled-64bpp-rotate-90: - shard-iclb: NOTRUN -> [SKIP][17] ([fdo#110723]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21003/shard-iclb1/igt@kms_big...@yf-tiled-64bpp-rotate-90.html * igt@kms_big_fb@yf-tiled-addfb-size-overflow: - shard-tglb: NOTRUN -> [SKIP][18] ([fdo#111615]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21003/shard-tglb5/igt@kms_big...@yf-tiled-addfb-size-overflow.html * igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip: - shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3777]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21003/shard-apl6/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip.html * igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip: - shard-skl: NOTRUN
[Intel-gfx] [PATCH 16/23] drm/i915/guc: Move guc_blocked fence to struct guc_state
Move guc_blocked fence to struct guc_state as the lock which protects
the fence lives there.
s/ce->guc_blocked/ce->guc_state.blocked/g
v2:
(Daniele)
- s/blocked_fence/blocked/g
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c| 5 +++--
drivers/gpu/drm/i915/gt/intel_context_types.h | 5 ++---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 18 +-
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 745e84c72c90..3048267ddc7e 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -405,8 +405,9 @@ intel_context_init(struct intel_context *ce, struct
intel_engine_cs *engine)
* Initialize fence to be complete as this is expected to be complete
* unless there is a pending schedule disable outstanding.
*/
- i915_sw_fence_init(>guc_blocked, sw_fence_dummy_notify);
- i915_sw_fence_commit(>guc_blocked);
+ i915_sw_fence_init(>guc_state.blocked,
+ sw_fence_dummy_notify);
+ i915_sw_fence_commit(>guc_state.blocked);
i915_active_init(>active,
__intel_context_active, __intel_context_retire, 0);
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 3a73f3117873..5aecb9038b5b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -167,6 +167,8 @@ struct intel_context {
* fence related to GuC submission
*/
struct list_head fences;
+ /* GuC context blocked fence */
+ struct i915_sw_fence blocked;
} guc_state;
struct {
@@ -190,9 +192,6 @@ struct intel_context {
*/
struct list_head guc_id_link;
- /* GuC context blocked fence */
- struct i915_sw_fence guc_blocked;
-
/*
* GuC priority management
*/
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 4b7ccf9730a3..99f223114331 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1502,24 +1502,24 @@ static void guc_blocked_fence_complete(struct
intel_context *ce)
{
lockdep_assert_held(>guc_state.lock);
- if (!i915_sw_fence_done(>guc_blocked))
- i915_sw_fence_complete(>guc_blocked);
+ if (!i915_sw_fence_done(>guc_state.blocked))
+ i915_sw_fence_complete(>guc_state.blocked);
}
static void guc_blocked_fence_reinit(struct intel_context *ce)
{
lockdep_assert_held(>guc_state.lock);
- GEM_BUG_ON(!i915_sw_fence_done(>guc_blocked));
+ GEM_BUG_ON(!i915_sw_fence_done(>guc_state.blocked));
/*
* This fence is always complete unless a pending schedule disable is
* outstanding. We arm the fence here and complete it when we receive
* the pending schedule disable complete message.
*/
- i915_sw_fence_fini(>guc_blocked);
- i915_sw_fence_reinit(>guc_blocked);
- i915_sw_fence_await(>guc_blocked);
- i915_sw_fence_commit(>guc_blocked);
+ i915_sw_fence_fini(>guc_state.blocked);
+ i915_sw_fence_reinit(>guc_state.blocked);
+ i915_sw_fence_await(>guc_state.blocked);
+ i915_sw_fence_commit(>guc_state.blocked);
}
static u16 prep_context_pending_disable(struct intel_context *ce)
@@ -1559,7 +1559,7 @@ static struct i915_sw_fence *guc_context_block(struct
intel_context *ce)
if (enabled)
clr_context_enabled(ce);
spin_unlock_irqrestore(>guc_state.lock, flags);
- return >guc_blocked;
+ return >guc_state.blocked;
}
/*
@@ -1575,7 +1575,7 @@ static struct i915_sw_fence *guc_context_block(struct
intel_context *ce)
with_intel_runtime_pm(runtime_pm, wakeref)
__guc_context_sched_disable(guc, ce, guc_id);
- return >guc_blocked;
+ return >guc_state.blocked;
}
#define SCHED_STATE_MULTI_BLOCKED_MASK \
--
2.32.0
[Intel-gfx] [PATCH 22/23] drm/i915/guc: Drop guc_active move everything into guc_state
Now that we have locking hierarchy of sched_engine->lock ->
ce->guc_state everything from guc_active can be moved into guc_state and
protected the guc_state.lock.
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_context.c | 10 +--
drivers/gpu/drm/i915/gt/intel_context_types.h | 7 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 88 +--
drivers/gpu/drm/i915/i915_trace.h | 2 +-
4 files changed, 49 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 485460a11331..ff637147b1a9 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -394,9 +394,7 @@ intel_context_init(struct intel_context *ce, struct
intel_engine_cs *engine)
spin_lock_init(>guc_state.lock);
INIT_LIST_HEAD(>guc_state.fences);
-
- spin_lock_init(>guc_active.lock);
- INIT_LIST_HEAD(>guc_active.requests);
+ INIT_LIST_HEAD(>guc_state.requests);
ce->guc_id.id = GUC_INVALID_LRC_ID;
INIT_LIST_HEAD(>guc_id.link);
@@ -521,15 +519,15 @@ struct i915_request
*intel_context_find_active_request(struct intel_context *ce)
GEM_BUG_ON(!intel_engine_uses_guc(ce->engine));
- spin_lock_irqsave(>guc_active.lock, flags);
- list_for_each_entry_reverse(rq, >guc_active.requests,
+ spin_lock_irqsave(>guc_state.lock, flags);
+ list_for_each_entry_reverse(rq, >guc_state.requests,
sched.link) {
if (i915_request_completed(rq))
break;
active = rq;
}
- spin_unlock_irqrestore(>guc_active.lock, flags);
+ spin_unlock_irqrestore(>guc_state.lock, flags);
return active;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 0b00d249c884..5285d660eacf 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -172,11 +172,6 @@ struct intel_context {
struct i915_sw_fence blocked;
/* GuC committed requests */
int number_committed_requests;
- } guc_state;
-
- struct {
- /** lock: protects everything in guc_active */
- spinlock_t lock;
/** requests: active requests on this context */
struct list_head requests;
/*
@@ -184,7 +179,7 @@ struct intel_context {
*/
u8 prio;
u32 prio_count[GUC_CLIENT_PRIORITY_NUM];
- } guc_active;
+ } guc_state;
struct {
/* GuC LRC descriptor ID */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 2c9a6b4ce071..a9cf49298067 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -846,9 +846,9 @@ __unwind_incomplete_requests(struct intel_context *ce)
unsigned long flags;
spin_lock_irqsave(_engine->lock, flags);
- spin_lock(>guc_active.lock);
+ spin_lock(>guc_state.lock);
list_for_each_entry_safe_reverse(rq, rn,
->guc_active.requests,
+>guc_state.requests,
sched.link) {
if (i915_request_completed(rq))
continue;
@@ -867,7 +867,7 @@ __unwind_incomplete_requests(struct intel_context *ce)
list_add(>sched.link, pl);
set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
}
- spin_unlock(>guc_active.lock);
+ spin_unlock(>guc_state.lock);
spin_unlock_irqrestore(_engine->lock, flags);
}
@@ -962,10 +962,10 @@ static void guc_cancel_context_requests(struct
intel_context *ce)
/* Mark all executing requests as skipped. */
spin_lock_irqsave(_engine->lock, flags);
- spin_lock(>guc_active.lock);
- list_for_each_entry(rq, >guc_active.requests, sched.link)
+ spin_lock(>guc_state.lock);
+ list_for_each_entry(rq, >guc_state.requests, sched.link)
i915_request_put(i915_request_mark_eio(rq));
- spin_unlock(>guc_active.lock);
+ spin_unlock(>guc_state.lock);
spin_unlock_irqrestore(_engine->lock, flags);
}
@@ -1416,7 +1416,7 @@ static int guc_lrc_desc_pin(struct intel_context *ce,
bool loop)
desc->engine_submit_mask = adjust_engine_mask(engine->class,
engine->mask);
desc->hw_context_desc = ce->lrc.lrca;
- desc->priority = ce->guc_active.prio;
+ desc->priority = ce->guc_state.prio;
desc->context_flags = CONTEXT_REGISTRATION_FLAG_KMD;
guc_context_policy_init(engine,
[Intel-gfx] [PATCH 19/23] drm/i915/guc: Drop pin count check trick between sched_disable and re-pin
Drop pin count check trick between a sched_disable and re-pin, now rely
on the lock and counter of the number of committed requests to determine
if scheduling should be disabled on the context.
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 53 +++
2 files changed, 34 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index d2f798ef678c..3a5d98e908f4 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -169,6 +169,8 @@ struct intel_context {
struct list_head fences;
/* GuC context blocked fence */
struct i915_sw_fence blocked;
+ /* GuC committed requests */
+ int number_committed_requests;
} guc_state;
struct {
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 4814acf1c2ac..31f911ae14fa 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -249,6 +249,25 @@ static inline void decr_context_blocked(struct
intel_context *ce)
ce->guc_state.sched_state -= SCHED_STATE_BLOCKED;
}
+static inline bool context_has_committed_requests(struct intel_context *ce)
+{
+ return !!ce->guc_state.number_committed_requests;
+}
+
+static inline void incr_context_committed_requests(struct intel_context *ce)
+{
+ lockdep_assert_held(>guc_state.lock);
+ ++ce->guc_state.number_committed_requests;
+ GEM_BUG_ON(ce->guc_state.number_committed_requests < 0);
+}
+
+static inline void decr_context_committed_requests(struct intel_context *ce)
+{
+ lockdep_assert_held(>guc_state.lock);
+ --ce->guc_state.number_committed_requests;
+ GEM_BUG_ON(ce->guc_state.number_committed_requests < 0);
+}
+
static inline bool context_guc_id_invalid(struct intel_context *ce)
{
return ce->guc_id == GUC_INVALID_LRC_ID;
@@ -1766,24 +1785,18 @@ static void guc_context_sched_disable(struct
intel_context *ce)
spin_lock_irqsave(>guc_state.lock, flags);
/*
-* We have to check if the context has been disabled by another thread.
-* We also have to check if the context has been pinned again as another
-* pin operation is allowed to pass this function. Checking the pin
-* count, within ce->guc_state.lock, synchronizes this function with
-* guc_request_alloc ensuring a request doesn't slip through the
-* 'context_pending_disable' fence. Checking within the spin lock (can't
-* sleep) ensures another process doesn't pin this context and generate
-* a request before we set the 'context_pending_disable' flag here.
+* We have to check if the context has been disabled by another thread,
+* check if submssion has been disabled to seal a race with reset and
+* finally check if any more requests have been committed to the
+* context ensursing that a request doesn't slip through the
+* 'context_pending_disable' fence.
*/
- if (unlikely(!context_enabled(ce) || submission_disabled(guc))) {
+ if (unlikely(!context_enabled(ce) || submission_disabled(guc) ||
+context_has_committed_requests(ce))) {
clr_context_enabled(ce);
spin_unlock_irqrestore(>guc_state.lock, flags);
goto unpin;
}
- if (unlikely(atomic_add_unless(>pin_count, -2, 2))) {
- spin_unlock_irqrestore(>guc_state.lock, flags);
- return;
- }
guc_id = prep_context_pending_disable(ce);
spin_unlock_irqrestore(>guc_state.lock, flags);
@@ -1813,6 +1826,7 @@ static void __guc_context_destroy(struct intel_context
*ce)
ce->guc_prio_count[GUC_CLIENT_PRIORITY_HIGH] ||
ce->guc_prio_count[GUC_CLIENT_PRIORITY_KMD_NORMAL] ||
ce->guc_prio_count[GUC_CLIENT_PRIORITY_NORMAL]);
+ GEM_BUG_ON(ce->guc_state.number_committed_requests);
lrc_fini(ce);
intel_context_fini(ce);
@@ -2043,6 +2057,10 @@ static void remove_from_context(struct i915_request *rq)
spin_unlock_irq(>guc_active.lock);
+ spin_lock_irq(>guc_state.lock);
+ decr_context_committed_requests(ce);
+ spin_unlock_irq(>guc_state.lock);
+
atomic_dec(>guc_id_ref);
i915_request_notify_execute_cb_imm(rq);
}
@@ -2193,15 +2211,7 @@ static int guc_request_alloc(struct i915_request *rq)
* schedule enable or context registration if either G2H is pending
* respectfully. Once a G2H returns, the fence is released that is
* blocking these requests (see guc_signal_context_fence).
-*
-
[Intel-gfx] [PATCH 23/23] drm/i915/guc: Add GuC kernel doc
Add GuC kernel doc for all structures added thus far for GuC submission
and update the main GuC submission section with the new interface
details.
v2:
- Drop guc_active.lock DOC
v3:
- Fixup a few kernel doc comments (Daniele)
v4 (Daniele):
- Implement doc suggestions from John
- Add kerneldoc for all members of the GuC structure and pull the file
in i915.rst
v5 (Daniele):
- Implement new doc suggestions from John
Signed-off-by: Matthew Brost
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
Reviewed-by: John Harrison
---
Documentation/gpu/i915.rst| 2 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 43 +---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 75 ++---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 100 ++
drivers/gpu/drm/i915/i915_request.h | 21 ++--
5 files changed, 181 insertions(+), 60 deletions(-)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 101dde3eb1ea..311e10400708 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -495,6 +495,8 @@ GuC
.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.c
:doc: GuC
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.h
+
GuC Firmware Layout
~~~
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 5285d660eacf..930569a1a01f 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -156,40 +156,51 @@ struct intel_context {
u8 wa_bb_page; /* if set, page num reserved for context workarounds */
struct {
- /** lock: protects everything in guc_state */
+ /** @lock: protects everything in guc_state */
spinlock_t lock;
/**
-* sched_state: scheduling state of this context using GuC
+* @sched_state: scheduling state of this context using GuC
* submission
*/
u32 sched_state;
/*
-* fences: maintains of list of requests that have a submit
-* fence related to GuC submission
+* @fences: maintains a list of requests that are currently
+* being fenced until a GuC operation completes
*/
struct list_head fences;
- /* GuC context blocked fence */
+ /**
+* @blocked: fence used to signal when the blocking of a
+* context's submissions is complete.
+*/
struct i915_sw_fence blocked;
- /* GuC committed requests */
+ /** @number_committed_requests: number of committed requests */
int number_committed_requests;
- /** requests: active requests on this context */
+ /** @requests: list of active requests on this context */
struct list_head requests;
- /*
-* GuC priority management
-*/
+ /** @prio: the context's current guc priority */
u8 prio;
+ /**
+* @prio_count: a counter of the number requests in flight in
+* each priority bucket
+*/
u32 prio_count[GUC_CLIENT_PRIORITY_NUM];
} guc_state;
struct {
- /* GuC LRC descriptor ID */
+ /**
+* @id: handle which is used to uniquely identify this context
+* with the GuC, protected by guc->contexts_lock
+*/
u16 id;
-
- /* GuC LRC descriptor reference count */
+ /**
+* @ref: the number of references to the guc_id, when
+* transitioning in and out of zero protected by
+* guc->contexts_lock
+*/
atomic_t ref;
-
- /*
-* GuC ID link - in list when unpinned but guc_id still valid
in GuC
+ /**
+* @link: in guc->guc_id_list when the guc_id has no refs but is
+* still valid, protected by guc->contexts_lock
*/
struct list_head link;
} guc_id;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 2e27fe59786b..5dd174babf7a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -22,74 +22,121 @@
struct __guc_ads_blob;
-/*
- * Top level structure of GuC. It handles firmware loading and manages client
- * pool. intel_guc owns a intel_guc_client to replace the legacy ExecList
- * submission.
+/**
+ * struct intel_guc - Top level structure of GuC.
+ *
+ * It handles firmware loading and manages client pool. intel_guc owns an
+ * i915_sched_engine for
[Intel-gfx] [PATCH 20/23] drm/i915/guc: Move GuC priority fields in context under guc_active
Move GuC management fields in context under guc_active struct as this is
where the lock that protects theses fields lives. Also only set guc_prio
field once during context init.
v2:
(Daniele)
- set CONTEXT_SET_INIT
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 12 ++--
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 69 +++
drivers/gpu/drm/i915/i915_trace.h | 2 +-
3 files changed, 46 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 3a5d98e908f4..b56960a781da 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -112,6 +112,7 @@ struct intel_context {
#define CONTEXT_FORCE_SINGLE_SUBMISSION7
#define CONTEXT_NOPREEMPT 8
#define CONTEXT_LRCA_DIRTY 9
+#define CONTEXT_GUC_INIT 10
struct {
u64 timeout_us;
@@ -178,6 +179,11 @@ struct intel_context {
spinlock_t lock;
/** requests: active requests on this context */
struct list_head requests;
+ /*
+* GuC priority management
+*/
+ u8 prio;
+ u32 prio_count[GUC_CLIENT_PRIORITY_NUM];
} guc_active;
/* GuC LRC descriptor ID */
@@ -191,12 +197,6 @@ struct intel_context {
*/
struct list_head guc_id_link;
- /*
-* GuC priority management
-*/
- u8 guc_prio;
- u32 guc_prio_count[GUC_CLIENT_PRIORITY_NUM];
-
#ifdef CONFIG_DRM_I915_SELFTEST
/**
* @drop_schedule_enable: Force drop of schedule enable G2H for selftest
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 31f911ae14fa..7e9ee7d5aaab 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1385,8 +1385,6 @@ static void guc_context_policy_init(struct
intel_engine_cs *engine,
desc->preemption_timeout = engine->props.preempt_timeout_ms * 1000;
}
-static inline u8 map_i915_prio_to_guc_prio(int prio);
-
static int guc_lrc_desc_pin(struct intel_context *ce, bool loop)
{
struct intel_engine_cs *engine = ce->engine;
@@ -1394,8 +1392,6 @@ static int guc_lrc_desc_pin(struct intel_context *ce,
bool loop)
struct intel_guc *guc = >gt->uc.guc;
u32 desc_idx = ce->guc_id;
struct guc_lrc_desc *desc;
- const struct i915_gem_context *ctx;
- int prio = I915_CONTEXT_DEFAULT_PRIORITY;
bool context_registered;
intel_wakeref_t wakeref;
int ret = 0;
@@ -1412,12 +1408,6 @@ static int guc_lrc_desc_pin(struct intel_context *ce,
bool loop)
context_registered = lrc_desc_registered(guc, desc_idx);
- rcu_read_lock();
- ctx = rcu_dereference(ce->gem_context);
- if (ctx)
- prio = ctx->sched.priority;
- rcu_read_unlock();
-
reset_lrc_desc(guc, desc_idx);
set_lrc_desc_registered(guc, desc_idx, ce);
@@ -1426,8 +1416,7 @@ static int guc_lrc_desc_pin(struct intel_context *ce,
bool loop)
desc->engine_submit_mask = adjust_engine_mask(engine->class,
engine->mask);
desc->hw_context_desc = ce->lrc.lrca;
- ce->guc_prio = map_i915_prio_to_guc_prio(prio);
- desc->priority = ce->guc_prio;
+ desc->priority = ce->guc_active.prio;
desc->context_flags = CONTEXT_REGISTRATION_FLAG_KMD;
guc_context_policy_init(engine, desc);
@@ -1822,10 +1811,10 @@ static inline void guc_lrc_desc_unpin(struct
intel_context *ce)
static void __guc_context_destroy(struct intel_context *ce)
{
- GEM_BUG_ON(ce->guc_prio_count[GUC_CLIENT_PRIORITY_KMD_HIGH] ||
- ce->guc_prio_count[GUC_CLIENT_PRIORITY_HIGH] ||
- ce->guc_prio_count[GUC_CLIENT_PRIORITY_KMD_NORMAL] ||
- ce->guc_prio_count[GUC_CLIENT_PRIORITY_NORMAL]);
+ GEM_BUG_ON(ce->guc_active.prio_count[GUC_CLIENT_PRIORITY_KMD_HIGH] ||
+ ce->guc_active.prio_count[GUC_CLIENT_PRIORITY_HIGH] ||
+ ce->guc_active.prio_count[GUC_CLIENT_PRIORITY_KMD_NORMAL] ||
+ ce->guc_active.prio_count[GUC_CLIENT_PRIORITY_NORMAL]);
GEM_BUG_ON(ce->guc_state.number_committed_requests);
lrc_fini(ce);
@@ -1935,14 +1924,17 @@ static void guc_context_set_prio(struct intel_guc *guc,
GEM_BUG_ON(prio < GUC_CLIENT_PRIORITY_KMD_HIGH ||
prio > GUC_CLIENT_PRIORITY_NORMAL);
+ lockdep_assert_held(>guc_active.lock);
- if (ce->guc_prio == prio || submission_disabled(guc) ||
- !context_registered(ce))
+ if (ce->guc_active.prio == prio || submission_disabled(guc) ||
[Intel-gfx] [PATCH 15/23] drm/i915/guc: Release submit fence from an irq_work
A subsequent patch will flip the locking hierarchy from
ce->guc_state.lock -> sched_engine->lock to sched_engine->lock ->
ce->guc_state.lock. As such we need to release the submit fence for a
request from an IRQ to break a lock inversion - i.e. the fence must be
release went holding ce->guc_state.lock and the releasing of the can
acquire sched_engine->lock.
v2:
(Daniele)
- Delete request from list before calling irq_work_queue
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 22 ---
drivers/gpu/drm/i915/i915_request.h | 5 +
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index dcd7a09f8559..4b7ccf9730a3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2049,17 +2049,32 @@ static const struct intel_context_ops guc_context_ops =
{
.create_virtual = guc_create_virtual,
};
+static void submit_work_cb(struct irq_work *wrk)
+{
+ struct i915_request *rq = container_of(wrk, typeof(*rq), submit_work);
+
+ might_lock(>engine->sched_engine->lock);
+ i915_sw_fence_complete(>submit);
+}
+
static void __guc_signal_context_fence(struct intel_context *ce)
{
- struct i915_request *rq;
+ struct i915_request *rq, *rn;
lockdep_assert_held(>guc_state.lock);
if (!list_empty(>guc_state.fences))
trace_intel_context_fence_release(ce);
- list_for_each_entry(rq, >guc_state.fences, guc_fence_link)
- i915_sw_fence_complete(>submit);
+ /*
+* Use an IRQ to ensure locking order of sched_engine->lock ->
+* ce->guc_state.lock is preserved.
+*/
+ list_for_each_entry_safe(rq, rn, >guc_state.fences,
+guc_fence_link) {
+ list_del(>guc_fence_link);
+ irq_work_queue(>submit_work);
+ }
INIT_LIST_HEAD(>guc_state.fences);
}
@@ -2169,6 +2184,7 @@ static int guc_request_alloc(struct i915_request *rq)
spin_lock_irqsave(>guc_state.lock, flags);
if (context_wait_for_deregister_to_register(ce) ||
context_pending_disable(ce)) {
+ init_irq_work(>submit_work, submit_work_cb);
i915_sw_fence_await(>submit);
list_add_tail(>guc_fence_link, >guc_state.fences);
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 1bc1349ba3c2..d818cfbfc41d 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -218,6 +218,11 @@ struct i915_request {
};
struct llist_head execute_cb;
struct i915_sw_fence semaphore;
+ /**
+* @submit_work: complete submit fence from an IRQ if needed for
+* locking hierarchy reasons.
+*/
+ struct irq_work submit_work;
/*
* A list of everyone we wait upon, and everyone who waits upon us.
--
2.32.0
[Intel-gfx] [PATCH 21/23] drm/i915/guc: Move fields protected by guc->contexts_lock into sub structure
To make ownership of locking clear move fields (guc_id, guc_id_ref,
guc_id_link) to sub structure guc_id in intel_context.
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 4 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 18 +--
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 6 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 104 +-
drivers/gpu/drm/i915/i915_trace.h | 4 +-
5 files changed, 69 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 3048267ddc7e..485460a11331 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -398,8 +398,8 @@ intel_context_init(struct intel_context *ce, struct
intel_engine_cs *engine)
spin_lock_init(>guc_active.lock);
INIT_LIST_HEAD(>guc_active.requests);
- ce->guc_id = GUC_INVALID_LRC_ID;
- INIT_LIST_HEAD(>guc_id_link);
+ ce->guc_id.id = GUC_INVALID_LRC_ID;
+ INIT_LIST_HEAD(>guc_id.link);
/*
* Initialize fence to be complete as this is expected to be complete
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index b56960a781da..0b00d249c884 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -186,16 +186,18 @@ struct intel_context {
u32 prio_count[GUC_CLIENT_PRIORITY_NUM];
} guc_active;
- /* GuC LRC descriptor ID */
- u16 guc_id;
+ struct {
+ /* GuC LRC descriptor ID */
+ u16 id;
- /* GuC LRC descriptor reference count */
- atomic_t guc_id_ref;
+ /* GuC LRC descriptor reference count */
+ atomic_t ref;
- /*
-* GuC ID link - in list when unpinned but guc_id still valid in GuC
-*/
- struct list_head guc_id_link;
+ /*
+* GuC ID link - in list when unpinned but guc_id still valid
in GuC
+*/
+ struct list_head link;
+ } guc_id;
#ifdef CONFIG_DRM_I915_SELFTEST
/**
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index 8be23e0f9306..7e6fdabac599 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -789,7 +789,7 @@ static int __igt_reset_engine(struct intel_gt *gt, bool
active)
if (err)
pr_err("[%s] Wait for request %lld:%lld
[0x%04X] failed: %d!\n",
engine->name, rq->fence.context,
- rq->fence.seqno,
rq->context->guc_id, err);
+ rq->fence.seqno,
rq->context->guc_id.id, err);
}
skip:
@@ -1098,7 +1098,7 @@ static int __igt_reset_engines(struct intel_gt *gt,
if (err)
pr_err("[%s] Wait for request %lld:%lld
[0x%04X] failed: %d!\n",
engine->name, rq->fence.context,
- rq->fence.seqno,
rq->context->guc_id, err);
+ rq->fence.seqno,
rq->context->guc_id.id, err);
}
count++;
@@ -1108,7 +1108,7 @@ static int __igt_reset_engines(struct intel_gt *gt,
pr_err("i915_reset_engine(%s:%s):
failed to reset request %lld:%lld [0x%04X]\n",
engine->name, test_name,
rq->fence.context,
- rq->fence.seqno,
rq->context->guc_id);
+ rq->fence.seqno,
rq->context->guc_id.id);
i915_request_put(rq);
GEM_TRACE_DUMP();
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 7e9ee7d5aaab..2c9a6b4ce071 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -270,12 +270,12 @@ static inline void decr_context_committed_requests(struct
intel_context *ce)
static inline bool context_guc_id_invalid(struct intel_context *ce)
{
- return ce->guc_id == GUC_INVALID_LRC_ID;
+ return ce->guc_id.id == GUC_INVALID_LRC_ID;
}
static inline void set_context_guc_id_invalid(struct intel_context *ce)
{
- ce->guc_id = GUC_INVALID_LRC_ID;
+ ce->guc_id.id = GUC_INVALID_LRC_ID;
}
static inline struct intel_guc *ce_to_guc(struct
[Intel-gfx] [PATCH 18/23] drm/i915/guc: Proper xarray usage for contexts_lookup
Lock the xarray and take ref to the context if needed.
v2:
(Checkpatch)
- Add new line after declaration
(Daniel Vetter)
- Correct put / get accounting in xa_for_loops
v3:
(Checkpatch)
- Extra new line
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 102 +++---
1 file changed, 87 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 383dc1017004..4814acf1c2ac 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -608,8 +608,18 @@ static void scrub_guc_desc_for_outstanding_g2h(struct
intel_guc *guc)
unsigned long index, flags;
bool pending_disable, pending_enable, deregister, destroyed, banned;
+ xa_lock_irqsave(>context_lookup, flags);
xa_for_each(>context_lookup, index, ce) {
- spin_lock_irqsave(>guc_state.lock, flags);
+ /*
+* Corner case where the ref count on the object is zero but and
+* deregister G2H was lost. In this case we don't touch the ref
+* count and finish the destroy of the context.
+*/
+ bool do_put = kref_get_unless_zero(>ref);
+
+ xa_unlock(>context_lookup);
+
+ spin_lock(>guc_state.lock);
/*
* Once we are at this point submission_disabled() is guaranteed
@@ -625,7 +635,9 @@ static void scrub_guc_desc_for_outstanding_g2h(struct
intel_guc *guc)
banned = context_banned(ce);
init_sched_state(ce);
- spin_unlock_irqrestore(>guc_state.lock, flags);
+ spin_unlock(>guc_state.lock);
+
+ GEM_BUG_ON(!do_put && !destroyed);
if (pending_enable || destroyed || deregister) {
decr_outstanding_submission_g2h(guc);
@@ -648,13 +660,19 @@ static void scrub_guc_desc_for_outstanding_g2h(struct
intel_guc *guc)
}
intel_context_sched_disable_unpin(ce);
decr_outstanding_submission_g2h(guc);
- spin_lock_irqsave(>guc_state.lock, flags);
+
+ spin_lock(>guc_state.lock);
guc_blocked_fence_complete(ce);
- spin_unlock_irqrestore(>guc_state.lock, flags);
+ spin_unlock(>guc_state.lock);
intel_context_put(ce);
}
+
+ if (do_put)
+ intel_context_put(ce);
+ xa_lock(>context_lookup);
}
+ xa_unlock_irqrestore(>context_lookup, flags);
}
static inline bool
@@ -890,16 +908,29 @@ void intel_guc_submission_reset(struct intel_guc *guc,
bool stalled)
{
struct intel_context *ce;
unsigned long index;
+ unsigned long flags;
if (unlikely(!guc_submission_initialized(guc))) {
/* Reset called during driver load? GuC not yet initialised! */
return;
}
- xa_for_each(>context_lookup, index, ce)
+ xa_lock_irqsave(>context_lookup, flags);
+ xa_for_each(>context_lookup, index, ce) {
+ if (!kref_get_unless_zero(>ref))
+ continue;
+
+ xa_unlock(>context_lookup);
+
if (intel_context_is_pinned(ce))
__guc_reset_context(ce, stalled);
+ intel_context_put(ce);
+
+ xa_lock(>context_lookup);
+ }
+ xa_unlock_irqrestore(>context_lookup, flags);
+
/* GuC is blown away, drop all references to contexts */
xa_destroy(>context_lookup);
}
@@ -974,11 +1005,24 @@ void intel_guc_submission_cancel_requests(struct
intel_guc *guc)
{
struct intel_context *ce;
unsigned long index;
+ unsigned long flags;
+
+ xa_lock_irqsave(>context_lookup, flags);
+ xa_for_each(>context_lookup, index, ce) {
+ if (!kref_get_unless_zero(>ref))
+ continue;
+
+ xa_unlock(>context_lookup);
- xa_for_each(>context_lookup, index, ce)
if (intel_context_is_pinned(ce))
guc_cancel_context_requests(ce);
+ intel_context_put(ce);
+
+ xa_lock(>context_lookup);
+ }
+ xa_unlock_irqrestore(>context_lookup, flags);
+
guc_cancel_sched_engine_requests(guc->sched_engine);
/* GuC is blown away, drop all references to contexts */
@@ -2866,21 +2910,28 @@ void intel_guc_find_hung_context(struct intel_engine_cs
*engine)
struct intel_context *ce;
struct i915_request *rq;
unsigned long index;
+ unsigned long flags;
/* Reset called during driver load? GuC not yet initialised! */
[Intel-gfx] [PATCH 11/23] drm/i915/selftests: Add initial GuC selftest for scrubbing lost G2H
While debugging an issue with full GT resets I went down a rabbit hole
thinking the scrubbing of lost G2H wasn't working correctly. This proved
to be incorrect as this was working just fine but this chase inspired me
to write a selftest to prove that this works. This simple selftest
injects errors dropping various G2H and then issues a full GT reset
proving that the scrubbing of these G2H doesn't blow up.
v2:
(Daniel Vetter)
- Use ifdef instead of macros for selftests
v3:
(Checkpatch)
- A space after 'switch' statement
v4:
(Daniele)
- A comment saying GT won't idle if G2H are lost
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 18 +++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 25
drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 127 ++
.../drm/i915/selftests/i915_live_selftests.h | 1 +
.../i915/selftests/intel_scheduler_helpers.c | 12 ++
.../i915/selftests/intel_scheduler_helpers.h | 2 +
6 files changed, 185 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gt/uc/selftest_guc.c
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index e54351a170e2..3a73f3117873 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -198,6 +198,24 @@ struct intel_context {
*/
u8 guc_prio;
u32 guc_prio_count[GUC_CLIENT_PRIORITY_NUM];
+
+#ifdef CONFIG_DRM_I915_SELFTEST
+ /**
+* @drop_schedule_enable: Force drop of schedule enable G2H for selftest
+*/
+ bool drop_schedule_enable;
+
+ /**
+* @drop_schedule_disable: Force drop of schedule disable G2H for
+* selftest
+*/
+ bool drop_schedule_disable;
+
+ /**
+* @drop_deregister: Force drop of deregister G2H for selftest
+*/
+ bool drop_deregister;
+#endif
};
#endif /* __INTEL_CONTEXT_TYPES__ */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index f5bee833ee7d..5970c54a2e72 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2639,6 +2639,13 @@ int intel_guc_deregister_done_process_msg(struct
intel_guc *guc,
trace_intel_context_deregister_done(ce);
+#ifdef CONFIG_DRM_I915_SELFTEST
+ if (unlikely(ce->drop_deregister)) {
+ ce->drop_deregister = false;
+ return 0;
+ }
+#endif
+
if (context_wait_for_deregister_to_register(ce)) {
struct intel_runtime_pm *runtime_pm =
>engine->gt->i915->runtime_pm;
@@ -2693,10 +2700,24 @@ int intel_guc_sched_done_process_msg(struct intel_guc
*guc,
trace_intel_context_sched_done(ce);
if (context_pending_enable(ce)) {
+#ifdef CONFIG_DRM_I915_SELFTEST
+ if (unlikely(ce->drop_schedule_enable)) {
+ ce->drop_schedule_enable = false;
+ return 0;
+ }
+#endif
+
clr_context_pending_enable(ce);
} else if (context_pending_disable(ce)) {
bool banned;
+#ifdef CONFIG_DRM_I915_SELFTEST
+ if (unlikely(ce->drop_schedule_disable)) {
+ ce->drop_schedule_disable = false;
+ return 0;
+ }
+#endif
+
/*
* Unpin must be done before __guc_signal_context_fence,
* otherwise a race exists between the requests getting
@@ -3073,3 +3094,7 @@ bool intel_guc_virtual_engine_has_heartbeat(const struct
intel_engine_cs *ve)
return false;
}
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include "selftest_guc.c"
+#endif
diff --git a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
new file mode 100644
index ..fb0e4a7bd8ca
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
@@ -0,0 +1,127 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright �� 2021 Intel Corporation
+ */
+
+#include "selftests/intel_scheduler_helpers.h"
+
+static struct i915_request *nop_user_request(struct intel_context *ce,
+struct i915_request *from)
+{
+ struct i915_request *rq;
+ int ret;
+
+ rq = intel_context_create_request(ce);
+ if (IS_ERR(rq))
+ return rq;
+
+ if (from) {
+ ret = i915_sw_fence_await_dma_fence(>submit,
+ >fence, 0,
+ I915_FENCE_GFP);
+ if (ret < 0) {
+ i915_request_put(rq);
+ return ERR_PTR(ret);
+ }
+ }
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ return rq;
+}
+
+static int
[Intel-gfx] [PATCH 17/23] drm/i915/guc: Rework and simplify locking
Rework and simplify the locking with GuC subission. Drop
sched_state_no_lock and move all fields under the guc_state.sched_state
and protect all these fields with guc_state.lock . This requires
changing the locking hierarchy from guc_state.lock -> sched_engine.lock
to sched_engine.lock -> guc_state.lock.
v2:
(Daniele)
- Don't check fields outside of lock during sched disable, check less
fields within lock as some of the outside are no longer needed
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 5 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 199 --
drivers/gpu/drm/i915/i915_trace.h | 6 +-
3 files changed, 90 insertions(+), 120 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 5aecb9038b5b..d2f798ef678c 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -161,7 +161,7 @@ struct intel_context {
* sched_state: scheduling state of this context using GuC
* submission
*/
- u16 sched_state;
+ u32 sched_state;
/*
* fences: maintains of list of requests that have a submit
* fence related to GuC submission
@@ -178,9 +178,6 @@ struct intel_context {
struct list_head requests;
} guc_active;
- /* GuC scheduling state flags that do not require a lock. */
- atomic_t guc_sched_state_no_lock;
-
/* GuC LRC descriptor ID */
u16 guc_id;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 99f223114331..383dc1017004 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -72,87 +72,24 @@ guc_create_virtual(struct intel_engine_cs **siblings,
unsigned int count);
#define GUC_REQUEST_SIZE 64 /* bytes */
-/*
- * Below is a set of functions which control the GuC scheduling state which do
- * not require a lock as all state transitions are mutually exclusive. i.e. It
- * is not possible for the context pinning code and submission, for the same
- * context, to be executing simultaneously. We still need an atomic as it is
- * possible for some of the bits to changing at the same time though.
- */
-#define SCHED_STATE_NO_LOCK_ENABLEDBIT(0)
-#define SCHED_STATE_NO_LOCK_PENDING_ENABLE BIT(1)
-#define SCHED_STATE_NO_LOCK_REGISTERED BIT(2)
-static inline bool context_enabled(struct intel_context *ce)
-{
- return (atomic_read(>guc_sched_state_no_lock) &
- SCHED_STATE_NO_LOCK_ENABLED);
-}
-
-static inline void set_context_enabled(struct intel_context *ce)
-{
- atomic_or(SCHED_STATE_NO_LOCK_ENABLED, >guc_sched_state_no_lock);
-}
-
-static inline void clr_context_enabled(struct intel_context *ce)
-{
- atomic_and((u32)~SCHED_STATE_NO_LOCK_ENABLED,
- >guc_sched_state_no_lock);
-}
-
-static inline bool context_pending_enable(struct intel_context *ce)
-{
- return (atomic_read(>guc_sched_state_no_lock) &
- SCHED_STATE_NO_LOCK_PENDING_ENABLE);
-}
-
-static inline void set_context_pending_enable(struct intel_context *ce)
-{
- atomic_or(SCHED_STATE_NO_LOCK_PENDING_ENABLE,
- >guc_sched_state_no_lock);
-}
-
-static inline void clr_context_pending_enable(struct intel_context *ce)
-{
- atomic_and((u32)~SCHED_STATE_NO_LOCK_PENDING_ENABLE,
- >guc_sched_state_no_lock);
-}
-
-static inline bool context_registered(struct intel_context *ce)
-{
- return (atomic_read(>guc_sched_state_no_lock) &
- SCHED_STATE_NO_LOCK_REGISTERED);
-}
-
-static inline void set_context_registered(struct intel_context *ce)
-{
- atomic_or(SCHED_STATE_NO_LOCK_REGISTERED,
- >guc_sched_state_no_lock);
-}
-
-static inline void clr_context_registered(struct intel_context *ce)
-{
- atomic_and((u32)~SCHED_STATE_NO_LOCK_REGISTERED,
- >guc_sched_state_no_lock);
-}
-
/*
* Below is a set of functions which control the GuC scheduling state which
- * require a lock, aside from the special case where the functions are called
- * from guc_lrc_desc_pin(). In that case it isn't possible for any other code
- * path to be executing on the context.
+ * require a lock.
*/
#define SCHED_STATE_WAIT_FOR_DEREGISTER_TO_REGISTERBIT(0)
#define SCHED_STATE_DESTROYED BIT(1)
#define SCHED_STATE_PENDING_DISABLEBIT(2)
#define SCHED_STATE_BANNED BIT(3)
-#define SCHED_STATE_BLOCKED_SHIFT 4
+#define SCHED_STATE_ENABLEDBIT(4)
+#define SCHED_STATE_PENDING_ENABLE BIT(5)
[Intel-gfx] [PATCH 12/23] drm/i915/guc: Take context ref when cancelling request
A context can get destroyed after cancelling a request, if a context or
GT reset occurs, so take a reference to context when cancelling a
request.
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 5970c54a2e72..e036a171ff17 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1624,8 +1624,10 @@ static void guc_context_cancel_request(struct
intel_context *ce,
struct i915_request *rq)
{
if (i915_sw_fence_signaled(>submit)) {
- struct i915_sw_fence *fence = guc_context_block(ce);
+ struct i915_sw_fence *fence;
+ intel_context_get(ce);
+ fence = guc_context_block(ce);
i915_sw_fence_wait(fence);
if (!i915_request_completed(rq)) {
__i915_request_skip(rq);
@@ -1640,6 +1642,7 @@ static void guc_context_cancel_request(struct
intel_context *ce,
flush_work(_to_guc(ce)->ct.requests.worker);
guc_context_unblock(ce);
+ intel_context_put(ce);
}
}
--
2.32.0
[Intel-gfx] [PATCH 08/23] drm/i915/guc: Kick tasklet after queuing a request
Kick tasklet after queuing a request so it submitted in a timely manner.
Fixes: 3a4cdf1982f0 ("drm/i915/guc: Implement GuC context operations for new
inteface")
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index f9e3725b94c1..bd401a5be87c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1049,6 +1049,7 @@ static inline void queue_request(struct i915_sched_engine
*sched_engine,
list_add_tail(>sched.link,
i915_sched_lookup_priolist(sched_engine, prio));
set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
+ tasklet_hi_schedule(_engine->tasklet);
}
static int guc_bypass_tasklet_submit(struct intel_guc *guc,
--
2.32.0
