Re: [Intel-gfx] [RFC PATCH v3 04/17] drm/i915: Implement bind and unbind of object
On Sun, 28 Aug 2022 at 05:45, Andi Shyti wrote: > > From: Niranjana Vishwanathapura > > Implement the bind and unbind of an object at the specified GPU virtual > addresses. > > Signed-off-by: Niranjana Vishwanathapura > Signed-off-by: Prathap Kumar Valsan > Signed-off-by: Ramalingam C > Signed-off-by: Andi Shyti > --- > drivers/gpu/drm/i915/Makefile | 1 + > drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 21 ++ > .../drm/i915/gem/i915_gem_vm_bind_object.c| 322 ++ > drivers/gpu/drm/i915/gt/intel_gtt.c | 10 + > drivers/gpu/drm/i915/gt/intel_gtt.h | 9 + > drivers/gpu/drm/i915/i915_driver.c| 1 + > drivers/gpu/drm/i915/i915_vma.c | 3 +- > drivers/gpu/drm/i915/i915_vma.h | 2 - > drivers/gpu/drm/i915/i915_vma_types.h | 14 + > include/uapi/drm/i915_drm.h | 163 + > 10 files changed, 543 insertions(+), 3 deletions(-) > create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h > create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c > > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile > index 522ef9b4aff32..4e1627e96c6e0 100644 > --- a/drivers/gpu/drm/i915/Makefile > +++ b/drivers/gpu/drm/i915/Makefile > @@ -165,6 +165,7 @@ gem-y += \ > gem/i915_gem_ttm_move.o \ > gem/i915_gem_ttm_pm.o \ > gem/i915_gem_userptr.o \ > + gem/i915_gem_vm_bind_object.o \ > gem/i915_gem_wait.o \ > gem/i915_gemfs.o > i915-y += \ > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h > b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h > new file mode 100644 > index 0..ebc493b7dafc1 > --- /dev/null > +++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h > @@ -0,0 +1,21 @@ > +/* SPDX-License-Identifier: MIT */ > +/* > + * Copyright © 2022 Intel Corporation > + */ > + > +#ifndef __I915_GEM_VM_BIND_H > +#define __I915_GEM_VM_BIND_H > + > +#include "i915_drv.h" > + > +struct i915_vma * > +i915_gem_vm_bind_lookup_vma(struct i915_address_space *vm, u64 va); > +void i915_gem_vm_bind_remove(struct i915_vma *vma, bool release_obj); > + > +int i915_gem_vm_bind_ioctl(struct drm_device *dev, void *data, > + struct drm_file *file); > +int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void *data, > +struct drm_file *file); > + > +void i915_gem_vm_unbind_vma_all(struct i915_address_space *vm); > +#endif /* __I915_GEM_VM_BIND_H */ > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c > b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c > new file mode 100644 > index 0..dadd1d4b1761b > --- /dev/null > +++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c > @@ -0,0 +1,322 @@ > +// SPDX-License-Identifier: MIT > +/* > + * Copyright © 2022 Intel Corporation > + */ > + > +#include > + > +#include "gem/i915_gem_vm_bind.h" > +#include "gem/i915_gem_context.h" > +#include "gt/gen8_engine_cs.h" > + > +#include "i915_drv.h" > +#include "i915_gem_gtt.h" > + > +#define START(node) ((node)->start) > +#define LAST(node) ((node)->last) > + > +INTERVAL_TREE_DEFINE(struct i915_vma, rb, u64, __subtree_last, > +START, LAST, static inline, i915_vm_bind_it) > + > +#undef START > +#undef LAST > + > +/** > + * DOC: VM_BIND/UNBIND ioctls > + * > + * DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer > + * objects (BOs) or sections of a BOs at specified GPU virtual addresses on a > + * specified address space (VM). Multiple mappings can map to the same > physical > + * pages of an object (aliasing). These mappings (also referred to as > persistent > + * mappings) will be persistent across multiple GPU submissions (execbuf > calls) > + * issued by the UMD, without user having to provide a list of all required > + * mappings during each submission (as required by older execbuf mode). > + * > + * The VM_BIND/UNBIND calls allow UMDs to request a timeline out fence for > + * signaling the completion of bind/unbind operation. > + * > + * VM_BIND feature is advertised to user via I915_PARAM_VM_BIND_VERSION. > + * User has to opt-in for VM_BIND mode of binding for an address space (VM) > + * during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension. > + * > + * VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently > + * are not ordered. Furthermore, parts of the VM_BIND/UNBIND operations can > be > + * done asynchronously, when valid out fence is specified. > + * > + * VM_BIND locking order is as below. > + * > + * 1) vm_bind_lock mutex will protect vm_bind lists. This lock is taken in > + *vm_bind/vm_unbind ioctl calls, in the execbuf path and while releasing > the > + *mapping. > + * > + *In future, when GPU page faults are supported, we can potentially use a > + *rwsem instead, so that multiple page fault handlers can take the read > + *side lock
Re: [Intel-gfx] [RFC PATCH v3 04/17] drm/i915: Implement bind and unbind of object
On Tue, Aug 30, 2022 at 07:19:17PM +0100, Matthew Auld wrote: On 27/08/2022 20:43, Andi Shyti wrote: From: Niranjana Vishwanathapura Implement the bind and unbind of an object at the specified GPU virtual addresses. Signed-off-by: Niranjana Vishwanathapura Signed-off-by: Prathap Kumar Valsan Signed-off-by: Ramalingam C Signed-off-by: Andi Shyti --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 21 ++ .../drm/i915/gem/i915_gem_vm_bind_object.c| 322 ++ drivers/gpu/drm/i915/gt/intel_gtt.c | 10 + drivers/gpu/drm/i915/gt/intel_gtt.h | 9 + drivers/gpu/drm/i915/i915_driver.c| 1 + drivers/gpu/drm/i915/i915_vma.c | 3 +- drivers/gpu/drm/i915/i915_vma.h | 2 - drivers/gpu/drm/i915/i915_vma_types.h | 14 + include/uapi/drm/i915_drm.h | 163 + 10 files changed, 543 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 522ef9b4aff32..4e1627e96c6e0 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -165,6 +165,7 @@ gem-y += \ gem/i915_gem_ttm_move.o \ gem/i915_gem_ttm_pm.o \ gem/i915_gem_userptr.o \ + gem/i915_gem_vm_bind_object.o \ gem/i915_gem_wait.o \ gem/i915_gemfs.o i915-y += \ diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h new file mode 100644 index 0..ebc493b7dafc1 --- /dev/null +++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h @@ -0,0 +1,21 @@ +/* SPDX-License-Identifier: MIT */ +/* + * Copyright © 2022 Intel Corporation + */ + +#ifndef __I915_GEM_VM_BIND_H +#define __I915_GEM_VM_BIND_H + +#include "i915_drv.h" + +struct i915_vma * +i915_gem_vm_bind_lookup_vma(struct i915_address_space *vm, u64 va); +void i915_gem_vm_bind_remove(struct i915_vma *vma, bool release_obj); + +int i915_gem_vm_bind_ioctl(struct drm_device *dev, void *data, + struct drm_file *file); +int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void *data, +struct drm_file *file); + +void i915_gem_vm_unbind_vma_all(struct i915_address_space *vm); +#endif /* __I915_GEM_VM_BIND_H */ diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c new file mode 100644 index 0..dadd1d4b1761b --- /dev/null +++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c @@ -0,0 +1,322 @@ +// SPDX-License-Identifier: MIT +/* + * Copyright © 2022 Intel Corporation + */ + +#include + +#include "gem/i915_gem_vm_bind.h" +#include "gem/i915_gem_context.h" +#include "gt/gen8_engine_cs.h" + +#include "i915_drv.h" +#include "i915_gem_gtt.h" + +#define START(node) ((node)->start) +#define LAST(node) ((node)->last) + +INTERVAL_TREE_DEFINE(struct i915_vma, rb, u64, __subtree_last, +START, LAST, static inline, i915_vm_bind_it) + +#undef START +#undef LAST + +/** + * DOC: VM_BIND/UNBIND ioctls + * + * DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer + * objects (BOs) or sections of a BOs at specified GPU virtual addresses on a + * specified address space (VM). Multiple mappings can map to the same physical + * pages of an object (aliasing). These mappings (also referred to as persistent + * mappings) will be persistent across multiple GPU submissions (execbuf calls) + * issued by the UMD, without user having to provide a list of all required + * mappings during each submission (as required by older execbuf mode). + * + * The VM_BIND/UNBIND calls allow UMDs to request a timeline out fence for + * signaling the completion of bind/unbind operation. + * + * VM_BIND feature is advertised to user via I915_PARAM_VM_BIND_VERSION. + * User has to opt-in for VM_BIND mode of binding for an address space (VM) + * during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension. + * + * VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently + * are not ordered. Furthermore, parts of the VM_BIND/UNBIND operations can be + * done asynchronously, when valid out fence is specified. + * + * VM_BIND locking order is as below. + * + * 1) vm_bind_lock mutex will protect vm_bind lists. This lock is taken in + *vm_bind/vm_unbind ioctl calls, in the execbuf path and while releasing the + *mapping. + * + *In future, when GPU page faults are supported, we can potentially use a + *rwsem instead, so that multiple page fault handlers can take the read + *side lock to lookup the mapping and hence can run in parallel. + *The older execbuf mode of binding do not need this lock. + * + * 2) The object's dma-resv lock will protect i915_vma state and needs + *to be
Re: [Intel-gfx] [RFC PATCH v3 10/17] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl
On Wed, Aug 31, 2022 at 08:38:48AM +0100, Tvrtko Ursulin wrote:
On 27/08/2022 20:43, Andi Shyti wrote:
From: Niranjana Vishwanathapura
Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.
The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects binding would have been requested by the
userspace before submitting the execbuf3.
And the legacy support like relocations etc are removed.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/Makefile |1 +
.../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 1000 +
drivers/gpu/drm/i915/gem/i915_gem_ioctls.h|2 +
include/uapi/drm/i915_drm.h | 62 +
4 files changed, 1065 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4e1627e96c6e0..38cd1c5bc1a55 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -148,6 +148,7 @@ gem-y += \
gem/i915_gem_dmabuf.o \
gem/i915_gem_domain.o \
gem/i915_gem_execbuffer.o \
+ gem/i915_gem_execbuffer3.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
gem/i915_gem_lmem.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
new file mode 100644
index 0..a3d767cd9f808
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -0,0 +1,1000 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include
+
+#include "gt/intel_context.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_gt_pm.h"
+#include "gt/intel_ring.h"
+
+#include "i915_drv.h"
+#include "i915_file_private.h"
+#include "i915_gem_context.h"
+#include "i915_gem_ioctls.h"
+#include "i915_gem_vm_bind.h"
+#include "i915_trace.h"
+
+#define __EXEC3_ENGINE_PINNED BIT_ULL(32)
+#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
+
+/* Catch emission of unexpected errors for CI! */
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+#undef EINVAL
+#define EINVAL ({ \
+ DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__, __LINE__); \
+ 22; \
+})
+#endif
+
+/**
+ * DOC: User command execution with execbuf3 ioctl
+ *
+ * A VM in VM_BIND mode will not support older execbuf mode of binding.
+ * The execbuf ioctl handling in VM_BIND mode differs significantly from the
+ * older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
+ * Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
+ * struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
+ * execlist. Hence, no support for implicit sync.
+ *
+ * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
+ * works with execbuf3 ioctl for submission.
+ *
+ * The execbuf3 ioctl directly specifies the batch addresses instead of as
+ * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
+ * support many of the older features like in/out/submit fences, fence array,
+ * default gem context etc. (See struct drm_i915_gem_execbuffer3).
+ *
+ * In VM_BIND mode, VA allocation is completely managed by the user instead of
+ * the i915 driver. Hence all VA assignment, eviction are not applicable in
+ * VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
+ * be using the i915_vma active reference tracking. It will instead check the
+ * dma-resv object's fence list for that.
+ *
+ * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
+ * vma lookup table, implicit sync, vma active reference tracking etc., are not
+ * applicable for execbuf3 ioctl.
+ */
+
+struct eb_fence {
+ struct drm_syncobj *syncobj;
+ struct dma_fence *dma_fence;
+ u64 value;
+ struct dma_fence_chain *chain_fence;
+};
+
+/**
+ * struct i915_execbuffer - execbuf struct for execbuf3
+ * @i915: reference to the i915 instance we run on
+ * @file: drm file reference
+ * args: execbuf3 ioctl structure
+ * @gt: reference to the gt instance ioctl submitted for
+ * @context: logical state for the request
+ * @gem_context: callers context
+ * @requests: requests to be build
+ * @composite_fence: used for excl fence in dma_resv objects when > 1 BB
submitted
+ * @ww: i915_gem_ww_ctx instance
+ * @num_batches: number of batches submitted
+ * @batch_addresses: addresses corresponds to the submitted batches
+ * @batches: references to the i915_vmas corresponding to the batches
+ */
+struct i915_execbuffer {
+ struct drm_i915_private *i915;
+ struct drm_file *file;
+ struct drm_i915_gem_execbuffer3 *args;
+
+ struct intel_gt *gt;
+ struct intel_context *context;
+
Re: [Intel-gfx] [PATCH 15/15] vfio: Add struct device to vfio_device
On Thu, 1 Sep 2022 00:46:51 + "Tian, Kevin" wrote: > > From: Alex Williamson > > Sent: Thursday, September 1, 2022 1:15 AM > > > > On Wed, 31 Aug 2022 06:10:51 + > > "Tian, Kevin" wrote: > > > > > > From: Jason Gunthorpe > > > > Sent: Wednesday, August 31, 2022 7:53 AM > > > > > > > > On Tue, Aug 30, 2022 at 04:18:38PM -0600, Alex Williamson wrote: > > > > > On Sun, 28 Aug 2022 01:10:37 +0800 > > > > > Kevin Tian wrote: > > > > > > > > > > > From: Yi Liu > > > > > > > > > > > > and replace kref. With it a 'vfio-dev/vfioX' node is created under > > > > > > the > > > > > > sysfs path of the parent, indicating the device is bound to a vfio > > > > > > driver, e.g.: > > > > > > > > > > > > /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0 > > > > > > > > > > > > It is also a preparatory step toward adding cdev for supporting > > > > > > future > > > > > > device-oriented uAPI. > > > > > > > > > > Shall we start Documentation/ABI/testing/vfio-dev now? Thanks. > > > > > > > > I always thought that was something to use when adding new custom > > > > sysfs attributes? > > > > > > > > Here we are just creating a standard struct device with its standard > > > > sysfs? > > > > > > > > > > There is nothing special for vfio-dev/vfioX. But from pci device p.o.v > > > this does introduce a custom node in the directory, which is probably > > > what Alex referred to? > > > > Yup, but not just for pci, we're adding a node into the device > > directory for any device bound to vfio. > > > > > Anyway if required following can be introduced: > > > > > > diff --git a/Documentation/ABI/testing/sysfs-devices-vfio-dev > > b/Documentation/ABI/testing/sysfs-devices-vfio-dev > > > new file mode 100644 > > > index ..dfe8baaf1ccb > > > --- /dev/null > > > +++ b/Documentation/ABI/testing/sysfs-devices-vfio-dev > > > @@ -0,0 +1,8 @@ > > > +What: /sys/...//vfio-dev/vfioX/ > > > +Date: September 2022 > > > +Contact: Yi Liu > > > +Description: > > > + This directory is created when the device is bound to a > > > + vfio driver. The layout under this directory matches what > > > + exists for a standard 'struct device'. 'X' is a random > > > + number marking this device in vfio. > > > > It's not really random, it's a unique index. Seems like a good > > starting point. > > > > > > > > At the start I thought it might make more sense to add it into an > > > existing vfio ABI file. But looks it doesn't exist. > > > > > > Curious why nobody asked for ABI doc for /dev/vfio/vfio, /sys/class/vfio, > > > > > etc... > > > > Oversight, there should probably be a sysfs-class-vfio file. Thanks, > > > > I can help add one. > > btw I plan to respin v2 tomorrow. Regarding to this ABI thing there are > three options: > > 1) Just add sysfs-devices-vfio-dev in this series. Later merge to >sysfs-class-vfio once the latter is introduced in a separate patch. This. Thanks, Alex > > 2) Do sysfs-class-vfio in this series, including both existing vfio ABIs and >the new vfio-dev. > > 3) No ABI file in this series. Handle it in a separate patch with >sysfs-class-vfio. > > Which one do you prefer to? > > Thanks > Kevin >
Re: [Intel-gfx] [PATCH 15/15] vfio: Add struct device to vfio_device
> From: Alex Williamson > Sent: Thursday, September 1, 2022 1:15 AM > > On Wed, 31 Aug 2022 06:10:51 + > "Tian, Kevin" wrote: > > > > From: Jason Gunthorpe > > > Sent: Wednesday, August 31, 2022 7:53 AM > > > > > > On Tue, Aug 30, 2022 at 04:18:38PM -0600, Alex Williamson wrote: > > > > On Sun, 28 Aug 2022 01:10:37 +0800 > > > > Kevin Tian wrote: > > > > > > > > > From: Yi Liu > > > > > > > > > > and replace kref. With it a 'vfio-dev/vfioX' node is created under the > > > > > sysfs path of the parent, indicating the device is bound to a vfio > > > > > driver, e.g.: > > > > > > > > > > /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0 > > > > > > > > > > It is also a preparatory step toward adding cdev for supporting future > > > > > device-oriented uAPI. > > > > > > > > Shall we start Documentation/ABI/testing/vfio-dev now? Thanks. > > > > > > I always thought that was something to use when adding new custom > > > sysfs attributes? > > > > > > Here we are just creating a standard struct device with its standard > > > sysfs? > > > > > > > There is nothing special for vfio-dev/vfioX. But from pci device p.o.v > > this does introduce a custom node in the directory, which is probably > > what Alex referred to? > > Yup, but not just for pci, we're adding a node into the device > directory for any device bound to vfio. > > > Anyway if required following can be introduced: > > > > diff --git a/Documentation/ABI/testing/sysfs-devices-vfio-dev > b/Documentation/ABI/testing/sysfs-devices-vfio-dev > > new file mode 100644 > > index ..dfe8baaf1ccb > > --- /dev/null > > +++ b/Documentation/ABI/testing/sysfs-devices-vfio-dev > > @@ -0,0 +1,8 @@ > > +What: /sys/...//vfio-dev/vfioX/ > > +Date: September 2022 > > +Contact:Yi Liu > > +Description: > > +This directory is created when the device is bound to a > > +vfio driver. The layout under this directory matches what > > +exists for a standard 'struct device'. 'X' is a random > > +number marking this device in vfio. > > It's not really random, it's a unique index. Seems like a good > starting point. > > > > > At the start I thought it might make more sense to add it into an > > existing vfio ABI file. But looks it doesn't exist. > > > > Curious why nobody asked for ABI doc for /dev/vfio/vfio, /sys/class/vfio, > etc... > > Oversight, there should probably be a sysfs-class-vfio file. Thanks, > I can help add one. btw I plan to respin v2 tomorrow. Regarding to this ABI thing there are three options: 1) Just add sysfs-devices-vfio-dev in this series. Later merge to sysfs-class-vfio once the latter is introduced in a separate patch. 2) Do sysfs-class-vfio in this series, including both existing vfio ABIs and the new vfio-dev. 3) No ABI file in this series. Handle it in a separate patch with sysfs-class-vfio. Which one do you prefer to? Thanks Kevin
[Intel-gfx] ✗ Fi.CI.BAT: failure for Initial Meteorlake Support (rev4)
== Series Details ==
Series: Initial Meteorlake Support (rev4)
URL : https://patchwork.freedesktop.org/series/106786/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12058 -> Patchwork_106786v4
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_106786v4 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_106786v4, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v4/index.html
Participating hosts (37 -> 35)
--
Missing(2): fi-hsw-4770 fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106786v4:
### IGT changes ###
Possible regressions
* igt@gem_exec_suspend@basic-s0@smem:
- fi-skl-6600u: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12058/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v4/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
Known issues
Here are the changes found in Patchwork_106786v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[PASS][3] -> [DMESG-FAIL][4] ([i915#4528])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12058/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v4/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [PASS][5] -> [INCOMPLETE][6] ([i915#5982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12058/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v4/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-g3258: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v4/fi-hsw-g3258/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@runner@aborted:
- fi-pnv-d510:NOTRUN -> [FAIL][8] ([fdo#109271] / [i915#2403] /
[i915#4312])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v4/fi-pnv-d510/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}: [DMESG-WARN][9] ([i915#2867]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12058/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v4/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258: [INCOMPLETE][11] ([i915#3303] / [i915#4785]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12058/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v4/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [FAIL][13] ([i915#6298]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12058/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106786v4/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.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#2403]: https://gitlab.freedesktop.org/drm/intel/issues/2403
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4528]: https://gitlab.freedesktop.org/drm/intel/issues/4528
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#5982]: https://gitlab.freedesktop.org/drm/intel/issues/5982
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6380]: https://gitlab.freedesktop.org/drm/intel/issues/6380
Build changes
-
* Linux: CI_DRM_12058 -> Patchwork_106786v4
CI-20190529: 20190529
CI_DRM_12058: 2ef8278465adc6572e0d22dffbaa332d56b4b40c @
Re: [Intel-gfx] [PATCH] i915/pmu: Wire GuC backend to per-client busyness
On Wed, Aug 31, 2022 at 01:25:11PM -0700, Dixit, Ashutosh wrote:
On Fri, 26 Aug 2022 09:33:08 -0700, Umesh Nerlige Ramappa wrote:
Hi Umesh,
Just to communicate my thoughts I have posted this patch on top of your
patch:
[1] https://patchwork.freedesktop.org/series/107983/
Could you please take a look at that and see if it makes sense.
On Thu, Aug 25, 2022 at 06:44:50PM -0700, Dixit, Ashutosh wrote:
> On Thu, 04 Aug 2022 16:21:25 -0700, Umesh Nerlige Ramappa wrote:
>
> Hi Umesh, I am fairly new to this code so some questions will be below will
> be newbie questions, thanks for bearing with me.
>
>> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
>> index 654a092ed3d6..e2d70a9fdac0 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_context.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
>> @@ -576,16 +576,24 @@ void intel_context_bind_parent_child(struct
intel_context *parent,
>>child->parallel.parent = parent;
>> }
>>
>> -u64 intel_context_get_total_runtime_ns(const struct intel_context *ce)
>> +u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
>> {
>>u64 total, active;
>>
>> + if (ce->ops->update_stats)
>> + ce->ops->update_stats(ce);
>> +
>>total = ce->stats.runtime.total;
>>if (ce->ops->flags & COPS_RUNTIME_CYCLES)
>>total *= ce->engine->gt->clock_period_ns;
>>
>>active = READ_ONCE(ce->stats.active);
>> - if (active)
>> + /*
>> + * When COPS_RUNTIME_ACTIVE_TOTAL is set for ce->cops, the backend
>> + * already provides the total active time of the context, so skip this
>> + * calculation when this flag is set.
>> + */
>> + if (active && !(ce->ops->flags & COPS_RUNTIME_ACTIVE_TOTAL))
>>active = intel_context_clock() - active;
>>
>>return total + active;
>
> /snip/
>
>> @@ -1396,6 +1399,10 @@ static void guc_timestamp_ping(struct work_struct
*wrk)
>>with_intel_runtime_pm(>i915->runtime_pm, wakeref)
>>__update_guc_busyness_stats(guc);
>>
>> + /* adjust context stats for overflow */
>> + xa_for_each(>context_lookup, index, ce)
>> + __guc_context_update_clks(ce);
>
> What is the reason for calling __guc_context_update_clks() periodically
> from guc_timestamp_ping() since it appears we should just be able to call
> __guc_context_update_clks() from intel_context_get_total_runtime_ns() to
> update 'active'? Is the reason for calling __guc_context_update_clks()
> periodically that the calculations in __guc_context_update_clks() become
> invalid if the counters overflow?
Correct, these are 32-bit counters and the worker just tracks overflow.
OK.
>
>> +
>>intel_gt_reset_unlock(gt, srcu);
>>
>>mod_delayed_work(system_highpri_wq, >timestamp.work,
>> @@ -1469,6 +1476,56 @@ void intel_guc_busyness_unpark(struct intel_gt *gt)
>> guc->timestamp.ping_delay);
>> }
>>
>> +static void __guc_context_update_clks(struct intel_context *ce)
>> +{
>> + struct intel_guc *guc = ce_to_guc(ce);
>> + struct intel_gt *gt = ce->engine->gt;
>> + u32 *pphwsp, last_switch, engine_id;
>> + u64 start_gt_clk, active;
>> + unsigned long flags;
>> + ktime_t unused;
>> +
>> + spin_lock_irqsave(>timestamp.lock, flags);
>> +
>> + /*
>> + * GPU updates ce->lrc_reg_state[CTX_TIMESTAMP] when context is
switched
>> + * out, however GuC updates PPHWSP offsets below. Hence KMD (CPU)
>> + * relies on GuC and GPU for busyness calculations. Due to this, A
>> + * potential race was highlighted in an earlier review that can lead
to
>> + * double accounting of busyness. While the solution to this is a wip,
>> + * busyness is still usable for platforms running GuC submission.
>> + */
>> + pphwsp = ((void *)ce->lrc_reg_state) - LRC_STATE_OFFSET;
>> + last_switch = READ_ONCE(pphwsp[PPHWSP_GUC_CONTEXT_USAGE_STAMP_LO]);
>> + engine_id = READ_ONCE(pphwsp[PPHWSP_GUC_CONTEXT_USAGE_ENGINE_ID]);
>> +
>> + guc_update_pm_timestamp(guc, );
>> +
>> + if (engine_id != 0x && last_switch) {
>> + start_gt_clk = READ_ONCE(ce->stats.runtime.start_gt_clk);
>> + __extend_last_switch(guc, _gt_clk, last_switch);
>> + active = intel_gt_clock_interval_to_ns(gt,
guc->timestamp.gt_stamp - start_gt_clk);
>> + WRITE_ONCE(ce->stats.runtime.start_gt_clk, start_gt_clk);
>> + WRITE_ONCE(ce->stats.active, active);
>
> Should not need WRITE_ONCE to update regular memory. Not even sure we need
> READ_ONCE above.
Not sure I checked what they do. I was thinking these are needed for the
memory ordering (as in be sure that start_gt_clk is updated before
active).
As long as our operations are done under correct locks we don't have to
worry about memory ordering. That is one of the reasons I am doing
everything under
Re: [Intel-gfx] [RFC PATCH 2/2] Fix per client busyness locking
On Wed, Aug 31, 2022 at 12:33:55PM -0700, Ashutosh Dixit wrote:
1. Do all ce->stats updates and reads under guc->timestamp.lock
Other than the question about READ_ONCE/WRITE_ONCE, I am not sure I
understand what's broken in the locking logic here. Can you please add
some description? thanks
2. Pin context image before reading
3. Merge __guc_context_update_clks and guc_context_update_stats into a
single function
4. Call lrc_update_runtime() unconditionally in guc_context_update_stats
5. Seems no need to update ce->stats.active with this approach
Some of the above steps may not be correct or complete but the idea is to
discuss/improve the original patch.
Cc: Umesh Nerlige Ramappa
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 41 ++-
3 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index e2d70a9fdac0..c004f676de27 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -581,7 +581,7 @@ u64 intel_context_get_total_runtime_ns(struct intel_context
*ce)
u64 total, active;
if (ce->ops->update_stats)
- ce->ops->update_stats(ce);
+ return ce->ops->update_stats(ce);
This is an improvement that we can add and eventually, we can make this
a GuC specific vfunc. Doing so may also remove the
COPS_RUNTIME_ACTIVE_TOTAL option that I added to GuC specific context
ops.
total = ce->stats.runtime.total;
if (ce->ops->flags & COPS_RUNTIME_CYCLES)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index f7ff4c7d81c7..699435bfff99 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -59,7 +59,7 @@ struct intel_context_ops {
void (*sched_disable)(struct intel_context *ce);
- void (*update_stats)(struct intel_context *ce);
+ u64 (*update_stats)(struct intel_context *ce);
void (*reset)(struct intel_context *ce);
void (*destroy)(struct kref *kref);
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 bee8cf10f749..40d0edaf2e0a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1376,7 +1376,6 @@ static void __update_guc_busyness_stats(struct intel_guc
*guc)
spin_unlock_irqrestore(>timestamp.lock, flags);
}
-static void __guc_context_update_clks(struct intel_context *ce);
static void guc_timestamp_ping(struct work_struct *wrk)
{
struct intel_guc *guc = container_of(wrk, typeof(*guc),
@@ -1401,7 +1400,8 @@ static void guc_timestamp_ping(struct work_struct *wrk)
/* adjust context stats for overflow */
xa_for_each(>context_lookup, index, ce)
- __guc_context_update_clks(ce);
+ if (ce->ops->update_stats)
+ ce->ops->update_stats(ce);
context pinning logic needs to be separated for this (ping) path vs. the
query path - intel_context_get_total_runtime_ns().
intel_gt_reset_unlock(gt, srcu);
@@ -1476,17 +1476,21 @@ void intel_guc_busyness_unpark(struct intel_gt *gt)
guc->timestamp.ping_delay);
}
-static void __guc_context_update_clks(struct intel_context *ce)
+static u64 guc_context_update_stats(struct intel_context *ce)
{
struct intel_guc *guc = ce_to_guc(ce);
struct intel_gt *gt = ce->engine->gt;
u32 *pphwsp, last_switch, engine_id;
- u64 start_gt_clk, active;
unsigned long flags;
+ u64 total, active = 0;
ktime_t unused;
+ intel_context_pin(ce);
intel_context_pin can sleep and we are not allowed to sleep in this path
- intel_context_get_total_runtime_ns(), however we can sleep in the ping
worker path, so ideally we want to separate it out for the 2 paths.
spin_lock_irqsave(>timestamp.lock, flags);
+ lrc_update_runtime(ce);
+ total = ce->stats.runtime.total;
For long running contexts and frequenct queries, calling this ^ when a
context is active does not add value. I would just call it in the else
like before.
+
/*
* GPU updates ce->lrc_reg_state[CTX_TIMESTAMP] when context is switched
* out, however GuC updates PPHWSP offsets below. Hence KMD (CPU)
@@ -1502,27 +1506,26 @@ static void __guc_context_update_clks(struct
intel_context *ce)
guc_update_pm_timestamp(guc, );
if (engine_id != 0x && last_switch) {
- start_gt_clk = READ_ONCE(ce->stats.runtime.start_gt_clk);
- __extend_last_switch(guc, _gt_clk, last_switch);
- active = intel_gt_clock_interval_to_ns(gt,
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Initial Meteorlake Support (rev4)
== Series Details == Series: Initial Meteorlake Support (rev4) URL : https://patchwork.freedesktop.org/series/106786/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Initial Meteorlake Support (rev4)
== Series Details == Series: Initial Meteorlake Support (rev4) URL : https://patchwork.freedesktop.org/series/106786/ State : warning == Summary == Error: dim checkpatch failed f0dff2f56c1d drm/i915: Move display and media IP version to runtime info -:29: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible side-effects? #29: FILE: drivers/gpu/drm/i915/i915_drv.h:479: +#define MEDIA_VER_FULL(i915) IP_VER(RUNTIME_INFO(i915)->media.ver, \ + RUNTIME_INFO(i915)->media.rel) -:138: WARNING:LONG_LINE: line length of 104 exceeds 100 columns #138: FILE: drivers/gpu/drm/i915/intel_device_info.c:107: + drm_printf(p, "display version: %u.%02u\n", runtime->display.ver, runtime->display.rel); total: 0 errors, 1 warnings, 1 checks, 140 lines checked 8453574f56d8 drm/i915: Read graphics/media/display arch version from hw dfbd430a56fb drm/i915: Parse and set stepping for platforms with GMD 440633cbcfbb drm/i915/mtl: Define engine context layouts -:17: WARNING:TYPO_SPELLING: 'seperate' may be misspelled - perhaps 'separate'? #17: - Dg2, mtl xcs offsets slightly vary. Use a seperate offsets array(Bala) -:73: WARNING:LEADING_SPACE: please, no spaces at the start of a line #73: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:642: + NOP(1),$ -:74: WARNING:LEADING_SPACE: please, no spaces at the start of a line #74: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:643: + LRI(13, POSTED),$ -:75: WARNING:LEADING_SPACE: please, no spaces at the start of a line #75: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:644: + REG16(0x244),$ -:76: WARNING:LEADING_SPACE: please, no spaces at the start of a line #76: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:645: + REG(0x034),$ -:77: WARNING:LEADING_SPACE: please, no spaces at the start of a line #77: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:646: + REG(0x030),$ -:78: WARNING:LEADING_SPACE: please, no spaces at the start of a line #78: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:647: + REG(0x038),$ -:79: WARNING:LEADING_SPACE: please, no spaces at the start of a line #79: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:648: + REG(0x03c),$ -:80: WARNING:LEADING_SPACE: please, no spaces at the start of a line #80: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:649: + REG(0x168),$ -:81: WARNING:LEADING_SPACE: please, no spaces at the start of a line #81: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:650: + REG(0x140),$ -:82: WARNING:LEADING_SPACE: please, no spaces at the start of a line #82: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:651: + REG(0x110),$ -:83: WARNING:LEADING_SPACE: please, no spaces at the start of a line #83: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:652: + REG(0x1c0),$ -:84: WARNING:LEADING_SPACE: please, no spaces at the start of a line #84: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:653: + REG(0x1c4),$ -:85: WARNING:LEADING_SPACE: please, no spaces at the start of a line #85: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:654: + REG(0x1c8),$ -:86: WARNING:LEADING_SPACE: please, no spaces at the start of a line #86: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:655: + REG(0x180),$ -:87: WARNING:LEADING_SPACE: please, no spaces at the start of a line #87: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:656: + REG16(0x2b4),$ -:89: WARNING:LEADING_SPACE: please, no spaces at the start of a line #89: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:658: + NOP(1),$ -:90: WARNING:LEADING_SPACE: please, no spaces at the start of a line #90: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:659: + LRI(9, POSTED),$ -:91: WARNING:LEADING_SPACE: please, no spaces at the start of a line #91: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:660: + REG16(0x3a8),$ -:92: WARNING:LEADING_SPACE: please, no spaces at the start of a line #92: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:661: + REG16(0x28c),$ -:93: WARNING:LEADING_SPACE: please, no spaces at the start of a line #93: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:662: + REG16(0x288),$ -:94: WARNING:LEADING_SPACE: please, no spaces at the start of a line #94: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:663: + REG16(0x284),$ -:95: WARNING:LEADING_SPACE: please, no spaces at the start of a line #95: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:664: + REG16(0x280),$ -:96: WARNING:LEADING_SPACE: please, no spaces at the start of a line #96: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:665: + REG16(0x27c),$ -:97: WARNING:LEADING_SPACE: please, no spaces at the start of a line #97: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:666: + REG16(0x278),$ -:98: WARNING:LEADING_SPACE: please, no spaces at the start of a line #98: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:667: + REG16(0x274),$ -:99: WARNING:LEADING_SPACE: please, no spaces at the start of a line #99: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:668: +
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/slpc: Set rps' min and max frequencies even with SLPC. (rev7)
== Series Details ==
Series: drm/i915/slpc: Set rps' min and max frequencies even with SLPC. (rev7)
URL : https://patchwork.freedesktop.org/series/107766/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12058 -> Patchwork_107766v7
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v7/index.html
Participating hosts (37 -> 36)
--
Missing(1): fi-bdw-samus
Known issues
Here are the changes found in Patchwork_107766v7 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_lrc:
- fi-rkl-11600: [PASS][1] -> [DMESG-FAIL][2] ([i915#2373])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12058/fi-rkl-11600/igt@i915_selftest@live@gt_lrc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v7/fi-rkl-11600/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][3] -> [INCOMPLETE][4] ([i915#4785])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12058/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v7/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[PASS][5] -> [DMESG-FAIL][6] ([i915#4528])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12058/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v7/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [PASS][7] -> [INCOMPLETE][8] ([i915#5982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12058/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v7/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-g3258: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v7/fi-hsw-g3258/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][10] ([fdo#109271] / [i915#4312] /
[i915#5594] / [i915#6246])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v7/fi-hsw-4770/igt@run...@aborted.html
- fi-pnv-d510:NOTRUN -> [FAIL][11] ([fdo#109271] / [i915#2403] /
[i915#4312])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v7/fi-pnv-d510/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258: [INCOMPLETE][12] ([i915#3303] / [i915#4785]) ->
[PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12058/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v7/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@slpc:
- {bat-rpls-1}: [DMESG-FAIL][14] ([i915#6367]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12058/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v7/bat-rpls-1/igt@i915_selftest@l...@slpc.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [FAIL][16] ([i915#6298]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12058/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v7/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
Warnings
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [DMESG-FAIL][18] ([i915#4494] / [i915#4957]) ->
[DMESG-FAIL][19] ([i915#4957])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12058/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v7/bat-dg1-5/igt@i915_selftest@l...@hangcheck.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#2373]: https://gitlab.freedesktop.org/drm/intel/issues/2373
[i915#2403]: https://gitlab.freedesktop.org/drm/intel/issues/2403
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4494]:
Re: [Intel-gfx] [PATCH] drm/i915/slpc: Let's fix the PCODE min freq table setup for SLPC
On Wed, 31 Aug 2022 14:45:38 -0700, Rodrigo Vivi wrote: > Hi Rodrigo, > We need to inform PCODE of a desired ring frequencies so PCODE update > the memory frequencies to us. rps->min_freq and rps->max_freq are the > frequencies used in that request. However they were unset when SLPC was > enabled and PCODE never updated the memory freq. > > v2 (as Suggested by Ashutosh): if SLPC is in use, let's pick the right >frequencies from the get_ia_constants instead of the fake init of >rps' min and max. > > v3: don't forget the max <= min return > > v4: Move all the freq conversion to intel_rps.c. And the max <= min > check to where it belongs. > > v5: (Ashutosh) Fix old comment s/50 HZ/50 MHz and add a doc explaining > the "raw format" I think we both agree that mostly the way this patch is written it is to add SLPC but not risk disturbing host turbo, specially old platforms (CHV/VLV/ILK and pre-Gen 6). Also these freq units (sometimes 16.67 MHz units, sometimes 50 MHz, sometime MHz) in different places in the driver and different product generations is hugely confusing to say the least. For old platform we don't really know what units the freq's are in, we only know intel_gpu_freq will magically convert freq's to MHz. In any case let's work with what we have. > @@ -130,6 +123,12 @@ static void gen6_update_ring_freq(struct intel_llc *llc) > if (!get_ia_constants(llc, )) > return; > > + /* > + * Although this is unlikely on any platform during initialization, > + * let's ensure we don't get accidentally into infinite loop > + */ > + if (consts.max_gpu_freq <= consts.min_gpu_freq) > + return; As I said I would remove reference to "infinite loop", I am not seeing any infinite loop, maybe just delete the comment. Also as I said I see the check above should be completely removed (so it is actually a pre-existing bug in the code). However since you want to carry it forward in order not to risk disturbing legacy behavior that's fine. Rest LGTM: Reviewed-by: Ashutosh Dixit
[Intel-gfx] [PATCH v3 04/11] drm/i915/mtl: Define engine context layouts
From: Matt Roper
The part of the media and blitter engine contexts that we care about for
setting up an initial state are the same on MTL as they were on DG2
(and PVC), so we need to update the driver conditions to re-use the DG2
context table.
For render/compute engines, the part of the context images are nearly
the same, although the layout had a very slight change --- one POSH
register was removed and the placement of some LRI/noops adjusted
slightly to compensate.
v2:
- Dg2, mtl xcs offsets slightly vary. Use a seperate offsets array(Bala)
- Drop unused registers in mtl rcs offsets.(Bala)
Bspec: 46261, 46260, 45585
Cc: Balasubramani Vivekanandan
Signed-off-by: Matt Roper
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 81 -
1 file changed, 79 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 070cec4ff8a4..ecb030ee39cd 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -264,6 +264,38 @@ static const u8 dg2_xcs_offsets[] = {
END
};
+static const u8 mtl_xcs_offsets[] = {
+ NOP(1),
+ LRI(13, POSTED),
+ REG16(0x244),
+ REG(0x034),
+ REG(0x030),
+ REG(0x038),
+ REG(0x03c),
+ REG(0x168),
+ REG(0x140),
+ REG(0x110),
+ REG(0x1c0),
+ REG(0x1c4),
+ REG(0x1c8),
+ REG(0x180),
+ REG16(0x2b4),
+
+ NOP(1),
+ LRI(9, POSTED),
+ REG16(0x3a8),
+ REG16(0x28c),
+ REG16(0x288),
+ REG16(0x284),
+ REG16(0x280),
+ REG16(0x27c),
+ REG16(0x278),
+ REG16(0x274),
+ REG16(0x270),
+
+ END
+};
+
static const u8 gen8_rcs_offsets[] = {
NOP(1),
LRI(14, POSTED),
@@ -606,6 +638,47 @@ static const u8 dg2_rcs_offsets[] = {
END
};
+static const u8 mtl_rcs_offsets[] = {
+ NOP(1),
+ LRI(13, POSTED),
+ REG16(0x244),
+ REG(0x034),
+ REG(0x030),
+ REG(0x038),
+ REG(0x03c),
+ REG(0x168),
+ REG(0x140),
+ REG(0x110),
+ REG(0x1c0),
+ REG(0x1c4),
+ REG(0x1c8),
+ REG(0x180),
+ REG16(0x2b4),
+
+ NOP(1),
+ LRI(9, POSTED),
+ REG16(0x3a8),
+ REG16(0x28c),
+ REG16(0x288),
+ REG16(0x284),
+ REG16(0x280),
+ REG16(0x27c),
+ REG16(0x278),
+ REG16(0x274),
+ REG16(0x270),
+
+ NOP(2),
+ LRI(2, POSTED),
+ REG16(0x5a8),
+ REG16(0x5ac),
+
+ NOP(6),
+ LRI(1, 0),
+ REG(0x0c8),
+
+ END
+};
+
#undef END
#undef REG16
#undef REG
@@ -624,7 +697,9 @@ static const u8 *reg_offsets(const struct intel_engine_cs
*engine)
!intel_engine_has_relative_mmio(engine));
if (engine->flags & I915_ENGINE_HAS_RCS_REG_STATE) {
- if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
+ if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 70))
+ return mtl_rcs_offsets;
+ else if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
return dg2_rcs_offsets;
else if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50))
return xehp_rcs_offsets;
@@ -637,7 +712,9 @@ static const u8 *reg_offsets(const struct intel_engine_cs
*engine)
else
return gen8_rcs_offsets;
} else {
- if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
+ if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 70))
+ return mtl_xcs_offsets;
+ else if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
return dg2_xcs_offsets;
else if (GRAPHICS_VER(engine->i915) >= 12)
return gen12_xcs_offsets;
--
2.25.1
[Intel-gfx] [PATCH v3 07/11] drm/i915/mtl: Add DP AUX support on TypeC ports
From: Imre Deak
On MTL TypeC ports the AUX_CH_CTL and AUX_CH_DATA addresses have
changed wrt. previous platforms, adjust the code accordingly.
Signed-off-by: Imre Deak
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_dp_aux.c | 45 -
drivers/gpu/drm/i915/i915_reg.h | 9 +
2 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c
b/drivers/gpu/drm/i915/display/intel_dp_aux.c
index 98bd33645b43..48c375c65a41 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
@@ -637,6 +637,46 @@ static i915_reg_t tgl_aux_data_reg(struct intel_dp
*intel_dp, int index)
}
}
+static i915_reg_t xelpdp_aux_ctl_reg(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ enum aux_ch aux_ch = dig_port->aux_ch;
+
+ switch (aux_ch) {
+ case AUX_CH_A:
+ case AUX_CH_B:
+ case AUX_CH_USBC1:
+ case AUX_CH_USBC2:
+ case AUX_CH_USBC3:
+ case AUX_CH_USBC4:
+ return XELPDP_DP_AUX_CH_CTL(aux_ch);
+ default:
+ MISSING_CASE(aux_ch);
+ return XELPDP_DP_AUX_CH_CTL(AUX_CH_A);
+ }
+}
+
+static i915_reg_t xelpdp_aux_data_reg(struct intel_dp *intel_dp, int index)
+{
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ enum aux_ch aux_ch = dig_port->aux_ch;
+
+ switch (aux_ch) {
+ case AUX_CH_A:
+ case AUX_CH_B:
+ case AUX_CH_USBC1:
+ case AUX_CH_USBC2:
+ case AUX_CH_USBC3:
+ case AUX_CH_USBC4:
+ return XELPDP_DP_AUX_CH_DATA(aux_ch, index);
+ default:
+ MISSING_CASE(aux_ch);
+ return XELPDP_DP_AUX_CH_DATA(AUX_CH_A, index);
+ }
+}
+
void intel_dp_aux_fini(struct intel_dp *intel_dp)
{
if (cpu_latency_qos_request_active(_dp->pm_qos))
@@ -652,7 +692,10 @@ void intel_dp_aux_init(struct intel_dp *intel_dp)
struct intel_encoder *encoder = _port->base;
enum aux_ch aux_ch = dig_port->aux_ch;
- if (DISPLAY_VER(dev_priv) >= 12) {
+ if (DISPLAY_VER(dev_priv) >= 14) {
+ intel_dp->aux_ch_ctl_reg = xelpdp_aux_ctl_reg;
+ intel_dp->aux_ch_data_reg = xelpdp_aux_data_reg;
+ } else if (DISPLAY_VER(dev_priv) >= 12) {
intel_dp->aux_ch_ctl_reg = tgl_aux_ctl_reg;
intel_dp->aux_ch_data_reg = tgl_aux_data_reg;
} else if (DISPLAY_VER(dev_priv) >= 9) {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 42e26057f44a..18adfd8126a2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3470,6 +3470,15 @@
_XELPDP_USBC3_AUX_CH_CTL, \
_XELPDP_USBC4_AUX_CH_CTL))
+#define XELPDP_DP_AUX_CH_DATA(aux_ch, i) _MMIO(_PICK(aux_ch, \
+ _DPA_AUX_CH_DATA1, \
+ _DPB_AUX_CH_DATA1, \
+ 0, /* port/aux_ch C is
non-existent */ \
+
_XELPDP_USBC1_AUX_CH_DATA1, \
+
_XELPDP_USBC2_AUX_CH_DATA1, \
+
_XELPDP_USBC3_AUX_CH_DATA1, \
+
_XELPDP_USBC4_AUX_CH_DATA1) + (i) * 4)
+
#define DP_AUX_CH_CTL_SEND_BUSY (1 << 31)
#define DP_AUX_CH_CTL_DONE (1 << 30)
#define DP_AUX_CH_CTL_INTERRUPT (1 << 29)
--
2.25.1
[Intel-gfx] [PATCH v3 09/11] drm/i915/mtl: Update MBUS_DBOX credits
Display version 14 platforms have different credits values compared to ADL-P.
Update the credits based on pipe usage.
v2: Simplify DBOX BW Credit definition(MattR)
Bspec: 49213
Cc: Jose Roberto de Souza
Cc: Matt Roper
Original Author: Caz Yokoyama
Signed-off-by: José Roberto de Souza
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/i915_reg.h | 4 +++
drivers/gpu/drm/i915/intel_pm.c | 47 ++---
2 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d22fabe35a0c..f9237586ab4f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1125,8 +1125,12 @@
#define MBUS_DBOX_REGULATE_B2B_TRANSACTIONS_EN REG_BIT(16) /* tgl+ */
#define MBUS_DBOX_BW_CREDIT_MASK REG_GENMASK(15, 14)
#define MBUS_DBOX_BW_CREDIT(x)
REG_FIELD_PREP(MBUS_DBOX_BW_CREDIT_MASK, x)
+#define MBUS_DBOX_BW_4CREDITS_MTL
REG_FIELD_PREP(MBUS_DBOX_BW_CREDIT_MASK, 0x2)
+#define MBUS_DBOX_BW_8CREDITS_MTL
REG_FIELD_PREP(MBUS_DBOX_BW_CREDIT_MASK, 0x3)
#define MBUS_DBOX_B_CREDIT_MASKREG_GENMASK(12, 8)
#define MBUS_DBOX_B_CREDIT(x)
REG_FIELD_PREP(MBUS_DBOX_B_CREDIT_MASK, x)
+#define MBUS_DBOX_I_CREDIT_MASKREG_GENMASK(7, 5)
+#define MBUS_DBOX_I_CREDIT(x)
REG_FIELD_PREP(MBUS_DBOX_I_CREDIT_MASK, x)
#define MBUS_DBOX_A_CREDIT_MASKREG_GENMASK(3, 0)
#define MBUS_DBOX_A_CREDIT(x)
REG_FIELD_PREP(MBUS_DBOX_A_CREDIT_MASK, x)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ebce6171ccef..b19a1ecb010e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -8448,6 +8448,27 @@ void intel_dbuf_post_plane_update(struct
intel_atomic_state *state)
new_dbuf_state->enabled_slices);
}
+static bool xelpdp_is_one_pipe_per_dbuf_bank(enum pipe pipe, u8 active_pipes)
+{
+ switch (pipe) {
+ case PIPE_A:
+ case PIPE_D:
+ if (is_power_of_2(active_pipes & (BIT(PIPE_A) | BIT(PIPE_D
+ return true;
+ break;
+ case PIPE_B:
+ case PIPE_C:
+ if (is_power_of_2(active_pipes & (BIT(PIPE_B) | BIT(PIPE_C
+ return true;
+ break;
+ default: /* to suppress compiler warning */
+ MISSING_CASE(pipe);
+ break;
+ }
+
+ return false;
+}
+
void intel_mbus_dbox_update(struct intel_atomic_state *state)
{
struct drm_i915_private *i915 = to_i915(state->base.dev);
@@ -8467,20 +8488,28 @@ void intel_mbus_dbox_update(struct intel_atomic_state
*state)
new_dbuf_state->active_pipes == old_dbuf_state->active_pipes))
return;
+ if (DISPLAY_VER(i915) >= 14)
+ val |= MBUS_DBOX_I_CREDIT(2);
+
if (DISPLAY_VER(i915) >= 12) {
val |= MBUS_DBOX_B2B_TRANSACTIONS_MAX(16);
val |= MBUS_DBOX_B2B_TRANSACTIONS_DELAY(1);
val |= MBUS_DBOX_REGULATE_B2B_TRANSACTIONS_EN;
}
- /* Wa_22010947358:adl-p */
- if (IS_ALDERLAKE_P(i915))
+ if (DISPLAY_VER(i915) >= 14)
+ val |= new_dbuf_state->joined_mbus ? MBUS_DBOX_A_CREDIT(12) :
+MBUS_DBOX_A_CREDIT(8);
+ else if (IS_ALDERLAKE_P(i915))
+ /* Wa_22010947358:adl-p */
val |= new_dbuf_state->joined_mbus ? MBUS_DBOX_A_CREDIT(6) :
MBUS_DBOX_A_CREDIT(4);
else
val |= MBUS_DBOX_A_CREDIT(2);
- if (IS_ALDERLAKE_P(i915)) {
+ if (DISPLAY_VER(i915) >= 14) {
+ val |= MBUS_DBOX_B_CREDIT(0xA);
+ } else if (IS_ALDERLAKE_P(i915)) {
val |= MBUS_DBOX_BW_CREDIT(2);
val |= MBUS_DBOX_B_CREDIT(8);
} else if (DISPLAY_VER(i915) >= 12) {
@@ -8492,10 +8521,20 @@ void intel_mbus_dbox_update(struct intel_atomic_state
*state)
}
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
+ u32 pipe_val = val;
+
if (!new_crtc_state->hw.active ||
!intel_crtc_needs_modeset(new_crtc_state))
continue;
- intel_de_write(i915, PIPE_MBUS_DBOX_CTL(crtc->pipe), val);
+ if (DISPLAY_VER(i915) >= 14) {
+ if (xelpdp_is_one_pipe_per_dbuf_bank(crtc->pipe,
+
new_dbuf_state->active_pipes))
+ pipe_val |= MBUS_DBOX_BW_8CREDITS_MTL;
+ else
+ pipe_val |= MBUS_DBOX_BW_4CREDITS_MTL;
+ }
+
+ intel_de_write(i915,
[Intel-gfx] [PATCH v3 03/11] drm/i915: Parse and set stepping for platforms with GMD
From: José Roberto de Souza
The GMD step field do not properly match the current stepping convention
that we use(STEP_A0, STEP_A1, STEP_B0...).
One platform could have { arch = 12, rel = 70, step = 1 } and the
actual stepping is STEP_B0 but without the translation of the step
field would mean STEP_A1.
That is why we will need to have gmd_to_intel_step tables for each IP.
Reviewed-by: Balasubramani Vivekanandan
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_step.c | 60 +++
1 file changed, 60 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_step.c
b/drivers/gpu/drm/i915/intel_step.c
index 42b3133d8387..0fa7147c7d0f 100644
--- a/drivers/gpu/drm/i915/intel_step.c
+++ b/drivers/gpu/drm/i915/intel_step.c
@@ -135,6 +135,48 @@ static const struct intel_step_info adlp_n_revids[] = {
[0x0] = { COMMON_GT_MEDIA_STEP(A0), .display_step = STEP_D0 },
};
+struct gmd_to_intel_step {
+ struct ip_version gmd;
+ enum intel_step step;
+};
+
+static const struct gmd_to_intel_step gmd_graphics_table[] = {
+ { .gmd.ver = 12, .gmd.rel = 70, .gmd.step = 0, .step = STEP_A0 },
+ { .gmd.ver = 12, .gmd.rel = 70, .gmd.step = 4, .step = STEP_B0 },
+ { .gmd.ver = 12, .gmd.rel = 71, .gmd.step = 0, .step = STEP_A0 },
+ { .gmd.ver = 12, .gmd.rel = 71, .gmd.step = 4, .step = STEP_B0 },
+ { .gmd.ver = 12, .gmd.rel = 73, .gmd.step = 0, .step = STEP_A0 },
+ { .gmd.ver = 12, .gmd.rel = 73, .gmd.step = 4, .step = STEP_B0 },
+};
+
+static const struct gmd_to_intel_step gmd_media_table[] = {
+ { .gmd.ver = 13, .gmd.rel = 70, .gmd.step = 0, .step = STEP_A0 },
+ { .gmd.ver = 13, .gmd.rel = 70, .gmd.step = 4, .step = STEP_B0 },
+};
+
+static const struct gmd_to_intel_step gmd_display_table[] = {
+ { .gmd.ver = 14, .gmd.rel = 0, .gmd.step = 0, .step = STEP_A0 },
+ { .gmd.ver = 14, .gmd.rel = 0, .gmd.step = 4, .step = STEP_B0 },
+};
+
+static u8 gmd_to_intel_step(struct drm_i915_private *i915,
+ struct ip_version *gmd,
+ const struct gmd_to_intel_step *table,
+ int len)
+{
+ int i;
+
+ for (i = 0; i < len; i++) {
+ if (table[i].gmd.ver == gmd->ver &&
+ table[i].gmd.rel == gmd->rel &&
+ table[i].gmd.step == gmd->step)
+ return table[i].step;
+ }
+
+ drm_dbg(>drm, "Using future steppings\n");
+ return STEP_FUTURE;
+}
+
static void pvc_step_init(struct drm_i915_private *i915, int pci_revid);
void intel_step_init(struct drm_i915_private *i915)
@@ -144,6 +186,24 @@ void intel_step_init(struct drm_i915_private *i915)
int revid = INTEL_REVID(i915);
struct intel_step_info step = {};
+ if (HAS_GMD_ID(i915)) {
+ step.graphics_step = gmd_to_intel_step(i915,
+
_INFO(i915)->graphics,
+ gmd_graphics_table,
+
ARRAY_SIZE(gmd_graphics_table));
+ step.media_step = gmd_to_intel_step(i915,
+ _INFO(i915)->media,
+ gmd_media_table,
+
ARRAY_SIZE(gmd_media_table));
+ step.display_step = gmd_to_intel_step(i915,
+
_INFO(i915)->display,
+ gmd_display_table,
+
ARRAY_SIZE(gmd_display_table));
+ RUNTIME_INFO(i915)->step = step;
+
+ return;
+ }
+
if (IS_PONTEVECCHIO(i915)) {
pvc_step_init(i915, revid);
return;
--
2.25.1
[Intel-gfx] [PATCH v3 10/11] drm/i915/mtl: Update CHICKEN_TRANS* register addresses
From: Madhumitha Tolakanahalli Pradeep
In Display version 14, Transcoder Chicken Registers are moved from DPRZ to DRPOS
to reduce register signal crossings for Unit Interface Optimization.
This patch modifies the CHICKEN_TRANS macro to add a DISPLAY_VER check for
calculating the correct platform offsets.
(And also updates existing CHICKEN_TRANS occurrences to the new definition)
v2: Omit display version check in i915_reg.h(Jani)
Bspec: 34387, 50054
Cc: Jani Nikula
Signed-off-by: Madhumitha Tolakanahalli Pradeep
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_display.c | 14 ---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +++-
drivers/gpu/drm/i915/display/intel_psr.c | 6 +++--
drivers/gpu/drm/i915/i915_reg.h | 25 +++-
4 files changed, 38 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index be7cff722196..a3d0d12084a9 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -618,7 +618,10 @@ void intel_disable_transcoder(const struct
intel_crtc_state *old_crtc_state)
if (!IS_I830(dev_priv))
val &= ~PIPECONF_ENABLE;
- if (DISPLAY_VER(dev_priv) >= 12)
+ if (DISPLAY_VER(dev_priv) >= 14)
+ intel_de_rmw(dev_priv, MTL_CHICKEN_TRANS(cpu_transcoder),
+FECSTALL_DIS_DPTSTREAM_DPTTG, 0);
+ else if (DISPLAY_VER(dev_priv) >= 12)
intel_de_rmw(dev_priv, CHICKEN_TRANS(cpu_transcoder),
FECSTALL_DIS_DPTSTREAM_DPTTG, 0);
@@ -1838,7 +1841,9 @@ static void hsw_set_frame_start_delay(const struct
intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- i915_reg_t reg = CHICKEN_TRANS(crtc_state->cpu_transcoder);
+ enum transcoder transcoder = crtc_state->cpu_transcoder;
+ i915_reg_t reg = DISPLAY_VER(dev_priv) >= 14 ?
MTL_CHICKEN_TRANS(transcoder) :
+CHICKEN_TRANS(transcoder);
u32 val;
val = intel_de_read(dev_priv, reg);
@@ -4033,6 +4038,7 @@ static bool hsw_get_pipe_config(struct intel_crtc *crtc,
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_display_power_domain_set power_domain_set = { };
+ i915_reg_t reg;
bool active;
u32 tmp;
@@ -4124,7 +4130,9 @@ static bool hsw_get_pipe_config(struct intel_crtc *crtc,
}
if (!transcoder_is_dsi(pipe_config->cpu_transcoder)) {
- tmp = intel_de_read(dev_priv,
CHICKEN_TRANS(pipe_config->cpu_transcoder));
+ reg = DISPLAY_VER(dev_priv) >= 14 ?
MTL_CHICKEN_TRANS(pipe_config->cpu_transcoder) :
+ CHICKEN_TRANS(pipe_config->cpu_transcoder);
+ tmp = intel_de_read(dev_priv, reg);
pipe_config->framestart_delay =
REG_FIELD_GET(HSW_FRAME_START_DELAY_MASK, tmp) + 1;
} else {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 13abe2b2170e..298004cae5a5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -568,7 +568,10 @@ static void intel_mst_enable_dp(struct intel_atomic_state
*state,
drm_dp_add_payload_part2(_dp->mst_mgr, >base,
drm_atomic_get_mst_payload_state(mst_state,
connector->port));
- if (DISPLAY_VER(dev_priv) >= 12 && pipe_config->fec_enable)
+ if (DISPLAY_VER(dev_priv) >= 14 && pipe_config->fec_enable)
+ intel_de_rmw(dev_priv, MTL_CHICKEN_TRANS(trans), 0,
+FECSTALL_DIS_DPTSTREAM_DPTTG);
+ else if (DISPLAY_VER(dev_priv) >= 12 && pipe_config->fec_enable)
intel_de_rmw(dev_priv, CHICKEN_TRANS(trans), 0,
FECSTALL_DIS_DPTSTREAM_DPTTG);
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 079b7d3d0c53..da2d0661b630 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1139,7 +1139,8 @@ static void intel_psr_enable_source(struct intel_dp
*intel_dp,
if (intel_dp->psr.psr2_enabled) {
if (DISPLAY_VER(dev_priv) == 9)
- intel_de_rmw(dev_priv, CHICKEN_TRANS(cpu_transcoder), 0,
+ intel_de_rmw(dev_priv,
+CHICKEN_TRANS(cpu_transcoder), 0,
PSR2_VSC_ENABLE_PROG_HEADER |
PSR2_ADD_VERTICAL_LINE_COUNT);
@@ -1149,7 +1150,8 @@ static void intel_psr_enable_source(struct intel_dp
*intel_dp,
* cause issues if non-supported panels are used.
[Intel-gfx] [PATCH v3 11/11] drm/i915/mtl: Do not update GV point, mask value
Display 14 and future platforms do not directly communicate to Pcode
via mailbox the SAGV bandwidth information. PM Demand registers are
used to communicate display power requirements to the PUnit which would
include GV point and mask value.
Skip programming GV point and mask values through legacy pcode mailbox
interface.
Bspec: 64636
Cc: Matt Roper
Original Author: Caz Yokoyama
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_pm.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b19a1ecb010e..69efd613bbde 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3923,6 +3923,14 @@ void intel_sagv_pre_plane_update(struct
intel_atomic_state *state)
{
struct drm_i915_private *i915 = to_i915(state->base.dev);
+ /*
+* No need to update mask value/restrict because
+* "Pcode only wants to use GV bandwidth value, not the mask value."
+* for DISPLAY_VER() >= 14.
+*/
+ if (DISPLAY_VER(i915) >= 14)
+ return;
+
/*
* Just return if we can't control SAGV or don't have it.
* This is different from situation when we have SAGV but just can't
@@ -3943,6 +3951,16 @@ void intel_sagv_post_plane_update(struct
intel_atomic_state *state)
{
struct drm_i915_private *i915 = to_i915(state->base.dev);
+ /*
+* No need to update mask value/restrict because
+* "Pcode only wants to use GV bandwidth value, not the mask value."
+* for DISPLAY_VER() >= 14.
+*
+* GV bandwidth will be set by intel_pmdemand_post_plane_update()
+*/
+ if (DISPLAY_VER(i915) >= 14)
+ return;
+
/*
* Just return if we can't control SAGV or don't have it.
* This is different from situation when we have SAGV but just can't
--
2.25.1
[Intel-gfx] [PATCH v3 01/11] drm/i915: Move display and media IP version to runtime info
Future platforms can read the IP version from a register and the
IP version numbers need not be hard coded in device info. Move the
ip version for media and display to runtime info.
On platforms where hard coding of IP version is required, update
the IP version in __runtime under device_info.
Suggested-by: Jani Nikula
Cc: Matt Roper
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/i915_drv.h | 8
drivers/gpu/drm/i915/i915_pci.c | 20 ++--
drivers/gpu/drm/i915/intel_device_info.c | 12 ++--
drivers/gpu/drm/i915/intel_device_info.h | 15 ++-
4 files changed, 30 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c9cca165bf5d..bf60593a4ce5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -475,13 +475,13 @@ static inline struct intel_gt *to_gt(struct
drm_i915_private *i915)
#define IS_GRAPHICS_VER(i915, from, until) \
(GRAPHICS_VER(i915) >= (from) && GRAPHICS_VER(i915) <= (until))
-#define MEDIA_VER(i915)(INTEL_INFO(i915)->media.ver)
-#define MEDIA_VER_FULL(i915) IP_VER(INTEL_INFO(i915)->media.ver, \
- INTEL_INFO(i915)->media.rel)
+#define MEDIA_VER(i915)(RUNTIME_INFO(i915)->media.ver)
+#define MEDIA_VER_FULL(i915) IP_VER(RUNTIME_INFO(i915)->media.ver, \
+ RUNTIME_INFO(i915)->media.rel)
#define IS_MEDIA_VER(i915, from, until) \
(MEDIA_VER(i915) >= (from) && MEDIA_VER(i915) <= (until))
-#define DISPLAY_VER(i915) (INTEL_INFO(i915)->display.ver)
+#define DISPLAY_VER(i915) (RUNTIME_INFO(i915)->display.ver)
#define IS_DISPLAY_VER(i915, from, until) \
(DISPLAY_VER(i915) >= (from) && DISPLAY_VER(i915) <= (until))
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 26b25d9434d6..72577e327c71 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -35,8 +35,8 @@
#define PLATFORM(x) .platform = (x)
#define GEN(x) \
.__runtime.graphics.ver = (x), \
- .media.ver = (x), \
- .display.ver = (x)
+ .__runtime.media.ver = (x), \
+ .__runtime.display.ver = (x)
#define I845_PIPE_OFFSETS \
.display.pipe_offsets = { \
@@ -740,7 +740,7 @@ static const struct intel_device_info bxt_info = {
static const struct intel_device_info glk_info = {
GEN9_LP_FEATURES,
PLATFORM(INTEL_GEMINILAKE),
- .display.ver = 10,
+ .__runtime.display.ver = 10,
.display.dbuf.size = 1024 - 4, /* 4 blocks for bypass path allocation */
GLK_COLORS,
};
@@ -962,7 +962,7 @@ static const struct intel_device_info adl_s_info = {
.display.has_hotplug = 1,
\
.display.has_ipc = 1,
\
.display.has_psr = 1,
\
- .display.ver = 13,
\
+ .__runtime.display.ver = 13,
\
.__runtime.pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) |
BIT(PIPE_D), \
.display.pipe_offsets = {
\
[TRANSCODER_A] = PIPE_A_OFFSET,
\
@@ -1027,8 +1027,8 @@ static const struct intel_device_info adl_p_info = {
.__runtime.ppgtt_type = INTEL_PPGTT_FULL
#define XE_HPM_FEATURES \
- .media.ver = 12, \
- .media.rel = 50
+ .__runtime.media.ver = 12, \
+ .__runtime.media.rel = 50
__maybe_unused
static const struct intel_device_info xehpsdv_info = {
@@ -1054,7 +1054,7 @@ static const struct intel_device_info xehpsdv_info = {
XE_HPM_FEATURES, \
DGFX_FEATURES, \
.__runtime.graphics.rel = 55, \
- .media.rel = 55, \
+ .__runtime.media.rel = 55, \
PLATFORM(INTEL_DG2), \
.has_4tile = 1, \
.has_64k_pages = 1, \
@@ -1098,7 +1098,7 @@ static const struct intel_device_info pvc_info = {
XE_HPM_FEATURES,
DGFX_FEATURES,
.__runtime.graphics.rel = 60,
- .media.rel = 60,
+ .__runtime.media.rel = 60,
PLATFORM(INTEL_PONTEVECCHIO),
.display = { 0 },
.has_flat_ccs = 0,
@@ -,7 +,7 @@ static const struct intel_device_info pvc_info = {
#define XE_LPDP_FEATURES \
XE_LPD_FEATURES,\
- .display.ver = 14, \
+ .__runtime.display.ver = 14,\
.display.has_cdclk_crawl = 1, \
.__runtime.fbc_mask = BIT(INTEL_FBC_A) | BIT(INTEL_FBC_B)
@@ -1125,7 +1125,7 @@ static const struct intel_device_info mtl_info = {
*/
.__runtime.graphics.ver = 12,
.__runtime.graphics.rel = 70,
-
[Intel-gfx] [PATCH v3 08/11] drm/i915/mtl: Obtain SAGV values from MMIO instead of GT pcode mailbox
>From Meteorlake, Latency Level, SAGV bloack time are read from
LATENCY_SAGV register instead of the GT driver pcode mailbox. DDR type
and QGV information are also to be read from Mem SS registers.
v2:
- Simplify MTL_MEM_SS_INFO_QGV_POINT macro(MattR)
- Nit: Rearrange the bit def's from higher to lower(MattR)
- Restore platform definition for ADL-P(MattR)
- Move back intel_qgv_point def to intel_bw.c(Jani)
Bspec: 64636, 64608
Cc: Jani Nikula
Reviewed-by: Matt Roper
Original Author: Caz Yokoyama
Signed-off-by: José Roberto de Souza
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_bw.c | 42 ++---
drivers/gpu/drm/i915/i915_reg.h | 18 +++
drivers/gpu/drm/i915/intel_dram.c | 41 +++-
drivers/gpu/drm/i915/intel_pm.c | 8 -
4 files changed, 102 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 61308ebe48aa..b13c4e240619 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -137,6 +137,42 @@ int icl_pcode_restrict_qgv_points(struct drm_i915_private
*dev_priv,
return 0;
}
+static int mtl_read_qgv_point_info(struct drm_i915_private *dev_priv,
+ struct intel_qgv_point *sp, int point)
+{
+ u32 val, val2;
+ u16 dclk;
+
+ val = intel_uncore_read(_priv->uncore,
+ MTL_MEM_SS_INFO_QGV_POINT_LOW(point));
+ val2 = intel_uncore_read(_priv->uncore,
+MTL_MEM_SS_INFO_QGV_POINT_HIGH(point));
+ dclk = REG_FIELD_GET(MTL_DCLK_MASK, val);
+ sp->dclk = DIV_ROUND_UP((16667 * dclk), 1000);
+ sp->t_rp = REG_FIELD_GET(MTL_TRP_MASK, val);
+ sp->t_rcd = REG_FIELD_GET(MTL_TRCD_MASK, val);
+
+ sp->t_rdpre = REG_FIELD_GET(MTL_TRDPRE_MASK, val2);
+ sp->t_ras = REG_FIELD_GET(MTL_TRAS_MASK, val2);
+
+ sp->t_rc = sp->t_rp + sp->t_ras;
+
+ return 0;
+}
+
+static int
+intel_read_qgv_point_info(struct drm_i915_private *dev_priv,
+ struct intel_qgv_point *sp,
+ int point)
+{
+ if (DISPLAY_VER(dev_priv) >= 14)
+ return mtl_read_qgv_point_info(dev_priv, sp, point);
+ else if (IS_DG1(dev_priv))
+ return dg1_mchbar_read_qgv_point_info(dev_priv, sp, point);
+ else
+ return icl_pcode_read_qgv_point_info(dev_priv, sp, point);
+}
+
static int icl_get_qgv_points(struct drm_i915_private *dev_priv,
struct intel_qgv_info *qi,
bool is_y_tile)
@@ -218,11 +254,7 @@ static int icl_get_qgv_points(struct drm_i915_private
*dev_priv,
for (i = 0; i < qi->num_points; i++) {
struct intel_qgv_point *sp = >points[i];
- if (IS_DG1(dev_priv))
- ret = dg1_mchbar_read_qgv_point_info(dev_priv, sp, i);
- else
- ret = icl_pcode_read_qgv_point_info(dev_priv, sp, i);
-
+ ret = intel_read_qgv_point_info(dev_priv, sp, i);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 18adfd8126a2..d22fabe35a0c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8334,4 +8334,22 @@ enum skl_power_gate {
#define MTL_LATENCY_LEVEL_ODD_MASKREG_GENMASK(28, 16)
#define MTL_MEDIA_GSI_BASE 0x38
+
+#define MTL_LATENCY_SAGV _MMIO(0x4578c)
+#define MTL_LATENCY_QCLK_SAGVREG_GENMASK(12, 0)
+
+#define MTL_MEM_SS_INFO_GLOBAL _MMIO(0x45700)
+#define MTL_N_OF_ENABLED_QGV_POINTS_MASK REG_GENMASK(11, 8)
+#define MTL_N_OF_POPULATED_CH_MASK REG_GENMASK(7, 4)
+#define MTL_DDR_TYPE_MASKREG_GENMASK(3, 0)
+
+#define MTL_MEM_SS_INFO_QGV_POINT_LOW(point)_MMIO(0x45710 + (point) * 2)
+#define MTL_TRCD_MASKREG_GENMASK(31, 24)
+#define MTL_TRP_MASK REG_GENMASK(23, 16)
+#define MTL_DCLK_MASKREG_GENMASK(15, 0)
+
+#define MTL_MEM_SS_INFO_QGV_POINT_HIGH(point) _MMIO(0x45714 + (point) * 2)
+#define MTL_TRAS_MASKREG_GENMASK(16, 8)
+#define MTL_TRDPRE_MASK REG_GENMASK(7, 0)
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_dram.c
b/drivers/gpu/drm/i915/intel_dram.c
index 437447119770..2403ccd52c74 100644
--- a/drivers/gpu/drm/i915/intel_dram.c
+++ b/drivers/gpu/drm/i915/intel_dram.c
@@ -466,6 +466,43 @@ static int gen12_get_dram_info(struct drm_i915_private
*i915)
return icl_pcode_read_mem_global_info(i915);
}
+static int xelpdp_get_dram_info(struct drm_i915_private *i915)
+{
+ u32 val = intel_uncore_read(>uncore, MTL_MEM_SS_INFO_GLOBAL);
+
[Intel-gfx] [PATCH v3 06/11] drm/i915/mtl: Add display power wells
From: Imre Deak
Add support for display power wells on MTL. The differences from XE_LPD:
- The AUX HW block is moved to the PICA block, where the registers are on
an always-on power well and the functionality needs to be powered on/off
via the AUX_CH_CTL register: [1], [2]
- The DDI IO power on/off programming sequence is moved to the PHY PLL
enable/disable sequence. [3], [4], [5]
Bspec: [1] 49233, [2] 65247, [3] 64568, [4] 65451, [5] 65450
v2:
- Update the comment in aux power well enable
- Reuse the noop sync fn for aux sync.
- Use REG_BIT for new register bit definitions
Signed-off-by: Imre Deak
Signed-off-by: Radhakrishna Sripada
---
.../i915/display/intel_display_power_map.c| 115 +-
.../i915/display/intel_display_power_well.c | 44 +++
.../i915/display/intel_display_power_well.h | 4 +
drivers/gpu/drm/i915/display/intel_dp_aux.c | 8 ++
drivers/gpu/drm/i915/i915_reg.h | 21
5 files changed, 191 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
b/drivers/gpu/drm/i915/display/intel_display_power_map.c
index 5ddd1b93751c..dc04afc6cc8f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -1350,6 +1350,117 @@ static const struct i915_power_well_desc_list
xelpd_power_wells[] = {
I915_PW_DESCRIPTORS(xelpd_power_wells_main),
};
+/*
+ * MTL is based on XELPD power domains with the exception of power gating for:
+ * - DDI_IO (moved to PLL logic)
+ * - AUX and AUX_IO functionality and register access for USBC1-4 (PICA
always-on)
+ */
+#define XELPDP_PW_2_POWER_DOMAINS \
+ XELPD_PW_B_POWER_DOMAINS, \
+ XELPD_PW_C_POWER_DOMAINS, \
+ XELPD_PW_D_POWER_DOMAINS, \
+ POWER_DOMAIN_AUDIO_PLAYBACK, \
+ POWER_DOMAIN_VGA, \
+ POWER_DOMAIN_PORT_DDI_LANES_TC1, \
+ POWER_DOMAIN_PORT_DDI_LANES_TC2, \
+ POWER_DOMAIN_PORT_DDI_LANES_TC3, \
+ POWER_DOMAIN_PORT_DDI_LANES_TC4
+
+I915_DECL_PW_DOMAINS(xelpdp_pwdoms_pw_2,
+ XELPDP_PW_2_POWER_DOMAINS,
+ POWER_DOMAIN_INIT);
+
+I915_DECL_PW_DOMAINS(xelpdp_pwdoms_dc_off,
+ XELPDP_PW_2_POWER_DOMAINS,
+ POWER_DOMAIN_AUDIO_MMIO,
+ POWER_DOMAIN_MODESET,
+ POWER_DOMAIN_AUX_A,
+ POWER_DOMAIN_AUX_B,
+ POWER_DOMAIN_INIT);
+
+I915_DECL_PW_DOMAINS(xelpdp_pwdoms_aux_tc1,
+ POWER_DOMAIN_AUX_USBC1,
+ POWER_DOMAIN_AUX_TBT1);
+
+I915_DECL_PW_DOMAINS(xelpdp_pwdoms_aux_tc2,
+ POWER_DOMAIN_AUX_USBC2,
+ POWER_DOMAIN_AUX_TBT2);
+
+I915_DECL_PW_DOMAINS(xelpdp_pwdoms_aux_tc3,
+ POWER_DOMAIN_AUX_USBC3,
+ POWER_DOMAIN_AUX_TBT3);
+
+I915_DECL_PW_DOMAINS(xelpdp_pwdoms_aux_tc4,
+ POWER_DOMAIN_AUX_USBC4,
+ POWER_DOMAIN_AUX_TBT4);
+
+static const struct i915_power_well_desc xelpdp_power_wells_main[] = {
+ {
+ .instances = _PW_INSTANCES(
+ I915_PW("DC_off", _pwdoms_dc_off,
+ .id = SKL_DISP_DC_OFF),
+ ),
+ .ops = _dc_off_power_well_ops,
+ }, {
+ .instances = _PW_INSTANCES(
+ I915_PW("PW_2", _pwdoms_pw_2,
+ .hsw.idx = ICL_PW_CTL_IDX_PW_2,
+ .id = SKL_DISP_PW_2),
+ ),
+ .ops = _power_well_ops,
+ .has_vga = true,
+ .has_fuses = true,
+ }, {
+ .instances = _PW_INSTANCES(
+ I915_PW("PW_A", _pwdoms_pw_a,
+ .hsw.idx = XELPD_PW_CTL_IDX_PW_A),
+ ),
+ .ops = _power_well_ops,
+ .irq_pipe_mask = BIT(PIPE_A),
+ .has_fuses = true,
+ }, {
+ .instances = _PW_INSTANCES(
+ I915_PW("PW_B", _pwdoms_pw_b,
+ .hsw.idx = XELPD_PW_CTL_IDX_PW_B),
+ ),
+ .ops = _power_well_ops,
+ .irq_pipe_mask = BIT(PIPE_B),
+ .has_fuses = true,
+ }, {
+ .instances = _PW_INSTANCES(
+ I915_PW("PW_C", _pwdoms_pw_c,
+ .hsw.idx = XELPD_PW_CTL_IDX_PW_C),
+ ),
+ .ops = _power_well_ops,
+ .irq_pipe_mask = BIT(PIPE_C),
+ .has_fuses = true,
+ }, {
+ .instances = _PW_INSTANCES(
+ I915_PW("PW_D", _pwdoms_pw_d,
+ .hsw.idx = XELPD_PW_CTL_IDX_PW_D),
+ ),
+ .ops = _power_well_ops,
+ .irq_pipe_mask = BIT(PIPE_D),
+ .has_fuses = true,
+ }, {
+ .instances = _PW_INSTANCES(
+ I915_PW("AUX_A", _pwdoms_aux_a, .xelpdp.aux_ch =
AUX_CH_A),
+ I915_PW("AUX_B", _pwdoms_aux_b, .xelpdp.aux_ch =
AUX_CH_B),
+
[Intel-gfx] [PATCH v3 05/11] drm/i915/mtl: Add gmbus and gpio support
Add tables to map the GMBUS pin pairs to GPIO registers and port to DDC.
>From spec we have registers GPIO_CTL[1-5] mapped to native display phys and
GPIO_CTL[9-12] are mapped to TC ports.
v2:
- Drop unused GPIO pins(MattR)
BSpec: 49306
Cc: Matt Roper
Original Author: Brian J Lovin
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_gmbus.c | 15 +++
drivers/gpu/drm/i915/display/intel_gmbus.h | 1 +
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c
b/drivers/gpu/drm/i915/display/intel_gmbus.c
index 6f6cfccad477..74443f57f62d 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.c
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
@@ -117,6 +117,18 @@ static const struct gmbus_pin gmbus_pins_dg2[] = {
[GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOJ },
};
+static const struct gmbus_pin gmbus_pins_mtp[] = {
+ [GMBUS_PIN_1_BXT] = { "dpa", GPIOB },
+ [GMBUS_PIN_2_BXT] = { "dpb", GPIOC },
+ [GMBUS_PIN_3_BXT] = { "dpc", GPIOD },
+ [GMBUS_PIN_4_CNP] = { "dpd", GPIOE },
+ [GMBUS_PIN_5_MTP] = { "dpe", GPIOF },
+ [GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOJ },
+ [GMBUS_PIN_10_TC2_ICP] = { "tc2", GPIOK },
+ [GMBUS_PIN_11_TC3_ICP] = { "tc3", GPIOL },
+ [GMBUS_PIN_12_TC4_ICP] = { "tc4", GPIOM },
+};
+
static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private *i915,
unsigned int pin)
{
@@ -129,6 +141,9 @@ static const struct gmbus_pin *get_gmbus_pin(struct
drm_i915_private *i915,
} else if (INTEL_PCH_TYPE(i915) >= PCH_DG1) {
pins = gmbus_pins_dg1;
size = ARRAY_SIZE(gmbus_pins_dg1);
+ } else if (INTEL_PCH_TYPE(i915) >= PCH_MTP) {
+ pins = gmbus_pins_mtp;
+ size = ARRAY_SIZE(gmbus_pins_mtp);
} else if (INTEL_PCH_TYPE(i915) >= PCH_ICP) {
pins = gmbus_pins_icp;
size = ARRAY_SIZE(gmbus_pins_icp);
diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.h
b/drivers/gpu/drm/i915/display/intel_gmbus.h
index 8edc2e99cf53..20f704bd4e70 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.h
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.h
@@ -24,6 +24,7 @@ struct i2c_adapter;
#define GMBUS_PIN_2_BXT2
#define GMBUS_PIN_3_BXT3
#define GMBUS_PIN_4_CNP4
+#define GMBUS_PIN_5_MTP5
#define GMBUS_PIN_9_TC1_ICP9
#define GMBUS_PIN_10_TC2_ICP 10
#define GMBUS_PIN_11_TC3_ICP 11
--
2.25.1
[Intel-gfx] [PATCH v3 02/11] drm/i915: Read graphics/media/display arch version from hw
From: Matt Roper
Going forward, the hardware teams no longer consider new platforms to
have a "generation" in the way we've defined it for past platforms.
Instead, each IP block (graphics, media, display) will have their own
architecture major.minor versions and stepping ID's which should be read
directly from a register in the MMIO space. New hardware programming
styles, features, and workarounds should be conditional solely on the
architecture version, and should no longer be derived from the PCI
device ID, revision ID, or platform-specific feature flags.
Bspec: 63361, 64111
v2:
- Move the IP version readout to intel_device_info.c
- Convert the macro into a function
Signed-off-by: Matt Roper
Signed-off-by: Rodrigo Vivi
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 +
drivers/gpu/drm/i915/i915_driver.c | 2 +
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_device_info.c | 73
drivers/gpu/drm/i915/intel_device_info.h | 3 +
7 files changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index d414785003cc..579da62158c4 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -39,6 +39,8 @@
#define FORCEWAKE_ACK_RENDER_GEN9 _MMIO(0xd84)
#define FORCEWAKE_ACK_MEDIA_GEN9 _MMIO(0xd88)
+#define GMD_ID_GRAPHICS_MMIO(0xd8c)
+
#define MCFG_MCR_SELECTOR _MMIO(0xfd0)
#define SF_MCR_SELECTOR_MMIO(0xfd8)
#define GEN8_MCR_SELECTOR _MMIO(0xfdc)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 3aedc33ded57..5826c70d6fa5 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -323,6 +323,8 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
if (i915_inject_probe_failure(dev_priv))
return -ENODEV;
+ intel_device_info_runtime_init_early(dev_priv);
+
intel_device_info_subplatform_init(dev_priv);
intel_step_init(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bf60593a4ce5..935ff3486fef 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -936,6 +936,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_GMCH(dev_priv) (INTEL_INFO(dev_priv)->display.has_gmch)
+#define HAS_GMD_ID(i915) INTEL_INFO(i915)->has_gmd_id
+
#define HAS_LSPCON(dev_priv) (IS_DISPLAY_VER(dev_priv, 9, 10))
#define HAS_L3_CCS_READ(i915) (INTEL_INFO(i915)->has_l3_ccs_read)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 72577e327c71..9772c315185d 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1129,6 +1129,7 @@ static const struct intel_device_info mtl_info = {
PLATFORM(INTEL_METEORLAKE),
.display.has_modular_fia = 1,
.has_flat_ccs = 0,
+ .has_gmd_id = 1,
.has_snoop = 1,
.__runtime.memory_regions = REGION_SMEM | REGION_STOLEN_LMEM,
.__runtime.platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(CCS0),
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5e6239864c35..f52ed6d00030 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5798,6 +5798,11 @@
#define ICL_DSSM_CDCLK_PLL_REFCLK_19_2MHz (1 << 29)
#define ICL_DSSM_CDCLK_PLL_REFCLK_38_4MHz (2 << 29)
+#define GMD_ID_DISPLAY _MMIO(0x510a0)
+#define GMD_ID_ARCH_MASK REG_GENMASK(31, 22)
+#define GMD_ID_RELEASE_MASK REG_GENMASK(21, 14)
+#define GMD_ID_STEP REG_GENMASK(5, 0)
+
/*GEN11 chicken */
#define _PIPEA_CHICKEN 0x70038
#define _PIPEB_CHICKEN 0x71038
@@ -8298,4 +8303,5 @@ enum skl_power_gate {
#define MTL_LATENCY_LEVEL_EVEN_MASK REG_GENMASK(12, 0)
#define MTL_LATENCY_LEVEL_ODD_MASKREG_GENMASK(28, 16)
+#define MTL_MEDIA_GSI_BASE 0x38
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 8ff66b4e11c1..e36ba0520be7 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -29,6 +29,7 @@
#include "display/intel_cdclk.h"
#include "display/intel_de.h"
+#include "gt/intel_gt_regs.h"
#include "intel_device_info.h"
#include "i915_drv.h"
#include "i915_utils.h"
@@ -133,6 +134,78 @@ void intel_device_info_print(const struct
intel_device_info *info,
drm_printf(p, "rawclk rate: %u kHz\n",
[Intel-gfx] [PATCH v3 00/11] Initial Meteorlake Support
The PCI Id's and platform definition are posted earlier. This series adds handful of early enablement patches including support for display power wells, VBT and AUX Channel mapping, PCH and gmbus support, dbus, mbus, sagv and memory bandwidth support. This series also add the support for a new way to read Graphics, Media and Display versions This is based out of the earlier series posted at [1]. Several of the patches from the earlier series got merged. This version is rebased on top of the earlier patches that got merged. [1] https://patchwork.freedesktop.org/series/106786/ Imre Deak (2): drm/i915/mtl: Add display power wells drm/i915/mtl: Add DP AUX support on TypeC ports José Roberto de Souza (1): drm/i915: Parse and set stepping for platforms with GMD Madhumitha Tolakanahalli Pradeep (1): drm/i915/mtl: Update CHICKEN_TRANS* register addresses Matt Roper (2): drm/i915: Read graphics/media/display arch version from hw drm/i915/mtl: Define engine context layouts Radhakrishna Sripada (5): drm/i915: Move display and media IP version to runtime info drm/i915/mtl: Add gmbus and gpio support drm/i915/mtl: Obtain SAGV values from MMIO instead of GT pcode mailbox drm/i915/mtl: Update MBUS_DBOX credits drm/i915/mtl: Do not update GV point, mask value drivers/gpu/drm/i915/display/intel_bw.c | 42 ++- drivers/gpu/drm/i915/display/intel_display.c | 14 ++- .../i915/display/intel_display_power_map.c| 115 +- .../i915/display/intel_display_power_well.c | 44 +++ .../i915/display/intel_display_power_well.h | 4 + drivers/gpu/drm/i915/display/intel_dp_aux.c | 53 +++- drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +- drivers/gpu/drm/i915/display/intel_gmbus.c| 15 +++ drivers/gpu/drm/i915/display/intel_gmbus.h| 1 + drivers/gpu/drm/i915/display/intel_psr.c | 6 +- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 + drivers/gpu/drm/i915/gt/intel_lrc.c | 81 +++- drivers/gpu/drm/i915/i915_driver.c| 2 + drivers/gpu/drm/i915/i915_drv.h | 10 +- drivers/gpu/drm/i915/i915_pci.c | 21 ++-- drivers/gpu/drm/i915/i915_reg.h | 83 - drivers/gpu/drm/i915/intel_device_info.c | 85 - drivers/gpu/drm/i915/intel_device_info.h | 18 ++- drivers/gpu/drm/i915/intel_dram.c | 41 ++- drivers/gpu/drm/i915/intel_pm.c | 73 ++- drivers/gpu/drm/i915/intel_step.c | 60 + 21 files changed, 723 insertions(+), 52 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH] drm/i915/slpc: Let's fix the PCODE min freq table setup for SLPC
We need to inform PCODE of a desired ring frequencies so PCODE update
the memory frequencies to us. rps->min_freq and rps->max_freq are the
frequencies used in that request. However they were unset when SLPC was
enabled and PCODE never updated the memory freq.
v2 (as Suggested by Ashutosh): if SLPC is in use, let's pick the right
frequencies from the get_ia_constants instead of the fake init of
rps' min and max.
v3: don't forget the max <= min return
v4: Move all the freq conversion to intel_rps.c. And the max <= min
check to where it belongs.
v5: (Ashutosh) Fix old comment s/50 HZ/50 MHz and add a doc explaining
the "raw format"
Fixes: 7ba79a671568 ("drm/i915/guc/slpc: Gate Host RPS when SLPC is enabled")
Cc: # v5.15+
Cc: Ashutosh Dixit
Tested-by: Sushma Venkatesh Reddy
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_llc.c | 19 ++-
drivers/gpu/drm/i915/gt/intel_rps.c | 50 +
drivers/gpu/drm/i915/gt/intel_rps.h | 2 ++
3 files changed, 61 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_llc.c
b/drivers/gpu/drm/i915/gt/intel_llc.c
index 14fe65812e42..1d19c073ba2e 100644
--- a/drivers/gpu/drm/i915/gt/intel_llc.c
+++ b/drivers/gpu/drm/i915/gt/intel_llc.c
@@ -12,6 +12,7 @@
#include "intel_llc.h"
#include "intel_mchbar_regs.h"
#include "intel_pcode.h"
+#include "intel_rps.h"
struct ia_constants {
unsigned int min_gpu_freq;
@@ -55,9 +56,6 @@ static bool get_ia_constants(struct intel_llc *llc,
if (!HAS_LLC(i915) || IS_DGFX(i915))
return false;
- if (rps->max_freq <= rps->min_freq)
- return false;
-
consts->max_ia_freq = cpu_max_MHz();
consts->min_ring_freq =
@@ -65,13 +63,8 @@ static bool get_ia_constants(struct intel_llc *llc,
/* convert DDR frequency from units of 266.6MHz to bandwidth */
consts->min_ring_freq = mult_frac(consts->min_ring_freq, 8, 3);
- consts->min_gpu_freq = rps->min_freq;
- consts->max_gpu_freq = rps->max_freq;
- if (GRAPHICS_VER(i915) >= 9) {
- /* Convert GT frequency to 50 HZ units */
- consts->min_gpu_freq /= GEN9_FREQ_SCALER;
- consts->max_gpu_freq /= GEN9_FREQ_SCALER;
- }
+ consts->min_gpu_freq = intel_rps_get_min_raw_freq(rps);
+ consts->max_gpu_freq = intel_rps_get_max_raw_freq(rps);
return true;
}
@@ -130,6 +123,12 @@ static void gen6_update_ring_freq(struct intel_llc *llc)
if (!get_ia_constants(llc, ))
return;
+ /*
+* Although this is unlikely on any platform during initialization,
+* let's ensure we don't get accidentally into infinite loop
+*/
+ if (consts.max_gpu_freq <= consts.min_gpu_freq)
+ return;
/*
* For each potential GPU frequency, load a ring frequency we'd like
* to use for memory access. We do this by specifying the IA frequency
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index de794f5f8594..318bf913c507 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2156,6 +2156,31 @@ u32 intel_rps_get_max_frequency(struct intel_rps *rps)
return intel_gpu_freq(rps, rps->max_freq_softlimit);
}
+/**
+ * intel_rps_get_max_raw_freq - returns the max frequency in some raw format.
+ * @rps: the intel_rps structure
+ *
+ * Returns the max frequency in a raw format. In newer platforms raw is in
+ * units of 50 MHz.
+ */
+u32 intel_rps_get_max_raw_freq(struct intel_rps *rps)
+{
+ struct intel_guc_slpc *slpc = rps_to_slpc(rps);
+ u32 freq;
+
+ if (rps_uses_slpc(rps)) {
+ return DIV_ROUND_CLOSEST(slpc->rp0_freq,
+GT_FREQUENCY_MULTIPLIER);
+ } else {
+ freq = rps->max_freq;
+ if (GRAPHICS_VER(rps_to_i915(rps)) >= 9) {
+ /* Convert GT frequency to 50 MHz units */
+ freq /= GEN9_FREQ_SCALER;
+ }
+ return freq;
+ }
+}
+
u32 intel_rps_get_rp0_frequency(struct intel_rps *rps)
{
struct intel_guc_slpc *slpc = rps_to_slpc(rps);
@@ -2244,6 +2269,31 @@ u32 intel_rps_get_min_frequency(struct intel_rps *rps)
return intel_gpu_freq(rps, rps->min_freq_softlimit);
}
+/**
+ * intel_rps_get_min_raw_freq - returns the min frequency in some raw format.
+ * @rps: the intel_rps structure
+ *
+ * Returns the min frequency in a raw format. In newer platforms raw is in
+ * units of 50 MHz.
+ */
+u32 intel_rps_get_min_raw_freq(struct intel_rps *rps)
+{
+ struct intel_guc_slpc *slpc = rps_to_slpc(rps);
+ u32 freq;
+
+ if (rps_uses_slpc(rps)) {
+ return DIV_ROUND_CLOSEST(slpc->min_freq,
+GT_FREQUENCY_MULTIPLIER);
+ } else {
+ freq =
Re: [Intel-gfx] [PATCH] i915/pmu: Wire GuC backend to per-client busyness
On Fri, 26 Aug 2022 09:33:08 -0700, Umesh Nerlige Ramappa wrote:
>
Hi Umesh,
Just to communicate my thoughts I have posted this patch on top of your
patch:
[1] https://patchwork.freedesktop.org/series/107983/
Could you please take a look at that and see if it makes sense.
> On Thu, Aug 25, 2022 at 06:44:50PM -0700, Dixit, Ashutosh wrote:
> > On Thu, 04 Aug 2022 16:21:25 -0700, Umesh Nerlige Ramappa wrote:
> >
> > Hi Umesh, I am fairly new to this code so some questions will be below will
> > be newbie questions, thanks for bearing with me.
> >
> >> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> >> b/drivers/gpu/drm/i915/gt/intel_context.c
> >> index 654a092ed3d6..e2d70a9fdac0 100644
> >> --- a/drivers/gpu/drm/i915/gt/intel_context.c
> >> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> >> @@ -576,16 +576,24 @@ void intel_context_bind_parent_child(struct
> >> intel_context *parent,
> >>child->parallel.parent = parent;
> >> }
> >>
> >> -u64 intel_context_get_total_runtime_ns(const struct intel_context *ce)
> >> +u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
> >> {
> >>u64 total, active;
> >>
> >> + if (ce->ops->update_stats)
> >> + ce->ops->update_stats(ce);
> >> +
> >>total = ce->stats.runtime.total;
> >>if (ce->ops->flags & COPS_RUNTIME_CYCLES)
> >>total *= ce->engine->gt->clock_period_ns;
> >>
> >>active = READ_ONCE(ce->stats.active);
> >> - if (active)
> >> + /*
> >> + * When COPS_RUNTIME_ACTIVE_TOTAL is set for ce->cops, the backend
> >> + * already provides the total active time of the context, so skip this
> >> + * calculation when this flag is set.
> >> + */
> >> + if (active && !(ce->ops->flags & COPS_RUNTIME_ACTIVE_TOTAL))
> >>active = intel_context_clock() - active;
> >>
> >>return total + active;
> >
> > /snip/
> >
> >> @@ -1396,6 +1399,10 @@ static void guc_timestamp_ping(struct work_struct
> >> *wrk)
> >>with_intel_runtime_pm(>i915->runtime_pm, wakeref)
> >>__update_guc_busyness_stats(guc);
> >>
> >> + /* adjust context stats for overflow */
> >> + xa_for_each(>context_lookup, index, ce)
> >> + __guc_context_update_clks(ce);
> >
> > What is the reason for calling __guc_context_update_clks() periodically
> > from guc_timestamp_ping() since it appears we should just be able to call
> > __guc_context_update_clks() from intel_context_get_total_runtime_ns() to
> > update 'active'? Is the reason for calling __guc_context_update_clks()
> > periodically that the calculations in __guc_context_update_clks() become
> > invalid if the counters overflow?
>
> Correct, these are 32-bit counters and the worker just tracks overflow.
OK.
>
> >
> >> +
> >>intel_gt_reset_unlock(gt, srcu);
> >>
> >>mod_delayed_work(system_highpri_wq, >timestamp.work,
> >> @@ -1469,6 +1476,56 @@ void intel_guc_busyness_unpark(struct intel_gt *gt)
> >> guc->timestamp.ping_delay);
> >> }
> >>
> >> +static void __guc_context_update_clks(struct intel_context *ce)
> >> +{
> >> + struct intel_guc *guc = ce_to_guc(ce);
> >> + struct intel_gt *gt = ce->engine->gt;
> >> + u32 *pphwsp, last_switch, engine_id;
> >> + u64 start_gt_clk, active;
> >> + unsigned long flags;
> >> + ktime_t unused;
> >> +
> >> + spin_lock_irqsave(>timestamp.lock, flags);
> >> +
> >> + /*
> >> + * GPU updates ce->lrc_reg_state[CTX_TIMESTAMP] when context is switched
> >> + * out, however GuC updates PPHWSP offsets below. Hence KMD (CPU)
> >> + * relies on GuC and GPU for busyness calculations. Due to this, A
> >> + * potential race was highlighted in an earlier review that can lead to
> >> + * double accounting of busyness. While the solution to this is a wip,
> >> + * busyness is still usable for platforms running GuC submission.
> >> + */
> >> + pphwsp = ((void *)ce->lrc_reg_state) - LRC_STATE_OFFSET;
> >> + last_switch = READ_ONCE(pphwsp[PPHWSP_GUC_CONTEXT_USAGE_STAMP_LO]);
> >> + engine_id = READ_ONCE(pphwsp[PPHWSP_GUC_CONTEXT_USAGE_ENGINE_ID]);
> >> +
> >> + guc_update_pm_timestamp(guc, );
> >> +
> >> + if (engine_id != 0x && last_switch) {
> >> + start_gt_clk = READ_ONCE(ce->stats.runtime.start_gt_clk);
> >> + __extend_last_switch(guc, _gt_clk, last_switch);
> >> + active = intel_gt_clock_interval_to_ns(gt,
> >> guc->timestamp.gt_stamp - start_gt_clk);
> >> + WRITE_ONCE(ce->stats.runtime.start_gt_clk, start_gt_clk);
> >> + WRITE_ONCE(ce->stats.active, active);
> >
> > Should not need WRITE_ONCE to update regular memory. Not even sure we need
> > READ_ONCE above.
>
> Not sure I checked what they do. I was thinking these are needed for the
> memory ordering (as in be sure that start_gt_clk is updated before
> active).
As long as our operations are done under correct locks we don't have to
worry about memory ordering. That is one of the reasons I am doing
everything under the spinlock in [1].
>
> >
> >> + } else {
> >> +
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] i915/pmu: Wire GuC backend to per-client busyness
== Series Details == Series: series starting with [1/2] i915/pmu: Wire GuC backend to per-client busyness URL : https://patchwork.freedesktop.org/series/107983/ State : failure == Summary == Error: make failed CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/gt/uc/intel_guc_submission.o drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:1520:6: error: no previous prototype for ‘lrc_update_runtime_locked’ [-Werror=missing-prototypes] void lrc_update_runtime_locked(struct intel_context *ce) ^ cc1: all warnings being treated as errors scripts/Makefile.build:249: recipe for target 'drivers/gpu/drm/i915/gt/uc/intel_guc_submission.o' failed make[4]: *** [drivers/gpu/drm/i915/gt/uc/intel_guc_submission.o] Error 1 scripts/Makefile.build:465: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:465: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:465: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1853: recipe for target 'drivers' failed make: *** [drivers] Error 2
Re: [Intel-gfx] [PATCH] drm/i915/slpc: Let's fix the PCODE min freq table setup for SLPC
On Tue, 2022-08-30 at 17:45 -0700, Dixit, Ashutosh wrote:
> On Tue, 30 Aug 2022 12:16:20 -0700, Rodrigo Vivi wrote:
> >
>
> Hi Rodrigo,
>
> > @@ -65,13 +63,8 @@ static bool get_ia_constants(struct intel_llc
> > *llc,
> > /* convert DDR frequency from units of 266.6MHz to
> > bandwidth */
> > consts->min_ring_freq = mult_frac(consts->min_ring_freq, 8,
> > 3);
> >
> > - consts->min_gpu_freq = rps->min_freq;
> > - consts->max_gpu_freq = rps->max_freq;
> > - if (GRAPHICS_VER(i915) >= 9) {
> > - /* Convert GT frequency to 50 HZ units */
> > - consts->min_gpu_freq /= GEN9_FREQ_SCALER;
> > - consts->max_gpu_freq /= GEN9_FREQ_SCALER;
> > - }
> > + consts->min_gpu_freq = intel_rps_get_min_raw_freq(rps);
> > + consts->max_gpu_freq = intel_rps_get_max_raw_freq(rps);
> >
> > return true;
> > }
> > @@ -130,6 +123,12 @@ static void gen6_update_ring_freq(struct
> > intel_llc *llc)
> > if (!get_ia_constants(llc, ))
> > return;
> >
> > + /*
> > + * Although this is unlikely on any platform during
> > initialization,
> > + * let's ensure we don't get accidentally into infinite
> > loop
> > + */
> > + if (consts.max_gpu_freq <= consts.min_gpu_freq)
> > + return;
>
> As I said this is not correct and is not needed. If
> 'consts.max_gpu_freq ==
> consts.min_gpu_freq' we would *want* to program PCODE. If
> 'consts.max_gpu_freq < consts.min_gpu_freq' the loop will
> automatically
> skip (and also it is not an infinite loop).
yeap, but if we change this condition in the loop we will
miss one entry in the case they are equal.
Since we are doing this generically for 15 years of hardware
I didn't want to take the risk of having some out there
where the min = max and the 1 entry in the table is needed.
>
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
> > b/drivers/gpu/drm/i915/gt/intel_rps.c
> > index de794f5f8594..26af974292c7 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> > @@ -2156,6 +2156,24 @@ u32 intel_rps_get_max_frequency(struct
> > intel_rps *rps)
> > return intel_gpu_freq(rps, rps-
> > >max_freq_softlimit);
> > }
> >
> > +u32 intel_rps_get_max_raw_freq(struct intel_rps *rps)
>
> What does "raw" mean? Or are we introducing a new concept here then
> we need
> to explain the new concept? I was previously told there is a concept
> of "hw
> units" of freq and intel_gpu_freq will convert from "hw units" to
> MHz.
yeap, it is the hw units, some folks also calling FID of the freqs.
I couldn't find a better name.
>
> Also, Is the return value in units of 50 MHz in all cases (we know it
> is
> for SLPC and Gen 9+)? In that case we should name such a function to
> something like intel_rps_get_max_freq_in_50mhz_units?
yeap, that would work... at least until in some future platform our hw
folks need to find another base...
>
> > +{
> > + struct intel_guc_slpc *slpc = rps_to_slpc(rps);
> > + u32 freq;
> > +
> > + if (rps_uses_slpc(rps)) {
> > + return DIV_ROUND_CLOSEST(slpc->rp0_freq,
> > + GT_FREQUENCY_MULTIPLIER);
> > + } else {
> > + freq = rps->max_freq;
> > + if (GRAPHICS_VER(rps_to_i915(rps)) >= 9) {
> > + /* Convert GT frequency to 50 HZ units */
>
> 50 MHz and not 50 Hz. Also the comment should be moved to above
> rps_uses_slpc() line if returned freq is always in units of 50 MHz.
yeap, this comment was already there and probably wrong...
>
> > + freq /= GEN9_FREQ_SCALER;
> > + }
> > + return freq;
> > + }
> > +}
>
> Also is this function equivalent to this:
>
> u32 intel_rps_get_max_freq_in_50mhz_units(struct intel_rps *rps)
> {
> struct intel_guc_slpc *slpc = rps_to_slpc(rps);
> u32 freq;
>
> /* freq in MHz */
> freq = rps_uses_slpc(rps) ? slpc->rp0_freq :
> intel_gpu_freq(rps->max_freq);
do you really want to convert forth and back? Can we minimize the math?
>
> return DIV_ROUND_CLOSEST(freq, GT_FREQUENCY_MULTIPLIER);
> }
>
> Sorry I don't have a lot of history in how these frequencies are
> scaled
> specially for old platforms like CHV/VLV/Gen6+. But afaiu
> intel_gpu_freq()
> will convert the freq to MHz for all platforms.
yeap, old platforms also concern me... another reason to avoid doing
something new and only using the conversion that was already there.
>
> And then does get_ia_constants() accept freq in 50 MHz units for all
> platforms?
Please notice that there's absolutely no change for the non-slpc
platforms.
>
> If we are not sure about this, we can go with your version which is
> closer
> to the original version in get_ia_constants() and so "safer" I guess.
so you mean this version? ;)
>
> Thanks.
> --
> Ashutosh
[Intel-gfx] [PATCH 1/2] i915/pmu: Wire GuC backend to per-client busyness
From: John Harrison
GuC provides engine_id and last_switch_in ticks for an active context in
the pphwsp. The context image provides a 32 bit total ticks which is the
accumulated by the context (a.k.a. context[CTX_TIMESTAMP]). This
information is used to calculate the context busyness as follows:
If the engine_id is valid, then busyness is the sum of accumulated total
ticks and active ticks. Active ticks is calculated with current gt time
as reference.
If engine_id is invalid, busyness is equal to accumulated total ticks.
Since KMD (CPU) retrieves busyness data from 2 sources - GPU and GuC, a
potential race was highlighted in an earlier review that can lead to
double accounting of busyness. While the solution to this is a wip,
busyness is still usable for platforms running GuC submission.
Remaining work: Enable and test context busyness for
virtual_parent_context_ops and virtual_child_context_ops.
v2: (Tvrtko)
- Use COPS_RUNTIME_ACTIVE_TOTAL
- Add code comment for the race
- Undo local variables initializations
v3:
- Add support for virtual engines based on
https://patchwork.freedesktop.org/series/105227/
v4:
- Update commit message with remaining work.
- Rebase
Signed-off-by: John Harrison
Signed-off-by: Umesh Nerlige Ramappa
Acked-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_context.c | 12 +++-
drivers/gpu/drm/i915/gt/intel_context.h | 6 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 6 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 5 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 65 ++-
drivers/gpu/drm/i915/i915_drm_client.c| 6 +-
6 files changed, 89 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 654a092ed3d6..e2d70a9fdac0 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -576,16 +576,24 @@ void intel_context_bind_parent_child(struct intel_context
*parent,
child->parallel.parent = parent;
}
-u64 intel_context_get_total_runtime_ns(const struct intel_context *ce)
+u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
{
u64 total, active;
+ if (ce->ops->update_stats)
+ ce->ops->update_stats(ce);
+
total = ce->stats.runtime.total;
if (ce->ops->flags & COPS_RUNTIME_CYCLES)
total *= ce->engine->gt->clock_period_ns;
active = READ_ONCE(ce->stats.active);
- if (active)
+ /*
+* When COPS_RUNTIME_ACTIVE_TOTAL is set for ce->cops, the backend
+* already provides the total active time of the context, so skip this
+* calculation when this flag is set.
+*/
+ if (active && !(ce->ops->flags & COPS_RUNTIME_ACTIVE_TOTAL))
active = intel_context_clock() - active;
return total + active;
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 8e2d70630c49..3d1d7436c1a4 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -58,7 +58,7 @@ static inline bool intel_context_is_parent(struct
intel_context *ce)
return !!ce->parallel.number_children;
}
-static inline bool intel_context_is_pinned(struct intel_context *ce);
+static inline bool intel_context_is_pinned(const struct intel_context *ce);
static inline struct intel_context *
intel_context_to_parent(struct intel_context *ce)
@@ -118,7 +118,7 @@ static inline int intel_context_lock_pinned(struct
intel_context *ce)
* Returns: true if the context is currently pinned for use by the GPU.
*/
static inline bool
-intel_context_is_pinned(struct intel_context *ce)
+intel_context_is_pinned(const struct intel_context *ce)
{
return atomic_read(>pin_count);
}
@@ -362,7 +362,7 @@ intel_context_clear_nopreempt(struct intel_context *ce)
clear_bit(CONTEXT_NOPREEMPT, >flags);
}
-u64 intel_context_get_total_runtime_ns(const struct intel_context *ce);
+u64 intel_context_get_total_runtime_ns(struct intel_context *ce);
u64 intel_context_get_avg_runtime_ns(struct intel_context *ce);
static inline u64 intel_context_clock(void)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 04eacae1aca5..f7ff4c7d81c7 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -38,6 +38,9 @@ struct intel_context_ops {
#define COPS_RUNTIME_CYCLES_BIT 1
#define COPS_RUNTIME_CYCLES BIT(COPS_RUNTIME_CYCLES_BIT)
+#define COPS_RUNTIME_ACTIVE_TOTAL_BIT 2
+#define COPS_RUNTIME_ACTIVE_TOTAL BIT(COPS_RUNTIME_ACTIVE_TOTAL_BIT)
+
int (*alloc)(struct intel_context *ce);
void (*revoke)(struct intel_context *ce, struct i915_request *rq,
@@ -56,6 +59,8 @@ struct intel_context_ops {
void (*sched_disable)(struct intel_context *ce);
+ void
[Intel-gfx] [RFC PATCH 2/2] Fix per client busyness locking
1. Do all ce->stats updates and reads under guc->timestamp.lock
2. Pin context image before reading
3. Merge __guc_context_update_clks and guc_context_update_stats into a
single function
4. Call lrc_update_runtime() unconditionally in guc_context_update_stats
5. Seems no need to update ce->stats.active with this approach
Some of the above steps may not be correct or complete but the idea is to
discuss/improve the original patch.
Cc: Umesh Nerlige Ramappa
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 41 ++-
3 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index e2d70a9fdac0..c004f676de27 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -581,7 +581,7 @@ u64 intel_context_get_total_runtime_ns(struct intel_context
*ce)
u64 total, active;
if (ce->ops->update_stats)
- ce->ops->update_stats(ce);
+ return ce->ops->update_stats(ce);
total = ce->stats.runtime.total;
if (ce->ops->flags & COPS_RUNTIME_CYCLES)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index f7ff4c7d81c7..699435bfff99 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -59,7 +59,7 @@ struct intel_context_ops {
void (*sched_disable)(struct intel_context *ce);
- void (*update_stats)(struct intel_context *ce);
+ u64 (*update_stats)(struct intel_context *ce);
void (*reset)(struct intel_context *ce);
void (*destroy)(struct kref *kref);
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 bee8cf10f749..40d0edaf2e0a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1376,7 +1376,6 @@ static void __update_guc_busyness_stats(struct intel_guc
*guc)
spin_unlock_irqrestore(>timestamp.lock, flags);
}
-static void __guc_context_update_clks(struct intel_context *ce);
static void guc_timestamp_ping(struct work_struct *wrk)
{
struct intel_guc *guc = container_of(wrk, typeof(*guc),
@@ -1401,7 +1400,8 @@ static void guc_timestamp_ping(struct work_struct *wrk)
/* adjust context stats for overflow */
xa_for_each(>context_lookup, index, ce)
- __guc_context_update_clks(ce);
+ if (ce->ops->update_stats)
+ ce->ops->update_stats(ce);
intel_gt_reset_unlock(gt, srcu);
@@ -1476,17 +1476,21 @@ void intel_guc_busyness_unpark(struct intel_gt *gt)
guc->timestamp.ping_delay);
}
-static void __guc_context_update_clks(struct intel_context *ce)
+static u64 guc_context_update_stats(struct intel_context *ce)
{
struct intel_guc *guc = ce_to_guc(ce);
struct intel_gt *gt = ce->engine->gt;
u32 *pphwsp, last_switch, engine_id;
- u64 start_gt_clk, active;
unsigned long flags;
+ u64 total, active = 0;
ktime_t unused;
+ intel_context_pin(ce);
spin_lock_irqsave(>timestamp.lock, flags);
+ lrc_update_runtime(ce);
+ total = ce->stats.runtime.total;
+
/*
* GPU updates ce->lrc_reg_state[CTX_TIMESTAMP] when context is switched
* out, however GuC updates PPHWSP offsets below. Hence KMD (CPU)
@@ -1502,27 +1506,26 @@ static void __guc_context_update_clks(struct
intel_context *ce)
guc_update_pm_timestamp(guc, );
if (engine_id != 0x && last_switch) {
- start_gt_clk = READ_ONCE(ce->stats.runtime.start_gt_clk);
- __extend_last_switch(guc, _gt_clk, last_switch);
- active = intel_gt_clock_interval_to_ns(gt,
guc->timestamp.gt_stamp - start_gt_clk);
- WRITE_ONCE(ce->stats.runtime.start_gt_clk, start_gt_clk);
- WRITE_ONCE(ce->stats.active, active);
- } else {
- lrc_update_runtime(ce);
+ __extend_last_switch(guc, >stats.runtime.start_gt_clk,
last_switch);
+ active = intel_gt_clock_interval_to_ns(gt,
+ guc->timestamp.gt_stamp -
ce->stats.runtime.start_gt_clk);
}
spin_unlock_irqrestore(>timestamp.lock, flags);
+ intel_context_unpin(ce);
+
+ return total + active;
}
-static void guc_context_update_stats(struct intel_context *ce)
+void lrc_update_runtime_locked(struct intel_context *ce)
{
- if (!intel_context_pin_if_active(ce)) {
- WRITE_ONCE(ce->stats.runtime.start_gt_clk, 0);
- WRITE_ONCE(ce->stats.active, 0);
- return;
- }
+ struct
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ttm: Abort suspend on i915_ttm_backup failure (rev2)
== Series Details ==
Series: drm/i915/ttm: Abort suspend on i915_ttm_backup failure (rev2)
URL : https://patchwork.freedesktop.org/series/107877/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12057 -> Patchwork_107877v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107877v2/index.html
Participating hosts (38 -> 34)
--
Additional (1): bat-jsl-3
Missing(5): fi-rkl-11600 fi-hsw-4200u fi-ctg-p8600 fi-hsw-4770
fi-bdw-samus
Known issues
Here are the changes found in Patchwork_107877v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gem:
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][1] ([i915#4528])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107877v2/fi-pnv-d510/igt@i915_selftest@l...@gem.html
Possible fixes
* igt@i915_selftest@live@requests:
- {bat-rpls-1}: [INCOMPLETE][2] ([i915#6257] / [i915#6380]) ->
[PASS][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12057/bat-rpls-1/igt@i915_selftest@l...@requests.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107877v2/bat-rpls-1/igt@i915_selftest@l...@requests.html
- fi-pnv-d510:[DMESG-FAIL][4] ([i915#4528]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12057/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107877v2/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [FAIL][6] ([i915#6298]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12057/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107877v2/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#3003]: https://gitlab.freedesktop.org/drm/intel/issues/3003
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4528]: https://gitlab.freedesktop.org/drm/intel/issues/4528
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#5278]: https://gitlab.freedesktop.org/drm/intel/issues/5278
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6380]: https://gitlab.freedesktop.org/drm/intel/issues/6380
[i915#6637]: https://gitlab.freedesktop.org/drm/intel/issues/6637
[i915#6690]: https://gitlab.freedesktop.org/drm/intel/issues/6690
Build changes
-
* Linux: CI_DRM_12057 -> Patchwork_107877v2
CI-20190529: 20190529
CI_DRM_12057: 2f15a899e2f2d3078fc1d5917114de9ece53a1d7 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6639: ba61c48dba71d5597d7297a07dc3e307665f961b @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_107877v2: 2f15a899e2f2d3078fc1d5917114de9ece53a1d7 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
6612ece27336 drm/i915/ttm: Abort suspend on i915_ttm_backup failure
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107877v2/index.html
[Intel-gfx] ✓ Fi.CI.BAT: success for Modify debugfs entry from dsc compressed bpp to input bpc
== Series Details ==
Series: Modify debugfs entry from dsc compressed bpp to input bpc
URL : https://patchwork.freedesktop.org/series/107972/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12057 -> Patchwork_107972v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107972v1/index.html
Participating hosts (38 -> 35)
--
Additional (1): bat-jsl-3
Missing(4): fi-ctg-p8600 bat-dg2-8 fi-bdw-samus fi-hsw-4200u
Known issues
Here are the changes found in Patchwork_107972v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gem:
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][1] ([i915#4528])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107972v1/fi-pnv-d510/igt@i915_selftest@l...@gem.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-rkl-11600: NOTRUN -> [SKIP][2] ([fdo#111827])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107972v1/fi-rkl-11600/igt@kms_chamel...@common-hpd-after-suspend.html
Possible fixes
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[DMESG-FAIL][3] ([i915#4528]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12057/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107972v1/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [INCOMPLETE][5] ([i915#5982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12057/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107972v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [FAIL][7] ([i915#6298]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12057/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107972v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3003]: https://gitlab.freedesktop.org/drm/intel/issues/3003
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4528]: https://gitlab.freedesktop.org/drm/intel/issues/4528
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#5982]: https://gitlab.freedesktop.org/drm/intel/issues/5982
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
Build changes
-
* IGT: IGT_6639 -> IGTPW_7709
* Linux: CI_DRM_12057 -> Patchwork_107972v1
CI-20190529: 20190529
CI_DRM_12057: 2f15a899e2f2d3078fc1d5917114de9ece53a1d7 @
git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_7709: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7709/index.html
IGT_6639: ba61c48dba71d5597d7297a07dc3e307665f961b @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_107972v1: 2f15a899e2f2d3078fc1d5917114de9ece53a1d7 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
ed5ccc198012 drm/i915/display: convert dsc debugfs entry from output_bpp to
input_bpc
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107972v1/index.html
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave and Daniel, only a single fix from drm-misc this week. Best regards Thomas drm-misc-fixes-2022-08-31: Short summary of fixes pull: * dma-buf/dma-resv: Fence-handling fix The following changes since commit 6b04ce966a738ecdd9294c9593e48513c0dc90aa: nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf (2022-08-23 18:00:12 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2022-08-31 for you to fetch changes up to a3f7c10a269d5b77dd5822ade822643ced3057f0: dma-buf/dma-resv: check if the new fence is really later (2022-08-25 13:10:30 +0200) Short summary of fixes pull: * dma-buf/dma-resv: Fence-handling fix Christian König (1): dma-buf/dma-resv: check if the new fence is really later drivers/dma-buf/dma-resv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: refine eDP power off sequence
== Series Details == Series: drm/i915/display: refine eDP power off sequence URL : https://patchwork.freedesktop.org/series/107965/ State : success == Summary == CI Bug Log - changes from CI_DRM_12052_full -> Patchwork_107965v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (13 -> 12) -- Missing(1): shard-dg1 Known issues Here are the changes found in Patchwork_107965v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_exec@basic-nohangcheck: - shard-tglb: [PASS][1] -> [FAIL][2] ([i915#6268]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-tglb6/igt@gem_ctx_e...@basic-nohangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/shard-tglb3/igt@gem_ctx_e...@basic-nohangcheck.html * igt@gem_eio@in-flight-suspend: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +5 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-apl2/igt@gem_...@in-flight-suspend.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/shard-apl1/igt@gem_...@in-flight-suspend.html * igt@gem_exec_balancer@parallel-bb-first: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-iclb1/igt@gem_exec_balan...@parallel-bb-first.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/shard-iclb3/igt@gem_exec_balan...@parallel-bb-first.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2846]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-glk2/igt@gem_exec_f...@basic-deadline.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/shard-glk2/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-tglb2/igt@gem_exec_fair@basic-f...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-apl: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-apl3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/shard-apl8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/shard-glk8/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-iclb: [PASS][17] -> [FAIL][18] ([i915#2842]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-iclb3/igt@gem_exec_fair@basic-p...@bcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/shard-iclb6/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-kbl: [PASS][19] -> [SKIP][20] ([fdo#109271]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-kbl7/igt@gem_exec_fair@basic-p...@vcs1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/shard-kbl1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gen9_exec_parse@allowed-single: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#5566] / [i915#716]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-kbl7/igt@gen9_exec_pa...@allowed-single.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/shard-kbl1/igt@gen9_exec_pa...@allowed-single.html * igt@i915_selftest@live@hangcheck: - shard-snb: [PASS][23] -> [INCOMPLETE][24] ([i915#3921]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-snb6/igt@i915_selftest@l...@hangcheck.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/shard-snb5/igt@i915_selftest@l...@hangcheck.html * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size: - shard-glk: [PASS][25] -> [FAIL][26] ([i915#2346]) [25]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915: audit bo->resource usage v2
== Series Details ==
Series: series starting with [1/3] drm/i915: audit bo->resource usage v2
URL : https://patchwork.freedesktop.org/series/107962/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12052_full -> Patchwork_107962v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_107962v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_107962v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 12)
--
Missing(1): shard-rkl
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_107962v1_full:
### IGT changes ###
Possible regressions
* igt@kms_cursor_legacy@single-bo@all-pipes:
- shard-apl: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-apl2/igt@kms_cursor_legacy@single...@all-pipes.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/shard-apl1/igt@kms_cursor_legacy@single...@all-pipes.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_madvise@dontneed-before-mmap:
- {shard-dg1}:[PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-dg1-19/igt@gem_madv...@dontneed-before-mmap.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/shard-dg1-14/igt@gem_madv...@dontneed-before-mmap.html
* igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-hflip:
- {shard-dg1}:[PASS][5] -> [FAIL][6] +19 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-dg1-19/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-0-hflip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/shard-dg1-13/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-0-hflip.html
*
igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs-downscaling@pipe-a-valid-mode:
- {shard-dg1}:NOTRUN -> [FAIL][7] +36 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/shard-dg1-18/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs-downscal...@pipe-a-valid-mode.html
Known issues
Here are the changes found in Patchwork_107962v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@kms:
- shard-tglb: [PASS][8] -> [FAIL][9] ([i915#5784])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-tglb7/igt@gem_...@kms.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/shard-tglb3/igt@gem_...@kms.html
* igt@gem_exec_balancer@parallel-bb-first:
- shard-iclb: [PASS][10] -> [SKIP][11] ([i915#4525])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-iclb1/igt@gem_exec_balan...@parallel-bb-first.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/shard-iclb6/igt@gem_exec_balan...@parallel-bb-first.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-tglb2/igt@gem_exec_fair@basic-f...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html
* igt@gem_exec_fair@basic-none@vcs1:
- shard-kbl: [PASS][14] -> [FAIL][15] ([i915#2842])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs1.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs1.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [PASS][16] -> [FAIL][17] ([i915#2842])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/shard-glk1/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@bcs0:
- shard-iclb: [PASS][18] -> [FAIL][19] ([i915#2842])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/shard-iclb3/igt@gem_exec_fair@basic-p...@bcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/shard-iclb8/igt@gem_exec_fair@basic-p...@bcs0.html
* igt@gem_lmem_swapping@parallel-multi:
- shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#4613])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/shard-apl6/igt@gem_lmem_swapp...@parallel-multi.html
*
Re: [Intel-gfx] [PATCH 15/15] vfio: Add struct device to vfio_device
On Wed, 31 Aug 2022 06:10:51 + "Tian, Kevin" wrote: > > From: Jason Gunthorpe > > Sent: Wednesday, August 31, 2022 7:53 AM > > > > On Tue, Aug 30, 2022 at 04:18:38PM -0600, Alex Williamson wrote: > > > On Sun, 28 Aug 2022 01:10:37 +0800 > > > Kevin Tian wrote: > > > > > > > From: Yi Liu > > > > > > > > and replace kref. With it a 'vfio-dev/vfioX' node is created under the > > > > sysfs path of the parent, indicating the device is bound to a vfio > > > > driver, e.g.: > > > > > > > > /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0 > > > > > > > > It is also a preparatory step toward adding cdev for supporting future > > > > device-oriented uAPI. > > > > > > Shall we start Documentation/ABI/testing/vfio-dev now? Thanks. > > > > I always thought that was something to use when adding new custom > > sysfs attributes? > > > > Here we are just creating a standard struct device with its standard > > sysfs? > > > > There is nothing special for vfio-dev/vfioX. But from pci device p.o.v > this does introduce a custom node in the directory, which is probably > what Alex referred to? Yup, but not just for pci, we're adding a node into the device directory for any device bound to vfio. > Anyway if required following can be introduced: > > diff --git a/Documentation/ABI/testing/sysfs-devices-vfio-dev > b/Documentation/ABI/testing/sysfs-devices-vfio-dev > new file mode 100644 > index ..dfe8baaf1ccb > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-devices-vfio-dev > @@ -0,0 +1,8 @@ > +What: /sys/...//vfio-dev/vfioX/ > +Date: September 2022 > +Contact: Yi Liu > +Description: > + This directory is created when the device is bound to a > + vfio driver. The layout under this directory matches what > + exists for a standard 'struct device'. 'X' is a random > + number marking this device in vfio. It's not really random, it's a unique index. Seems like a good starting point. > > At the start I thought it might make more sense to add it into an > existing vfio ABI file. But looks it doesn't exist. > > Curious why nobody asked for ABI doc for /dev/vfio/vfio, /sys/class/vfio, > etc... Oversight, there should probably be a sysfs-class-vfio file. Thanks, Alex
[Intel-gfx] ✓ Fi.CI.IGT: success for Tidy up vfio_device life cycle (rev2)
== Series Details == Series: Tidy up vfio_device life cycle (rev2) URL : https://patchwork.freedesktop.org/series/107838/ State : success == Summary == CI Bug Log - changes from CI_DRM_12051_full -> Patchwork_107838v2_full Summary --- **SUCCESS** No regressions found. Participating hosts (13 -> 12) -- Missing(1): shard-rkl Known issues Here are the changes found in Patchwork_107838v2_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-apl: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [FAIL][23], [PASS][24], [PASS][25]) ([i915#4386]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl8/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl8/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl8/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl8/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl7/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl7/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl3/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl3/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl3/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl3/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl3/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl2/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl2/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl1/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl1/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl1/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl1/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107838v2/shard-apl6/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107838v2/shard-apl1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107838v2/shard-apl1/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107838v2/shard-apl1/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107838v2/shard-apl1/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107838v2/shard-apl1/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107838v2/shard-apl2/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107838v2/shard-apl2/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107838v2/shard-apl2/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107838v2/shard-apl2/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107838v2/shard-apl2/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107838v2/shard-apl3/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107838v2/shard-apl3/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107838v2/shard-apl8/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107838v2/shard-apl8/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107838v2/shard-apl8/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107838v2/shard-apl8/boot.html [43]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Allow more varied alternate fixed modes for panels
== Series Details == Series: drm/i915: Allow more varied alternate fixed modes for panels URL : https://patchwork.freedesktop.org/series/107953/ State : success == Summary == CI Bug Log - changes from CI_DRM_12051_full -> Patchwork_107953v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (13 -> 13) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_107953v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-apl: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [FAIL][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25]) ([i915#4386]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl8/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl8/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl8/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl8/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl7/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl1/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl1/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl1/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl7/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl7/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl1/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl2/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl2/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl6/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl2/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl3/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl6/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl3/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl3/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl6/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl3/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl3/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl6/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107953v1/shard-apl1/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107953v1/shard-apl1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107953v1/shard-apl1/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107953v1/shard-apl2/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107953v1/shard-apl2/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107953v1/shard-apl2/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107953v1/shard-apl2/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107953v1/shard-apl2/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107953v1/shard-apl3/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107953v1/shard-apl3/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107953v1/shard-apl3/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107953v1/shard-apl3/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107953v1/shard-apl1/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107953v1/shard-apl6/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107953v1/shard-apl6/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107953v1/shard-apl6/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107953v1/shard-apl6/boot.html [43]:
Re: [Intel-gfx] [PATCH 1/3] drm/i915: audit bo->resource usage
On 31/08/2022 15:53, Matthew Auld wrote: On 31/08/2022 14:34, Christian König wrote: Am 31.08.22 um 14:50 schrieb Matthew Auld: On 31/08/2022 13:35, Christian König wrote: Am 31.08.22 um 14:06 schrieb Matthew Auld: On 31/08/2022 12:03, Christian König wrote: Am 31.08.22 um 12:37 schrieb Matthew Auld: [SNIP] That hopefully just leaves i915_ttm_shrink(), which is swapping out shmem ttm_tt and is calling ttm_bo_validate() with empty placements to force the pipeline-gutting path, which importantly unpopulates the ttm_tt for us (since ttm_tt_unpopulate is not exported it seems). But AFAICT it looks like that will now also nuke the bo->resource, instead of just leaving it in system memory. My assumption is that when later calling ttm_bo_validate(), it will just do the bo_move_null() in i915_ttm_move(), instead of re-populating the ttm_tt and then potentially copying it back to local-memory? Well you do ttm_bo_validate() with something like GTT domain, don't you? This should result in re-populating the tt object, but I'm not 100% sure if that really works as expected. AFAIK for domains we either have system memory (which uses ttm_tt and might be shmem underneath) or local-memory. But perhaps i915 is doing something wrong here, or abusing TTM in some way. I'm not sure tbh. Anyway, I think we have two cases here: - We have some system memory only object. After doing i915_ttm_shrink(), bo->resource is now NULL. We then call ttm_bo_validate() at some later point, but here we don't need to copy anything, but it also looks like ttm_bo_handle_move_mem() won't populate the ttm_tt or us either, since mem_type == TTM_PL_SYSTEM. It looks like i915_ttm_move() was taking care of this, but now we just call ttm_bo_move_null(). - We have a local-memory only object, which was evicted to shmem, and then swapped out by the shrinker like above. The bo->resource is NULL. However this time when calling ttm_bo_validate() we need to actually do a copy in i915_ttm_move(), as well as re-populate the ttm_tt. i915_ttm_move() was taking care of this, but now we just call ttm_bo_move_null(). Perhaps i915 is doing something wrong in the above two cases? Mhm, as far as I can see that should still work. See previously you should got a transition from SYSTEM->GTT in i915_ttm_move() to re-create your backing store. Not you get NULL->SYSTEM which is handled by ttm_bo_move_null() and then SYSTEM->GTT. What is GTT here in TTM world? Also I'm not seeing where there is this SYSTEM->GTT transition? Maybe I'm blind. Just to be clear, i915 is only calling ttm_bo_validate() once when acquiring the pages, and we don't call it again, unless it was evicted (and potentially swapped out). Well GTT means TTM_PL_TT. And calling it only once is perfectly fine, TTM will internally see that we need two hops to reach TTM_PL_TT and so does the NULL->SYSTEM transition and then SYSTEM->TT. Ah interesting, so that's what the multi-hop thing does. But AFAICT i915 is not using either TTM_PL_TT or -EMULTIHOP. Mhm, it could be that we then have a problem and the i915 driver only sees NULL->TT directly. But I really don't know the i915 driver code good enough to judge that. Can you take a look at this and test it maybe? I'll grab a machine and try to see what is going on here. Well at least the issue with the firmware not loading looks to be fixed now. So running some eviction + oom tests it looks it now does: /* eviction kicks in */ i915_ttm_move(bo): LMEM -> PL_SYSTEM /* shrinker/oom kicks in at some point */ i915_ttm_shrink(bo): bo->resource = NULL, /* pipeline_gutting */ shmem ttm_tt is unpopulated and pages are correctly swapped out /* user touches the same object later */ i915_ttm_move(bo): NULL -> LMEM, bo_move_null() So seems to incorrectly skip swapping it back in and then copy over to lmem. It just allocates directly in lmem. And previously the last two steps would have been: i915_ttm_shrink(bo): bo->resource = PL_SYSTEM, /* pipeline_gutting */ shmem ttm_tt is unpopulated and pages are correctly swapped out i915_ttm_move(bo): PL_SYSTEM -> LMEM, ttm_tt is repopulated and pages are copied over to lmem Also what is the difference between TTM_PL_TT and TM_PL_SYSTEM? When should you use one over the other? TTM_PL_SYSTEM means the device is not accessing the buffer and TTM has the control over the backing store and can swapout/swapin as it wants it. TTM_PL_TT means that the device is accessing the data (TT stands for translation table) and so TTM can't swap the backing store in/out. TTM_PL_VRAM well that one is obvious. Thanks for the explanation. So it looks like i915 is using TTM_PL_SYSTEM even for device access it seems. Thanks, Christian. As far as I can see that should work like it did before. Christian. If you just validated to SYSTEM memory before I think the tt object wouldn't have been populated either. Regards,
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/slpc: Fix inconsistent locked return (rev2)
== Series Details == Series: drm/i915/slpc: Fix inconsistent locked return (rev2) URL : https://patchwork.freedesktop.org/series/107938/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12051_full -> Patchwork_107938v2_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_107938v2_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_107938v2_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (13 -> 12) -- Missing(1): shard-rkl Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_107938v2_full: ### IGT changes ### Possible regressions * igt@kms_flip@plain-flip-ts-check@a-edp1: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-tglb3/igt@kms_flip@plain-flip-ts-ch...@a-edp1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107938v2/shard-tglb3/igt@kms_flip@plain-flip-ts-ch...@a-edp1.html Warnings * igt@i915_pm_dc@dc6-psr: - shard-snb: [SKIP][3] ([fdo#109271]) -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-snb6/igt@i915_pm...@dc6-psr.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107938v2/shard-snb6/igt@i915_pm...@dc6-psr.html Known issues Here are the changes found in Patchwork_107938v2_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-apl: ([PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [FAIL][27], [PASS][28], [PASS][29]) ([i915#4386]) -> ([PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl8/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl8/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl8/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl8/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl7/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl7/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl7/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl7/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl6/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl6/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl6/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl3/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl3/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl3/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl3/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl3/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl2/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl2/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl2/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl1/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl1/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12051/shard-apl1/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107938v2/shard-apl3/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107938v2/shard-apl1/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107938v2/shard-apl1/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107938v2/shard-apl1/boot.html [34]:
[Intel-gfx] [PATCH] drm/i915/ttm: Abort suspend on i915_ttm_backup failure
On system suspend when system memory is low then i915_gem_obj_copy_ttm()
could fail trying to backup a lmem obj. GEM_WARN_ON() is not enough,
suspend shouldn't continue if i915_ttm_backup() throws an error.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6529
Reviewed-by: Matthew Auld
Suggested-by: Chris P Wilson
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
index 9aad84059d56..6f5d5c0909b4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
@@ -79,7 +79,12 @@ static int i915_ttm_backup(struct i915_gem_apply_to_region
*apply,
goto out_no_populate;
err = i915_gem_obj_copy_ttm(backup, obj, pm_apply->allow_gpu, false);
- GEM_WARN_ON(err);
+ if (err) {
+ drm_err(>drm,
+ "Unable to copy from device to system memory, err:%d\n",
+ err);
+ goto out_no_populate;
+ }
ttm_bo_wait_ctx(backup_bo, );
obj->ttm.backup = backup;
--
2.35.1
Re: [Intel-gfx] [PATCH] drm/i915/ttm: Abort suspend on i915_ttm_backup failure
On 8/31/2022 5:50 PM, Matthew Auld wrote:
On 29/08/2022 13:04, Nirmoy Das wrote:
On system suspend when system memory is low then i915_gem_obj_copy_ttm()
could fail trying to backup a lmem obj. GEM_WARN_ON() is not enough,
suspend shouldn't continue if i915_ttm_backup() throws an error.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6529
Does this fix it? Does CI not complain about the drm_err? Also do we
know what the actual error was?
The error isn't reoccurring so the best guess is: large framebuffer copy
took long time and wait_for_suspend()
timed out. This needs more coverage from IGT and I am looking into
that. Let's ignore the "Closes" tag from this
patch till I come up a IGT test for this.
Nirmoy
Suggested-by: Chris P Wilson
Signed-off-by: Nirmoy Das
Passing the error along seems reasonable to me,
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
index 9aad84059d56..6f5d5c0909b4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
@@ -79,7 +79,12 @@ static int i915_ttm_backup(struct
i915_gem_apply_to_region *apply,
goto out_no_populate;
err = i915_gem_obj_copy_ttm(backup, obj, pm_apply->allow_gpu,
false);
- GEM_WARN_ON(err);
+ if (err) {
+ drm_err(>drm,
+ "Unable to copy from device to system memory, err:%d\n",
+ err);
+ goto out_no_populate;
+ }
ttm_bo_wait_ctx(backup_bo, );
obj->ttm.backup = backup;
[Intel-gfx] [PATCH 1/1] drm/i915/display: convert dsc debugfs entry from output_bpp to input_bpc
With this patch, converting DSC debugfs entry from output_bpp to input_bpc.
Corresponding changes are done in i-g-t to validate DSC with different
input bpc supported per platform.
Signed-off-by: Swati Sharma
---
.../drm/i915/display/intel_display_debugfs.c | 26 +--
.../drm/i915/display/intel_display_types.h| 2 +-
drivers/gpu/drm/i915/display/intel_dp.c | 23 +---
3 files changed, 21 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 225b6bfc783c..23627ed3beb1 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -2138,7 +2138,7 @@ static const struct file_operations
i915_dsc_fec_support_fops = {
.write = i915_dsc_fec_support_write
};
-static int i915_dsc_bpp_show(struct seq_file *m, void *data)
+static int i915_dsc_bpc_show(struct seq_file *m, void *data)
{
struct drm_connector *connector = m->private;
struct drm_device *dev = connector->dev;
@@ -2161,14 +2161,14 @@ static int i915_dsc_bpp_show(struct seq_file *m, void
*data)
}
crtc_state = to_intel_crtc_state(crtc->state);
- seq_printf(m, "Compressed_BPP: %d\n", crtc_state->dsc.compressed_bpp);
+ seq_printf(m, "Input_BPC: %d\n",
crtc_state->dsc.config.bits_per_component);
out: drm_modeset_unlock(>mode_config.connection_mutex);
return ret;
}
-static ssize_t i915_dsc_bpp_write(struct file *file,
+static ssize_t i915_dsc_bpc_write(struct file *file,
const char __user *ubuf,
size_t len, loff_t *offp)
{
@@ -2176,33 +2176,33 @@ static ssize_t i915_dsc_bpp_write(struct file *file,
((struct seq_file *)file->private_data)->private;
struct intel_encoder *encoder =
intel_attached_encoder(to_intel_connector(connector));
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
- int dsc_bpp = 0;
+ int dsc_bpc = 0;
int ret;
- ret = kstrtoint_from_user(ubuf, len, 0, _bpp);
+ ret = kstrtoint_from_user(ubuf, len, 0, _bpc);
if (ret < 0)
return ret;
- intel_dp->force_dsc_bpp = dsc_bpp;
+ intel_dp->force_dsc_bpc = dsc_bpc;
*offp += len;
return len;
}
-static int i915_dsc_bpp_open(struct inode *inode,
+static int i915_dsc_bpc_open(struct inode *inode,
struct file *file)
{
- return single_open(file, i915_dsc_bpp_show,
+ return single_open(file, i915_dsc_bpc_show,
inode->i_private);
}
-static const struct file_operations i915_dsc_bpp_fops = {
+static const struct file_operations i915_dsc_bpc_fops = {
.owner = THIS_MODULE,
- .open = i915_dsc_bpp_open,
+ .open = i915_dsc_bpc_open,
.read = seq_read,
.llseek = seq_lseek,
.release = single_release,
- .write = i915_dsc_bpp_write
+ .write = i915_dsc_bpc_write
};
/*
@@ -2272,8 +2272,8 @@ void intel_connector_debugfs_add(struct intel_connector
*intel_connector)
debugfs_create_file("i915_dsc_fec_support", 0644, root,
connector, _dsc_fec_support_fops);
- debugfs_create_file("i915_dsc_bpp", 0644, root,
- connector, _dsc_bpp_fops);
+ debugfs_create_file("i915_dsc_bpc", 0644, root,
+ connector, _dsc_bpc_fops);
}
if (connector->connector_type == DRM_MODE_CONNECTOR_DSI ||
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 0da9b208d56e..dbda845030bf 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1712,7 +1712,7 @@ struct intel_dp {
/* Display stream compression testing */
bool force_dsc_en;
- int force_dsc_bpp;
+ int force_dsc_bpc;
bool hobl_failed;
bool hobl_active;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 8d1559323412..0d75b00d3e5d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1474,6 +1474,13 @@ static int intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp,
conn_state->max_requested_bpc);
+ if (intel_dp->force_dsc_bpc) {
+ pipe_bpp = intel_dp->force_dsc_bpc * 3;
+ drm_dbg_kms(_priv->drm,
+ "Input DSC BPP forced to %d",
+ pipe_bpp);
+ }
+
/* Min Input BPC for ICL+ is 8 */
if (pipe_bpp < 8 * 3) {
drm_dbg_kms(_priv->drm,
@@ -1525,22 +1532,6 @@ static int
[Intel-gfx] [PATCH 0/1] Modify debugfs entry from dsc compressed bpp to input bpc
In this patch, output dsc compressed bpp debufs entry is changed to input bpc dsc. Also, corresponding changes done in kms_dsc i-g-t. Test-with: 20220831120849.28883-1-swati2.sha...@intel.com Swati Sharma (1): drm/i915/display: convert dsc debugfs entry from output_bpp to input_bpc .../drm/i915/display/intel_display_debugfs.c | 26 +-- .../drm/i915/display/intel_display_types.h| 2 +- drivers/gpu/drm/i915/display/intel_dp.c | 23 +--- 3 files changed, 21 insertions(+), 30 deletions(-) -- 2.25.1
Re: [Intel-gfx] [PATCH v2 2/5] drm/i915/dpll: replace BUG_ON() with drm_WARN_ON()
On Wed, 31 Aug 2022, Andrzej Hajda wrote:
> On 30.08.2022 11:34, Jani Nikula wrote:
>> Avoid BUG_ON(). Actually check the dpll count and bail out loudly with
>> drm_WARN_ON() from the loop before overflowing
>> i915->dpll.shared_dplls[].
>>
>> v2: Rebase
>>
>> Reviewed-by: Ville Syrjälä
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>> index bbe142056c7c..ed267c918009 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>> @@ -4199,6 +4199,10 @@ void intel_shared_dpll_init(struct drm_i915_private
>> *dev_priv)
>> dpll_info = dpll_mgr->dpll_info;
>>
>> for (i = 0; dpll_info[i].name; i++) {
>> +if (drm_WARN_ON(_priv->drm,
>> +i >=
>> ARRAY_SIZE(dev_priv->display.dpll.shared_dplls)))
>> +break;
>> +
>
> Shouldn't this check be replaced by some compile time checker.
Can't do that because the dpll_info arrays are null terminated.
> Anyway:
> Reviewed-by: Andrzej Hajda
Thanks, but I just pushed the series as Ville already reviewed it.
BR,
Jani.
>
> Regards
> Andrzej
>
>
>> drm_WARN_ON(_priv->drm, i != dpll_info[i].id);
>> dev_priv->display.dpll.shared_dplls[i].info = _info[i];
>> }
>> @@ -4206,8 +4210,6 @@ void intel_shared_dpll_init(struct drm_i915_private
>> *dev_priv)
>> dev_priv->display.dpll.mgr = dpll_mgr;
>> dev_priv->display.dpll.num_shared_dpll = i;
>> mutex_init(_priv->display.dpll.lock);
>> -
>> -BUG_ON(dev_priv->display.dpll.num_shared_dpll > I915_NUM_PLLS);
>> }
>>
>> /**
>
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915/ttm: Abort suspend on i915_ttm_backup failure
On 29/08/2022 13:04, Nirmoy Das wrote:
On system suspend when system memory is low then i915_gem_obj_copy_ttm()
could fail trying to backup a lmem obj. GEM_WARN_ON() is not enough,
suspend shouldn't continue if i915_ttm_backup() throws an error.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6529
Does this fix it? Does CI not complain about the drm_err? Also do we
know what the actual error was?
Suggested-by: Chris P Wilson
Signed-off-by: Nirmoy Das
Passing the error along seems reasonable to me,
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
index 9aad84059d56..6f5d5c0909b4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
@@ -79,7 +79,12 @@ static int i915_ttm_backup(struct i915_gem_apply_to_region
*apply,
goto out_no_populate;
err = i915_gem_obj_copy_ttm(backup, obj, pm_apply->allow_gpu, false);
- GEM_WARN_ON(err);
+ if (err) {
+ drm_err(>drm,
+ "Unable to copy from device to system memory, err:%d\n",
+ err);
+ goto out_no_populate;
+ }
ttm_bo_wait_ctx(backup_bo, );
obj->ttm.backup = backup;
Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/pch: replace BUG_ON() with drm_WARN_ON()
On 30.08.2022 11:34, Jani Nikula wrote: Avoid BUG_ON(). Replace with drm_WARN_ON(). Reviewed-by: Ville Syrjälä Signed-off-by: Jani Nikula Reviewed-by: Andrzej Hajda Regards Andrzej
Re: [Intel-gfx] [PATCH v2 2/5] drm/i915/dpll: replace BUG_ON() with drm_WARN_ON()
On 30.08.2022 11:34, Jani Nikula wrote:
Avoid BUG_ON(). Actually check the dpll count and bail out loudly with
drm_WARN_ON() from the loop before overflowing
i915->dpll.shared_dplls[].
v2: Rebase
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index bbe142056c7c..ed267c918009 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -4199,6 +4199,10 @@ void intel_shared_dpll_init(struct drm_i915_private
*dev_priv)
dpll_info = dpll_mgr->dpll_info;
for (i = 0; dpll_info[i].name; i++) {
+ if (drm_WARN_ON(_priv->drm,
+ i >=
ARRAY_SIZE(dev_priv->display.dpll.shared_dplls)))
+ break;
+
Shouldn't this check be replaced by some compile time checker.
Anyway:
Reviewed-by: Andrzej Hajda
Regards
Andrzej
drm_WARN_ON(_priv->drm, i != dpll_info[i].id);
dev_priv->display.dpll.shared_dplls[i].info = _info[i];
}
@@ -4206,8 +4210,6 @@ void intel_shared_dpll_init(struct drm_i915_private
*dev_priv)
dev_priv->display.dpll.mgr = dpll_mgr;
dev_priv->display.dpll.num_shared_dpll = i;
mutex_init(_priv->display.dpll.lock);
-
- BUG_ON(dev_priv->display.dpll.num_shared_dpll > I915_NUM_PLLS);
}
/**
Re: [Intel-gfx] [PATCH 0/6] drm/i915/gmbus: stop using implicit dev_priv
On Tue, 30 Aug 2022, Jani Nikula wrote: > On Tue, 30 Aug 2022, Ville Syrjälä wrote: >> On Tue, Aug 30, 2022 at 01:27:56PM +0300, Jani Nikula wrote: >>> The register macros are the last holdout for implicit dev_priv local >>> variable. Try out what it would mean to stop using it, and require >>> passing i915 as parameter to the register macros. Use gmbus as a nicely >>> isolated playing ground. >>> >>> Jani Nikula (6): >>> drm/i915/gmbus: split out gmbus regs in a separate file >>> drm/i915/gmbus: whitespace cleanup in reg definitions >>> drm/i915/gmbus: add wrapper for gmbus mmio base >>> drm/i915/gmbus: stop using implicit dev_priv in register definitions >>> drm/i915/reg: stop using implicit dev_priv in DSPCLK_GATE_D >>> drm/i915/gmbus: mass dev_priv -> i915 rename >> >> Looks reasonable enough to me. Just wondering when I'll start >> getting annoyed at not finding something in i915_reg.h :) > > That's a risk. :) > > The flip side is, I've actually liked to see how few places really need > each of the new *_regs.h files. It's almost an indication the design is > wrong if more than a couple .c files include the same regs file. > >> Series is >> Reviewed-by: Ville Syrjälä > > Thanks! And pushed to drm-intel-next. BR, Jani. > > Jani. > >> >>> >>> .../i915/display/intel_display_power_well.c | 4 +- >>> drivers/gpu/drm/i915/display/intel_gmbus.c| 275 +- >>> .../gpu/drm/i915/display/intel_gmbus_regs.h | 81 ++ >>> drivers/gpu/drm/i915/display/intel_overlay.c | 4 +- >>> drivers/gpu/drm/i915/display/vlv_dsi.c| 8 +- >>> drivers/gpu/drm/i915/gvt/edid.c | 3 +- >>> drivers/gpu/drm/i915/i915_reg.h | 65 + >>> drivers/gpu/drm/i915/intel_pm.c | 4 +- >>> 8 files changed, 232 insertions(+), 212 deletions(-) >>> create mode 100644 drivers/gpu/drm/i915/display/intel_gmbus_regs.h >>> >>> -- >>> 2.34.1 -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/crt: remove BUG_ON()
On Wed, 31 Aug 2022, Andrzej Hajda wrote: > On 30.08.2022 11:34, Jani Nikula wrote: >> Avoid BUG_ON(). We don't have such checks on output type anywhere else >> either, so just remove. >> >> Suggested-by: Ville Syrjälä >> Signed-off-by: Jani Nikula >> --- > Reviewed-by: Andrzej Hajda Thanks for the reviews, pushed to drm-intel-next. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/slpc: Set rps' min and max frequencies even with SLPC. (rev6)
== Series Details == Series: drm/i915/slpc: Set rps' min and max frequencies even with SLPC. (rev6) URL : https://patchwork.freedesktop.org/series/107766/ State : success == Summary == CI Bug Log - changes from CI_DRM_12050_full -> Patchwork_107766v6_full Summary --- **SUCCESS** No regressions found. Participating hosts (11 -> 12) -- Additional (1): shard-rkl Known issues Here are the changes found in Patchwork_107766v6_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_param@set-priority-not-supported: - shard-tglb: NOTRUN -> [SKIP][1] ([fdo#109314]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v6/shard-tglb6/igt@gem_ctx_pa...@set-priority-not-supported.html * igt@gem_ctx_persistence@engines-mixed-process: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v6/shard-snb6/igt@gem_ctx_persiste...@engines-mixed-process.html * igt@gem_eio@reset-stress: - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#5784]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12050/shard-tglb3/igt@gem_...@reset-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v6/shard-tglb2/igt@gem_...@reset-stress.html * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][5] -> [TIMEOUT][6] ([i915#3070]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12050/shard-iclb5/igt@gem_...@unwedge-stress.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v6/shard-iclb2/igt@gem_...@unwedge-stress.html - shard-snb: NOTRUN -> [FAIL][7] ([i915#3354]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v6/shard-snb5/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@parallel-contexts: - shard-iclb: [PASS][8] -> [SKIP][9] ([i915#4525]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12050/shard-iclb1/igt@gem_exec_balan...@parallel-contexts.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v6/shard-iclb8/igt@gem_exec_balan...@parallel-contexts.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: [PASS][10] -> [FAIL][11] ([i915#2846]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12050/shard-kbl7/igt@gem_exec_f...@basic-deadline.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v6/shard-kbl1/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-apl: NOTRUN -> [FAIL][12] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v6/shard-apl8/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12050/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v6/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_lmem_swapping@massive: - shard-kbl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v6/shard-kbl7/igt@gem_lmem_swapp...@massive.html * igt@gem_lmem_swapping@parallel-random-verify: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v6/shard-apl3/igt@gem_lmem_swapp...@parallel-random-verify.html * igt@gem_pread@exhaustion: - shard-apl: NOTRUN -> [WARN][17] ([i915#2658]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v6/shard-apl3/igt@gem_pr...@exhaustion.html * igt@gem_pwrite@basic-exhaustion: - shard-snb: NOTRUN -> [WARN][18] ([i915#2658]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v6/shard-snb6/igt@gem_pwr...@basic-exhaustion.html - shard-kbl: NOTRUN -> [WARN][19] ([i915#2658]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v6/shard-kbl7/igt@gem_pwr...@basic-exhaustion.html * igt@gem_render_copy@x-tiled-to-vebox-yf-tiled: - shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271]) +147 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v6/shard-apl3/igt@gem_render_c...@x-tiled-to-vebox-yf-tiled.html * igt@gem_userptr_blits@dmabuf-sync: - shard-apl: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#3323]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v6/shard-apl3/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@dmabuf-unsync: - shard-tglb: NOTRUN -> [SKIP][22] ([i915#3297]) [22]:
Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/crt: remove BUG_ON()
On 30.08.2022 11:34, Jani Nikula wrote: Avoid BUG_ON(). We don't have such checks on output type anywhere else either, so just remove. Suggested-by: Ville Syrjälä Signed-off-by: Jani Nikula --- Reviewed-by: Andrzej Hajda Regards Andrzej
Re: [Intel-gfx] [PATCH] drm/i915/display: Fix warning callstack for imbalance wakeref
On 30.08.2022 10:51, Mitul Golani wrote: While executing i915_selftest, wakeref imbalance warning is seen with i915_selftest failure. Currently when Driver is suspended, while doing unregister it is taking wakeref without resuming the device. This patch is resuming the device, if driver is already suspended and doing unregister process. Signed-off-by: Mitul Golani Reviewed-by: Andrzej Hajda Regards Andrzej
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Fix warning callstack for imbalance wakeref (rev7)
== Series Details == Series: drm/i915/display: Fix warning callstack for imbalance wakeref (rev7) URL : https://patchwork.freedesktop.org/series/107211/ State : success == Summary == CI Bug Log - changes from CI_DRM_12050_full -> Patchwork_107211v7_full Summary --- **SUCCESS** No regressions found. Participating hosts (11 -> 12) -- Additional (1): shard-rkl Known issues Here are the changes found in Patchwork_107211v7_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_param@set-priority-not-supported: - shard-tglb: NOTRUN -> [SKIP][1] ([fdo#109314]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v7/shard-tglb7/igt@gem_ctx_pa...@set-priority-not-supported.html * igt@gem_ctx_persistence@engines-mixed-process: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v7/shard-snb4/igt@gem_ctx_persiste...@engines-mixed-process.html * igt@gem_eio@in-flight-contexts-1us: - shard-iclb: [PASS][3] -> [TIMEOUT][4] ([i915#3070]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12050/shard-iclb7/igt@gem_...@in-flight-contexts-1us.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v7/shard-iclb8/igt@gem_...@in-flight-contexts-1us.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][5] ([i915#3354]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v7/shard-snb6/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: [PASS][6] -> [FAIL][7] ([i915#2846]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12050/shard-kbl7/igt@gem_exec_f...@basic-deadline.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v7/shard-kbl7/igt@gem_exec_f...@basic-deadline.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_107211v7/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-apl: NOTRUN -> [FAIL][9] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v7/shard-apl7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html - shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12050/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v7/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][12] -> [FAIL][13] ([i915#2842]) +3 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12050/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v7/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][14] -> [SKIP][15] ([i915#2190]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12050/shard-tglb1/igt@gem_huc_c...@huc-copy.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v7/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@heavy-verify-random-ccs: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v7/shard-apl7/igt@gem_lmem_swapp...@heavy-verify-random-ccs.html * igt@gem_lmem_swapping@smem-oom: - shard-kbl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v7/shard-kbl4/igt@gem_lmem_swapp...@smem-oom.html * igt@gem_mmap_gtt@fault-concurrent-x: - shard-snb: NOTRUN -> [INCOMPLETE][18] ([i915#5161]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v7/shard-snb6/igt@gem_mmap_...@fault-concurrent-x.html * igt@gem_pwrite@basic-exhaustion: - shard-snb: NOTRUN -> [WARN][19] ([i915#2658]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v7/shard-snb4/igt@gem_pwr...@basic-exhaustion.html * igt@gem_userptr_blits@dmabuf-unsync: - shard-tglb: NOTRUN -> [SKIP][20] ([i915#3297]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v7/shard-tglb7/igt@gem_userptr_bl...@dmabuf-unsync.html * igt@gem_userptr_blits@vma-merge: - shard-snb: NOTRUN -> [FAIL][21] ([i915#2724]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v7/shard-snb4/igt@gem_userptr_bl...@vma-merge.html * igt@gen9_exec_parse@allowed-single: - shard-kbl: [PASS][22] -> [DMESG-WARN][23] ([i915#5566] / [i915#716]) [22]:
Re: [Intel-gfx] [PATCH 1/3] drm/i915: audit bo->resource usage
On 31/08/2022 14:34, Christian König wrote:
Am 31.08.22 um 14:50 schrieb Matthew Auld:
On 31/08/2022 13:35, Christian König wrote:
Am 31.08.22 um 14:06 schrieb Matthew Auld:
On 31/08/2022 12:03, Christian König wrote:
Am 31.08.22 um 12:37 schrieb Matthew Auld:
[SNIP]
That hopefully just leaves i915_ttm_shrink(), which is swapping
out shmem ttm_tt and is calling ttm_bo_validate() with empty
placements to force the pipeline-gutting path, which importantly
unpopulates the ttm_tt for us (since ttm_tt_unpopulate is not
exported it seems). But AFAICT it looks like that will now also
nuke the bo->resource, instead of just leaving it in system
memory. My assumption is that when later calling
ttm_bo_validate(), it will just do the bo_move_null() in
i915_ttm_move(), instead of re-populating the ttm_tt and then
potentially copying it back to local-memory?
Well you do ttm_bo_validate() with something like GTT domain,
don't you? This should result in re-populating the tt object, but
I'm not 100% sure if that really works as expected.
AFAIK for domains we either have system memory (which uses ttm_tt
and might be shmem underneath) or local-memory. But perhaps i915
is doing something wrong here, or abusing TTM in some way. I'm not
sure tbh.
Anyway, I think we have two cases here:
- We have some system memory only object. After doing
i915_ttm_shrink(), bo->resource is now NULL. We then call
ttm_bo_validate() at some later point, but here we don't need to
copy anything, but it also looks like ttm_bo_handle_move_mem()
won't populate the ttm_tt or us either, since mem_type ==
TTM_PL_SYSTEM. It looks like i915_ttm_move() was taking care of
this, but now we just call ttm_bo_move_null().
- We have a local-memory only object, which was evicted to shmem,
and then swapped out by the shrinker like above. The bo->resource
is NULL. However this time when calling ttm_bo_validate() we need
to actually do a copy in i915_ttm_move(), as well as re-populate
the ttm_tt. i915_ttm_move() was taking care of this, but now we
just call ttm_bo_move_null().
Perhaps i915 is doing something wrong in the above two cases?
Mhm, as far as I can see that should still work.
See previously you should got a transition from SYSTEM->GTT in
i915_ttm_move() to re-create your backing store. Not you get
NULL->SYSTEM which is handled by ttm_bo_move_null() and then
SYSTEM->GTT.
What is GTT here in TTM world? Also I'm not seeing where there is
this SYSTEM->GTT transition? Maybe I'm blind. Just to be clear, i915
is only calling ttm_bo_validate() once when acquiring the pages, and
we don't call it again, unless it was evicted (and potentially
swapped out).
Well GTT means TTM_PL_TT.
And calling it only once is perfectly fine, TTM will internally see
that we need two hops to reach TTM_PL_TT and so does the NULL->SYSTEM
transition and then SYSTEM->TT.
Ah interesting, so that's what the multi-hop thing does. But AFAICT
i915 is not using either TTM_PL_TT or -EMULTIHOP.
Mhm, it could be that we then have a problem and the i915 driver only
sees NULL->TT directly. But I really don't know the i915 driver code
good enough to judge that.
Can you take a look at this and test it maybe?
I'll grab a machine and try to see what is going on here.
Also what is the difference between TTM_PL_TT and TM_PL_SYSTEM? When
should you use one over the other?
TTM_PL_SYSTEM means the device is not accessing the buffer and TTM has
the control over the backing store and can swapout/swapin as it wants it.
TTM_PL_TT means that the device is accessing the data (TT stands for
translation table) and so TTM can't swap the backing store in/out.
TTM_PL_VRAM well that one is obvious.
Thanks for the explanation. So it looks like i915 is using TTM_PL_SYSTEM
even for device access it seems.
Thanks,
Christian.
As far as I can see that should work like it did before.
Christian.
If you just validated to SYSTEM memory before I think the tt object
wouldn't have been populated either.
Regards,
Christian.
Thanks,
Christian.
I've been considering to replacing the ttm_bo_type with a bunch
of behavior flags for a bo. I'm hoping that this will clean
things up a bit.
Regards,
Christian.
caching = i915_ttm_select_tt_caching(obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 9a7e50534b84bb..c420d1ab605b6f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -560,7 +560,7 @@ int i915_ttm_move(struct
ttm_buffer_object *bo, bool evict,
bool clear;
int ret;
- if (GEM_WARN_ON(!obj)) {
+ if (GEM_WARN_ON(!obj) || !bo->resource) {
ttm_bo_move_null(bo, dst_mem);
return 0;
}
Re: [Intel-gfx] [PATCH v3 00/18] drm/i915: add display sub-struct to drm_i915_private
On Mon, 29 Aug 2022, Jani Nikula wrote: > v3 of https://patchwork.freedesktop.org/series/107170/ > > Dropped already merged patches, rebased the rest. And pushed the lot to drm-intel-next. Thanks for the review. BR, Jani. > > Jani Nikula (18): > drm/i915: move and group hdcp under display.hdcp > drm/i915: move and group max_bw and bw_obj under display.bw > drm/i915: move opregion to display.opregion > drm/i915: move and group cdclk under display.cdclk > drm/i915: move backlight to display.backlight > drm/i915: move mipi_mmio_base to display.dsi > drm/i915: move vbt to display.vbt > drm/i915: move fbc to display.fbc > drm/i915: move and group power related members under display.power > drm/i915: move and group fdi members under display.fdi > drm/i915: move fb_tracking under display sub-struct > drm/i915: move dbuf under display sub-struct > drm/i915: move and group modeset_wq and flip_wq under display.wq > drm/i915/quirks: abstract checking for display quirks > drm/i915/quirks: abstract quirks further by making quirk ids an enum > drm/i915: move quirks under display sub-struct > drm/i915: move atomic_helper under display sub-struct > drm/i915: move and group properties under display.properties > > drivers/gpu/drm/i915/display/hsw_ips.c| 2 +- > drivers/gpu/drm/i915/display/i9xx_plane.c | 2 +- > drivers/gpu/drm/i915/display/intel_atomic.c | 8 +- > drivers/gpu/drm/i915/display/intel_audio.c| 6 +- > .../gpu/drm/i915/display/intel_backlight.c| 41 ++-- > drivers/gpu/drm/i915/display/intel_bios.c | 216 +- > drivers/gpu/drm/i915/display/intel_bw.c | 42 ++-- > drivers/gpu/drm/i915/display/intel_cdclk.c| 206 - > drivers/gpu/drm/i915/display/intel_cdclk.h| 4 +- > .../gpu/drm/i915/display/intel_connector.c| 8 +- > drivers/gpu/drm/i915/display/intel_crt.c | 8 +- > drivers/gpu/drm/i915/display/intel_ddi.c | 3 +- > drivers/gpu/drm/i915/display/intel_display.c | 56 ++--- > .../gpu/drm/i915/display/intel_display_core.h | 155 + > .../drm/i915/display/intel_display_debugfs.c | 10 +- > .../drm/i915/display/intel_display_power.c| 122 +- > .../i915/display/intel_display_power_map.c| 4 +- > .../i915/display/intel_display_power_well.c | 60 ++--- > .../i915/display/intel_display_power_well.h | 12 +- > drivers/gpu/drm/i915/display/intel_dp.c | 6 +- > drivers/gpu/drm/i915/display/intel_dp_aux.c | 2 +- > drivers/gpu/drm/i915/display/intel_dpio_phy.c | 2 +- > drivers/gpu/drm/i915/display/intel_dpll.c | 14 +- > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 22 +- > drivers/gpu/drm/i915/display/intel_dsi.c | 2 +- > drivers/gpu/drm/i915/display/intel_fbc.c | 6 +- > drivers/gpu/drm/i915/display/intel_fdi.c | 10 +- > .../gpu/drm/i915/display/intel_frontbuffer.c | 54 ++--- > drivers/gpu/drm/i915/display/intel_hdcp.c | 134 +-- > drivers/gpu/drm/i915/display/intel_lvds.c | 4 +- > .../drm/i915/display/intel_modeset_setup.c| 12 +- > drivers/gpu/drm/i915/display/intel_opregion.c | 42 ++-- > drivers/gpu/drm/i915/display/intel_panel.c| 5 +- > .../gpu/drm/i915/display/intel_pch_refclk.c | 2 +- > drivers/gpu/drm/i915/display/intel_pps.c | 3 +- > drivers/gpu/drm/i915/display/intel_quirks.c | 22 +- > drivers/gpu/drm/i915/display/intel_quirks.h | 14 +- > drivers/gpu/drm/i915/display/intel_sdvo.c | 18 +- > drivers/gpu/drm/i915/display/intel_vbt_defs.h | 8 +- > .../drm/i915/display/skl_universal_plane.c| 2 +- > drivers/gpu/drm/i915/display/vlv_dsi.c| 4 +- > drivers/gpu/drm/i915/display/vlv_dsi_regs.h | 188 +++ > drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 4 +- > drivers/gpu/drm/i915/i915_debugfs.c | 2 +- > drivers/gpu/drm/i915/i915_driver.c| 4 +- > drivers/gpu/drm/i915/i915_drv.h | 153 + > drivers/gpu/drm/i915/i915_gem.c | 2 +- > drivers/gpu/drm/i915/i915_irq.c | 2 +- > drivers/gpu/drm/i915/intel_pm.c | 16 +- > drivers/gpu/drm/i915/intel_pm.h | 4 +- > 50 files changed, 885 insertions(+), 843 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/crt: remove BUG_ON()
On Tue, Aug 30, 2022 at 12:34:07PM +0300, Jani Nikula wrote: > Avoid BUG_ON(). We don't have such checks on output type anywhere else > either, so just remove. > > Suggested-by: Ville Syrjälä > Signed-off-by: Jani Nikula Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_crt.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_crt.c > b/drivers/gpu/drm/i915/display/intel_crt.c > index 6a3893c8ff22..d766c506b235 100644 > --- a/drivers/gpu/drm/i915/display/intel_crt.c > +++ b/drivers/gpu/drm/i915/display/intel_crt.c > @@ -643,8 +643,6 @@ static bool intel_crt_detect_ddc(struct drm_connector > *connector) > struct i2c_adapter *i2c; > bool ret = false; > > - BUG_ON(crt->base.type != INTEL_OUTPUT_ANALOG); > - > i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->vbt.crt_ddc_pin); > edid = intel_crt_get_edid(connector, i2c); > > -- > 2.34.1 -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH] drm/i915/display: clear plane color control register when turn plane off
On Wed, Aug 31, 2022 at 01:27:24PM +, Lee, Shawn C wrote:
> On Wed, August 31, 2022 8:33 PM, Ville Syrjälä wrote:
> >On Mon, Aug 01, 2022 at 11:16:16PM +0800, Lee Shawn C wrote:
> >> Customer report abnormal display output while switch eDP off sometimes.
> >> In current display disable flow, plane will be off at first. Then turn
> >> eDP off and disable HW pipe line. We found the abnormal pixel comes
> >> after turn plane off. Clear plane color ctl register when driver
> >> disable plane can solve this symptom.
> >>
> >> Signed-off-by: Lee Shawn C
> >> Reviewed-by: Uma Shankar
> >> ---
> >> drivers/gpu/drm/i915/display/skl_universal_plane.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> >> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> >> index caa03324a733..90977cfb7ebb 100644
> >> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> >> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> >> @@ -620,6 +620,8 @@ skl_plane_disable_arm(struct intel_plane *plane,
> >>
> >>intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), 0);
> >>intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id), 0);
> >> + if (DISPLAY_VER(dev_priv) >= 10)
> >> + intel_de_write_fw(dev_priv, PLANE_COLOR_CTL(pipe, plane_id), 0);
> >> }
> >>
> >> static void
> >> @@ -638,6 +640,7 @@ icl_plane_disable_arm(struct intel_plane *plane,
> >>intel_psr2_disable_plane_sel_fetch(plane, crtc_state);
> >>intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), 0);
> >>intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id), 0);
> >> + intel_de_write_fw(dev_priv, PLANE_COLOR_CTL(pipe, plane_id), 0);
> >
> >This makes no sense. The register value shouldn't even get latched since you
> >wrote the arming register (PLANE_SURF) before this one.
> >
> >What platform is the problematic machine?
> >
>
> ADL-P
PSR related?
Do you have commit 031a2fea0482 ("drm/i915/psr: Disable PSR before disable
pipe")?
--
Ville Syrjälä
Intel
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gmbus: stop using implicit dev_priv
== Series Details == Series: drm/i915/gmbus: stop using implicit dev_priv URL : https://patchwork.freedesktop.org/series/107930/ State : success == Summary == CI Bug Log - changes from CI_DRM_12048_full -> Patchwork_107930v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (13 -> 12) -- Missing(1): shard-dg1 Known issues Here are the changes found in Patchwork_107930v1_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@crc32: - shard-tglb: NOTRUN -> [SKIP][1] ([i915#6230]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107930v1/shard-tglb6/igt@api_intel...@crc32.html * igt@feature_discovery@chamelium: - shard-tglb: NOTRUN -> [SKIP][2] ([fdo#111827]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107930v1/shard-tglb3/igt@feature_discov...@chamelium.html * igt@feature_discovery@display-2x: - shard-tglb: NOTRUN -> [SKIP][3] ([i915#1839]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107930v1/shard-tglb7/igt@feature_discov...@display-2x.html * igt@gem_ccs@ctrl-surf-copy: - shard-tglb: NOTRUN -> [SKIP][4] ([i915#3555] / [i915#5325]) +2 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107930v1/shard-tglb7/igt@gem_...@ctrl-surf-copy.html * igt@gem_ccs@suspend-resume: - shard-tglb: NOTRUN -> [SKIP][5] ([i915#5325]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107930v1/shard-tglb6/igt@gem_...@suspend-resume.html * igt@gem_create@create-ext-cpu-access-sanity-check: - shard-tglb: NOTRUN -> [SKIP][6] ([i915#6335]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107930v1/shard-tglb5/igt@gem_cre...@create-ext-cpu-access-sanity-check.html * igt@gem_create@create-massive: - shard-kbl: NOTRUN -> [DMESG-WARN][7] ([i915#4991]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107930v1/shard-kbl1/igt@gem_cre...@create-massive.html - shard-tglb: NOTRUN -> [DMESG-WARN][8] ([i915#4991]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107930v1/shard-tglb6/igt@gem_cre...@create-massive.html * igt@gem_ctx_exec@basic-nohangcheck: - shard-tglb: NOTRUN -> [FAIL][9] ([i915#6268]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107930v1/shard-tglb5/igt@gem_ctx_e...@basic-nohangcheck.html * igt@gem_ctx_param@set-priority-not-supported: - shard-tglb: NOTRUN -> [SKIP][10] ([fdo#109314]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107930v1/shard-tglb3/igt@gem_ctx_pa...@set-priority-not-supported.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: NOTRUN -> [FAIL][11] ([i915#2410]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107930v1/shard-tglb1/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_ctx_sseu@engines: - shard-tglb: NOTRUN -> [SKIP][12] ([i915#280]) +3 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107930v1/shard-tglb7/igt@gem_ctx_s...@engines.html * igt@gem_eio@kms: - shard-tglb: NOTRUN -> [FAIL][13] ([i915#5784]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107930v1/shard-tglb1/igt@gem_...@kms.html * igt@gem_exec_balancer@parallel-bb-first: - shard-iclb: [PASS][14] -> [SKIP][15] ([i915#4525]) +2 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12048/shard-iclb1/igt@gem_exec_balan...@parallel-bb-first.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107930v1/shard-iclb7/igt@gem_exec_balan...@parallel-bb-first.html * igt@gem_exec_balancer@parallel-ordering: - shard-tglb: NOTRUN -> [FAIL][16] ([i915#6117]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107930v1/shard-tglb2/igt@gem_exec_balan...@parallel-ordering.html * igt@gem_exec_capture@capture-invisible@smem0: - shard-tglb: NOTRUN -> [SKIP][17] ([i915#6334]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107930v1/shard-tglb6/igt@gem_exec_capture@capture-invisi...@smem0.html * igt@gem_exec_capture@capture-recoverable: - shard-tglb: NOTRUN -> [SKIP][18] ([i915#6344]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107930v1/shard-tglb7/igt@gem_exec_capt...@capture-recoverable.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][19] -> [FAIL][20] ([i915#2842]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12048/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107930v1/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace@vcs1: -
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/5] drm/i915/crt: remove BUG_ON()
== Series Details == Series: series starting with [v2,1/5] drm/i915/crt: remove BUG_ON() URL : https://patchwork.freedesktop.org/series/107929/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12048_full -> Patchwork_107929v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_107929v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_107929v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (13 -> 12) -- Missing(1): shard-rkl Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_107929v1_full: ### IGT changes ### Possible regressions * igt@kms_cursor_legacy@single-bo@all-pipes: - shard-apl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12048/shard-apl2/igt@kms_cursor_legacy@single...@all-pipes.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107929v1/shard-apl2/igt@kms_cursor_legacy@single...@all-pipes.html Known issues Here are the changes found in Patchwork_107929v1_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@crc32: - shard-tglb: NOTRUN -> [SKIP][3] ([i915#6230]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107929v1/shard-tglb6/igt@api_intel...@crc32.html * igt@feature_discovery@chamelium: - shard-tglb: NOTRUN -> [SKIP][4] ([fdo#111827]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107929v1/shard-tglb7/igt@feature_discov...@chamelium.html * igt@feature_discovery@display-2x: - shard-tglb: NOTRUN -> [SKIP][5] ([i915#1839]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107929v1/shard-tglb2/igt@feature_discov...@display-2x.html * igt@gem_ccs@ctrl-surf-copy: - shard-tglb: NOTRUN -> [SKIP][6] ([i915#3555] / [i915#5325]) +2 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107929v1/shard-tglb2/igt@gem_...@ctrl-surf-copy.html * igt@gem_ccs@suspend-resume: - shard-tglb: NOTRUN -> [SKIP][7] ([i915#5325]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107929v1/shard-tglb5/igt@gem_...@suspend-resume.html * igt@gem_create@create-ext-cpu-access-sanity-check: - shard-tglb: NOTRUN -> [SKIP][8] ([i915#6335]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107929v1/shard-tglb3/igt@gem_cre...@create-ext-cpu-access-sanity-check.html * igt@gem_create@create-massive: - shard-kbl: NOTRUN -> [DMESG-WARN][9] ([i915#4991]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107929v1/shard-kbl1/igt@gem_cre...@create-massive.html - shard-tglb: NOTRUN -> [DMESG-WARN][10] ([i915#4991]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107929v1/shard-tglb6/igt@gem_cre...@create-massive.html * igt@gem_ctx_param@set-priority-not-supported: - shard-tglb: NOTRUN -> [SKIP][11] ([fdo#109314]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107929v1/shard-tglb7/igt@gem_ctx_pa...@set-priority-not-supported.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: NOTRUN -> [FAIL][12] ([i915#2410]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107929v1/shard-tglb6/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_ctx_sseu@engines: - shard-tglb: NOTRUN -> [SKIP][13] ([i915#280]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107929v1/shard-tglb2/igt@gem_ctx_s...@engines.html * igt@gem_eio@unwedge-stress: - shard-tglb: NOTRUN -> [FAIL][14] ([i915#5784]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107929v1/shard-tglb5/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@parallel-bb-first: - shard-iclb: [PASS][15] -> [SKIP][16] ([i915#4525]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12048/shard-iclb1/igt@gem_exec_balan...@parallel-bb-first.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107929v1/shard-iclb6/igt@gem_exec_balan...@parallel-bb-first.html * igt@gem_exec_balancer@parallel-ordering: - shard-tglb: NOTRUN -> [FAIL][17] ([i915#6117]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107929v1/shard-tglb1/igt@gem_exec_balan...@parallel-ordering.html * igt@gem_exec_capture@capture-invisible@smem0: - shard-tglb: NOTRUN -> [SKIP][18] ([i915#6334]) [18]:
Re: [Intel-gfx] [PATCH] drm/i915/display: clear plane color control register when turn plane off
On Wed, August 31, 2022 8:33 PM, Ville Syrjälä wrote: >On Mon, Aug 01, 2022 at 11:16:16PM +0800, Lee Shawn C wrote: >> Customer report abnormal display output while switch eDP off sometimes. >> In current display disable flow, plane will be off at first. Then turn >> eDP off and disable HW pipe line. We found the abnormal pixel comes >> after turn plane off. Clear plane color ctl register when driver >> disable plane can solve this symptom. >> >> Signed-off-by: Lee Shawn C >> Reviewed-by: Uma Shankar >> --- >> drivers/gpu/drm/i915/display/skl_universal_plane.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c >> b/drivers/gpu/drm/i915/display/skl_universal_plane.c >> index caa03324a733..90977cfb7ebb 100644 >> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c >> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c >> @@ -620,6 +620,8 @@ skl_plane_disable_arm(struct intel_plane *plane, >> >> intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), 0); >> intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id), 0); >> +if (DISPLAY_VER(dev_priv) >= 10) >> +intel_de_write_fw(dev_priv, PLANE_COLOR_CTL(pipe, plane_id), 0); >> } >> >> static void >> @@ -638,6 +640,7 @@ icl_plane_disable_arm(struct intel_plane *plane, >> intel_psr2_disable_plane_sel_fetch(plane, crtc_state); >> intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), 0); >> intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id), 0); >> +intel_de_write_fw(dev_priv, PLANE_COLOR_CTL(pipe, plane_id), 0); > >This makes no sense. The register value shouldn't even get latched since you >wrote the arming register (PLANE_SURF) before this one. > >What platform is the problematic machine? > ADL-P Best regards, Shawn >> } >> >> static bool >> -- >> 2.17.1 > >-- >Ville Syrjälä >Intel
Re: [Intel-gfx] [PATCH 1/3] drm/i915: audit bo->resource usage
On 31/08/2022 13:35, Christian König wrote:
Am 31.08.22 um 14:06 schrieb Matthew Auld:
On 31/08/2022 12:03, Christian König wrote:
Am 31.08.22 um 12:37 schrieb Matthew Auld:
[SNIP]
That hopefully just leaves i915_ttm_shrink(), which is swapping
out shmem ttm_tt and is calling ttm_bo_validate() with empty
placements to force the pipeline-gutting path, which importantly
unpopulates the ttm_tt for us (since ttm_tt_unpopulate is not
exported it seems). But AFAICT it looks like that will now also
nuke the bo->resource, instead of just leaving it in system
memory. My assumption is that when later calling
ttm_bo_validate(), it will just do the bo_move_null() in
i915_ttm_move(), instead of re-populating the ttm_tt and then
potentially copying it back to local-memory?
Well you do ttm_bo_validate() with something like GTT domain, don't
you? This should result in re-populating the tt object, but I'm not
100% sure if that really works as expected.
AFAIK for domains we either have system memory (which uses ttm_tt
and might be shmem underneath) or local-memory. But perhaps i915 is
doing something wrong here, or abusing TTM in some way. I'm not sure
tbh.
Anyway, I think we have two cases here:
- We have some system memory only object. After doing
i915_ttm_shrink(), bo->resource is now NULL. We then call
ttm_bo_validate() at some later point, but here we don't need to
copy anything, but it also looks like ttm_bo_handle_move_mem() won't
populate the ttm_tt or us either, since mem_type == TTM_PL_SYSTEM.
It looks like i915_ttm_move() was taking care of this, but now we
just call ttm_bo_move_null().
- We have a local-memory only object, which was evicted to shmem,
and then swapped out by the shrinker like above. The bo->resource is
NULL. However this time when calling ttm_bo_validate() we need to
actually do a copy in i915_ttm_move(), as well as re-populate the
ttm_tt. i915_ttm_move() was taking care of this, but now we just
call ttm_bo_move_null().
Perhaps i915 is doing something wrong in the above two cases?
Mhm, as far as I can see that should still work.
See previously you should got a transition from SYSTEM->GTT in
i915_ttm_move() to re-create your backing store. Not you get
NULL->SYSTEM which is handled by ttm_bo_move_null() and then
SYSTEM->GTT.
What is GTT here in TTM world? Also I'm not seeing where there is this
SYSTEM->GTT transition? Maybe I'm blind. Just to be clear, i915 is
only calling ttm_bo_validate() once when acquiring the pages, and we
don't call it again, unless it was evicted (and potentially swapped out).
Well GTT means TTM_PL_TT.
And calling it only once is perfectly fine, TTM will internally see that
we need two hops to reach TTM_PL_TT and so does the NULL->SYSTEM
transition and then SYSTEM->TT.
Ah interesting, so that's what the multi-hop thing does. But AFAICT i915
is not using either TTM_PL_TT or -EMULTIHOP.
Also what is the difference between TTM_PL_TT and TM_PL_SYSTEM? When
should you use one over the other?
As far as I can see that should work like it did before.
Christian.
If you just validated to SYSTEM memory before I think the tt object
wouldn't have been populated either.
Regards,
Christian.
Thanks,
Christian.
I've been considering to replacing the ttm_bo_type with a bunch
of behavior flags for a bo. I'm hoping that this will clean
things up a bit.
Regards,
Christian.
caching = i915_ttm_select_tt_caching(obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 9a7e50534b84bb..c420d1ab605b6f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -560,7 +560,7 @@ int i915_ttm_move(struct ttm_buffer_object
*bo, bool evict,
bool clear;
int ret;
- if (GEM_WARN_ON(!obj)) {
+ if (GEM_WARN_ON(!obj) || !bo->resource) {
ttm_bo_move_null(bo, dst_mem);
return 0;
}
Re: [Intel-gfx] [PATCH] drm/i915/display: clear plane color control register when turn plane off
On Mon, Aug 01, 2022 at 11:16:16PM +0800, Lee Shawn C wrote: > Customer report abnormal display output while switch eDP off sometimes. > In current display disable flow, plane will be off at first. Then turn > eDP off and disable HW pipe line. We found the abnormal pixel comes > after turn plane off. Clear plane color ctl register when driver disable > plane can solve this symptom. > > Signed-off-by: Lee Shawn C > Reviewed-by: Uma Shankar > --- > drivers/gpu/drm/i915/display/skl_universal_plane.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c > b/drivers/gpu/drm/i915/display/skl_universal_plane.c > index caa03324a733..90977cfb7ebb 100644 > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c > @@ -620,6 +620,8 @@ skl_plane_disable_arm(struct intel_plane *plane, > > intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), 0); > intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id), 0); > + if (DISPLAY_VER(dev_priv) >= 10) > + intel_de_write_fw(dev_priv, PLANE_COLOR_CTL(pipe, plane_id), 0); > } > > static void > @@ -638,6 +640,7 @@ icl_plane_disable_arm(struct intel_plane *plane, > intel_psr2_disable_plane_sel_fetch(plane, crtc_state); > intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), 0); > intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id), 0); > + intel_de_write_fw(dev_priv, PLANE_COLOR_CTL(pipe, plane_id), 0); This makes no sense. The register value shouldn't even get latched since you wrote the arming register (PLANE_SURF) before this one. What platform is the problematic machine? > } > > static bool > -- > 2.17.1 -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH 1/3] drm/i915: audit bo->resource usage
On 31/08/2022 12:03, Christian König wrote:
Am 31.08.22 um 12:37 schrieb Matthew Auld:
[SNIP]
That hopefully just leaves i915_ttm_shrink(), which is swapping out
shmem ttm_tt and is calling ttm_bo_validate() with empty placements
to force the pipeline-gutting path, which importantly unpopulates
the ttm_tt for us (since ttm_tt_unpopulate is not exported it
seems). But AFAICT it looks like that will now also nuke the
bo->resource, instead of just leaving it in system memory. My
assumption is that when later calling ttm_bo_validate(), it will
just do the bo_move_null() in i915_ttm_move(), instead of
re-populating the ttm_tt and then potentially copying it back to
local-memory?
Well you do ttm_bo_validate() with something like GTT domain, don't
you? This should result in re-populating the tt object, but I'm not
100% sure if that really works as expected.
AFAIK for domains we either have system memory (which uses ttm_tt and
might be shmem underneath) or local-memory. But perhaps i915 is doing
something wrong here, or abusing TTM in some way. I'm not sure tbh.
Anyway, I think we have two cases here:
- We have some system memory only object. After doing
i915_ttm_shrink(), bo->resource is now NULL. We then call
ttm_bo_validate() at some later point, but here we don't need to copy
anything, but it also looks like ttm_bo_handle_move_mem() won't
populate the ttm_tt or us either, since mem_type == TTM_PL_SYSTEM. It
looks like i915_ttm_move() was taking care of this, but now we just
call ttm_bo_move_null().
- We have a local-memory only object, which was evicted to shmem, and
then swapped out by the shrinker like above. The bo->resource is NULL.
However this time when calling ttm_bo_validate() we need to actually
do a copy in i915_ttm_move(), as well as re-populate the ttm_tt.
i915_ttm_move() was taking care of this, but now we just call
ttm_bo_move_null().
Perhaps i915 is doing something wrong in the above two cases?
Mhm, as far as I can see that should still work.
See previously you should got a transition from SYSTEM->GTT in
i915_ttm_move() to re-create your backing store. Not you get
NULL->SYSTEM which is handled by ttm_bo_move_null() and then SYSTEM->GTT.
What is GTT here in TTM world? Also I'm not seeing where there is this
SYSTEM->GTT transition? Maybe I'm blind. Just to be clear, i915 is only
calling ttm_bo_validate() once when acquiring the pages, and we don't
call it again, unless it was evicted (and potentially swapped out).
If you just validated to SYSTEM memory before I think the tt object
wouldn't have been populated either.
Regards,
Christian.
Thanks,
Christian.
I've been considering to replacing the ttm_bo_type with a bunch of
behavior flags for a bo. I'm hoping that this will clean things up
a bit.
Regards,
Christian.
caching = i915_ttm_select_tt_caching(obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 9a7e50534b84bb..c420d1ab605b6f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -560,7 +560,7 @@ int i915_ttm_move(struct ttm_buffer_object
*bo, bool evict,
bool clear;
int ret;
- if (GEM_WARN_ON(!obj)) {
+ if (GEM_WARN_ON(!obj) || !bo->resource) {
ttm_bo_move_null(bo, dst_mem);
return 0;
}
Re: [Intel-gfx] [PATCH] drm/i915/display: Fix warning callstack for imbalance wakeref
On Tue, Aug 30, 2022 at 02:21:58PM +0530, Mitul Golani wrote:
> While executing i915_selftest, wakeref imbalance warning is seen
> with i915_selftest failure.
>
> Currently when Driver is suspended, while doing unregister
> it is taking wakeref without resuming the device.
> This patch is resuming the device, if driver is already suspended
> and doing unregister process.
>
> Signed-off-by: Mitul Golani
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_driver.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index 1332c70370a6..be0d51c04cc5 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -953,7 +953,9 @@ int i915_driver_probe(struct pci_dev *pdev, const struct
> pci_device_id *ent)
>
> void i915_driver_remove(struct drm_i915_private *i915)
> {
> - disable_rpm_wakeref_asserts(>runtime_pm);
> + intel_wakeref_t wakeref;
> +
> + wakeref = intel_runtime_pm_get(>runtime_pm);
>
> i915_driver_unregister(i915);
>
> @@ -977,18 +979,19 @@ void i915_driver_remove(struct drm_i915_private *i915)
>
> i915_driver_hw_remove(i915);
>
> - enable_rpm_wakeref_asserts(>runtime_pm);
> + intel_runtime_pm_put(>runtime_pm, wakeref);
> }
>
> static void i915_driver_release(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_runtime_pm *rpm = _priv->runtime_pm;
> + intel_wakeref_t wakeref;
>
> if (!dev_priv->do_release)
> return;
>
> - disable_rpm_wakeref_asserts(rpm);
> + wakeref = intel_runtime_pm_get(rpm);
>
> i915_gem_driver_release(dev_priv);
>
> @@ -999,7 +1002,8 @@ static void i915_driver_release(struct drm_device *dev)
>
> i915_driver_mmio_release(dev_priv);
>
> - enable_rpm_wakeref_asserts(rpm);
> + intel_runtime_pm_put(rpm, wakeref);
> +
> intel_runtime_pm_driver_release(rpm);
>
> i915_driver_late_release(dev_priv);
> --
> 2.25.1
>
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/bios: Copy the whole MIPI sequence block (rev2)
== Series Details == Series: drm/i915/bios: Copy the whole MIPI sequence block (rev2) URL : https://patchwork.freedesktop.org/series/107896/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12046_full -> Patchwork_107896v2_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_107896v2_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_107896v2_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (13 -> 13) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_107896v2_full: ### IGT changes ### Possible regressions * igt@gem_exec_whisper@basic-queues-forked: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-iclb1/igt@gem_exec_whis...@basic-queues-forked.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107896v2/shard-iclb7/igt@gem_exec_whis...@basic-queues-forked.html Known issues Here are the changes found in Patchwork_107896v2_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-snb: ([PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [FAIL][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27]) ([i915#4338]) -> ([PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb6/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb6/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb6/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb6/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb6/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb6/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb5/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb5/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb5/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb5/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb5/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb5/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb5/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb4/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb4/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb4/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb4/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb4/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb4/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12046/shard-snb4/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107896v2/shard-snb6/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107896v2/shard-snb6/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107896v2/shard-snb6/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107896v2/shard-snb6/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107896v2/shard-snb6/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107896v2/shard-snb6/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107896v2/shard-snb6/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107896v2/shard-snb6/boot.html [36]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: refine eDP power off sequence
== Series Details == Series: drm/i915/display: refine eDP power off sequence URL : https://patchwork.freedesktop.org/series/107965/ State : success == Summary == CI Bug Log - changes from CI_DRM_12052 -> Patchwork_107965v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/index.html Participating hosts (37 -> 34) -- Additional (2): bat-dg2-8 bat-dg1-5 Missing(5): fi-hsw-4200u fi-ctg-p8600 fi-hsw-4770 bat-jsl-3 bat-rpls-2 Known issues Here are the changes found in Patchwork_107965v1 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@read: - bat-dg1-5: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/bat-dg1-5/igt@fb...@read.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][2] ([i915#4083]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#4077]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][4] ([i915#4079]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/bat-dg1-5/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg1-5: NOTRUN -> [SKIP][5] ([i915#1155]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rps@basic-api: - bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#6621]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/bat-dg1-5/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gem: - fi-pnv-d510:NOTRUN -> [DMESG-FAIL][7] ([i915#4528]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/fi-pnv-d510/igt@i915_selftest@l...@gem.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: NOTRUN -> [DMESG-FAIL][8] ([i915#4494] / [i915#4957]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@ring_submission: - fi-cfl-8109u: NOTRUN -> [DMESG-WARN][9] ([i915#5904]) +30 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/fi-cfl-8109u/igt@i915_selftest@live@ring_submission.html * igt@i915_suspend@basic-s2idle-without-i915: - fi-cfl-8109u: NOTRUN -> [DMESG-WARN][10] ([i915#5904] / [i915#62]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/fi-cfl-8109u/igt@i915_susp...@basic-s2idle-without-i915.html - bat-dg1-5: NOTRUN -> [INCOMPLETE][11] ([i915#6011]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/bat-dg1-5/igt@i915_susp...@basic-s2idle-without-i915.html * igt@kms_addfb_basic@basic-x-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][12] ([i915#4212]) +7 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][13] ([i915#4215]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_busy@basic: - bat-dg1-5: NOTRUN -> [SKIP][14] ([i915#1845] / [i915#4303]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/bat-dg1-5/igt@kms_b...@basic.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-cfl-8109u: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/fi-cfl-8109u/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@hdmi-hpd-fast: - bat-dg1-5: NOTRUN -> [SKIP][16] ([fdo#111827]) +7 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/bat-dg1-5/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_force_connector_basic@force-load-detect: - bat-dg1-5: NOTRUN -> [SKIP][17] ([fdo#109285]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107965v1/bat-dg1-5/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_force_connector_basic@prune-stale-modes: - fi-cfl-8109u: [PASS][18] -> [DMESG-WARN][19] ([i915#62]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/fi-cfl-8109u/igt@kms_force_connector_ba...@prune-stale-modes.html [19]:
Re: [Intel-gfx] [PATCH] drm/i915/display: refine eDP power off sequence
On Wed, Aug 31, 2022 at 06:49, Ville Syrjälä wrote:
>On Wed, Aug 31, 2022 at 06:37:24PM +0800, Lee Shawn C wrote:
>> The current eDP disable sequence like this.
>>
>> disable plane > disable backlight (include T9, the delay from
>> backlight disable to end of valid video data) > disalbe
>> transcoder/pipe > disable eDP power
>>
>> Found abnormal pixel output after plane off sometimes.
>> It did not cause any issue but impact user experience.
>> So we modify the eDP disable flow to turn backlight off earlier to
>> avoid abnormal display.
>
>NAK. Planes can be disable at any time by userspace.
>We need to find out what is causing the glitch.
>
Hi Ville, thanks for comment! I uploaded a patch earlier to fix the problem.
https://patchwork.freedesktop.org/patch/496067/
It pass the review by Uma. Unfortunately, the change is not able to pass CI.
With that change, FIFO underrun always be found during CI testing.
Best regards,
Shawn
>>
>> disable backlight > disable plane > disalbe transcoder/pipe
>> > disable eDP power
>>
>> Cc: Shankar Uma
>> Cc: Jani Nikula
>> Signed-off-by: Lee Shawn C
>> ---
>> drivers/gpu/drm/i915/display/intel_display.c | 8 +---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> b/drivers/gpu/drm/i915/display/intel_display.c
>> index 72e2091d9fcb..d08927036350 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -2045,10 +2045,8 @@ static void hsw_crtc_disable(struct
>> intel_atomic_state *state,
>> * FIXME collapse everything to one hook.
>> * Need care with mst->ddi interactions.
>> */
>> -if (!intel_crtc_is_bigjoiner_slave(old_crtc_state)) {
>> -intel_encoders_disable(state, crtc);
>> +if (!intel_crtc_is_bigjoiner_slave(old_crtc_state))
>> intel_encoders_post_disable(state, crtc);
>> -}
>> }
>>
>> static void i9xx_pfit_enable(const struct intel_crtc_state
>> *crtc_state) @@ -7224,6 +7222,10 @@ static void
>> intel_commit_modeset_disables(struct intel_atomic_state *state)
>> continue;
>>
>> intel_pre_plane_update(state, crtc);
>> +
>> +if (!intel_crtc_is_bigjoiner_slave(old_crtc_state))
>> +intel_encoders_disable(state, crtc);
>> +
>> intel_crtc_disable_planes(state, crtc);
>> }
>>
>> --
>> 2.31.1
>
>--
>Ville Syrjälä
>Intel
Re: [Intel-gfx] [PATCH] drm/i915: Allow more varied alternate fixed modes for panels
On Wed, 31 Aug 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On some systems the panel reports alternate modes with
> different blanking periods. If the EDID reports them and VBT
> doesn't tell us otherwise then I can't really see why they
> should be rejected. So allow their use for the purposes of
> static DRRS.
>
> For seamless DRRS we still require a much more exact match
> of course. But that logic only kicks in when selecting the
> downclock mode (or in the future when determining whether
> we can do a seamless refresh rate change due to a user
> modeset).
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6374
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_panel.c | 25 ++
> 1 file changed, 6 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index 237a40623dd7..cb44984bb9a2 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -81,15 +81,14 @@ static bool is_alt_drrs_mode(const struct
> drm_display_mode *mode,
> mode->clock != preferred_mode->clock;
> }
>
> -static bool is_alt_vrr_mode(const struct drm_display_mode *mode,
> - const struct drm_display_mode *preferred_mode)
> +static bool is_alt_fixed_mode(const struct drm_display_mode *mode,
> + const struct drm_display_mode *preferred_mode)
> {
> return drm_mode_match(mode, preferred_mode,
> DRM_MODE_MATCH_FLAGS |
> DRM_MODE_MATCH_3D_FLAGS) &&
> mode->hdisplay == preferred_mode->hdisplay &&
> - mode->vdisplay == preferred_mode->vdisplay &&
> - mode->clock != preferred_mode->clock;
> + mode->vdisplay == preferred_mode->vdisplay;
> }
>
> const struct drm_display_mode *
> @@ -172,19 +171,7 @@ int intel_panel_compute_config(struct intel_connector
> *connector,
> return 0;
> }
>
> -static bool is_alt_fixed_mode(const struct drm_display_mode *mode,
> - const struct drm_display_mode *preferred_mode,
> - bool has_vrr)
> -{
> - /* is_alt_drrs_mode() is a subset of is_alt_vrr_mode() */
> - if (has_vrr)
> - return is_alt_vrr_mode(mode, preferred_mode);
> - else
> - return is_alt_drrs_mode(mode, preferred_mode);
> -}
> -
> -static void intel_panel_add_edid_alt_fixed_modes(struct intel_connector
> *connector,
> - bool has_vrr)
> +static void intel_panel_add_edid_alt_fixed_modes(struct intel_connector
> *connector)
> {
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> const struct drm_display_mode *preferred_mode =
> @@ -192,7 +179,7 @@ static void intel_panel_add_edid_alt_fixed_modes(struct
> intel_connector *connect
> struct drm_display_mode *mode, *next;
>
> list_for_each_entry_safe(mode, next, >base.probed_modes,
> head) {
> - if (!is_alt_fixed_mode(mode, preferred_mode, has_vrr))
> + if (!is_alt_fixed_mode(mode, preferred_mode))
> continue;
>
> drm_dbg_kms(_priv->drm,
> @@ -255,7 +242,7 @@ void intel_panel_add_edid_fixed_modes(struct
> intel_connector *connector,
> {
> intel_panel_add_edid_preferred_mode(connector);
> if (intel_panel_preferred_fixed_mode(connector) && (has_drrs ||
> has_vrr))
> - intel_panel_add_edid_alt_fixed_modes(connector, has_vrr);
> + intel_panel_add_edid_alt_fixed_modes(connector);
> intel_panel_destroy_probed_modes(connector);
> }
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915/display: refine eDP power off sequence
On Wed, Aug 31, 2022 at 06:37:24PM +0800, Lee Shawn C wrote:
> The current eDP disable sequence like this.
>
> disable plane > disable backlight (include T9, the delay
> from backlight disable to end of valid video data) >
> disalbe transcoder/pipe > disable eDP power
>
> Found abnormal pixel output after plane off sometimes.
> It did not cause any issue but impact user experience.
> So we modify the eDP disable flow to turn backlight off
> earlier to avoid abnormal display.
NAK. Planes can be disable at any time by userspace.
We need to find out what is causing the glitch.
>
> disable backlight > disable plane > disalbe transcoder/pipe
> > disable eDP power
>
> Cc: Shankar Uma
> Cc: Jani Nikula
> Signed-off-by: Lee Shawn C
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 72e2091d9fcb..d08927036350 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2045,10 +2045,8 @@ static void hsw_crtc_disable(struct intel_atomic_state
> *state,
>* FIXME collapse everything to one hook.
>* Need care with mst->ddi interactions.
>*/
> - if (!intel_crtc_is_bigjoiner_slave(old_crtc_state)) {
> - intel_encoders_disable(state, crtc);
> + if (!intel_crtc_is_bigjoiner_slave(old_crtc_state))
> intel_encoders_post_disable(state, crtc);
> - }
> }
>
> static void i9xx_pfit_enable(const struct intel_crtc_state *crtc_state)
> @@ -7224,6 +7222,10 @@ static void intel_commit_modeset_disables(struct
> intel_atomic_state *state)
> continue;
>
> intel_pre_plane_update(state, crtc);
> +
> + if (!intel_crtc_is_bigjoiner_slave(old_crtc_state))
> + intel_encoders_disable(state, crtc);
> +
> intel_crtc_disable_planes(state, crtc);
> }
>
> --
> 2.31.1
--
Ville Syrjälä
Intel
[Intel-gfx] [PATCH] drm/i915/display: refine eDP power off sequence
The current eDP disable sequence like this.
disable plane > disable backlight (include T9, the delay
from backlight disable to end of valid video data) >
disalbe transcoder/pipe > disable eDP power
Found abnormal pixel output after plane off sometimes.
It did not cause any issue but impact user experience.
So we modify the eDP disable flow to turn backlight off
earlier to avoid abnormal display.
disable backlight > disable plane > disalbe transcoder/pipe
> disable eDP power
Cc: Shankar Uma
Cc: Jani Nikula
Signed-off-by: Lee Shawn C
---
drivers/gpu/drm/i915/display/intel_display.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 72e2091d9fcb..d08927036350 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2045,10 +2045,8 @@ static void hsw_crtc_disable(struct intel_atomic_state
*state,
* FIXME collapse everything to one hook.
* Need care with mst->ddi interactions.
*/
- if (!intel_crtc_is_bigjoiner_slave(old_crtc_state)) {
- intel_encoders_disable(state, crtc);
+ if (!intel_crtc_is_bigjoiner_slave(old_crtc_state))
intel_encoders_post_disable(state, crtc);
- }
}
static void i9xx_pfit_enable(const struct intel_crtc_state *crtc_state)
@@ -7224,6 +7222,10 @@ static void intel_commit_modeset_disables(struct
intel_atomic_state *state)
continue;
intel_pre_plane_update(state, crtc);
+
+ if (!intel_crtc_is_bigjoiner_slave(old_crtc_state))
+ intel_encoders_disable(state, crtc);
+
intel_crtc_disable_planes(state, crtc);
}
--
2.31.1
Re: [Intel-gfx] [PATCH 1/3] drm/i915: audit bo->resource usage
On 31/08/2022 10:38, Christian König wrote:
Am 31.08.22 um 11:26 schrieb Matthew Auld:
On 31/08/2022 09:16, Christian König wrote:
Hi Matthew,
Am 30.08.22 um 12:45 schrieb Matthew Auld:
Hi,
On 30/08/2022 08:33, Christian König wrote:
Hi guys,
can we get an rb/acked-by for this i915 change?
Basically we are just making sure that the driver doesn't crash
when bo->resource is NULL and a bo doesn't have any backing store
assigned to it.
The Intel CI seems to be happy with this change, so I'm pretty sure
it is correct.
It looks like DG2/DG1 (which happen to use TTM here) are no longer
loading the module:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fintel-gfx-ci.01.org%2Ftree%2Fdrm-tip%2FPatchwork_107680v1%2Findex.htmldata=05%7C01%7Cchristian.koenig%40amd.com%7Ccaca567b3279492450fd08da8b32e598%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637975347967354305%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=apanfOjzSWD2vduINzr2j6F2DiIBC93hLRnnGJcGQ5o%3Dreserved=0?
According to the logs the firmware is failing to load, so perhaps
related to I915_BO_ALLOC_CPU_CLEAR, since that is one of the rare
users. See below.
Thanks,
Christian.
Am 24.08.22 um 16:23 schrieb Luben Tuikov:
From: Christian König
Make sure we can at least move and alloc TT objects without
backing store.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 6 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 2 +-
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index bc9c432edffe03..45ce2d1f754cc4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -271,8 +271,6 @@ static struct ttm_tt
*i915_ttm_tt_create(struct ttm_buffer_object *bo,
{
struct drm_i915_private *i915 = container_of(bo->bdev,
typeof(*i915),
bdev);
- struct ttm_resource_manager *man =
- ttm_manager_type(bo->bdev, bo->resource->mem_type);
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
unsigned long ccs_pages = 0;
enum ttm_caching caching;
@@ -286,8 +284,8 @@ static struct ttm_tt
*i915_ttm_tt_create(struct ttm_buffer_object *bo,
if (!i915_tt)
return NULL;
- if (obj->flags & I915_BO_ALLOC_CPU_CLEAR &&
- man->use_tt)
+ if (obj->flags & I915_BO_ALLOC_CPU_CLEAR && bo->resource &&
+ ttm_manager_type(bo->bdev, bo->resource->mem_type)->use_tt)
page_flags |= TTM_TT_FLAG_ZERO_ALLOC;
AFAICT i915 was massively relying on everything starting out in a
"dummy" system memory resource (ttm_tt), where it then later
"transitions" to the real resource. And if we need to clear the
memory we rely on ZERO_ALLOC being set before calling into the
i915_ttm_move() callback (even when allocating local-memory).
For ttm_bo_type_device objects (userspace stuff) it looks like this
was previously handled by ttm_bo_validate() always doing:
ret = ttm_tt_create(bo, true); /* clear = true */
Which we would always hit since the resource was always "compatible"
for the dummy case. But it looks like this is no longer even called,
since we can now call into ttm_move with bo->resource == NULL, which
still calls tt_create eventually, which not always with clear = true.
All other objects are then ttm_bo_type_kernel so we don't care about
clearing, except in the rare case of ALLOC_CPU_CLEAR, which was
handled as per above in i915_ttm_tt_create(). But I think here
bo->resource is NULL at the start when first creating the object,
which will skip setting ZERO_ALLOC, which might explain the CI failure.
The other possible concern (not sure since CI didn't get that far)
is around ttm_bo_pipeline_gutting(), which now leaves bo->resource =
NULL. It looks like i915_ttm_shrink() was relying on that to
unpopulate the ttm_tt. When later calling ttm_bo_validate(),
i915_ttm_move() would see the SWAPPED flag set on the ttm_tt ,
re-populate it and then potentially move it back to local-memory.
What are your thoughts here? Also sorry if i915 is making a bit of
mess here.
First of all thanks a lot for taking a look. We previously got
reports about strange crashes with this patch, but couldn't really
reproduce them (even not by sending them out again). This explains
that a bit.
The simplest solution would be to just change the && into a ||, e.g.
when previously either no resource is allocated or the resource
requires to use a tt we clear it.
That should give you the same behavior as before, but I agree that
this is a bit messy.
Yeah, that should do the trick.
That hopefully just leaves i915_ttm_shrink(), which is swapping out
shmem ttm_tt and is calling ttm_bo_validate() with empty placements to
force the pipeline-gutting path, which importantly unpopulates the
ttm_tt for us
[Intel-gfx] ✓ Fi.CI.IGT: success for i915: Add "standalone media" support for MTL (rev2)
== Series Details ==
Series: i915: Add "standalone media" support for MTL (rev2)
URL : https://patchwork.freedesktop.org/series/107908/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12044_full -> Patchwork_107908v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (12 -> 13)
--
Additional (1): shard-dg1
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_107908v2_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_flip@flip-vs-expired-vblank@d-hdmi-a1:
- {shard-dg1}:NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v2/shard-dg1-16/igt@kms_flip@flip-vs-expired-vbl...@d-hdmi-a1.html
Known issues
Here are the changes found in Patchwork_107908v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_balancer@parallel:
- shard-iclb: [PASS][2] -> [SKIP][3] ([i915#4525]) +1 similar issue
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-iclb2/igt@gem_exec_balan...@parallel.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v2/shard-iclb6/igt@gem_exec_balan...@parallel.html
* igt@gem_exec_fair@basic-deadline:
- shard-apl: NOTRUN -> [FAIL][4] ([i915#2846])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v2/shard-apl3/igt@gem_exec_f...@basic-deadline.html
* igt@gem_lmem_swapping@parallel-random-verify:
- shard-apl: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +1
similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v2/shard-apl8/igt@gem_lmem_swapp...@parallel-random-verify.html
* igt@i915_selftest@live@hangcheck:
- shard-snb: [PASS][6] -> [INCOMPLETE][7] ([i915#3921])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-snb5/igt@i915_selftest@l...@hangcheck.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v2/shard-snb4/igt@i915_selftest@l...@hangcheck.html
* igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3886]) +7
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v2/shard-apl8/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html
* igt@kms_chamelium@vga-frame-dump:
- shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +3
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v2/shard-apl3/igt@kms_chamel...@vga-frame-dump.html
* igt@kms_flip@flip-vs-suspend-interruptible@b-dp1:
- shard-apl: [PASS][10] -> [DMESG-WARN][11] ([i915#180])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-apl7/igt@kms_flip@flip-vs-suspend-interrupti...@b-dp1.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v2/shard-apl2/igt@kms_flip@flip-vs-suspend-interrupti...@b-dp1.html
*
igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-upscaling@pipe-a-valid-mode:
- shard-iclb: NOTRUN -> [SKIP][12] ([i915#2672]) +6 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v2/shard-iclb5/igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-upscal...@pipe-a-valid-mode.html
*
igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling@pipe-a-default-mode:
- shard-iclb: NOTRUN -> [SKIP][13] ([i915#3555])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v2/shard-iclb2/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscal...@pipe-a-default-mode.html
*
igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilegen12rcccs-upscaling@pipe-a-valid-mode:
- shard-iclb: NOTRUN -> [SKIP][14] ([i915#2672] / [i915#3555])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v2/shard-iclb5/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilegen12rcccs-upscal...@pipe-a-valid-mode.html
* igt@kms_plane_alpha_blend@pipe-a-alpha-transparent-fb:
- shard-apl: NOTRUN -> [FAIL][15] ([i915#265])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v2/shard-apl3/igt@kms_plane_alpha_bl...@pipe-a-alpha-transparent-fb.html
* igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-apl: NOTRUN -> [FAIL][16] ([fdo#108145] / [i915#265]) +1
similar issue
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v2/shard-apl3/igt@kms_plane_alpha_bl...@pipe-b-alpha-basic.html
*
igt@kms_plane_scaling@plane-scaler-with-clipping-clamping-pixel-formats@pipe-b-edp-1:
- shard-iclb: [PASS][17] -> [SKIP][18] ([i915#5176]) +1
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: audit bo->resource usage v2
== Series Details ==
Series: series starting with [1/3] drm/i915: audit bo->resource usage v2
URL : https://patchwork.freedesktop.org/series/107962/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12052 -> Patchwork_107962v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/index.html
Participating hosts (37 -> 35)
--
Additional (1): bat-dg2-8
Missing(3): fi-ctg-p8600 bat-rpls-2 fi-hsw-4200u
Known issues
Here are the changes found in Patchwork_107962v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@load:
- fi-bdw-gvtdvm: [PASS][1] -> [DMESG-WARN][2] ([i915#6540])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/fi-bdw-gvtdvm/igt@i915_module_l...@load.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/fi-bdw-gvtdvm/igt@i915_module_l...@load.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-cfl-8109u: NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/fi-cfl-8109u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-bdw-gvtdvm: [PASS][4] -> [DMESG-WARN][5] ([i915#5922])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/fi-bdw-gvtdvm/igt@kms_force_connector_ba...@force-connector-state.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/fi-bdw-gvtdvm/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-hdmi-a-2:
- fi-bdw-5557u: [PASS][6] -> [INCOMPLETE][7] ([i915#146])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/fi-bdw-5557u/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-hdmi-a-2.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/fi-bdw-5557u/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-hdmi-a-2.html
* igt@runner@aborted:
- fi-bdw-gvtdvm: NOTRUN -> [FAIL][8] ([i915#4312])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/fi-bdw-gvtdvm/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@smem:
- {bat-rplp-1}: [DMESG-WARN][9] ([i915#2867]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@mman:
- fi-rkl-guc: [INCOMPLETE][11] ([i915#6637]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/fi-rkl-guc/igt@i915_selftest@l...@mman.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/fi-rkl-guc/igt@i915_selftest@l...@mman.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u: [DMESG-FAIL][13] ([i915#62]) -> [PASS][14] +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
* igt@prime_vgem@basic-fence-flip:
- fi-cfl-8109u: [DMESG-WARN][15] ([i915#62]) -> [PASS][16] +10
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12052/fi-cfl-8109u/igt@prime_v...@basic-fence-flip.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107962v1/fi-cfl-8109u/igt@prime_v...@basic-fence-flip.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#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
[i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
[i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
Re: [Intel-gfx] [PATCH v3 1/9] dma-buf: Add _unlocked postfix to function names
On Wed, Aug 24, 2022 at 01:22:40PM +0300, Dmitry Osipenko wrote:
> Add _unlocked postfix to the dma-buf API function names in a preparation
> to move all non-dynamic dma-buf users over to the dynamic locking
> specification. This patch only renames API functions, preparing drivers
> to the common locking convention. Later on, we will make the "unlocked"
> functions to take the reservation lock.
>
> Acked-by: Christian König
> Suggested-by: Christian König
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/dma-buf/dma-buf.c | 76 ++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 +-
> drivers/gpu/drm/armada/armada_gem.c | 14 ++--
> drivers/gpu/drm/drm_gem_dma_helper.c | 6 +-
> drivers/gpu/drm/drm_gem_shmem_helper.c| 8 +-
> drivers/gpu/drm/drm_prime.c | 12 +--
> drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 6 +-
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 12 +--
> .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 20 ++---
> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 8 +-
> drivers/gpu/drm/tegra/gem.c | 27 +++
> drivers/infiniband/core/umem_dmabuf.c | 11 +--
> .../common/videobuf2/videobuf2-dma-contig.c | 15 ++--
> .../media/common/videobuf2/videobuf2-dma-sg.c | 12 +--
> .../common/videobuf2/videobuf2-vmalloc.c | 6 +-
> .../platform/nvidia/tegra-vde/dmabuf-cache.c | 12 +--
> drivers/misc/fastrpc.c| 12 +--
> drivers/xen/gntdev-dmabuf.c | 14 ++--
> include/linux/dma-buf.h | 34 +
> 21 files changed, 162 insertions(+), 153 deletions(-)
>
For drivers/media/videobu2:
Acked-by: Tomasz Figa
Best regards,
Tomasz
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 1c912255c5d6..452a6a1f1e60 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -795,7 +795,7 @@ static struct sg_table * __map_dma_buf(struct
> dma_buf_attachment *attach,
> }
>
> /**
> - * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list
> + * dma_buf_dynamic_attach_unlocked - Add the device to dma_buf's attachments
> list
> * @dmabuf: [in]buffer to attach device to.
> * @dev: [in]device to be attached.
> * @importer_ops:[in]importer operations for the attachment
> @@ -817,9 +817,9 @@ static struct sg_table * __map_dma_buf(struct
> dma_buf_attachment *attach,
> * indicated with the error code -EBUSY.
> */
> struct dma_buf_attachment *
> -dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> -const struct dma_buf_attach_ops *importer_ops,
> -void *importer_priv)
> +dma_buf_dynamic_attach_unlocked(struct dma_buf *dmabuf, struct device *dev,
> + const struct dma_buf_attach_ops *importer_ops,
> + void *importer_priv)
> {
> struct dma_buf_attachment *attach;
> int ret;
> @@ -892,25 +892,25 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
> device *dev,
> if (dma_buf_is_dynamic(attach->dmabuf))
> dma_resv_unlock(attach->dmabuf->resv);
>
> - dma_buf_detach(dmabuf, attach);
> + dma_buf_detach_unlocked(dmabuf, attach);
> return ERR_PTR(ret);
> }
> -EXPORT_SYMBOL_NS_GPL(dma_buf_dynamic_attach, DMA_BUF);
> +EXPORT_SYMBOL_NS_GPL(dma_buf_dynamic_attach_unlocked, DMA_BUF);
>
> /**
> - * dma_buf_attach - Wrapper for dma_buf_dynamic_attach
> + * dma_buf_attach_unlocked - Wrapper for dma_buf_dynamic_attach
> * @dmabuf: [in]buffer to attach device to.
> * @dev: [in]device to be attached.
> *
> - * Wrapper to call dma_buf_dynamic_attach() for drivers which still use a
> static
> - * mapping.
> + * Wrapper to call dma_buf_dynamic_attach_unlocked() for drivers which still
> + * use a static mapping.
> */
> -struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> - struct device *dev)
> +struct dma_buf_attachment *dma_buf_attach_unlocked(struct dma_buf *dmabuf,
> +struct device *dev)
> {
> - return dma_buf_dynamic_attach(dmabuf, dev, NULL, NULL);
> + return dma_buf_dynamic_attach_unlocked(dmabuf, dev, NULL, NULL);
> }
> -EXPORT_SYMBOL_NS_GPL(dma_buf_attach, DMA_BUF);
> +EXPORT_SYMBOL_NS_GPL(dma_buf_attach_unlocked, DMA_BUF);
>
> static void __unmap_dma_buf(struct dma_buf_attachment *attach,
> struct sg_table *sg_table,
> @@ -923,7 +923,7 @@ static void __unmap_dma_buf(struct dma_buf_attachment
> *attach,
> }
>
> /**
> - * dma_buf_detach - Remove the given attachment from dmabuf's attachments
> list
> + * dma_buf_detach_unlocked - Remove the given attachment from dmabuf's
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Fix warning callstack for imbalance wakeref (rev6)
== Series Details == Series: drm/i915/display: Fix warning callstack for imbalance wakeref (rev6) URL : https://patchwork.freedesktop.org/series/107211/ State : success == Summary == CI Bug Log - changes from CI_DRM_12044_full -> Patchwork_107211v6_full Summary --- **SUCCESS** No regressions found. Participating hosts (12 -> 12) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_107211v6_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@parallel: - shard-iclb: [PASS][1] -> [SKIP][2] ([i915#4525]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-iclb2/igt@gem_exec_balan...@parallel.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v6/shard-iclb3/igt@gem_exec_balan...@parallel.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][3] ([i915#2846]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v6/shard-apl3/igt@gem_exec_f...@basic-deadline.html * igt@gem_lmem_swapping@basic: - shard-apl: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v6/shard-apl3/igt@gem_lmem_swapp...@basic.html * igt@gem_ppgtt@blt-vs-render-ctx0: - shard-snb: [PASS][5] -> [FAIL][6] ([i915#4998]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-snb4/igt@gem_pp...@blt-vs-render-ctx0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v6/shard-snb6/igt@gem_pp...@blt-vs-render-ctx0.html * igt@gem_render_copy@y-tiled-to-vebox-x-tiled: - shard-apl: NOTRUN -> [SKIP][7] ([fdo#109271]) +56 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v6/shard-apl3/igt@gem_render_c...@y-tiled-to-vebox-x-tiled.html * igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3886]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v6/shard-apl3/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html * igt@kms_chamelium@vga-frame-dump: - shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v6/shard-apl3/igt@kms_chamel...@vga-frame-dump.html * igt@kms_flip@flip-vs-suspend@a-dp1: - shard-apl: [PASS][10] -> [DMESG-WARN][11] ([i915#180]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-apl3/igt@kms_flip@flip-vs-susp...@a-dp1.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v6/shard-apl6/igt@kms_flip@flip-vs-susp...@a-dp1.html * igt@kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-downscaling@pipe-a-default-mode: - shard-iclb: NOTRUN -> [SKIP][12] ([i915#3555]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v6/shard-iclb2/igt@kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-downscal...@pipe-a-default-mode.html * igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-upscaling@pipe-a-valid-mode: - shard-iclb: NOTRUN -> [SKIP][13] ([i915#2672]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v6/shard-iclb8/igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-upscal...@pipe-a-valid-mode.html * igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilegen12rcccs-upscaling@pipe-a-valid-mode: - shard-iclb: NOTRUN -> [SKIP][14] ([i915#2672] / [i915#3555]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v6/shard-iclb6/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilegen12rcccs-upscal...@pipe-a-valid-mode.html * igt@kms_plane_alpha_blend@pipe-a-alpha-transparent-fb: - shard-apl: NOTRUN -> [FAIL][15] ([i915#265]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v6/shard-apl3/igt@kms_plane_alpha_bl...@pipe-a-alpha-transparent-fb.html * igt@kms_plane_alpha_blend@pipe-b-alpha-basic: - shard-apl: NOTRUN -> [FAIL][16] ([fdo#108145] / [i915#265]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v6/shard-apl3/igt@kms_plane_alpha_bl...@pipe-b-alpha-basic.html * igt@kms_psr2_sf@plane-move-sf-dmg-area: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#658]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107211v6/shard-apl3/igt@kms_psr2...@plane-move-sf-dmg-area.html * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: [PASS][18] -> [SKIP][19] ([fdo#109441]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html [19]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915: audit bo->resource usage v2
== Series Details == Series: series starting with [1/3] drm/i915: audit bo->resource usage v2 URL : https://patchwork.freedesktop.org/series/107962/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +drivers/gpu/drm/ttm/ttm_bo.c:1142:20: warning: context imbalance in 'ttm_bo_swapout' - unexpected unlock
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915: audit bo->resource usage v2
== Series Details == Series: series starting with [1/3] drm/i915: audit bo->resource usage v2 URL : https://patchwork.freedesktop.org/series/107962/ State : warning == Summary == Error: dim checkpatch failed 4aa8cb1151d4 drm/i915: audit bo->resource usage v2 -:35: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #35: FILE: drivers/gpu/drm/i915/gem/i915_gem_ttm.c:288: + if (obj->flags & I915_BO_ALLOC_CPU_CLEAR && (!bo->resource || + ttm_manager_type(bo->bdev, bo->resource->mem_type)->use_tt)) -:51: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: "Christian König" ' != 'Signed-off-by: Christian König ' total: 0 errors, 1 warnings, 1 checks, 26 lines checked ddc1bcb53b22 drm/ttm: stop allocating dummy resources during BO creation -:39: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: "Christian König" ' != 'Signed-off-by: Christian König ' total: 0 errors, 1 warnings, 0 checks, 19 lines checked 5fd44c053e24 drm/ttm: stop allocating a dummy resource for pipelined gutting -:75: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: "Christian König" ' != 'Signed-off-by: Christian König ' total: 0 errors, 1 warnings, 0 checks, 52 lines checked
[Intel-gfx] ✓ Fi.CI.IGT: success for Add DP MST DSC support to i915 (rev10)
== Series Details == Series: Add DP MST DSC support to i915 (rev10) URL : https://patchwork.freedesktop.org/series/101492/ State : success == Summary == CI Bug Log - changes from CI_DRM_12044_full -> Patchwork_101492v10_full Summary --- **SUCCESS** No regressions found. Participating hosts (12 -> 12) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_101492v10_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-contexts-1us: - shard-apl: [PASS][1] -> [TIMEOUT][2] ([i915#3063]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-apl2/igt@gem_...@in-flight-contexts-1us.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v10/shard-apl1/igt@gem_...@in-flight-contexts-1us.html * igt@gem_eio@in-flight-contexts-immediate: - shard-iclb: [PASS][3] -> [TIMEOUT][4] ([i915#3070]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-iclb3/igt@gem_...@in-flight-contexts-immediate.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v10/shard-iclb7/igt@gem_...@in-flight-contexts-immediate.html * igt@gem_exec_balancer@parallel: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-iclb2/igt@gem_exec_balan...@parallel.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v10/shard-iclb8/igt@gem_exec_balan...@parallel.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][7] ([i915#2846]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v10/shard-apl7/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-apl: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-apl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v10/shard-apl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_lmem_swapping@parallel-random-verify: - shard-apl: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v10/shard-apl3/igt@gem_lmem_swapp...@parallel-random-verify.html * igt@i915_pm_dc@dc6-dpms: - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#454]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-iclb7/igt@i915_pm...@dc6-dpms.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v10/shard-iclb3/igt@i915_pm...@dc6-dpms.html * igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#3886]) +9 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v10/shard-apl2/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html * igt@kms_chamelium@vga-frame-dump: - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v10/shard-apl7/igt@kms_chamel...@vga-frame-dump.html * igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-upscaling@pipe-a-valid-mode: - shard-iclb: NOTRUN -> [SKIP][15] ([i915#2672]) +8 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v10/shard-iclb5/igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-upscal...@pipe-a-valid-mode.html * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs-downscaling@pipe-a-default-mode: - shard-iclb: NOTRUN -> [SKIP][16] ([i915#2672] / [i915#3555]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v10/shard-iclb2/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs-downscal...@pipe-a-default-mode.html * igt@kms_flip_scaled_crc@flip-64bpp-linear-to-16bpp-linear-downscaling@pipe-a-default-mode: - shard-iclb: NOTRUN -> [SKIP][17] ([i915#3555]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v10/shard-iclb2/igt@kms_flip_scaled_crc@flip-64bpp-linear-to-16bpp-linear-downscal...@pipe-a-default-mode.html * igt@kms_plane_alpha_blend@pipe-a-alpha-transparent-fb: - shard-apl: NOTRUN -> [FAIL][18] ([i915#265]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v10/shard-apl7/igt@kms_plane_alpha_bl...@pipe-a-alpha-transparent-fb.html * igt@kms_plane_alpha_blend@pipe-b-alpha-basic: - shard-apl: NOTRUN -> [FAIL][19] ([fdo#108145] / [i915#265]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v10/shard-apl7/igt@kms_plane_alpha_bl...@pipe-b-alpha-basic.html *
[Intel-gfx] [PATCH 3/3] drm/ttm: stop allocating a dummy resource for pipelined gutting
That should not be necessary any more when drivers should at least be
able to handle a move without a resource.
Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 497ee1fdbad7..a1c4dc031cae 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -607,16 +607,10 @@ EXPORT_SYMBOL(ttm_bo_move_sync_cleanup);
*/
int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
{
- static const struct ttm_place sys_mem = { .mem_type = TTM_PL_SYSTEM };
struct ttm_buffer_object *ghost;
- struct ttm_resource *sys_res;
struct ttm_tt *ttm;
int ret;
- ret = ttm_resource_alloc(bo, _mem, _res);
- if (ret)
- return ret;
-
/* If already idle, no need for ghost object dance. */
ret = ttm_bo_wait(bo, false, true);
if (ret != -EBUSY) {
@@ -624,14 +618,13 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
/* See comment below about clearing. */
ret = ttm_tt_create(bo, true);
if (ret)
- goto error_free_sys_mem;
+ return ret;
} else {
ttm_tt_unpopulate(bo->bdev, bo->ttm);
if (bo->type == ttm_bo_type_device)
ttm_tt_mark_for_clear(bo->ttm);
}
ttm_resource_free(bo, >resource);
- ttm_bo_assign_mem(bo, sys_res);
return 0;
}
@@ -648,7 +641,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
ret = ttm_tt_create(bo, true);
swap(bo->ttm, ttm);
if (ret)
- goto error_free_sys_mem;
+ return ret;
ret = ttm_buffer_object_transfer(bo, );
if (ret)
@@ -662,13 +655,9 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
dma_resv_unlock(>base._resv);
ttm_bo_put(ghost);
bo->ttm = ttm;
- ttm_bo_assign_mem(bo, sys_res);
return 0;
error_destroy_tt:
ttm_tt_destroy(bo->bdev, ttm);
-
-error_free_sys_mem:
- ttm_resource_free(bo, _res);
return ret;
}
--
2.25.1
[Intel-gfx] [PATCH 2/3] drm/ttm: stop allocating dummy resources during BO creation
That should not be necessary any more when drivers should at least be
able to handle the move without a resource.
Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index f066e8124c50..d7ed891d3887 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -959,7 +959,6 @@ int ttm_bo_init_reserved(struct ttm_device *bdev, struct
ttm_buffer_object *bo,
struct sg_table *sg, struct dma_resv *resv,
void (*destroy) (struct ttm_buffer_object *))
{
- static const struct ttm_place sys_mem = { .mem_type = TTM_PL_SYSTEM };
int ret;
kref_init(>kref);
@@ -977,12 +976,6 @@ int ttm_bo_init_reserved(struct ttm_device *bdev, struct
ttm_buffer_object *bo,
bo->base.resv = >base._resv;
atomic_inc(_glob.bo_count);
- ret = ttm_resource_alloc(bo, _mem, >resource);
- if (unlikely(ret)) {
- ttm_bo_put(bo);
- return ret;
- }
-
/*
* For ttm_bo_type_device buffers, allocate
* address space from the device.
--
2.25.1
[Intel-gfx] [PATCH 1/3] drm/i915: audit bo->resource usage v2
Make sure we can at least move and alloc TT objects without backing store.
v2: clear the tt object even when no resource is allocated.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 6 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 2 +-
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index bc9c432edffe..a81063e5aa93 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -271,8 +271,6 @@ static struct ttm_tt *i915_ttm_tt_create(struct
ttm_buffer_object *bo,
{
struct drm_i915_private *i915 = container_of(bo->bdev, typeof(*i915),
bdev);
- struct ttm_resource_manager *man =
- ttm_manager_type(bo->bdev, bo->resource->mem_type);
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
unsigned long ccs_pages = 0;
enum ttm_caching caching;
@@ -286,8 +284,8 @@ static struct ttm_tt *i915_ttm_tt_create(struct
ttm_buffer_object *bo,
if (!i915_tt)
return NULL;
- if (obj->flags & I915_BO_ALLOC_CPU_CLEAR &&
- man->use_tt)
+ if (obj->flags & I915_BO_ALLOC_CPU_CLEAR && (!bo->resource ||
+ ttm_manager_type(bo->bdev, bo->resource->mem_type)->use_tt))
page_flags |= TTM_TT_FLAG_ZERO_ALLOC;
caching = i915_ttm_select_tt_caching(obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 9a7e50534b84..c420d1ab605b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -560,7 +560,7 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
bool clear;
int ret;
- if (GEM_WARN_ON(!obj)) {
+ if (GEM_WARN_ON(!obj) || !bo->resource) {
ttm_bo_move_null(bo, dst_mem);
return 0;
}
--
2.25.1
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: add display sub-struct to drm_i915_private (rev3)
== Series Details == Series: drm/i915: add display sub-struct to drm_i915_private (rev3) URL : https://patchwork.freedesktop.org/series/107170/ State : success == Summary == CI Bug Log - changes from CI_DRM_12044_full -> Patchwork_107170v3_full Summary --- **SUCCESS** No regressions found. Participating hosts (12 -> 12) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_107170v3_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@parallel: - shard-iclb: [PASS][1] -> [SKIP][2] ([i915#4525]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-iclb2/igt@gem_exec_balan...@parallel.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107170v3/shard-iclb7/igt@gem_exec_balan...@parallel.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][3] ([i915#2846]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107170v3/shard-apl8/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-kbl: [PASS][4] -> [FAIL][5] ([i915#2842]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-kbl1/igt@gem_exec_fair@basic-none-s...@rcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107170v3/shard-kbl4/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_lmem_swapping@parallel-random-verify: - shard-apl: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107170v3/shard-apl8/igt@gem_lmem_swapp...@parallel-random-verify.html * igt@gem_userptr_blits@huge-split: - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#3376]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-kbl1/igt@gem_userptr_bl...@huge-split.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107170v3/shard-kbl4/igt@gem_userptr_bl...@huge-split.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][9] -> [FAIL][10] ([i915#454]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-iclb6/igt@i915_pm...@dc6-psr.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107170v3/shard-iclb7/igt@i915_pm...@dc6-psr.html * igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#3886]) +9 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107170v3/shard-apl8/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_rc_ccs_cc: - shard-kbl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#3886]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107170v3/shard-kbl1/igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_rc_ccs_cc.html * igt@kms_chamelium@vga-frame-dump: - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107170v3/shard-apl8/igt@kms_chamel...@vga-frame-dump.html * igt@kms_fbcon_fbt@fbc-suspend: - shard-apl: [PASS][14] -> [FAIL][15] ([i915#4767]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-apl2/igt@kms_fbcon_...@fbc-suspend.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107170v3/shard-apl1/igt@kms_fbcon_...@fbc-suspend.html * igt@kms_flip@flip-vs-expired-vblank@c-dp1: - shard-apl: [PASS][16] -> [FAIL][17] ([i915#79]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-apl8/igt@kms_flip@flip-vs-expired-vbl...@c-dp1.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107170v3/shard-apl7/igt@kms_flip@flip-vs-expired-vbl...@c-dp1.html * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-downscaling@pipe-a-default-mode: - shard-iclb: NOTRUN -> [SKIP][18] ([i915#3555]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107170v3/shard-iclb2/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-downscal...@pipe-a-default-mode.html * igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-16bpp-4tile-upscaling@pipe-a-default-mode: - shard-iclb: NOTRUN -> [SKIP][19] ([i915#2672]) +5 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107170v3/shard-iclb2/igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-16bpp-4tile-upscal...@pipe-a-default-mode.html * igt@kms_plane_alpha_blend@pipe-a-alpha-transparent-fb: - shard-apl: NOTRUN -> [FAIL][20] ([i915#265]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107170v3/shard-apl8/igt@kms_plane_alpha_bl...@pipe-a-alpha-transparent-fb.html * igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
Re: [Intel-gfx] [PATCH 1/3] drm/i915: audit bo->resource usage
On 31/08/2022 09:16, Christian König wrote:
Hi Matthew,
Am 30.08.22 um 12:45 schrieb Matthew Auld:
Hi,
On 30/08/2022 08:33, Christian König wrote:
Hi guys,
can we get an rb/acked-by for this i915 change?
Basically we are just making sure that the driver doesn't crash when
bo->resource is NULL and a bo doesn't have any backing store assigned
to it.
The Intel CI seems to be happy with this change, so I'm pretty sure
it is correct.
It looks like DG2/DG1 (which happen to use TTM here) are no longer
loading the module:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fintel-gfx-ci.01.org%2Ftree%2Fdrm-tip%2FPatchwork_107680v1%2Findex.htmldata=05%7C01%7Cchristian.koenig%40amd.com%7Caa9bdb0e31064859568708da8a74b899%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637974531164663116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=UW8BEnIFXHawhAfLUcknGmE88g2wwAiTLAQ3Y5v1pFA%3Dreserved=0?
According to the logs the firmware is failing to load, so perhaps
related to I915_BO_ALLOC_CPU_CLEAR, since that is one of the rare
users. See below.
Thanks,
Christian.
Am 24.08.22 um 16:23 schrieb Luben Tuikov:
From: Christian König
Make sure we can at least move and alloc TT objects without backing
store.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 6 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 2 +-
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index bc9c432edffe03..45ce2d1f754cc4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -271,8 +271,6 @@ static struct ttm_tt *i915_ttm_tt_create(struct
ttm_buffer_object *bo,
{
struct drm_i915_private *i915 = container_of(bo->bdev,
typeof(*i915),
bdev);
- struct ttm_resource_manager *man =
- ttm_manager_type(bo->bdev, bo->resource->mem_type);
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
unsigned long ccs_pages = 0;
enum ttm_caching caching;
@@ -286,8 +284,8 @@ static struct ttm_tt *i915_ttm_tt_create(struct
ttm_buffer_object *bo,
if (!i915_tt)
return NULL;
- if (obj->flags & I915_BO_ALLOC_CPU_CLEAR &&
- man->use_tt)
+ if (obj->flags & I915_BO_ALLOC_CPU_CLEAR && bo->resource &&
+ ttm_manager_type(bo->bdev, bo->resource->mem_type)->use_tt)
page_flags |= TTM_TT_FLAG_ZERO_ALLOC;
AFAICT i915 was massively relying on everything starting out in a
"dummy" system memory resource (ttm_tt), where it then later
"transitions" to the real resource. And if we need to clear the memory
we rely on ZERO_ALLOC being set before calling into the
i915_ttm_move() callback (even when allocating local-memory).
For ttm_bo_type_device objects (userspace stuff) it looks like this
was previously handled by ttm_bo_validate() always doing:
ret = ttm_tt_create(bo, true); /* clear = true */
Which we would always hit since the resource was always "compatible"
for the dummy case. But it looks like this is no longer even called,
since we can now call into ttm_move with bo->resource == NULL, which
still calls tt_create eventually, which not always with clear = true.
All other objects are then ttm_bo_type_kernel so we don't care about
clearing, except in the rare case of ALLOC_CPU_CLEAR, which was
handled as per above in i915_ttm_tt_create(). But I think here
bo->resource is NULL at the start when first creating the object,
which will skip setting ZERO_ALLOC, which might explain the CI failure.
The other possible concern (not sure since CI didn't get that far) is
around ttm_bo_pipeline_gutting(), which now leaves bo->resource =
NULL. It looks like i915_ttm_shrink() was relying on that to
unpopulate the ttm_tt. When later calling ttm_bo_validate(),
i915_ttm_move() would see the SWAPPED flag set on the ttm_tt ,
re-populate it and then potentially move it back to local-memory.
What are your thoughts here? Also sorry if i915 is making a bit of
mess here.
First of all thanks a lot for taking a look. We previously got reports
about strange crashes with this patch, but couldn't really reproduce
them (even not by sending them out again). This explains that a bit.
The simplest solution would be to just change the && into a ||, e.g.
when previously either no resource is allocated or the resource requires
to use a tt we clear it.
That should give you the same behavior as before, but I agree that this
is a bit messy.
Yeah, that should do the trick.
That hopefully just leaves i915_ttm_shrink(), which is swapping out
shmem ttm_tt and is calling ttm_bo_validate() with empty placements to
force the pipeline-gutting path, which importantly unpopulates the
ttm_tt for us (since ttm_tt_unpopulate is not exported it seems). But
AFAICT it looks like that will now
[Intel-gfx] ✓ Fi.CI.IGT: success for Move all drivers to a common dma-buf locking convention
== Series Details == Series: Move all drivers to a common dma-buf locking convention URL : https://patchwork.freedesktop.org/series/107884/ State : success == Summary == CI Bug Log - changes from CI_DRM_12044_full -> Patchwork_107884v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (12 -> 12) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_107884v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fair@basic-deadline: - shard-kbl: [PASS][1] -> [FAIL][2] ([i915#2846]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-kbl4/igt@gem_exec_f...@basic-deadline.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107884v1/shard-kbl4/igt@gem_exec_f...@basic-deadline.html - shard-apl: NOTRUN -> [FAIL][3] ([i915#2846]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107884v1/shard-apl7/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-kbl: [PASS][4] -> [SKIP][5] ([fdo#109271]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-kbl7/igt@gem_exec_fair@basic-none-sh...@rcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107884v1/shard-kbl1/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][6] -> [FAIL][7] ([i915#2842]) +3 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107884v1/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_lmem_swapping@parallel-random-verify: - shard-apl: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107884v1/shard-apl7/igt@gem_lmem_swapp...@parallel-random-verify.html * igt@gem_userptr_blits@create-destroy-unsync: - shard-kbl: NOTRUN -> [SKIP][9] ([fdo#109271]) +49 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107884v1/shard-kbl1/igt@gem_userptr_bl...@create-destroy-unsync.html * igt@gem_workarounds@suspend-resume: - shard-apl: [PASS][10] -> [DMESG-WARN][11] ([i915#180]) +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-apl1/igt@gem_workarou...@suspend-resume.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107884v1/shard-apl6/igt@gem_workarou...@suspend-resume.html * igt@i915_pm_dc@dc6-dpms: - shard-iclb: [PASS][12] -> [FAIL][13] ([i915#454]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-iclb7/igt@i915_pm...@dc6-dpms.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107884v1/shard-iclb3/igt@i915_pm...@dc6-dpms.html * igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#3886]) +7 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107884v1/shard-apl7/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_rc_ccs_cc: - shard-kbl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#3886]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107884v1/shard-kbl1/igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_rc_ccs_cc.html * igt@kms_chamelium@dp-frame-dump: - shard-kbl: NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107884v1/shard-kbl1/igt@kms_chamel...@dp-frame-dump.html * igt@kms_chamelium@vga-frame-dump: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107884v1/shard-apl7/igt@kms_chamel...@vga-frame-dump.html * igt@kms_flip@flip-vs-suspend@a-dp1: - shard-kbl: [PASS][18] -> [DMESG-WARN][19] ([i915#180]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-kbl1/igt@kms_flip@flip-vs-susp...@a-dp1.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107884v1/shard-kbl7/igt@kms_flip@flip-vs-susp...@a-dp1.html * igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-upscaling@pipe-a-valid-mode: - shard-iclb: NOTRUN -> [SKIP][20] ([i915#2672]) +6 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107884v1/shard-iclb6/igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-upscal...@pipe-a-valid-mode.html * igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilegen12rcccs-upscaling@pipe-a-valid-mode: -
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: fix repeated words in comments (rev3)
== Series Details == Series: drm/i915: fix repeated words in comments (rev3) URL : https://patchwork.freedesktop.org/series/107885/ State : success == Summary == CI Bug Log - changes from CI_DRM_12044_full -> Patchwork_107885v3_full Summary --- **SUCCESS** No regressions found. Participating hosts (12 -> 13) -- Additional (1): shard-dg1 Known issues Here are the changes found in Patchwork_107885v3_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-contexts-immediate: - shard-apl: [PASS][1] -> [TIMEOUT][2] ([i915#3063]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-apl6/igt@gem_...@in-flight-contexts-immediate.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107885v3/shard-apl6/igt@gem_...@in-flight-contexts-immediate.html * igt@gem_exec_balancer@parallel: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#4525]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-iclb2/igt@gem_exec_balan...@parallel.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107885v3/shard-iclb6/igt@gem_exec_balan...@parallel.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: [PASS][5] -> [FAIL][6] ([i915#2846]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-kbl4/igt@gem_exec_f...@basic-deadline.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107885v3/shard-kbl1/igt@gem_exec_f...@basic-deadline.html - shard-apl: NOTRUN -> [FAIL][7] ([i915#2846]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107885v3/shard-apl6/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2842]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107885v3/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_lmem_swapping@parallel-random-verify: - shard-apl: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107885v3/shard-apl6/igt@gem_lmem_swapp...@parallel-random-verify.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: NOTRUN -> [DMESG-WARN][11] ([i915#180]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107885v3/shard-apl2/igt@gem_workarou...@suspend-resume-context.html * igt@i915_pm_dc@dc6-dpms: - shard-iclb: [PASS][12] -> [FAIL][13] ([i915#454]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-iclb7/igt@i915_pm...@dc6-dpms.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107885v3/shard-iclb3/igt@i915_pm...@dc6-dpms.html * igt@i915_suspend@debugfs-reader: - shard-apl: [PASS][14] -> [DMESG-WARN][15] ([i915#180]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-apl8/igt@i915_susp...@debugfs-reader.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107885v3/shard-apl8/igt@i915_susp...@debugfs-reader.html * igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3886]) +6 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107885v3/shard-apl6/igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-c-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc: - shard-kbl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3886]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107885v3/shard-kbl4/igt@kms_ccs@pipe-c-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html * igt@kms_chamelium@hdmi-mode-timings: - shard-kbl: NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) +2 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107885v3/shard-kbl4/igt@kms_chamel...@hdmi-mode-timings.html * igt@kms_chamelium@vga-frame-dump: - shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107885v3/shard-apl6/igt@kms_chamel...@vga-frame-dump.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-kbl: NOTRUN -> [SKIP][20] ([fdo#109271]) +49 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107885v3/shard-kbl1/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html * igt@kms_fbcon_fbt@fbc-suspend: - shard-apl: [PASS][21] -> [INCOMPLETE][22] ([i915#180] / [i915#1982] / [i915#4939] / [i915#6598]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-apl2/igt@kms_fbcon_...@fbc-suspend.html
[Intel-gfx] ✓ Fi.CI.IGT: success for i915/display: fix repeated words in comments
== Series Details == Series: i915/display: fix repeated words in comments URL : https://patchwork.freedesktop.org/series/107887/ State : success == Summary == CI Bug Log - changes from CI_DRM_12044_full -> Patchwork_107887v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (12 -> 12) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_107887v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@close-race: - shard-snb: [PASS][1] -> [TIMEOUT][2] ([i915#5748]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-snb4/igt@gem_b...@close-race.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107887v1/shard-snb5/igt@gem_b...@close-race.html * igt@gem_exec_balancer@parallel: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#4525]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-iclb2/igt@gem_exec_balan...@parallel.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107887v1/shard-iclb6/igt@gem_exec_balan...@parallel.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: [PASS][5] -> [FAIL][6] ([i915#2846]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-kbl4/igt@gem_exec_f...@basic-deadline.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107887v1/shard-kbl4/igt@gem_exec_f...@basic-deadline.html - shard-apl: NOTRUN -> [FAIL][7] ([i915#2846]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107887v1/shard-apl6/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2842]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107887v1/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_lmem_swapping@parallel-random-verify: - shard-apl: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107887v1/shard-apl6/igt@gem_lmem_swapp...@parallel-random-verify.html * igt@i915_suspend@fence-restore-untiled: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-kbl1/igt@i915_susp...@fence-restore-untiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107887v1/shard-kbl7/igt@i915_susp...@fence-restore-untiled.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-apl2/igt@i915_susp...@sysfs-reader.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107887v1/shard-apl3/igt@i915_susp...@sysfs-reader.html * igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_rc_ccs_cc: - shard-kbl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#3886]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107887v1/shard-kbl4/igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_rc_ccs_cc.html * igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3886]) +5 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107887v1/shard-apl6/igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs.html * igt@kms_chamelium@dp-frame-dump: - shard-kbl: NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107887v1/shard-kbl1/igt@kms_chamel...@dp-frame-dump.html * igt@kms_chamelium@vga-frame-dump: - shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107887v1/shard-apl6/igt@kms_chamel...@vga-frame-dump.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-dp1: - shard-kbl: [PASS][19] -> [FAIL][20] ([i915#79]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-kbl1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-dp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107887v1/shard-kbl7/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-dp1.html * igt@kms_flip_scaled_crc@flip-32bpp-4tile-to-64bpp-4tile-upscaling@pipe-a-valid-mode: - shard-kbl: NOTRUN -> [SKIP][21] ([fdo#109271]) +17 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107887v1/shard-kbl1/igt@kms_flip_scaled_crc@flip-32bpp-4tile-to-64bpp-4tile-upscal...@pipe-a-valid-mode.html *
[Intel-gfx] ✓ Fi.CI.IGT: success for i915/gvt: fix repeated words in comments
== Series Details == Series: i915/gvt: fix repeated words in comments URL : https://patchwork.freedesktop.org/series/107883/ State : success == Summary == CI Bug Log - changes from CI_DRM_12044_full -> Patchwork_107883v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (12 -> 13) -- Additional (1): shard-dg1 Known issues Here are the changes found in Patchwork_107883v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-glk: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [FAIL][21], [FAIL][22], [PASS][23], [PASS][24], [PASS][25]) ([i915#4392]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk8/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk9/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk9/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk9/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk8/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk8/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk7/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk3/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk3/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk3/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk2/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk2/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk1/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk1/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12044/shard-glk1/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107883v1/shard-glk8/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107883v1/shard-glk1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107883v1/shard-glk1/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107883v1/shard-glk1/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107883v1/shard-glk2/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107883v1/shard-glk2/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107883v1/shard-glk2/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107883v1/shard-glk2/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107883v1/shard-glk3/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107883v1/shard-glk3/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107883v1/shard-glk5/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107883v1/shard-glk5/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107883v1/shard-glk6/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107883v1/shard-glk9/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107883v1/shard-glk6/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107883v1/shard-glk9/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107883v1/shard-glk6/boot.html [43]:
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Hi Mateusz,
On Wed, Aug 31, 2022 at 3:44 AM Mateusz Kwiatkowski wrote:
> Wow. That's an enormous amount of effort put into this patch.
>
> But I'm tempted to say that this is actually overengineered quite a bit :D
> Considering that there's no way to access all these calculations from user
> space, and I can't imagine anybody using anything else than those standard
> 480i/576i (and maybe 240p/288p) modes at 13.5 MHz any time soon... I'm not
> sure if we actually need all this.
We'll need it when we get an Amiga DRM driver, which will use
7/14/28 MHz pixel clocks.
> But anyway, I'm not the maintainer of this subsystem, so I'm not the one to
> decide.
>
> > +enum drm_mode_analog {
> > +DRM_MODE_ANALOG_NTSC,
> > +DRM_MODE_ANALOG_PAL,
> > +};
>
> Using "NTSC" and "PAL" to describe the 50Hz and 60Hz analog TV modes is
> common,
> but strictly speaking a misnomer. Those are color encoding systems, and your
> patchset fully supports lesser used, but standard encodings for those (e.g.
> PAL-M for 60Hz and SECAM for 50Hz). I'd propose switching to some more neutral
> naming scheme. Some ideas:
>
> - DRM_MODE_ANALOG_60_HZ / DRM_MODE_ANALOG_50_HZ (after standard refresh rate)
> - DRM_MODE_ANALOG_525_LINES / DRM_MODE_ANALOG_625_LINES (after standard line
> count)
IMHO these are bad names, as e.g. VGA640x480@60 is also analog, using
60 Hz and 525 lines. Add "TV" to the name?
> - DRM_MODE_ANALOG_JM / DRM_MODE_ANALOG_BDGHIKLN (after corresponding ITU
> System
> Letter Designations)
Or DRM_MODE_ITU_*?
But given the long list of letters, this looks fragile to me.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [Intel-gfx] [RFC PATCH v3 10/17] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl
On 27/08/2022 20:43, Andi Shyti wrote:
From: Niranjana Vishwanathapura
Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.
The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects binding would have been requested by the
userspace before submitting the execbuf3.
And the legacy support like relocations etc are removed.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/Makefile |1 +
.../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 1000 +
drivers/gpu/drm/i915/gem/i915_gem_ioctls.h|2 +
include/uapi/drm/i915_drm.h | 62 +
4 files changed, 1065 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4e1627e96c6e0..38cd1c5bc1a55 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -148,6 +148,7 @@ gem-y += \
gem/i915_gem_dmabuf.o \
gem/i915_gem_domain.o \
gem/i915_gem_execbuffer.o \
+ gem/i915_gem_execbuffer3.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
gem/i915_gem_lmem.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
new file mode 100644
index 0..a3d767cd9f808
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -0,0 +1,1000 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include
+
+#include "gt/intel_context.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_gt_pm.h"
+#include "gt/intel_ring.h"
+
+#include "i915_drv.h"
+#include "i915_file_private.h"
+#include "i915_gem_context.h"
+#include "i915_gem_ioctls.h"
+#include "i915_gem_vm_bind.h"
+#include "i915_trace.h"
+
+#define __EXEC3_ENGINE_PINNED BIT_ULL(32)
+#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
+
+/* Catch emission of unexpected errors for CI! */
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+#undef EINVAL
+#define EINVAL ({ \
+ DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__, __LINE__); \
+ 22; \
+})
+#endif
+
+/**
+ * DOC: User command execution with execbuf3 ioctl
+ *
+ * A VM in VM_BIND mode will not support older execbuf mode of binding.
+ * The execbuf ioctl handling in VM_BIND mode differs significantly from the
+ * older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
+ * Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
+ * struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
+ * execlist. Hence, no support for implicit sync.
+ *
+ * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
+ * works with execbuf3 ioctl for submission.
+ *
+ * The execbuf3 ioctl directly specifies the batch addresses instead of as
+ * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
+ * support many of the older features like in/out/submit fences, fence array,
+ * default gem context etc. (See struct drm_i915_gem_execbuffer3).
+ *
+ * In VM_BIND mode, VA allocation is completely managed by the user instead of
+ * the i915 driver. Hence all VA assignment, eviction are not applicable in
+ * VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
+ * be using the i915_vma active reference tracking. It will instead check the
+ * dma-resv object's fence list for that.
+ *
+ * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
+ * vma lookup table, implicit sync, vma active reference tracking etc., are not
+ * applicable for execbuf3 ioctl.
+ */
+
+struct eb_fence {
+ struct drm_syncobj *syncobj;
+ struct dma_fence *dma_fence;
+ u64 value;
+ struct dma_fence_chain *chain_fence;
+};
+
+/**
+ * struct i915_execbuffer - execbuf struct for execbuf3
+ * @i915: reference to the i915 instance we run on
+ * @file: drm file reference
+ * args: execbuf3 ioctl structure
+ * @gt: reference to the gt instance ioctl submitted for
+ * @context: logical state for the request
+ * @gem_context: callers context
+ * @requests: requests to be build
+ * @composite_fence: used for excl fence in dma_resv objects when > 1 BB
submitted
+ * @ww: i915_gem_ww_ctx instance
+ * @num_batches: number of batches submitted
+ * @batch_addresses: addresses corresponds to the submitted batches
+ * @batches: references to the i915_vmas corresponding to the batches
+ */
+struct i915_execbuffer {
+ struct drm_i915_private *i915;
+ struct drm_file *file;
+ struct drm_i915_gem_execbuffer3 *args;
+
+ struct intel_gt *gt;
+ struct intel_context *context;
+ struct i915_gem_context *gem_context;
+
+
Re: [Intel-gfx] [RFC PATCH v3 00/17] drm/i915/vm_bind: Add VM_BIND functionality
On 27/08/2022 20:43, Andi Shyti wrote: Hi, just sending the original Niranjana's patch as an RFC. It's v3 as the v2 has been reviewed offline with Ramalingam. I'm still keeping most of the structure even though some further discussion can be done starting from here. Copy pasting Niranjana's original cover letter message: DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer objects (BOs) or sections of a BOs at specified GPU virtual addresses on a specified address space (VM). Multiple mappings can map to the same physical pages of an object (aliasing). These mappings (also referred to as persistent mappings) will be persistent across multiple GPU submissions (execbuf calls) issued by the UMD, without user having to provide a list of all required mappings during each submission (as required by older execbuf mode). This patch series support VM_BIND version 1, as described by the param I915_PARAM_VM_BIND_VERSION. Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only works in vm_bind mode. The vm_bind mode only works with this new execbuf3 ioctl. The new execbuf3 ioctl will not have any execlist support and all the legacy support like relocations etc., are removed. We should consider not overloading the term execlists when really talking about the array of struct gem_exec_object2. Before it gets too confusing. At least I assume that's what it is meant and eb3 is not intended to be used only with the GuC. Alternatively, correct me if I am wrong that the term is somehow already established and I did not realise. Regards, Tvrtko
Re: [Intel-gfx] [RFC PATCH v3 04/17] drm/i915: Implement bind and unbind of object
On 30/08/2022 19:19, Matthew Auld wrote:
On 27/08/2022 20:43, Andi Shyti wrote:
From: Niranjana Vishwanathapura
Implement the bind and unbind of an object at the specified GPU virtual
addresses.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
[snip]
+static struct i915_vma *vm_bind_get_vma(struct i915_address_space *vm,
+ struct drm_i915_gem_object *obj,
+ struct drm_i915_gem_vm_bind *va)
+{
+ struct i915_ggtt_view view;
Should that be renamed to i915_gtt_view? So all of this just works with
ppgtt insertion, as-is? I'm impressed.
Yes please, do refactor first in the series. It is my standing request
since January 2021. See
ab307584-d97b-4fcf-7d4e-4d7de2d94...@linux.intel.com from a ~month ago.
Regards,
Tvrtko
[Intel-gfx] ✓ Fi.CI.BAT: success for Tidy up vfio_device life cycle (rev2)
== Series Details ==
Series: Tidy up vfio_device life cycle (rev2)
URL : https://patchwork.freedesktop.org/series/107838/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12051 -> Patchwork_107838v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107838v2/index.html
Participating hosts (36 -> 32)
--
Missing(4): fi-adl-ddr5 fi-ctg-p8600 fi-bdw-samus fi-hsw-4200u
Known issues
Here are the changes found in Patchwork_107838v2 that come from known issues:
### IGT changes ###
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6380]: https://gitlab.freedesktop.org/drm/intel/issues/6380
Build changes
-
* Linux: CI_DRM_12051 -> Patchwork_107838v2
CI-20190529: 20190529
CI_DRM_12051: 87e7c1f925771561efe162f261251ed72b095007 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6638: 9338ab3ec085292817ab1e74d1f2fb90b6a98332 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_107838v2: 87e7c1f925771561efe162f261251ed72b095007 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
bd91582b60f8 vfio: Add struct device to vfio_device
f8270bcb436e vfio: Rename vfio_device_put() and vfio_device_try_get()
3d1532d2295c vfio/ccw: Use the new device life cycle helpers
0cc7ad404d2c vfio/amba: Use the new device life cycle helpers
1f0568824155 vfio/platform: Use the new device life cycle helpers
0d2c0ac46cc9 vfio/fsl-mc: Use the new device life cycle helpers
5c25744ecc67 vfio/ap: Use the new device life cycle helpers
2526a89e122c drm/i915/gvt: Use the new device life cycle helpers
5acd97dfcc3e vfio/mbochs: Use the new device life cycle helpers
5053ba759ea8 vfio/mtty: Use the new device life cycle helpers
3d9553a48c1f vfio/mdpy: Use the new device life cycle helpers
dcb1a8c8f3e1 vfio/hisi_acc: Use the new device life cycle helpers
66863015b8e7 vfio/mlx5: Use the new device life cycle helpers
7678baf87812 vfio/pci: Use the new device life cycle helpers
d484641676f8 vfio: Add helpers for unifying vfio_device life cycle
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107838v2/index.html
Re: [Intel-gfx] [RFC PATCH v3 13/17] drm/i915/vm_bind: userptr dma-resv changes
On Sat, Aug 27, 2022 at 09:43:59PM +0200, Andi Shyti wrote:
From: Niranjana Vishwanathapura
For persistent (vm_bind) vmas of userptr BOs, handle the user
page pinning by using the i915_gem_object_userptr_submit_init()
/done() functions
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
.../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 139 ++
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 10 ++
.../drm/i915/gem/i915_gem_vm_bind_object.c| 16 ++
drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 4 +
drivers/gpu/drm/i915/i915_vma_types.h | 2 +
6 files changed, 142 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
index 8e0dde26194e0..72d6771da2113 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -23,6 +23,7 @@
#include "i915_gem_vm_bind.h"
#include "i915_trace.h"
+#define __EXEC3_USERPTR_USED BIT_ULL(34)
#define __EXEC3_HAS_PIN BIT_ULL(33)
#define __EXEC3_ENGINE_PINNED BIT_ULL(32)
#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
@@ -157,10 +158,45 @@ static void eb_scoop_unbound_vma_all(struct
i915_address_space *vm)
spin_unlock(>vm_rebind_lock);
}
+static int eb_lookup_persistent_userptr_vmas(struct i915_execbuffer *eb)
+{
+ struct i915_address_space *vm = eb->context->vm;
+ struct i915_vma *last_vma = NULL;
+ struct i915_vma *vma;
+ int err;
+
+ lockdep_assert_held(>vm_bind_lock);
+
+ list_for_each_entry(vma, >vm_userptr_invalidated_list,
+ vm_userptr_invalidated_link) {
+ list_del_init(>vm_userptr_invalidated_link);
+ err = i915_gem_object_userptr_submit_init(vma->obj);
+ if (err)
+ return err;
+
+ last_vma = vma;
+ }
This should be done under the list lock. As it is a spinlock, we
should scoop them first under that spinlock and call submit_init()
outside that lock.
+
+ list_for_each_entry(vma, >vm_bind_list, vm_bind_link)
+ if (i915_gem_object_is_userptr(vma->obj)) {
+ err = i915_gem_object_userptr_submit_init(vma->obj);
+ if (err)
+ return err;
+
+ last_vma = vma;
+ }
+
+ if (last_vma)
+ eb->args->flags |= __EXEC3_USERPTR_USED;
+
+ return 0;
+}
+
static int eb_lookup_vma_all(struct i915_execbuffer *eb)
{
unsigned int i, current_batch = 0;
struct i915_vma *vma;
+ int err = 0;
for (i = 0; i < eb->num_batches; i++) {
vma = eb_find_vma(eb->context->vm, eb->batch_addresses[i]);
@@ -171,6 +207,10 @@ static int eb_lookup_vma_all(struct i915_execbuffer *eb)
++current_batch;
}
+ err = eb_lookup_persistent_userptr_vmas(eb);
+ if (err)
+ return err;
+
eb_scoop_unbound_vma_all(eb->context->vm);
return 0;
@@ -286,33 +326,6 @@ static int eb_validate_persistent_vma_all(struct
i915_execbuffer *eb)
return ret;
}
-static int eb_validate_vma_all(struct i915_execbuffer *eb)
-{
- /* only throttle once, even if we didn't need to throttle */
- for (bool throttle = true;; throttle = false) {
- int err;
-
- err = eb_pin_engine(eb, throttle);
- if (!err)
- err = eb_lock_vma_all(eb);
-
- if (!err)
- err = eb_validate_persistent_vma_all(eb);
-
- if (!err)
- return 0;
-
- if (err != -EDEADLK)
- return err;
-
- err = i915_gem_ww_ctx_backoff(>ww);
- if (err)
- return err;
- }
-
- return 0;
-}
-
/*
* Using two helper loops for the order of which requests / batches are created
* and added the to backend. Requests are created in order from the parent to
@@ -360,15 +373,51 @@ static void eb_move_all_persistent_vma_to_active(struct
i915_execbuffer *eb)
static int eb_move_to_gpu(struct i915_execbuffer *eb)
{
+ int err = 0, j;
+
lockdep_assert_held(>context->vm->vm_bind_lock);
assert_object_held(eb->context->vm->root_obj);
eb_move_all_persistent_vma_to_active(eb);
- /* Unconditionally flush any chipset caches (for streaming writes). */
- intel_gt_chipset_flush(eb->gt);
+#ifdef CONFIG_MMU_NOTIFIER
+ if (!err && (eb->args->flags & __EXEC3_USERPTR_USED)) {
+ struct i915_vma *vma;
- return 0;
+ lockdep_assert_held(>context->vm->vm_bind_lock);
+ assert_object_held(eb->context->vm->root_obj);
+
+
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Tidy up vfio_device life cycle (rev2)
== Series Details == Series: Tidy up vfio_device life cycle (rev2) URL : https://patchwork.freedesktop.org/series/107838/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Tidy up vfio_device life cycle (rev2)
== Series Details ==
Series: Tidy up vfio_device life cycle (rev2)
URL : https://patchwork.freedesktop.org/series/107838/
State : warning
== Summary ==
Error: dim checkpatch failed
405257a130f0 vfio: Add helpers for unifying vfio_device life cycle
-:69: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#69: FILE: drivers/vfio/vfio_main.c:512:
+struct vfio_device *_vfio_alloc_device(size_t size, struct device *dev,
+ const struct vfio_device_ops *ops)
-:189: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_struct' - possible
side-effects?
#189: FILE: include/linux/vfio.h:147:
+#define vfio_alloc_device(dev_struct, member, dev, ops)
\
+ container_of(_vfio_alloc_device(sizeof(struct dev_struct) +
\
+ BUILD_BUG_ON_ZERO(offsetof(
\
+ struct dev_struct, member)),
\
+ dev, ops),
\
+struct dev_struct, member)
-:189: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'member' - possible
side-effects?
#189: FILE: include/linux/vfio.h:147:
+#define vfio_alloc_device(dev_struct, member, dev, ops)
\
+ container_of(_vfio_alloc_device(sizeof(struct dev_struct) +
\
+ BUILD_BUG_ON_ZERO(offsetof(
\
+ struct dev_struct, member)),
\
+ dev, ops),
\
+struct dev_struct, member)
total: 0 errors, 0 warnings, 3 checks, 147 lines checked
df0991d343cd vfio/pci: Use the new device life cycle helpers
43ddd4b3b4eb vfio/mlx5: Use the new device life cycle helpers
-:21: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#21: FILE: drivers/vfio/pci/mlx5/main.c:584:
+ struct mlx5vf_pci_core_device *mvdev = container_of(
-:33: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
#33: FILE: drivers/vfio/pci/mlx5/main.c:596:
+
+}
-:37: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#37: FILE: drivers/vfio/pci/mlx5/main.c:600:
+ struct mlx5vf_pci_core_device *mvdev = container_of(
total: 0 errors, 0 warnings, 3 checks, 74 lines checked
e4bb5c47eaf7 vfio/hisi_acc: Use the new device life cycle helpers
f5c7d76e8b8f vfio/mdpy: Use the new device life cycle helpers
ac90d6a82ba1 vfio/mtty: Use the new device life cycle helpers
c3540147339d vfio/mbochs: Use the new device life cycle helpers
73067e42b2dd drm/i915/gvt: Use the new device life cycle helpers
-:155: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#155: FILE: drivers/gpu/drm/i915/gvt/vgpu.c:365:
+static int __intel_gvt_create_vgpu(struct intel_vgpu *vgpu,
struct intel_vgpu_creation_params *param)
total: 0 errors, 0 warnings, 1 checks, 197 lines checked
dd517d04b701 vfio/ap: Use the new device life cycle helpers
291765af61e2 vfio/fsl-mc: Use the new device life cycle helpers
910cf1cc7e4e vfio/platform: Use the new device life cycle helpers
1e4453d1c194 vfio/amba: Use the new device life cycle helpers
ce8562ac714a vfio/ccw: Use the new device life cycle helpers
45939f17c91c vfio: Rename vfio_device_put() and vfio_device_try_get()
212d729dc851 vfio: Add struct device to vfio_device
-:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#15:
> > > and replace kref. With it a 'vfio-dev/vfioX' node is created under the
-:48: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#48:
new file mode 100644
-:60: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 1 errors, 2 warnings, 0 checks, 8 lines checked
Re: [Intel-gfx] [RFC PATCH v3 08/17] drm/i915/vm_bind: Add out fence support
On Sat, Aug 27, 2022 at 09:43:54PM +0200, Andi Shyti wrote:
From: Niranjana Vishwanathapura
Add support for handling out fence of vm_bind call.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 3 +
.../drm/i915/gem/i915_gem_vm_bind_object.c| 82 +++
drivers/gpu/drm/i915/i915_vma.c | 6 +-
drivers/gpu/drm/i915/i915_vma_types.h | 7 ++
4 files changed, 97 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
index ebc493b7dafc1..d65e6e4fb3972 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -18,4 +18,7 @@ int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void
*data,
struct drm_file *file);
void i915_gem_vm_unbind_vma_all(struct i915_address_space *vm);
+void i915_vm_bind_signal_fence(struct i915_vma *vma,
+ struct dma_fence * const fence);
+
#endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 3b45529fe8d4c..e57b9c492a7f9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -5,6 +5,8 @@
#include
+#include
+
#include "gem/i915_gem_vm_bind.h"
#include "gem/i915_gem_context.h"
#include "gt/gen8_engine_cs.h"
@@ -109,6 +111,67 @@ void i915_gem_vm_bind_remove(struct i915_vma *vma, bool
release_obj)
}
}
+static int i915_vm_bind_add_fence(struct drm_file *file, struct i915_vma *vma,
+ u32 handle, u64 point)
+{
+ struct drm_syncobj *syncobj;
+
+ syncobj = drm_syncobj_find(file, handle);
+ if (!syncobj) {
+ DRM_DEBUG("Invalid syncobj handle provided\n");
+ return -ENOENT;
+ }
+
+ /*
+* For timeline syncobjs we need to preallocate chains for
+* later signaling.
+*/
+ if (point) {
+ vma->vm_bind_fence.chain_fence = dma_fence_chain_alloc();
+ if (!vma->vm_bind_fence.chain_fence) {
+ drm_syncobj_put(syncobj);
+ return -ENOMEM;
+ }
+ } else {
+ vma->vm_bind_fence.chain_fence = NULL;
+ }
+ vma->vm_bind_fence.syncobj = syncobj;
+ vma->vm_bind_fence.value = point;
+
+ return 0;
+}
+
+static void i915_vm_bind_put_fence(struct i915_vma *vma)
+{
+ if (!vma->vm_bind_fence.syncobj)
+ return;
+
+ drm_syncobj_put(vma->vm_bind_fence.syncobj);
+ dma_fence_chain_free(vma->vm_bind_fence.chain_fence);
+}
+
+void i915_vm_bind_signal_fence(struct i915_vma *vma,
+ struct dma_fence * const fence)
+{
+ struct drm_syncobj *syncobj = vma->vm_bind_fence.syncobj;
+
+ if (!syncobj)
+ return;
+
+ if (vma->vm_bind_fence.chain_fence) {
+ drm_syncobj_add_point(syncobj,
+ vma->vm_bind_fence.chain_fence,
+ fence, vma->vm_bind_fence.value);
+ /*
+* The chain's ownership is transferred to the
+* timeline.
+*/
+ vma->vm_bind_fence.chain_fence = NULL;
+ } else {
+ drm_syncobj_replace_fence(syncobj, fence);
+ }
+}
+
static int i915_gem_vm_unbind_vma(struct i915_address_space *vm,
struct i915_vma *vma,
struct drm_i915_gem_vm_unbind *va)
@@ -243,6 +306,15 @@ static int i915_gem_vm_bind_obj(struct i915_address_space
*vm,
goto unlock_vm;
}
+ if (va->fence.flags & I915_TIMELINE_FENCE_SIGNAL) {
+ ret = i915_vm_bind_add_fence(file, vma, va->fence.handle,
+va->fence.value);
+ if (ret)
+ goto put_vma;
+ }
+
+ pin_flags = va->start | PIN_OFFSET_FIXED | PIN_USER;
Setting pin_flags should part of patch #4.
+
for_i915_gem_ww(, ret, true) {
retry:
ret = i915_gem_object_lock(vma->obj, );
@@ -267,12 +339,22 @@ static int i915_gem_vm_bind_obj(struct i915_address_space
*vm,
ret = i915_gem_ww_ctx_backoff();
if (!ret)
goto retry;
+
Redundent white space. remove.
} else {
/* Hold object reference until vm_unbind */
i915_gem_object_get(vma->obj);
}
}
+ if (va->fence.flags & I915_TIMELINE_FENCE_SIGNAL)
+ i915_vm_bind_put_fence(vma);
+
+put_vma:
+ if (ret && vma) {
+
Re: [Intel-gfx] [RFC PATCH v3 07/17] drm/i915/vm_bind: Handle persistent vmas
On Sat, Aug 27, 2022 at 09:43:53PM +0200, Andi Shyti wrote:
From: Niranjana Vishwanathapura
Treat VM_BIND vmas as persistent across execbuf ioctl calls and handle
them during the request submission in the execbuff path.
Support eviction by maintaining a list of evicted persistent vmas
for rebinding during next submission.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 +
.../drm/i915/gem/i915_gem_vm_bind_object.c| 8 +++
drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 4 ++
drivers/gpu/drm/i915/i915_gem_gtt.c | 38 +
drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +
drivers/gpu/drm/i915/i915_vma.c | 50 +++--
drivers/gpu/drm/i915/i915_vma.h | 56 +++
drivers/gpu/drm/i915/i915_vma_types.h | 24
9 files changed, 169 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 389e9f157ca5e..825dce41f7113 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -38,6 +38,7 @@
#include "i915_gem_mman.h"
#include "i915_gem_object.h"
#include "i915_gem_ttm.h"
+#include "i915_gem_vm_bind.h"
#include "i915_memcpy.h"
#include "i915_trace.h"
Not needed, should be removed.
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 9ff929f187cfd..3b45529fe8d4c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -91,6 +91,13 @@ void i915_gem_vm_bind_remove(struct i915_vma *vma, bool
release_obj)
{
lockdep_assert_held(>vm->vm_bind_lock);
+ spin_lock(>vm->vm_rebind_lock);
+ if (!list_empty(>vm_rebind_link))
+ list_del_init(>vm_rebind_link);
+ i915_vma_set_purged(vma);
+ i915_vma_set_freed(vma);
+ spin_unlock(>vm->vm_rebind_lock);
+
if (!list_empty(>vm_bind_link)) {
list_del_init(>vm_bind_link);
list_del_init(>non_priv_vm_bind_link);
@@ -190,6 +197,7 @@ static struct i915_vma *vm_bind_get_vma(struct
i915_address_space *vm,
vma->start = va->start;
vma->last = va->start + va->length - 1;
+ i915_vma_set_persistent(vma);
This can be set in vma_create() now that it knows whether the vma
is persistent or not.
Niranjana
return vma;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index c4f75826213ae..97cd0089b516d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -296,6 +296,8 @@ void i915_address_space_init(struct i915_address_space *vm,
int subclass)
INIT_LIST_HEAD(>non_priv_vm_bind_list);
vm->root_obj = i915_gem_object_create_internal(vm->i915, PAGE_SIZE);
GEM_BUG_ON(IS_ERR(vm->root_obj));
+ INIT_LIST_HEAD(>vm_rebind_list);
+ spin_lock_init(>vm_rebind_lock);
}
void *__px_vaddr(struct drm_i915_gem_object *p)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 9a2665e4ec2e5..1f3b1967ec175 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -265,6 +265,10 @@ struct i915_address_space {
struct list_head vm_bind_list;
/** @vm_bound_list: List of vm_binding completed */
struct list_head vm_bound_list;
+ /* @vm_rebind_list: list of vmas to be rebinded */
+ struct list_head vm_rebind_list;
+ /* @vm_rebind_lock: protects vm_rebound_list */
+ spinlock_t vm_rebind_lock;
/* @va: tree of persistent vmas */
struct rb_root_cached va;
struct list_head non_priv_vm_bind_list;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 329ff75b80b97..f083724163deb 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -25,6 +25,44 @@
#include "i915_trace.h"
#include "i915_vgpu.h"
+/**
+ * i915_vm_sync() - Wait for all requests on private vmas of a vm to be
completed
+ * @vm: address space we need to wait for idle
+ *
+ * Waits till all requests of the vm_binded private objs are completed.
+ *
+ * Returns: 0 on success -ve errcode on failure
+ */
+int i915_vm_sync(struct i915_address_space *vm)
+{
+ int ret;
+
+ /* Wait for all requests under this vm to finish */
+ ret = dma_resv_wait_timeout(vm->root_obj->base.resv,
+ DMA_RESV_USAGE_BOOKKEEP, false,
+ MAX_SCHEDULE_TIMEOUT);
+ if (ret < 0)
+ return ret;
+ else if (ret > 0)
+ return 0;
+ else
+ return -ETIMEDOUT;
+}
+
+/**
+ * i915_vm_is_active() -
Re: [Intel-gfx] [PATCH 00/15] Tidy up vfio_device life cycle
> From: Jason Gunthorpe > Sent: Wednesday, August 31, 2022 8:35 AM > > On Sun, Aug 28, 2022 at 01:10:22AM +0800, Kevin Tian wrote: > > > Kevin Tian (6): > > vfio: Add helpers for unifying vfio_device life cycle > > drm/i915/gvt: Use the new device life cycle helpers > > vfio/platform: Use the new device life cycle helpers > > vfio/amba: Use the new device life cycle helpers > > vfio/ccw: Use the new device life cycle helpers > > vfio: Rename vfio_device_put() and vfio_device_try_get() > > > > Yi Liu (9): > > vfio/pci: Use the new device life cycle helpers > > vfio/mlx5: Use the new device life cycle helpers > > vfio/hisi_acc: Use the new device life cycle helpers > > vfio/mdpy: Use the new device life cycle helpers > > vfio/mtty: Use the new device life cycle helpers > > vfio/mbochs: Use the new device life cycle helpers > > vfio/ap: Use the new device life cycle helpers > > vfio/fsl-mc: Use the new device life cycle helpers > > vfio: Add struct device to vfio_device > > Other than my small remarks this all looked good to me - for every patch: > > Reviewed-by: Jason Gunthorpe > Thanks for the review!
Re: [Intel-gfx] [PATCH 15/15] vfio: Add struct device to vfio_device
> From: Jason Gunthorpe
> Sent: Wednesday, August 31, 2022 8:32 AM
>
> On Sun, Aug 28, 2022 at 01:10:37AM +0800, Kevin Tian wrote:
> > From: Yi Liu
> >
> > and replace kref. With it a 'vfio-dev/vfioX' node is created under the
> > sysfs path of the parent, indicating the device is bound to a vfio
> > driver, e.g.:
> >
> > /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0
> >
> > It is also a preparatory step toward adding cdev for supporting future
> > device-oriented uAPI.
> >
> > Suggested-by: Jason Gunthorpe
> > Signed-off-by: Yi Liu
> > Signed-off-by: Kevin Tian
> > ---
> > drivers/vfio/vfio_main.c | 70 +---
> > include/linux/vfio.h | 6 ++--
> > 2 files changed, 61 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> > index 0c5d120aeced..9ad0cbb83f1c 100644
> > --- a/drivers/vfio/vfio_main.c
> > +++ b/drivers/vfio/vfio_main.c
> > @@ -46,6 +46,8 @@ static struct vfio {
> > struct mutexgroup_lock; /* locks group_list */
> > struct ida group_ida;
> > dev_t group_devt;
> > + struct class*device_class;
> > + struct ida device_ida;
> > } vfio;
> >
> > struct vfio_iommu_driver {
> > @@ -524,11 +526,19 @@ EXPORT_SYMBOL_GPL(_vfio_alloc_device);
> > *
> > * Only vfio-ccw driver should call this interface.
> > */
> > +static void vfio_device_release(struct device *dev);
>
> Since you added this new function in patch 1, it would be nice to
> place it in a way that avoids this forward reference in this patch
>
> > ret = alloc_chrdev_region(_devt, 0, MINORMASK + 1,
> "vfio");
>
> I think we should change this "vfio" string at this point, it is
> really the group fd, so "vfio_group" ?
>
> It only shows in procfs.
>
All make sense and fixed.
